[jupenur]

This is great. I feel like E2EE has slowly fallen out of focus in recent years as the tech has stabilized, but important developments like this and the MLS standardization still continue to happen.

One specific area where I'd love to see more focus and attention is the web as a platform for E2EE applications. Currently, because of the inherent problems related to application delivery and trust relationships on the web, every step forward in E2EE adoption is a step away from webapps being first-class citizens -- even as PWAs keep becoming more viable for a wider range of use-cases otherwise. Even though an increasing number of companies maintain web implementations of their E2EE apps, these are always the fallback option when nothing "better" is available; the tech to make E2EE secure in webapps doesn't exist yet, but companies also have a unrelated incentives to push users to native apps. There are no serious efforts to remedy the situation and develop tech that would make it possible to deliver secure E2EE through the web.

The post mentions a couple of relevant goals:

> 3. Control over endpoints

> 8. Third-party scrutiny

They also mention the Code Verify extension[1], which may seem like a solution, but does not stand up to scrutiny: It only notifies the user of unexpected changes in the app, but does not prevent them. The detection logic it implements also seems trivially bypassable, and in more ways than one. Even if it was sufficiently enforcing application integrity, an extension like Code Verify is unlikely to ever become widely-adopted enough to make a dent. And of course it's not even available in all browsers on all host platforms.

There are also other similar extensions that suffer from similar shortcomings.

Browser vendors could solve the problem by providing APIs that allow the kind of integrity enforcement needed, akin to SRI[2], but that would mean you first have to agree on a standard and then implement it consistently everywhere and then webapps could slowly start adopting it. And because of past failures like HPKP[3], browser vendors would probably be hesitant to even start considering anything like it.

I believe a solution is possible using only the currently available web APIs, however, and for the past few months I've been prototyping something that's now at a stage where I can call it functional. The general idea is that using service worker APIs and a little bit of cryptography, a server and a client application can mutually agree to harden the application instance in a way that the server can no longer push new updates to it. After that, the client application can be inspected manually with no risk of it changing unannounced, and new versions of the app can be delivered in a controlled way. While my prototype is nowhere near production-grade at this point, it's nearing a stage where I'll be able to publish it for public scrutiny and fully validate the concept. Until then I'll be implementing tests and examples, documenting the API and threat model, and smoothing out the rough parts of the code.

If anyone's interested in collaborating on this or just hearing more details, feel free to reach out. I'd love some early feedback before going fully public.

[1] https://engineering.fb.com/2022/03/10/security/code-verify/

[2] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

[3] https://developer.mozilla.org/en-US/docs/Glossary/HPKP

[Ajedi32]

I've actually been thinking quite a bit about this very issue. As it stands, it's not really possible to do E2E encryption on the web in a secure way, since the server can always just silently update the client side code for a particular user to steal any encrypted data. I'm kind of curious about what you're doing with service workers to lock the server out of being able to update its own client side application. That sounds almost like a bug.

My ideal solution to this problem would be Web Bundles[1] signed by the server's TLS key[2], combined with Binary Transparency[3] to make targeted attacks impossible to hide (and maybe independent Static Analysis[4] to make attacks impossible to carry out in the first place), but work on many of those standards seems to have died out in the last few years.

[1]: https://wpack-wg.github.io/bundled-responses/draft-ietf-wpac...

[2]: https://datatracker.ietf.org/doc/html/draft-yasskin-http-ori...

[3]: https://datatracker.ietf.org/doc/html/draft-yasskin-http-ori...

[4]: https://datatracker.ietf.org/doc/html/draft-yasskin-http-ori...

[jupenur]

I've looked at web bundles and a variety of other solutions myself, but the service worker approach feels like a winner so far. There's no magic, nor any bug being abused, but the client does have to trust the server to behave nicely during initial setup. After the initial setup is done, the client never again has to trust the server again as long as the browser's local storage isn't purged manually; so if the server is compromised after the initial setup, the compromised server cannot compromise established clients. It's not perfect, there's still the need for initial point-in-time trust, but it's still a significant improvement on the standard way of serving webapps where a server can compromise any client at any time.

The way it works is the server returns a unique service worker script every time, and the script file itself contains an AES key. The user trusts the server not to store this key and the server never sees it again. This AES key is then used to encrypt all persisted local state and sign all cached source files. If the server replaces the service worker, the key is lost and local state cannot be accessed. If the server somehow replaces a source file, its integrity check will fail and the webapp will refuse to load it. If the server manages to skip the service worker and serve a malicious file directly (e.g. because the user did Shift+F5), the malicious file won't have access to any local state because the service worker will refuse to give it access. The server can destroy all local state and then serve a malicious application, but the user will immediately notice, hopefully before interacting with the app, because suddenly all their data is gone.

[Ajedi32]

That's really clever! Fixes the "silently" part at least, though given that most applications typically require frequent updates and that this doesn't prevent targeted attacks, I'm not sure how useful it is in practice, at least for mainstream applications.

Signed web bundles with binary transparency and independent review would be far superior, if they actually existed. (Which sadly, they don't right now.)

[jupenur]

Thanks! Automatic updates are still possible; you can implement a code signing-based flow on top of this, or fetch hashes from GitHub releases, or anything, really. Attacks are only possible during setup, and targeting at that point in time is difficult because the client won't have authenticated yet. Anything else (attacks that rely on clearing the local state) can be mitigated using careful UI design.

[jupenur]

The big problem with transparency logs is that they can't prevent attacks in real time because of the merge delay. You'll only find out afterwards if you've been attacked. It significantly raises the bar for an attack, but can't stop one from happening.