purplehat_

i'm trying to understand how outer shell works here. on the website you give the following as your motivation:

> Apps like Jupyter and Tensorboard are not typically visible to standard web browsers if they’re running on remote servers, because it would be terribly unsafe to let the whole internet touch this app. Instead, they run on a local port on the server, which your computer can’t access directly.

> Classically, to get access to these, you had to open a new terminal and run:

> ssh -L 24601:localhost:8889 [email protected] &

> ssh -L 24602:localhost:6006 [email protected] &

is this true? isn't the normal thing just to do this ssh forwarding for prototyping, then for deployment, you set up a website like myjupyternotebook.com, and then set up auth so that others can't access it. HTTP basic auth is not too much work.

if you want SSH, not HTTP, to be what's publicly exposed, there's other options too, like putting it behind a VPN or tunnel.

all this to say, outer loop is super cool, but I don't get it. I must be missing something about why you built it, so could you help me understand?

On Being the Right Size turned 100 this year. It's not entirely the same topic as this essay, but this reminded me of it and it's a pretty famous short essay that's worth reading if you haven't seen it.

https://teaching.hkaiser.org/fall2025/csc7103/course/papers/... (PDF 50 KB, 5 pages essay + 3 pages commentary)

Cool find and a very interesting analysis!

There's a lot more to morphology than just the shape of the shell, and indeed the shape can sometimes be misleading, in that very different species can have somewhat similar shells, and different individuals of the same species can have quite different shell shapes. You've got a gasteropod, so it would be good to pay special attention to the peristome and siphonal canal (based on the bio classes I took in the area, I'm no expert) but of course there's lots of features that could be helpful in an identification.

https://en.wikipedia.org/wiki/Gastropod_shell#Parts_of_the_s... is a good list, and maybe you've already done this but you would want to find a dichotomous key of gasteropod families native to the area to narrow it down. Good luck in figuring out your shell!

The first bit seems possibly solvable with private set intersection. You can publish a salted hash of everybody you trust, and I can compute hashes of everyone I trust with your salt to see if we have anyone in common. Then I check the signature corresponding to the salted hash I like, and hopefully it doesn't reveal anything you don't want to reveal.

I don't know if anyone has actually done this in practice. Does it work?

For people reading this, you may want to know the the NSA is allegedly trying to weaken hybrid ML-KEM and X25519 down to just ML-KEM. This is a good thing to pay attention to!

Here is a 6-part article about the topic: https://blog.cr.yp.to/20251004-weakened.html

I believe ML-KEM is the standard algorithm for post-quantum asymmetric encryption. I think it's slower mainly because there's not good hardware support, but it shouldn't be a big deal because most encryption is hybrid where you only use the asymmetric crypto briefly to share a secret you can use for symmetric cryptography.

ML-KEM based on a lattice problem called "Learning With Errors", and there are similar lattice-based algorithms which have no known quantum speedup. Most traditional asymmetric encryption algorithms are based on number-theoretic assumptions like the discrete logarithm problem or the RSA assumption, which are broken by Shor's algorithm.

Symmetric cryptography (AES and SHA hash functions) are post-quantum resistant for now. Grover's algorithm technically cuts their asymptotic security in half, but that doesn't parallelize, so practically there is no known good quantum attack, and cryptographers and standards agencies tend to not worry about that. You can keep using those.

[edit: according to the sister comment posted simulataneously ML-KEM is faster than X25519. good to know!]

This article, "Factoring is not a good benchmark to track Q-day", was posted this month by one of Cloudflare's lead post-quantum researchers specifically addressing the factoring issue.

https://bas.westerbaan.name/notes/2026/04/02/factoring.html

It doesn't say much by itself, but it has four very good links on the subject. One of these has a picture of the smallest known factor-21 circuit, which is vastly larger than that of the factor-15 circuit, and comparable to much larger numbers. Another is Scott Aaronson's article making the analogy of asking factoring small numbers as asking for a "small nuclear explosion" - if you're in 1940 and not able to make a small nuclear explosion, that doesn't mean you're much farther away from a big nuclear explosion.

I'm surprised people are advocating self-hosting as a viable solution. It takes a lot of knowledge to do sync and backup yourself, most of it implicit knowledge that people here don't realize we have and so for us it seems very easy.

There was a comment in another post on the front page about how anyone "remotely technical" can set up a docker container, and I think this is a good example because the mechanics of it are simple (edit a couple text files, run a couple commands), but half the world couldn't tell you what a terminal is and they're focused on other things in life instead of learning how computers work. Cloud succeeded because cloud is easy (at least in the beginning), it's that simple.

If we are to solve this problem, we're going to have to make self-hosting easy enough for the average 7-8 year old to do it without struggling. One promising way forward is with local-first E2EE sync and backup. The only good implementation I know of personally is Obsidian Sync, which has a UX that I adore, and hope to see more of in the future. There's other good options too, but none that I'd feel comfortable trusting a seven-year-old to execute correctly first try.

what's the advantage of a static site generator over pandoc + makefile?

Hi Matt, there's lots of speech-to-text programs out there with varying levels of quality. 100% local is admirable but it's always a tradeoff and users have to decide for themselves what's worth it.

Would you consider making available a video showing someone using the app?

Have you (or anyone reading this) been able to "beat" fingerprint.com without Tor or turning JavaScript off outright?

I've tried it various times over the last couple years, using different browsers with various privacy settings enabled and a VPN.

I can get good partial results and am able to reset my fingerprint by changing my OS and browser at the same time, so it's not entirely there with regards to sniffing the hardware. But I can never revisit the site and have it not recognize me. Is there no one but me using (for example) Debian testing Librewolf with resistFingerprinting on Proton VPN? If there are others, then resistFingerprinting is doing a bad job hiding my hardware.

That's depressing! Despite our genuine best efforts, enough identifiers leak that it seems to me there's no practical solution. I am genuinely at a loss for what we can do.

(If you're reading this and think it doesn't matter, it's possible you're not realizing that this means that any site collecting and storing these identifiers now will be able to talk to any site in the future and link your identity. Your past actions on every website on a given piece of hardware are liable to be linked to create a detailed profile in the future, so even if Reddit and Pornhub and Discord and the government aren't talking to each other now, you can put some decent probability in the fact that if they decided to share identifiers, they could link all your historical (signed out) activity to your real-world identity without much effort. I use those sites as examples because they're sites where people tend to generate information that they may want private, but they visit using the same hardware identifiers.)

Fair point, but that solution doesn't address the market for theft, so there's a tradeoff there.

Can you elaborate on "fairly well documented exploit tactics"? My impression is that most of these are either social engineering, for which we need to hire better designers, or complicated chains of hard-to-find primitives only accessible to state actors.

There's definitely problems but the solution isn't to make the iPhone a general purpose computer. We definitely need to defend the existence of general purpose computing at a time where regulation is likely to begin encroaching on it, but the promise of the App Store is "pay a 30% tax and any app you download here will be safe." In my mind, at least, that's the promise, and perhaps one solution to the situation would be to erect consequences to breaking that promise.

I really don't understand the argument here. That the product is locked down by design is a feature, not a limitation.

Yes, this has the side effect of making them more money and allowing a walled garden to form, but given that the vast majority of users wouldn't do anything different with their phones if a shell was present, this is in my opinion not that large of an effect.

The snide around "clicking on links is dangerous" and locking down the bootloader is unwarranted, because for most people a phone is not a toy (or at least, not just a toy) - it has their communications history, their bank information, their passwords, any many more. And it's really easy to steal people's phones on the subway. This isn't about freedom of computing, this is about the fact that an iPhone in BFU is nearly as secure as a GrapheneOS phone.

There are many problems with Apple software. It's buggy, uses proprietary formats that you can't export, and interoperable with open standards. It's bad, and is the primary reason why I won't buy another iPhone, but Macs have that same problem. On the other hand, being cryptographically locked-down is an optional feature. If you don't like it, buy a computer without that feature. It's harmful to us, to tinkerers and people who want to see how things work, but the average person does not care at all and just wants to be able to open LOVE-LETTER-FOR-YOU.TXT.vbs without having their 401k get drained.

I'm not sure anyone is being this explicitly malicious. Parents' groups, child safety organizations, and researchers have been at this for years, and while I agree with you that the solutions are very misguided, I think it does our own priorities a disservice to stick our fingers in our ears with regards to their concerns.

Can you give an example of how less private solutions will benefit them and their sponsors? I could see big tech / adtech and government surveillance benefitting but I don't think they're the ones behind this push.

As another example, consider the "small web" community, say at Bear Blog, which is a group of technically sophisticated people who routinely complain about the harms of traditional social media. I doubt most of them would support this particular implementation, but they show that there is popular support for solving the ills of at least one of the targets of this legislation.

So to answer your question, yes, I do see this as an attempt to protect people. The restriction of free speech is in my opinion a side effect of this legislation opening the way to worse-designed laws in the future.

there is a `theme set` command

I'm surprised zero-knowledge proofs have not been mentioned. This is a technique where (for example) the government signs your digital license, then you can present a proof that you are over 18 to a site without revealing anything else about yourself. ZKPassport exists, Privacy Pass is an implementation being standardized by the IETF, and Google is working on a similar implementation. Granted, these are not yet widely used, but I'd be very interested in hearing HN's thoughts on this.

Let's try to figure out what a good policy solution looks like:

- entities with harmful or adult content must require proof of the user being over 18

- entities cannot ask for, store, or process more detailed information without explicit business needs (this should be phrased in a way that disallows Instagram from asking for your birth year, for example)

- entities cannot share this data with other sites, to avoid privacy leaks, unless there is an explicit business need (this is tricky to get right; someone might try to set up a centralized non-anonymous age-verification service, erasing many benefits)

- entities must in general not store or process information about the user that is not strictly relevant to their function

- there ought to be different treatment for anonymous users (which ideally these protocols will allow, just submit proof of work plus a ZKP that you are a human and authorized to access the resource) compared to pseudonymous and non-anonymous users, who are more at risk of being censored or tracked.

There's some loopholes here, but if the government can enact good policy on this I personally think it's feasible. Please share your thoughts, if you have a minute to do so.

There's also an interesting political split to note among the opposition here. I see a lot of people vehemently against this, and as far as I can see this is largely for concerns regarding one of 1) privacy abuses, 2) censorship, or 3) restriction of general computing. Still, there is a problem with harmful content and platforms on the web. (Not just for minors, I don't think we should pretend it doesn't harm adults too.) The privacy crowd seems to be distinctly different from the computing-freedom crowd; the most obvious example is in attitudes towards iOS. As I personally generally align more towards what I perceive as the privacy-focused side, I'm very interested in what people more focused on software freedom think about zero-knowledge proofs as a politically workable solution here.

The quote seems to imply that if the watch receives the payload from any source, even without a compromised AP, it'll pop the shell.

The easiest source of this is local network attacks, and it's not that unusual. In this case you could imagine a teacher at school who knows how to use Metasploit.

It doesn't seem like it has to be local network, though, the computer just has to receive the packet somehow. So for example if the watch loads a website or connects to some service on the internet (firmware updates, cloud sync, telemetry, whatever), an attacker could try to receive/intercepts/redirect that traffic and serve the payload through that channel.

You might need the watch has no certificate pinning or weak certificate validation if it's using TLS but IoT devices often skip TLS.

Let me know if I'm misunderstanding the quote.

Yes, to self-host it you will need a Google maps API key.

In the related links at the bottom, https://gdir.telae.net/links.html, the Git repo https://github.com/pafoster/gdir.telae.net is available along with some other cool things.

Omega-3 good, Omega-6 bad has been known for many years.

For example, Scott Alexander wrote in 2014 on his blog Slate Star Codex about how Omega-3 lowers crime rates and Omega-6 increases crime rates. And he links to some cool RCTs where you can check the methodology yourself.

https://slatestarcodex.com/2014/02/18/proposed-biological-ex...

Eat your fish!

To be fair, the octet as the byte has been dominant for decades. POSIX even has the definition “A byte is composed of a contiguous sequence of 8 bits.” I would wager many software engineers don't even know that a non-octet bytes were a thing, given that college CS curricula typically just teach a byte is 8 bits.

I found some search results about Texas Instruments' digital signal processors using 16-bit bytes, and came across this blogpost from 2017 talking about implementing 16-bit bytes in LLVM: https://embecosm.com/2017/04/18/non-8-bit-char-support-in-cl.... Not sure if they actually implemented it, but that was surprising to me that non octet bytes still exist, albeit in a very limited manner.

Do you know of any other uses for bytes that are not 8 bits?

I hear sentiment like this occasionally and I genuinely wonder if this is conspiracy theory stuff or if this sort of thing actually happened in the past.

I'm aware of the programs Snowden revealed, Tempora / XKeyscore / Longhaul / the like, plus I've heard J. Edgar Hoover did bad things and lots of CIA meddling internationally was bad. Still, these seem qualitatively different to the explicit blackmail you're referring to.

Do you (or someone else reading this) know of historical examples that demonstrate a pattern of this sort of thing? You can interpret "this sort of thing" as you wish.

That's a lot to ask for on the spot, so if not, I would be interested in what generally makes you approach the situation from this cynical angle, especially given that it's the FBI. In my experience, which is fairly limited but is as a US citizen, most of the time the US government mostly follows the law and doesn't do this sort of thing to citizens.

For anyone else who got a little too excited at the title, ECC here is error correction codes, not elliptic curve crypto.

Very cool writeup, thanks for digging into all those data sheets and sharing it with us! I feel like the hands-on electronics stuff has always been a little bit inaccessible to me, but posts like these always make me a little more excited to start doing little projects myself. So thanks for posting.

Why do you say that?

Bubblewrap is a it's a very minimal setuid binary. It's 4000 lines of C but essentially all it does is parse your flags ask the kernel to do the sandboxing (drop capabilities, change namespaces) for it. You do have to do cgroups yourself, though. It's very small and auditable compared to docker and I'd say it's safer.

If you want something with a bit more features but not as complex as docker, I think the usual choices are podman or firejail.

Thanks for linking to the essay. I just read it and really enjoyed it. I think I'll try to put the ideas into practice in my writing (and hope I'll succeed).

