- From: Mark Goodwin <mgoodwin@mozilla.com>
- Date: Mon, 6 Oct 2014 08:03:11 -0700 (PDT)
- To: Devdatta Akhawe <dev.akhawe@gmail.com>
- Cc: Frederik Braun <fbraun@mozilla.com>, public-webappsec@w3.org
> Currently, the spec tries to address this by requiring that resources > that can be content-addressed need to be publicly cacheable or open > via CORS. > see > http://w3c.github.io/webappsec/specs/subresourceintegrity/#is-resource-eligible-for-integrity-validation > > Wdyt? My apologies; I missed this section. Technically, I think a mechanism along these lines could work but, for caching, more detail is needed. It may be that integrity checks are allowed for the original on-domain use of that resource (on and for target.example.com in my example)... but if that same integrity value is used for content-addressing some cache later, what are the rules? Caching changes this from being about confidentiality of the resource to also being about confidentiality of the user's visit - it might be clear that private.js shouldn't be cached but we also need to make it explicit that unique.js is also tricky. > I am not sure why this counts as an opaque bug though. Maybe you can > clarify? It is roughly equivalent to the existing possibilities that you mention. The difference is that that, once the cache entries can come from other origins, it becomes more likely that a document with a resource that has never had a good src / integrity combination will appear to work fine for many users (including the developer), especially if it's a common library.
Received on Monday, 6 October 2014 15:03:40 UTC