[kodablah]

> you can trust in TLS when you’re downloading signed software too; but for the web, you only trust in the connection, there’s nothing else to save you if you can’t trust that connection.

While Signed HTTP Exchanges were originally developed for a more nefarious purpose (to allow the URL to be changed by a trusted proxy), I think the idea or one like it can apply to serving trusted web content. Think of it as instead of your current TLS cert verifying your host, it would also verify the full URL and content including headers. It's a bit untenable for regular use, but some apps could leverage it for extra trust.

> When designing E2EE protocols for persistent vs ephemeral applications, we need to figure out where we need long-term identity in terms of cryptographic keys, and where we don’t.

I would hope that web apps always lean towards ephemeral key use whenever possible (i.e. key generation and post of public key in browser upon authentication, with private key only in local JS memory for just that page). If this means the webapp has to be built to work with 20 different keys for a user because they opened 20 tabs, so be it. I know people are afraid of doing anything like key generation in the browser, but we can't ride-off the possibility of e2ee web apps altogether. I fear the browser allowing access to the OS's key management or the system's TPM for key storage because it may lead to overuse/over-reliance on long-term keys, but I'm sure it'll happen if it hasn't already.

[dane-pgp]

I'm hopeful that Signed HTTP Exchanges lead to what you describe, but another Chrome-originating technology that could be extended/abused to achieve a similar goal is the <portal> tag.

There is already a little trick[0] that can be done with bookmarklets (or locally saved files) which allow you to bootstrap a page with a known set of JavaScript code running on it, but it has the disadvantage that the URL bar doesn't contain a familiar domain. If the <portal> spec[1] ends up supporting SRI[2] integrity hashes in a sensible way, this little bootstrapping technique could actually be practical.

[0] https://news.ycombinator.com/item?id=17776456

[1] https://wicg.github.io/portals/

[2] https://www.w3.org/TR/SRI/

[the8472]

Combine SRI with CSPs and cache-control: immutable and you could already commit a page to never change. All that's missing for TOFU is fingerprinting this combination, watching for changes and surfacing the information to the user.

[lisper]

Unfortunately that by itself does not guarantee security. The code that is verified by the bookmarklet could download additional code when it runs, and that code would not be verified.

[the8472]

No, preventing that would be the CSP's job.

[lisper]

My point is that verifying that the content doesn't change is by itself not enough. You also have to verify that it was secure to begin with, and that is much harder, especially for your typical end-user.

[the8472]

That's a separate problem to solve. But for audits to even make sense you first need to solve the problem of sites changing under your feet, i.e. enabling TOFU.

[AlexCoventry]

> Signed HTTP Exchanges

Has anyone compiled a list of sites which offer Signed HTTP Exchanges/Real URL AMP feeds? Is there a straightforward way to make one?