That's really funny. Yes, in case it wasn't clear for others reading this and thinking about installing these, it's almost certain that uBlock Origin and Brave browser will not cause you any problems and if you're using stock Chrome I really encourage you improve your situation dramatically for ~5 minutes worth of effort.

I often see things like this and get a little bit of FOMO because I'd love to see what I can get out of this but I'm just not willing to upload all these private documents of mine to other people's computers where they're likely to be stored for training or advertising purposes.

How are you guys dealing with this risk? I'm sure on this site nobody is naive to the potential harms of tech, but if you're able to articulate how you've figured out that the risk is worth the benefits to you I'd love to hear it. I don't think I'm being to cynical to wait for either local LLMs to get good or for me to be able to afford expensive GPUs for current local LLMs, but maybe I should be time-discounting a bit harder?

I'm happy to elaborate on why I find it dangerous, too, if this is too vague. Just really would like to have a more nuanced opinion here.

I've tried a few times to convince people in my life who would self describe as "bad with computers" to download an adblocker, but they usually find the friction too high. Adding extensions is unfamiliar for most, and even if it seems very basic for us, the non-tech people I know don't really want to deal with the risk of unknown unknowns from that, let alone switching to a healthier browser. (Perhaps reasonable since it feels like these days half the extensions on the Chrome Web Store are spyware or adware behind the scenes.)

