Subresource integrity for cache content verification

[crisperdue]

Examples in the document show issues with pure content-addressable browser caches. Existence of such a cache can affect interactions with servers at arbitrary origins and result in leaks of information to outside parties.

In some examples the third party can detect that a resource from another origin has already been loaded into the user agent because it is not requested.

An example is also given where the URL given for a resource can be deceptive, since content in the cache is looked up only by the subresource integrity metadata and not by the accompanying URL.

Another design option

All of these issues can be remedied by using the SRI metadata in the user agent only for verification that the desired content is already in the cache. (This in addition to its role of verifying that the resource has not been tampered, e.g. in a CDN.) The cache is addressed by the URL, but the user agent compares the SRI metadata of the request with the content already present, and the cache is used if and only if they match. (Some special cases such as "hard reload" may still ignore the cache.) In the very common case where most resources in the cache are valid, this can still eliminate a great many costly network roundtrips that would otherwise result in 304 response codes.

Perhaps this option is well-known to the participants in the original discussion, but I do not see it referenced elsewhere. If it is known and perhaps even being pursued elsewhere, I would be very interested to learn.