- From: Ángel González <angel@16bits.net>
- Date: Fri, 04 Sep 2015 22:47:59 +0200
- To: public-webappsec@w3.org
On Richard Barnes wrote: > This was discussed during the development of SRI. It was not added > because it would provide the ability for a calling site to "speak > for" another origin, in the sense that the browser would load the > content even the origin server would have sent something completely > different. > > --Richard Expanding the above: If host A could use the hash to get "data from host B" that was't really in host B, it might be able to escape same-origin policy. That shouldn't be an issue if the request points to the same origin, it's passive content or it was sandboxed so the origin didn't matter.* However, it would be horible for privacy: Here are the pages you recently visited: <img src="missing.png" integrity="<hash of google logo>" /> <img src="missing.png" integrity="<hash of facebook logo>" /> <img src="missing.png" integrity="<hash of youtube logo>" /> <img src="missing.png" integrity="<hash of yahoo logo>" /> <img src="missing.png" integrity="<hash of amazon logo>" /> <img src="missing.png" integrity="<hash of wikipedia logo>" /> <img src="missing.png" integrity="<hash of twitter logo>" /> Moreover, when combined with onload/onerror or simple time measuring, that could be sent back to the server. *It would be great source for code obfuscation, though.
Received on Friday, 4 September 2015 20:48:27 UTC