Anyhow, that might be a good place to contribute.
While browsers having an internal copy of various common scripts is a great idea, I was briefly working on a Firefox addon that would simply hard-caches any URL that matched some sort of criteria (e.g. regexp for "//ajax.googleapis.com/ajax/libs/.*\.js")
Unfortunately, the project is on hold for now. While it it was easy to match HTTP requests with an observer for 'http-on-modify-request', the nsIHttpChannel[2] object you get from that only seems to let you redirect the request. I considered trying to redirect to a "chrome:" or "file:" url, but that seem like a horrible solution. The real way to mess with HTTP loading and caching, unfortunately, is buried somewhere I have yet to find. :/
[1] or any other shared CDN, such as CloudFlare and their horrible hashed domain names
[2] https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/...
Right now there's nothing to stop a malicious CDN from changing the content of an included script on your site without you knowing it.
With a hash tag like this the browser could refuse to load the file or warn the user if it didn't match.
The question then is - how do you distribute the trusted hash?
Maybe there should be an independent organization or website that serves trusted hashes for common or registered libraries and files.
I'm just thinking of some libraries that could be security sensitive, and thus using latest releases on day 1 is the most important. I surmise these would also be the same libraries you would want to use this type of authentication on.
Then you create an entirely new, fragmented ecosystem like the current html and css web standards, adding more complexity and layers to front-end web development.
Best that the browsers stay agnostic in that regard.
All the browser companies are in a particularly good position to collect this information too.
It needs to be built into the browser because of issues like the one he was having.
The suggestion solves that issue by using hashes of the files, so it doesn't matter if they are loaded from a remote/CDN URL or from the same server, they will be considered cached by the browser (and loaded from cache) regardless once the hash matches.
> It turns out that many websites are loading content from Google’s CDN, or Facebook/Twitter APIs, which are blocked in China.
Using a hash would allow you to load them from any URL, including the blocked ones.
But, you know, you live in the US and your solution works for everyone in the US, so F everyone who doesn't.
good.com:
<script src="/js/site.js">
evil.com:
<img src="https://www.good.com/js/site.js">
Even things like NoScript don't stop that vector if you whitelist common CDN's like google's.
The only information you could have with this is that the browser already downloaded jquery from another website, that is not going to help that much.
One simple solution could be something like this:
<script type="text/javascript" src="/js/jquery.min.js" public="sha1:356a192b7913b04c54574d18c28d46e6395428ab">
This way the browser can have a look at the hash and not query the file at all. This could not lead to security issues since the hash saved by the browser is not the hash displayed but the one computed with the actual file. (and obviously you are only using the public attribute for scripts which are meant to be public).
With this technique, the most popular libraries could be cached and not downloaded by users.