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

Re: Subresource Integrity and fingerprinting

From: Mike West <mkwst@google.com>
Date: Thu, 9 Jan 2014 08:32:32 +0100
Message-ID: <CAKXHy=ccAz5g2M0afEgubXvO057Xvzcabusa3BZ6i6qOY2QA_w@mail.gmail.com>
To: Devdatta Akhawe <dev.akhawe@gmail.com>
Cc: Michal Zalewski <lcamtuf@coredump.cx>, Mark Nottingham <mnot@mnot.net>, Joel Weinberger <jww@chromium.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Frederik Braun <fbraun@mozilla.com>
Indeed. I would expect the user agent to write a reasonable message to the
console, describing the error in ways that would allow the author to
correct the mistake.

-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, Devdatta Akhawe <dev.akhawe@gmail.com>wrote:

> 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.
>
> --dev
>
>
> 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:33:20 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:04 UTC