hash. Douglas Crockford: “Any HTML tag that accepts a src= or href= attribute should also be allowed to take a hash= attribute”—to protect against file tampering and (more importantly) provide a truly robust caching mechanism.
Sign in with 
OpenID
Can't you do something like that with etags?
This is total nonsense, that's exactly what ALL of the existing HTTP caching headers are for.
It also completely ignores content negotiation by the user-agent. A resource does not map one-to-to to any specific representation, as well he should know.
Noah Slater - 30th March 2008 21:19 - #
I agree with Noah on caching.
And for the security part, it can't really be used. For example, the ad systems need to return a different content each time.
This adds no security: if whatever corresponds to the hash can be tampered with in transit, then so can the hash itself.
It also completely ignores how the web works.
The web is addressed by resource, not content. If you want to refer to the same resource on the web, you use the same URI. (What does that acronym stand for anyway?)
On the web, whatever the origin server says about a resource is final, not what some link tells you.
And on, and on, and on...
This is complete bogus.
arien - 31st March 2008 07:27 - #
I doubt this will provide more security than https.
Also imagine changing one page - and then changing all pages that link to it, and so on. Wow, that spreads fast : )
Concerning cache improvement: enormous number of documents and links in internet seriously questions reliability of short string keys in "hash table" of browser cache. I think conflicts are imminent.
By the way, HTTP's Content-MD5 header already provides a message integrity check.
(The last sentence in my previous comment should have read: There was a vulgar noun meaning at the end of that sentence...)
arien - 31st March 2008 08:56 - #
@arien: The hash is not transmitted by the server but computed by the browser after the download.
It adds security in the case where you are linking to material hosted on a different site from your own - which I assumed was the principle use-case for the idea.
@Simon How fragile a security method is it though? How often do pages change in very small ways? Dates, incomming links, related links, top headlines? Template change? Something so fragile has no real use.
As arien pointed out, resources are addressed by identifier, not content, and this proposal breaks some fairly fundamental aspects of WebArch.
Noah Slater - 31st March 2008 11:28 - #
He doesn't seem to be talking about that type of scenario (emphasis mine):
Even if he were talking about the scenario you describe, what added security would there be? And what would happen if the hash doesn't match? Is the user informed of the mismatch? How? What does it mean for the hash not to match? After how many false positives do people just give up on this "feature"?
arien - 31st March 2008 12:03 - #