W3C home > Mailing lists > Public > public-html@w3.org > August 2013

RE: [Feature Proposal] New attributes "library" and "version" on script tags

From: François REMY <francois.remy.dev@outlook.com>
Date: Sat, 10 Aug 2013 16:46:12 -0700
Message-ID: <DUB406-EAS424AA960A8C77D713FBC40EA5590@phx.gbl>
To: "'Nathanael D. Jones'" <nathanael.jones@gmail.com>
CC: "'Chris Bojarski'" <chris@cbojar.net>, "'HTML WG'" <public-html@w3.org>
> A 512-bit SHA-2 hash cannot have conflicts. 

Wait, what? This is absurd. Every hash system has conflicts, by definition. You can even calculate how many conflicts there exist: you simply divide the number of possible files of a certain length by the number of possible hashes. Let's suppose all JS files are exactly 64 kilobytes long, there are exactly 1000 files that share the same hash. Arguably, the probability that those files are javascript files is very low (most of them will be garbage) but you cannot base your system on something that's only based on an hash, it doesn't make sense.

The point of the hash is not the identify the resource, but to make sure no attacker could actually poison the cache by sending a fake file with the same name as a popular library to execute code on other websites (hash are secure in the sense it's hard to find another of the 999 other files having the same hash, let alone creating another file that actually is valid javascript and has the same length and hash, this is generally impossible).



> Filename matching would make the feature unreliable, adding another point of failure.

I don't see how it makes the feature unreliable. DLLs are loaded based on filename on all OSes and I don't think it has ever been an issue... By the way, .NET use exactly the combination of filename+guid to identify DLLs and versions.



> There's also no point this feature if you move it to the HTTP layer; it only provides a benefit if (a) eliminates network traffic and (b) securely identifies a file across multiple websites so (c) browsers can implement higher-order caching.

Not true. Moving the feature to HTTP does not remove (b) and (c) benefits, and conserve most of the (a) benefits. It also add the possibility to accept multiple versions of a same file on the server side, and to update this in real time as new versions get supported, without modifying all the pages.



> Think about how *trivial* it is to implement a text editor plugin that updates these hashes. 

Not an argument.  
Received on Saturday, 10 August 2013 23:46:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:34 UTC