Unsurprisingly, I am very much opposed. You don't see innerHTML littered with concerns about XSS within the DOM specification. You don't see RFC6265 littered with remarks about httpOnly or Secure. I agree that the world needs solid cryptographic advice. Putting it in the specification for an API, however, is living in a world that doesn't exist - a world that believes authors (not implementers) read such specifications. They don't - the read MDN, MSDN, and WebPlatform.org. That's where such concerns should live - and be updated - the same way they would for other 'dangerous' bits. We are deluding ourselves to think for a moment that adding it to the spec will help a single author suddenly write cryptographically secure code. If we are going to continue to discuss "secure", then the proponents of such solutions must be absolutely clear on their threat model, so that such a term has meaning. A significant amount of time and energy has been spent attempting to tease out what is being viewed as the threat model, with some contributors actively avoiding the question. Security is a term without meaning without defining the threats.
Received on Thursday, 19 June 2014 15:21:10 UTC