W3C home > Mailing lists > Public > public-webappsec@w3.org > December 2015

Re: [SRI] Unmentioned use case: caching

From: Joel Weinberger <jww@chromium.org>
Date: Mon, 21 Dec 2015 15:41:02 +0000
Message-ID: <CAHQV2KnJcBmi7GRpuXCEv-MnCQg+5usVSbXMNZrJf=D8drEDvQ@mail.gmail.com>
To: Jonathan Kingston <jonathan@jooped.co.uk>, Ian Denhardt <ian@zenhack.net>, public-webappsec@w3.org
Hi Ian. We have actually discussed this a bunch on this list (see the
thread
https://lists.w3.org/Archives/Public/public-webappsec/2015May/0095.html,
for example). Basically, we decided to exclude caching form v1 because
there's a lot of nuance in doing to securely. That having been said, we
definitely have it on our radar for SRI v2 (see
https://github.com/w3c/webappsec-subresource-integrity/issues/22 which
we've filed to track it). If you have ideas, feel free to post here or on
that issue.
--Joel

On Sun, Dec 20, 2015 at 9:17 PM Jonathan Kingston <jonathan@jooped.co.uk>
wrote:

> Hi Ian,
>
> I believe it wasn't mentioned because it was outside of the groups
> charter. It has been mentioned in various ways regarding SRI however I'm
> not sure it has had any progress as such.
>
> This might actually be something that is more applicable bringing up in a
> different group though I'm not exactly sure which one however the WICG
> discourse group might be a start: http://discourse.wicg.io/. I suspect it
> would likely be added to WHATWG fetch.
>
> Thanks
>
> On Sun, Dec 20, 2015 at 9:24 PM Ian Denhardt <ian@zenhack.net> wrote:
>
>> Hey all,
>>
>> I was bouncing around some ideas the other day and came up with what
>> basically amounts to SRI. I figured someone must have thought of this so
>> asked a friend, and turns out yep, folks are working on it. Interesting
>> thing is: I had a completely different use case in mind for the same
>> mechanism specified.
>>
>> The presence of the integrity attribute could be used for caching
>> purposes. This has some neat properties:
>>
>> * No need to check modification times/etags with the server before using
>>   the cached entry; the hash tells you what the content is, so you know
>>   whether your cache is up to date without making any extra requests.
>> * As a corollary, cache entries based on integrity don't need to have a
>>   notion of expiration.
>> * The cache entry can be valid even for different URLs. For example the
>>   browser can download one copy of jquery *ever*, even for sites that
>>   link to it on different CDNs.
>>
>> The spec doesn't mention this use case at all. Thoughts?
>>
>> I'm not subscribed to the list, so please Cc me in any responses.
>>
>> -Ian
>>
>
Received on Monday, 21 December 2015 15:41:41 UTC

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