Re: Subresource Integrity and fingerprinting

I took a stab at speccing this at
https://github.com/w3c/webappsec/commit/28fc03a79433ca105b80430b00833a8074bec69a

Thoughts?

-mike

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, 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:31 AM, Mike West <mkwst@google.com> wrote:

> 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
> window.onerror.
>
> For the moment, I like the proposal you've outlined; I'll add it to the
> strawman.
>
> -mike
>
> --
> Mike West <mkwst@google.com>
> Google+: https://mkw.st/+, 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 <lcamtuf@coredump.cx>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
>>
>
>