W3C home > Mailing lists > Public > public-webappsec@w3.org > October 2014

Re: [integrity] content-addressable cache?

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
Message-ID: <1517818770.16192052.1412607791412.JavaMail.zimbra@mozilla.com>
> 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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:07 UTC