Use integrity hash as cache identifier

[Munter]

When using subresource integrity hashes to verify the content of downloaded script and style assets, could the integrity hash be used as an additional cache identifier with higher priority that the url?

Since the SRI specification already defines a way to upgrade to a better hash function in case the used hash algorithm is broken and outdated, it should be safe enough to assume that these hashes can uniquely identify content regardless of URL.

In such a cache identifier regime these use cases could result in cache hits:

• Visitor has a cached jquery 2.2.3 from https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.3/jquery.min.js and visits a page that use the same version of jquery with the same integrity hash, but from a different CDN provider that the browser hasn't seen yet. The user gets a cache hit.
• Visitor has a cached jquery 2.2.3 from https://cdnjs.cloudflare.com/ajax/libs/jquery/2.2.3/jquery.min.js and visits a page that use the same version of jquery with the same integrity hash, but from the hosts own domain. The user gets a cache hit.

Obviously this makes maintaining the browser cache slightly more complex, as it will need to maintain two indexes for the same content.

If this idea gets implemented in the spec it might be beneficial for the browser to always calculate an integrity hash for third party scripts/styles in order to add the hash to the integrity cache. This should then be done in a non-blocking manner when the browser is idle or similar.

I don't have any experience with writing specs, and have tried for the last few days to wrap my head around the fetch spec, with limited success. I don't feel capable to write the proposal myself, but I'm hoping some experts can weigh in here and highlight the parts I haven't thought about.

[annevk]

You're always welcome to join https://wiki.whatwg.org/wiki/IRC and ask any questions you might have. Depending on the time of day someone might be able to help you out.

As for identifier-based caching, the problem is that this exposes, across origins, which resources you have visited. w3c/webappsec-subresource-integrity#22 has more details and pointers on this.

Given that, I'm going to close this issue. It's best if this is first worked out within the subresource integrity community. Hope that's acceptable.