Re: [integrity] content-addressable cache?

> * 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

Wdyt?


> * 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.


cheers
Dev

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