Re: [SRI] Unmentioned use case: caching

Shades of BitTorrent! See also ideas about a distributed HTTP:
https://www.mnot.net/blog/2015/08/18/distributed_http

On Mon, Dec 21, 2015 at 7:41 AM, Joel Weinberger <jww@chromium.org> wrote:

> 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
>>>
>>