Improving the Trustworthiness of JavaScript on the Web

It doesn't seem like there's much difference in the trust model between E2EE web apps and App Store apps. Either way the publisher controls the code and you essentially decide whether to trust the publisher or not.

Perhaps there's something here that affects that dynamic, but I don't know what it is. It would help this effort to point out what that is.

everyone gets the same version that sends your secure messages to another server? I'm impressed.

I'll actually argue that you're arguing exactly what I'm arguing :)

My comment near the end is that we absolutely need transparency - just that what we need tracked more than all the code ever run under a URL is that one signing key. All your points are right: users aren't going to check it. It needs to be automatic and it needs to be distributed in a way that browsers and site owners can be confident that the code being run is the code the site owner intended to be run.

If they want to make a proposal, they should have httpc://sha-256;... URLS which are essentially constant ones, same as SRI but for top-level domains.

Then we can really have security on the Web! Audit companies (even anonymous ones but with a good reputation) could vet certain hashes as being secure, and people and organizations could see a little padlock when M of N approved a new version.

As it is, we need an extension for that. Because SRI is only for subresource integrity. And it doesn't even work on HTML in iframes, which is a shame!

<3 FWIW, I know Hacker News discussions often go stale after a bit and later responses might never be seen, and I don't really have time until later tonight to work on this (I used up my minutes earlier frantically reading this article to leave that other comment), so I thought I'd leave a quick comment here saying that I will be doing some further explanation in a comment here later tonight into what I thought is so interesting with cache manifests and some further thoughts viz-a-viz shared origins. (And, if you also happen to think any of my commentary is somewhat useful, I'd love to have a call or something with you at some point to talk about some of your vision for this work: I have a number of use cases for this kind of verification, and I think I was one of the more serious users of cache manifests back a decade ago.)

So, the other standard that relates to this is Signed HTTP Exchanges (which, I only, just now, learned that Cloudflare I guess decided to, also just now, withdraw support of, lol), and I think when you fit all of these together, and look at the existing practice from both Android and Web3, a really amazing possible vision starts to form.

AFAIK, the goal there was the idea that you should be able to implement stuff like a caching peer-to-peer proxy network in a secure manner, as you'd be able to prove that a response came from the official server... and, since that could have a Date header and associated cache control information, that it was even "up to date"/valid content.

The way this works is that the signed exchange is considered part of the origin that signed the exchange, rather than the origin from which you received it; this totally changes the game for distributing censorship resistant applications... except that I believe it all ends up tied back to the TLS ecosystem, to establish the correct key.

Essentially, what I've seen a lot of people want to do -- primarily very much in the decentralized crypto / Web3 ecosystem -- is to be able to have an application where the "server" is a blockchain (accessed via a commodity server that just tracks access to blockchain state), identity is handled by keys, and all data is in local storage...

...but the problem is: where do you get this app from? It ends up having to be on a random web host, and, even with separate wallets managed by browser extensions or even full hardware, you end up in a terrifying place if the server can keep modifying the app you are using as you are using it. This is like, your core use case for this! ;P

Only, these people are trying to simultaneously solve this: they don't want the site to be tied to the existing website infrastructure at all. If I disappear, you should be able to continue to use the website forever, as long as someone has a backup copy of it and they are willing to host it, which is similar to the signed exchanges case.

The closest we have for this currently is to host the app on IPFS, but: 1) the browser doesn't have a supported way to verify anything that comes from IPFS, so we are reliant on the security of some random proxy server (which we could run local, but it is super expensive); and 2) the only way to get updates re-exposes the original issue.

To me then, "table stakes" for any attempt to solve this problem has to cover this use case, as this is where I see the vast majority of people, today, actively trying to pull this off. In fact, with the exception of WhatsApp, the only people I've ever even heard of with a need for this right now are these people who are going all the way.

One way to approach this would be to try to stare at IPFS and figure out how to make it better, but I totally appreciate that that might be a lost cause: IPFS is extremely inefficient and intricate... what I feel we need is for a standard to be put forward that allowed for stuff on top of IPFS--or all competing mechanisms--to be compliant.

Like, the thing I actually want to be able to do is to host a website "out there somewhere", maybe on a bunch of mirror sites, maybe on IPFS, maybe in .zip files that people distribute on USB keys... just, somewhere/somehow, and then when they use that website it is considered just as secure as any other way that they might get the app.

This is how it works with Android apps, for example: no matter how I found the app, or an upgrade to the app (even if that upgrade came from a different path than how I got to the app originally), the app gets access to its private/secure storage on a user's device because of its identity, not because of the path by which I'd found the app.

And this is where the whole problem just starts sounding like the same thing that we were doing with app cache manifests: the ostensible reason those existed is that one would like to be able to download a full copy of a web application so you aren't using it on a train and suddenly realize you are missing some key file for it to operate.

What that means, though, is that the app cache manifest essentially becomes a bill of materials for an entire web app: with a link to just the app cache manifest, what you are able to do is download and "install" the app. (iOS then used this heavily for their personal web app install to homescreen flow, so you really downloaded the app.)

The mechanism also had a kind of atomicity to it, wherein it would download the entire new application and only switch to the new app as a single unified unit: either it had an updated copy of all of the files in the new manifest, or it is going to keep using the old app; once ready, a script event fired and you could notify the user to reload.

So like, in my mind, there is this amazing intersection ready to be found, wherein the goals of the app cache manifest and Signed HTTP Exchanges -- but with a root of trust that is more like an Android app than the TLS authorities -- are combined together to let the ecosystem trying to build decentralized peer-to-peer e2ee web applications.

And like, viewed from that perspective, the "more cryptographic material" that people need for their app is just the same thing as the signing key they'd use for an Android app, a concept that people built workflows around and I don't think is such a big lift: somehow, Android was fine, despite this being how it worked for a dozen+ years.

That said, I think that this still has a lot of value even if it is tied back down to the centralized hostname ecosystem, but what I like about HTTP Message Signatures (not Signed HTTP Exchanges) is that I think they have a trust root that is more like DANE, using a DNS entry to anchor the public key rather than tying it to a TLS certificate.

Regardless, in my perfect world, what I want is for all of these copies of the app that might exist in the world -- whether signed by the same key or tied back through Signed HTTP Exchanges to an underlying host (which, maybe some day, can be on a fully decentralized registrar) and a key furnished by DNS -- to share the same web origin.

And like, the reason I keep coming back to this, is because most of the people I have seen in the wild trying to solve this problem barely have a server at all and want to be able to write an application that entirely uses local storage and distributed hash tables or blockchains or even manual message passing to connect up, peer-to-peer.

But so, yeah: I've now spent a bunch more time typing a giant manifesto for a thing that you are already working on and I get that that is an awkward thing if the vision doesn't align at all (or maybe you are actively trying not to solve the use case of the people I keep pointing at)... but, if you do, I'd love to chat about this (a lot).

They specifically suggest using a blockchain for Tor:

> A paranoid Tor user may not trust existing transparency services or witnesses, and there might not be any other trusted party with the resources to self-host these functionalities. For this use case, it may be reasonable to put the prefix tree on a blockchain somewhere. This makes the usual domain validation impossible (there’s no validator server to speak of), but this is fine for onion services. Since an onion address is just a public key, a signature is sufficient to prove ownership of the domain.