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

Re: Subresource Integrity strawman.

From: Joel Weinberger <jww@chromium.org>
Date: Wed, 8 Jan 2014 10:21:19 -0800
Message-ID: <CAHQV2KkNHEshcDe5_TFaZg7mb5Ss3gb8veg=ZRN2KuJCiE4+qw@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Devdatta Akhawe <dev.akhawe@gmail.com>, Frederik Braun <fbraun@mozilla.com>, Brad Hill <bhill@paypal.com>, Anne van Kesteren <annevk@annevk.nl>, Mark Nottingham <mnot@mnot.net>, Tab Atkins <tabatkins@google.com>, Ilya Grigorik <igrigorik@google.com>
On Wed, Jan 8, 2014 at 8:38 AM, Michal Zalewski <lcamtuf@coredump.cx> wrote:

> The possibility of examining the contents of cross-origin documents by
> attempting to load them with different known hashes and then
> triggering the reporting behavior (or noticing that navigation in an
> <iframe> has not taken place) seems like a fairly significant issue,
> right? It feels that it would make it considerably easier to
> fingerprint user state across a large number of sites, compared to
> previously demonstrated approaches.
 To clarify, is your concern that CSP reports about the failure to load
documents reveals too much information about what your logged into, have
visited, etc.? Sort of like the old CSS anchor tag color attacks?

> What would be the behavior of clicking on a non-download link with the
> integrity parameter specified? What would happen if this link is
> opened in a new window? It seems that it may be difficult to behave
> consistently in this case (e.g., how to handle right-click + "open in
> an incognito window" in Chrome?).
 I guess my assumption was that for non-download links, the user agent
would not respect an integrity attribute. The only way it would work would
be if the page is completely static, which in this day and age, is far and
few between. Seems like we'd avoid all sorts of complexities, as you're
alluding to here, without a lot of loss of value.

> /mz
Received on Wednesday, 8 January 2014 18:21:46 UTC

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