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

Re: [integrity] content-addressable cache?

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Mon, 6 Oct 2014 07:34:13 -0700
Message-ID: <CAPfop_3n+Q+EAtNtqNoj8=8uZS1Jz3VcJNxbXdv+HOLg7Xgngw@mail.gmail.com>
To: Mark Goodwin <mgoodwin@mozilla.com>
Cc: Frederik Braun <fbraun@mozilla.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
> * By comparing the behaviour of visitors they can ascertain which visitors have also visited the target.
> We could, perhaps, mitigate this by denoting (e.g. in a response header - maybe via a new CSP directive?) which resources may be content-addressed off-domain (or maybe I've missed something).

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


> * User A visits the document with a cache that has a valid entry for the integrity attribute supplied (from visiting another site or, perhaps, a previous version of this document before a breaking change). The document behaves correctly in this case.
> * Another user, User B, visits the same document with no such cache entry (perhaps it's a first visit, or maybe the entry has expired). The user agent attempts to load the resource at the specified source and fails.

I am not sure why this counts as an opaque bug though. Maybe you can
clarify? It seems to me like a bug that will clearly marked in the
console as "integrity attribute did not match" or something like that
for user B. Additionally, if I am not wrong, a similar bug can also
exist today if a developer messes up the caching just right. And in
the latter case, there are no indicators in the console explaining
what went wrong, I believe.

Received on Monday, 6 October 2014 14:35:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:41 UTC