W3C home > Mailing lists > Public > public-webapi@w3.org > August 2006

Re: [selectors-api] Security Considerations and stability

From: Ian Hickson <ian@hixie.ch>
Date: Sat, 5 Aug 2006 05:55:11 +0000 (UTC)
To: Charles McCathieNevile <chaals@opera.com>
Cc: Karl Dubost <karl@w3.org>, public-webapi@w3.org
Message-ID: <Pine.LNX.4.62.0608050545280.5340@dhalsim.dreamhost.com>

On Sat, 5 Aug 2006, Charles McCathieNevile wrote:
> > >
> > > What you suggest, recommend practically?
> > 
> > Include security concerns as a core part of any specification, just 
> > like error handling and conformance criteria.
> > 
> > i.e. instead of: [vague text with no conformance criteria] have [very 
> > specific text that handles error cases, security, everything].
> 
> Actually I think the first version is clearer in many ways.

To each his own, I guess. Personally I have found that every spec that 
does it the first way ends up being *massively* more work for 
implementors, QA, documentation writers, and authors, than the second. 
IMHO the first is the kind of material you would expect in a tutorial, not 
a serious specification intended to ensure interoperability across many 
implementations in a world as wide as the Web.


> But then, I am generally opposed to specifications making arbitrary 
> security decisions which in my opinion more properly belong either in 
> the domain of a sensible general security framework for the web (which 
> would be lovely to have but doesn't really exist still) or with 
> implementors deciding the most appropriate policy for what they are 
> implementing.

In practice, I usually use "should" for security considerations, for this 
very reason. But that's as far as I'd go. Putting security in a section on 
its own results in fiascos like SVG Tiny 1.2's "Connection" interface.


> While in the common open web case security restrictions such as (for the 
> sake of argument) "XSS must not be enabled" there are situations where 
> it is valuable and safe to enable it, and declaring it wrong by 
> specification is not necessarily realistic or helpful.

Given the sheer cost of getting security wrong, I'd rather that the 
security be right up there, and that the security-free implementations be 
non-conformant, than have the implementors not read the security section 
and therefore get it wrong. (Implementors read as little of the spec as 
they can get away with. In many cases, they read none of it and rely 
purely on the testcases. It sucks, but it's the way it is.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 5 August 2006 05:55:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:55 GMT