Hacker News Reader

Comment by seveneightn9ne | Hacker News Reader

How is this using end-to-end encryption? It seems like the recipient just clicks a link to download. How can it have been encrypted for that person? end-to-end encryption normally means that there's no way for the intermediary to unencrypt the data but I can't see how that's possible in this case.

View on HN

IIRC The link contains an anchor `#abc123` which is the decryption key. Browsers do not send anchor parts of the URL to the server, and so the browser decrypts.

Hinges on the browsers never sending that key, though.

Client side JavaScript that encrypts locally befor uploading and puts the encryption key in the url you share with someone that never gets sent to Mozilla. Also client side decryption on the person you shared the link with. It’s end to end.

With the caveat about client side browser encryption in general, which I'm sure someone will pop in here and explain in detail. :)

The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files.

If you want, you can also set a passphrase on the file to share via another channel

That's why the key is in the hash part of the URL; the server can't access that (unless it also sends client Javascript that parses it and sends it back to the server, but that could be detected).

What if I'm on a network I don't trust? Is the only option to set a passphrase? More importantly, the UI doesn't call this out explicitly, so uninformed users may think it's "secure enough" without a passphrase.

The anchor hash/fragment (#hello) isn't sent over the network.

https://tools.ietf.org/html/rfc3986#section-3.5

"(...) the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme."

Ed: as for an untrusted network, tls should be able to secure that. Except if the network owner can insist on/enforce a tls stripping mitm/proxy.

The browser will never send the key across the network by itself because it is in the fragment. Of course, you have to get the url with the fragment off your computer and to the intended recipient, so a MITM of this communication could intercept and download the file before the intended recipient. The intended recipient would know that this has happened, though, as the link will then be expired (assuming it was set to 1 download); if this is a fear, I would suggest adding a passphrase and sending the passphrase out of band, for example over a voice call.

> The url effectively contains the decryption key, so the web server could be set to capture the urls and decrypt files.

If that's the case, I think setting a passphrase should be mandatory. Proxy servers are extremely common at every workplace. Since they probably log all requests, they will capture all keys in the URL.

The key is in the fragment and thus is not sent to any server.

Reply on news.ycombinator.com