> > >> "When a hash function is determined to be insecure, user agents MUST >> deprecate support for integrity validation using that hash function, but >> MAY continue to check hashes which use it." >> > I think, at this point, we need input from others, since I still disagree > :-) > One thing I worry about is that the MUST wording might limit UAs---if a UA wants to deprecate a hash function in one corner of its implementation, the current wording might force its hand for SRI (and thus affect the ability to deprecate an old hash function in another corner). Additionally, deprecation is an art and a long game. For example, UAs might actually go out and block known broken hashes to make sure the world moves on to better hashes or it may decide to only warn and then start blocking a year later. Or do something more weird involving the set of permissions granted to the script etc. This sort of stuff requires measurements and trade-offs and I don't think is something the spec should get into. How about this wording instead? "User agents MAY deprecate support (by blocking loads) for integrity validation using hash functions deemed insecure. Web application authors SHOULD update integrity metadata to remove use of insecure hash functions." @gerv @joel I feel like this might handle both of your concerns. WDYT? cheers Dev > > >> >> Gerv >> >
Received on Sunday, 17 May 2015 07:52:15 UTC