[SRI] Shared Cache through `sharedcache` attribute

The idea of using the digest defined in the `integrity` attribute as key
for a cross-origin shared cache has been discussed before.
It seems that the idea has been rejected.
However I can't find the reason why it has been rejected.

Concretely, I don't see how following implementation would imply a security
flaw.


Upon

```
<script src="https://cdn.example.org/common-library.js"

 integrity="sha384-+/M6kredJcxdsqkczBUjMLvqyHb1K/JThDXWsBVxMEeZHEaMKEOEct339VItX1zB"
           sharedcache="true"
           crossorigin="anonymous"></script>
```

following algorithm is applied;
1. If the shared cache holds an asset with the same digest as defined in
the integrity attribute:
  -then: Load this asset from the shared cache instead of fetching the
asset over the network. Don't apply step 2.
  -else: Apply step 2.
2. Upon successful loading of the asset and successful validation with the
integrity attribute add the loaded asset to the shared cache.

Note 1: As per the SRI specification, the validation is only successful if `
cdn.example.org` has set the CORS headers.

Note 2: If the `sharedcache` attribute is missing or set to false then do
not apply the algorithm and proceed normally as defined in the current SRI
specification.

Note 3: The author should be aware that adding the `sharedcache` attribute
to an asset loaded exclusively on its website effectively exposes its
website to a "history-tracking-attack"; any other website can check if the
user visited the website by checking if the shared cache holds the
exclusive asset. However, the `sharedcache` is meant to be used with common
assets loaded by many websites which renders such attack not very useful
(the attacker can at best know that the user has not visited a website,
i.e. it is infeasible to get an exhaustive list of all websites loading a
common asset).


How does this hold a security flaw that would justify the rejection of such
feature?


This would turn SRI into not only a security feature but also a performance
feature.
It would be super convenient to be able to use common JavaScript libraries
and other web assets with almost no network cost.
Not only would this increase performance of the web but it would also allow
new size-heavy libraries to emerge.