[jkire]

A similar idea is to allow pages to download static content over HTTP if they include the hashes of the content. Things like CSS and javascript need authentication so you know they haven't been tampered with, but don't necessarily require encryption. (The authentication here is from the fact you would download the page containing the hashes via HTTPS). Using this to download the global static content for a site doesn't even leak which individual page you were looking at.

On the other hand, it complicates things a lot without really giving much advantages. The only time I can think of where it might be useful is for using CDNs from a HTTPS site, without having to set up HTTPS with your CDN.

[theandrewbailey]

If you're concerned about things getting tampered with, encryption guarantees that it won't. With your suggestion of hashes + HTTP, if it is tampered with, the page silently won't work as intended. With hashes + HTTPS, loud errors happen when things are tampered with. And because it's static content, deliver over HTTPS once and cache the hell out of it.

[jkire]

> If you're concerned about things getting tampered with, encryption guarantees that it won't

Sure, HTTPS protects against tampering, but its not the only way. The parent comment seemed interested in ways of solving the same problem without the CPU overhead of encryption (whether this is a valid concern or not is a separate question).

In fact, hashes offer superior protection when loading resources via a CDN since you don't need to trust that the CDN won't tamper with things.

> With your suggestion of hashes + HTTP, if it is tampered with, the page silently won't work as intended.

Why? This would require browser support and it could whine about mismatched hashes as much as it wants.

---

I'm not seriously proposing that we should do this, but I find it interesting to think about the different ways that things can be done.