[jmull]

It would be helpful if they included a problem statement of some sort.

I don't know what problem this solves.

While I could possibly read all this and deduce what it's for, I probably won't... (the stated premise of this, "It is as true today as it was in 2011 that Javascript cryptography is Considered Harmful." is not true.)

[miloignis]

For me, the key problem being solved here is to have reasonably trustworthy web implementations of end-to-end-encrypted (E2EE) messaging.

The classic problem with E2EE messaging on the web is that the point of E2EE is that you don't have to trust the server not to read your messages, but if you're using a web client you have to trust the server to serve you JS that won't just send the plain text of your messages to the admin.

The properties of the web really exacerbate this problem, as you can serve every visitor to your site a different version of the app based on their IP, geolocation, tracking cookies, whatever. (Whereas with a mobile app everyone gets the same version you submitted to the app store).

With this proposed system, we could actually have really trustworthy E2EE messaging apps on the web, which would be huge.

(BTW, I do think E2EE web apps still have their place currently, if you trust the server to not be malicious (say, you or a trusted friend runs it), and you're protecting from accidental disclosure)

[jmull]

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.

[fabrice_d]

On the web, if your server is compromised it's game over, even if the publisher is not malicious. In app stores, you have some guarantee that the code that ends up on your device is what the publisher intended to ship (basically signed packages). On the web it's currently impossible to bootstrap the integrity verification with just SRI.

This proposal aims at providing the same guarantees for web apps, without resorting to signed packages on the web (ie. not the same mechanism that FirefoxOS or ChromeOS apps used). It's competing with the IWA proposal from Google, which is a good thing.

[netdevphoenix]

> On the web, if your server is compromised it's game over, even if the publisher is not malicious. In app stores, you have some guarantee that the code that ends up on your device is what the publisher intended to ship (basically signed packages)

Not quite. It is possible for an account to be taken over or bought and a new update deployed. It is also possible for the server the app gets its data from to be taken over just like in your example and serve you fake data to make you regurgitate whatever data the malicious actor wants

[miloignis]

Sorry, I should have been more concise - the two big differences are:

1) everyone gets the same code

2) it doesn't change too quickly

This means you can (esp with reproducible builds) audit that the code is correct and know that everyone is getting the correct code, and that misbehavior will be identified.

[knowitnone3]

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

[CharlesW]

> I don't know what problem this solves.

This allows you to validate that "what you sent is what they got", meaning that the code and assets the user's browser executes are exactly what you intended to publish.

So, this gives web apps and PWAs some of the same guarantees of native app stores, making them more trustworthy for security-sensitive use cases.