I also suspect that those who lived through the days of frequent Windows errors and Chrome running out of memory all the time often expect software to fail in weird and unexpected ways, and a lot of people adopt a "don't fix it if it isn't broken" mindset.

Still, uBlock Lite and Brave browser are definitely easy wins and I'm glad to see more random people in my life using them than I would have expected. :)

Thanks for sharing this!!

I like using silly fonts, e.g. Comic Sans Mono has been my daily driver for the past year or so, and it's really fun to see the Minecraft fonts and old DOS and VT323 fonts. If anyone's into retro computing, it's worth checking those out, particularly the website link for the IBM VGA 9x16, which has loads and loads more old fonts.

I think I'll try using Monocraft in the shell for a while and see if it works well for me, though I might stick to Comic Sans for actual coding :)

The Forbes link unfortunately doesn't say much about how it works. This link does a little better:

https://github.com/Ashwesker/Blackash-CVE-2025-48633

The text there:

                  ┌──────────────────────────┐
                  │   Attacker (C2 Server)   │
                  └────────┬─────────────────┘
                           │ 1. Delivers malicious APK
                           │    (phishing, fake app store, drive-by)
                           ▼
  ┌─────────────────────────────────────────────────────┐
  │                Victim's Android 15 Phone            │
  │  (Security patch < 2025-12-01 → still vulnerable)   │
  └─────────────────────────────────────────────────────┘
                           │
            ┌──────────────┴──────────────┐
            ▼                             ▼
     User installs & opens       Malicious app runs in background
     "Fake Game / Tool" APK      (no permissions needed for this CVE)
            │
            │ 2. App triggers vulnerable Framework API
            │    (crafted Intent / Binder transaction)
            ▼
     ┌───────────────────────────────────┐
     │   Android Framework (buggy)       │
     │   code in Parcel/Binder handling) │
     └───────────────────────────────────┘
            │
            │ 3. Information Disclosure occurs
            │    → Sensitive data leaked without user interaction
            ▼
     Leaked data examples:
     • Device ID / IMEI
     • Installed app list
     • Account tokens
     • Contacts / SMS snippets
     • Clipboard content
     • Location history fragments
            │
            │ 4. Data silently sent back
            ▼
     ┌───────────────────────────────────┐
     │   Attacker receives stolen data   │
     → Can be sold, used for             │
     └───────────────────────────────────┘        spying, or chained with
                                             other exploits (e.g. CVE-2025-48572)