Re: [SRI] Shared Cache through `sharedcache` attribute

*** CSP ***

I don't see any issues with CSP;

because AFAIK:

```
<script src=http://mywebsite.example.org/same_code.js></script>
```
is equivalent to
```
<script src=http://cdn.example.org/same_code.js></script>
```
given that both `same_code.js` are equivalent and with the exception that
`[].slice.call(document.getElementsByTagName('script')).pop().src` will be
evaluated to `http://mywebsite.example.org/same_code.js` and `
http://cdn.example.org/same_code.js` respectively.

I can't think of any situation where this would be a security issue.



*** Privacy ***

Timing the cache to figure out where the user has been is an inherent
problem with sharing a same cache.

This is already a problem on the web.

Many websites have
```
<script src="//code.jquery.com/jquery-1.11.3.min.js"></script>
```
which gives the opportunity to an attacker to know that if the browser
cache doesn't hold `jquery-1.11.3.min.js` then the user has likely not been
on any website that loads this version of jQuery.


Now doing
```
<script src="https://mywebsite.example.org/jquery-1.11.3.min.js"

 integrity="sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
           sharedcache="true"
           crossorigin="anonymous"></script>
```
gives the attacker the same opportunity.


However `sharedcache="true"` actually improves the situation because;

  - the exact same jQuery v1.11.3 script is hosted on both jQuery's CDN and
Google's CDN. This means that the same script can have different browser
cache entries. This gives the attacker more knowledge. With
`sharedcache="true"` the shared cache holds only exactly one entry for the
same script.

Furthermore the situation with `sharedcache="true"` is less critical
because;

  - As an author it's easier to unknowingly make a mistake regarding
privacy with the cache headers. Because the author may very well add long
caching to an asset that is exclusive to his website with the intention to
increase the performance of his website. The author is likely to not
consider the fact that doing so effectively exposes the information that a
user has visited his website. In contrast, the shared cache is clearly
intended towards wide spread common assets and the author is unlikely to
add the `sharedcache="true"` attribute to an asset exclusive to his website.

For exactly this privacy concern, it is crucial to make the shared cache an
opt-in feature and that's the purpose of the `sharedcache="true"`
attribute; the shared cache is only used when `sharedcache` is truthy.



*** V1 ***

I posted this yesterday because it was the last day for the Call for
Consensus.
But ok it makes sense to have at first an easier implementation for browser
vendors.

For the specification itself I would say that adding this wouldn't be that
much work.
I'd be up to participate.

I would personally be super excited to see such shared cache implemented.
HTTP2 + shared cache could be really nice.



Thanks for the replies.
Romuald