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

Re: Subresource Integrity and fingerprinting

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 9 Jan 2014 16:14:01 +0800
Message-Id: <5F946201-2792-4CD1-9DE0-1D6E5C908E8C@mnot.net>
Cc: Mike West <mkwst@google.com>, Devdatta Akhawe <dev.akhawe@gmail.com>, Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Frederik Braun <fbraun@mozilla.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Doesn't relying on CORS assume that sensitive data will never be available cross-origin?

Sent from my iPhone

On 9 Jan 2014, at 3:26 pm, 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 08:14:34 UTC

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