

Subresource Integrity Sample - mondainx
https://googlechrome.github.io/samples/subresource-integrity/index.html

======
zacwest
I'm curious what is the use case.

If it's 3rd-party resources, wouldn't this make things like Google Analytics
unable to be updated if they use hashes? I guess this must be mostly targeted
at resource hosts who modify resources maliciously, but how often does that
occur?

If it's 1st-party resources, wouldn't SSL better handle the authenticity part?
If they can modify resources you're loading but hashing, surely they can
modify the resource delivering those.

~~~
rictic
At this stage it looks like it's primarily for hosting of known versions of
libraries by CDNs. For example,
[https://code.jquery.com/jquery-1.9.0.min.js](https://code.jquery.com/jquery-1.9.0.min.js)
should serve out those bytes exactly, even though there's a 1.9.1.

There have been proposals for adding fallback URLs to fetch from if the
primary resource fails. This way you can have your CDN and cache but fallback
to a local resource too. As the spec is written currently it looks like the
user will have to do this manually with an on error event. I haven't been
following closely enough to see why it's taken this route. Perhaps for
simplicity of the initial implementation?

------
roller
Will chrome be using this as a cache hint? It might be an explicit way to
signal a change, but the real benefit would be to dedupe every resource on the
Internet. If I have a cached resource with a matching sha256, do I really need
to make another request?

~~~
rgbrenner
_the real benefit would be to dedupe every resource on the Internet_

Hopefully not. Even if we ignore the possibility of hash collisions (since
that's not that likely yet with SHA 256).. There's still the issue of cross
origin data leakage. Using a known hash and whether a request is made for the
resource to tell if a user has visited another website.

This should require a cors header

~~~
smilliken
A common solution to this problem is salting the sensitive value before it's
hashed. Then we can have de-duplication and security.

~~~
rgbrenner
No. Do you understand the attack I'm referring to?

(Legitimate) Site A sends file a.com/image.png w/ a hash.

(Attacker) Site B sends file b.com/image.png w/ identical hash. If no request
is made for b.com/image.png, the attacker knows the visitor has gone to Site
A.

~~~
smilliken
To clarify: the hash for the sensitive resource can be salted, making the hash
unique and avoiding de-duplication. For non-sensitive resources, eg jquery.js,
we can use an unsalted hash and get de-duplication.

Another benefit of identify resources by their hash is that we don't need to
request them from a specific host. Instead, you can get them from any CDN that
has a matching resource.

