Hacker News new | past | comments | ask | show | jobs | submit login
Subresource Integrity Sample (googlechrome.github.io)
34 points by mondainx on July 27, 2015 | hide | past | favorite | 7 comments



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.


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


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?


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


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


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: