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

Re: Subresource Integrity and fingerprinting

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Wed, 8 Jan 2014 23:31:19 -0800
Message-ID: <CAPfop_3YOkBS6OH9Bm9ViVjX5wsnzaf33Jvw8re=X60_k4o9Mw@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: Mike West <mkwst@google.com>, Mark Nottingham <mnot@mnot.net>, Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Frederik Braun <fbraun@mozilla.com>
I like the idea of unconditionally failing if none of the three
conditions are met. Although, presumably, you want the application be
able to distinguish this failure from the failure in integrity
verification or network error.


On 8 January 2014 23:26, 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
Received on Thursday, 9 January 2014 07:32:06 UTC

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