Re: Current TAG election

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.


> 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 


Received on Friday, 3 January 2014 11:56:23 UTC