- From: Graham Klyne <GK@ninebynine.org>
- Date: Fri, 03 Jan 2014 11:46:55 +0000
- To: Harry Halpin <hhalpin@ibiblio.org>, www-tag <www-tag@w3.org>
On 03/01/2014 08:42, Harry Halpin wrote: > I'd just like to note that, as great as the current activity in JS > APIs is, we should also not be content in our current paradigms of web > development. For example, in the post-Snowden era, the Web Security > Model that completely trusts the server to control absolutely all > content on the client is clearly not suitable for all Web > applications. > > There's lots of work to be done to transform the Web and Javascript > into more secure and privacy-preserving platforms for coding > high-value applications - applications that currently are too risky to > responsibly be put on the Web. Problems that the Web has lived with > for years, such as multi-tier web programming (leading to SQL > injection attacks), no secure username-password entry in websites > (leading to hashcrackin), and the CA system are now no longer obscure > technical issues but causing massive breaches of trust in the Web > itself and so vital to solve via open standards. +1 > Thus, it would be great if someone with real-world Web and Internet > security experience ran for the TAG. Or was even offered to the W3C as > a Fellow :) But as you suggest in a later message, finding good security expertise is not always easy. And I think many pairs of eyeballs are better than one. One approach that I think might be considered is to follow the IETF practice of requiring a security considerations section in every recommendation. This does not of itself guarantee good security properties for implementations of a specification, but I think it does serve (at least) two useful purposes: 1. Provides a focus for consideration and discussion of security issues. The act of writing a security considerations section can surface issues that might otherwise go un-noticed. And reviewers may be prompted to raise further issues that did not occur to the original authors. I have come across both of these effects in my own work. 2. Mentioning security considerations helps to alert developers to wider issues they need to be aware of, even though they may not be part of the specification itself. #g
Received on Friday, 3 January 2014 11:56:23 UTC