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?

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?

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!]

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.