Re: Subresource Integrity and fingerprinting

I think requiring CORS for resource validation is potentially an avenue we
can explore; it would certainly be appropriate for scripts, where CDNs are
already rolling out CORS headers in order to enable error handling via

For the moment, I like the proposal you've outlined; I'll add it to the


Mike West <>
Google+:, Twitter: @mikewest, Cell: +49 162 10 255 91

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

On Thu, Jan 9, 2014 at 8:26 AM, Michal Zalewski <> wrote:

> > What is the mitigation that you're agreeing with, Michal? Only performing
> > integrity checks on resources delivered with explicitly public
> cache-control
> > or CORS headers?
> Well, Eduardo's take is that we should just require CORS and not dance
> around it. Maybe that would work, although it does require explicit
> cooperation of the third-party site that hosts a particular download,
> has a copy of jQuery, etc. I'd imagine this won't always be painless.
> An alternative would be to unconditionally fail if integrity= is
> specified and none of the following three conditions are met:
> 1) The subresource is same-origin with the requestor,
> 2) The subresource is publicly cacheable by proxies (either due to
> implicit caching rules, or due to Cache-Control),
> 3) There is a CORS header that explicitly permits this subresource to
> be accessed across origins.
> /mz

Received on Thursday, 9 January 2014 07:32:14 UTC