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 22:09:32 -0800
Message-ID: <CAPfop_0W4VbNju=bg8GVvFAp-+U_HaJKJAsmGVEw16iYOh5bqA@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>, Mark Nottingham <mnot@mnot.net>
Cc: Joel Weinberger <jww@chromium.org>, Mike West <mkwst@google.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Frederik Braun <fbraun@mozilla.com>
Aah, sorry I misunderstood your concerns. I like the
allow-if-publicly-cacheable idea too. The current spec has, I believe,
a stronger condition: it requires a Access-Control-Allow-Origin *
header for the integrity-enabled cache (which would make the resource
readable cross-origin)

http://w3c.github.io/webappsec/specs/subresourceintegrity/#recommendations-1


--dev

On 8 January 2014 21:42, Michal Zalewski <lcamtuf@coredump.cx> wrote:
>> Maybe, integrity verification should
>> also follow this: sub-resource integrity verification only works
>> directly for files with an explicit mime-type that is for JS/CSS/img
>> etc.
>
> Not sure how viable that would be with various existing CDNs (where
> the control over MIME types available to content publishers may be
> sloppy); plus, JSON is commonly returned as application/x-javascript
> or so, the use of application/json isn't widespread.
>
> I like Mark's allow-by-default-if-publicly-cacheable proposal, though.
>
> /mz
Received on Thursday, 9 January 2014 06:10:19 UTC

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