Re: [whatwg] checksum attribute in a href tag

On Thu, 25 Oct 2012, Mikko Rantalainen wrote:
> 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.

If it would be used pretty seldom, it's probably not the highest priority 
in terms of things we should add. :-)


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

In practice, users blame the browser, not the server. Especially when 
using another (older) browser (that doesn't check the checksum) results in 
it "working fine".


> The server administrator can then either fix the checksum attribute or 
> the actual file.

Or tell you to use another browser, because they don't have any idea what 
this "checksum" thing is, since they had paid someone to write the site 
and only later replaced the file being downloaded and aren't HTML experts...


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

The problem isn't casual content authors, it's authors who copy other 
people's pages and don't test with supporting browsers, or authors who got 
help from their geek Web designer daughter at Christmas and then later 
changed the file and broke it because they didn't understand it, or the 
case I referenced above where a company hires a Web designer to do the 
initial work and then later go and "update" 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.

It doesn't really help against memory corruption, as discussed above. 
If network corruption is a concern, then TLS really is the way to go (I 
would expect network corruption to be more of an issue with an active 
attacker than passive hardware failure, and in the case of an attacker, 
they can just update the checksum too).


In conclusion, it seems this proposal only solves a small problem, and 
doesn't solve it in a particularly successful manner. It's worth 
considering again if we have no more important things to address, but for 
now I haven't added it.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 29 December 2012 07:16:19 UTC