- From: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Date: Thu, 25 Oct 2012 10:27:05 +0300
- To: whatwg@lists.whatwg.org
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
Received on Thursday, 25 October 2012 07:27:54 UTC