Francois, I wasn't accusing you of being 'general public', if you'd read what I actually wrote. I am accusing you of being hand-wavy and failing to provide any evidence for ANY of your claims. You've evidently misinterpreted my proposal. I'm not suggesting any server-side or HTTP-level behavior whatsoever - the hash only appears once, in the HTML. It is never transmitted again. We're not discussing a reinvention of ETags here. This is a secure, backwards-compatible, opt-in browser-level cache, with the only author responsibility being to provide the aforementioned hash in the HTML. Please don't pretend that we don't deal with caching in HTML and the application layer, there's a blurry line between protocol and application responsibilities here and it was crossed with HTML 3. *Until you can show mathematical evidence otherwise, we can safely assume that collisions for SHA-2 (512-bit) cannot presently be found through chance or malicious intent. There doesn't seem to be much hope for this happening anytime soon, either. * * * *Provide specific attack scenarios for your hand-wavy references to XSS, or stop generating FUD. Assuming a secure hash function, I can't see how this could possibly be useful for XSS.* It should be noted that the hash of a resource and the resource itself should be protected with equal vigor; the hash contains 'part of the resource', and can be used to reconstruct the entire resource (through a directed attack at shared visitors). This may not be obvious at first glance, so authors should be informed to consider the security implications similar to using a data URI for the resource.
Received on Sunday, 11 August 2013 23:03:42 UTC