[whatwg] checksum attribute in a href tag

[Mikko Rantalainen]

Ian Hickson, 2012-10-24 19:28 (Europe/Helsinki):
> Anyway, if you have memory corruption there's nothing to say the 
> corruption won't occur _after_ you've done the checksum verification. In 
> particular, there's nothing to say it'll happen between receiving and 
> decoding the packets over TLS and comparing the packets to the checksum, 
> and not either before (in which case TLS will catch it as part of its own 
> integrity checking) or after (in which case the checksum won't help). 
> That's a pretty narrow window.
> 
> My guess would be that people will screw up their hidden metadata (e.g. 
> updating the .img file without updating the HTML file) more often, much 
> more often, than the checksum will catch an error.

That might be true, I really don't know. I'd guess that this attribute
would be used pretty seldom but in those cases the correctness of
transferred file would be important enough to take the possibility of
false positive.

In addition, if the correctness of the file is important to you and the
downloaded file does not match the hidden metadata, you definitely
should contact the server administrator in any case. The server
administrator can then either fix the checksum attribute or the actual
file. As a result, I wouldn't expect the false positive error to be the
permanent state for important files. And the extra work required for the
attribute should prevent it's usage for non-important files. I'd trust
that casual content authors are too lazy to bother with it.

Furthermore, the checksum attribute could be valuable against both
memory corruption and network transfer corruption over unsecured
(non-TLS) links. Of course, it wouldn't provide any safety against
malicious uses.

If @checksum is added to the spec, it should include a notice that the
feature is only intended to provide a safety net for non-malicious
corruption and TLS should be used instead or in addition if malicious
corruption is considered possible.
	
Example cases of such (non-malicious) checksum failure:

(1) remote server or intermediate network device hardware or software error
(2) local machine hardware or software error
(3) server administrator error (metadata error vs. actual file content
error - it's not _always_ the metadata that's corrupted)

-- 
Mikko