Re: [selectors-api] Security Considerations and stability

On Sat, 05 Aug 2006 00:22:10 +0300, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 27 Jul 2006, Karl Dubost 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:
>
>    When you user sets the foobar to A, activate the baz.
>    Security:
>    Don't activate the baz if the baz and foobar have different domains.
>
>
> ...have:
>
>    When the user sets the foobar to A, and the foobar and the baz are in
>    the same domain, the user agent must activate the baz. If the foobar
>    and the baz are in different domains, the user agent must do nothing.
>    If the foobar is set to any value other than A, then the user agent
>    must ignore the value.

Actually I think the first version is clearer in many ways. If the notes  
are in the relevant part of the spec (which I don't think is the common  
case that Ian is actually describing) as well as a collected discussion of  
security issues, it is probably easier to see what issues are listed for  
security and what the concerns are.

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.

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.

cheers

Chaals

-- 
   Charles McCathieNevile, Opera Software: Standards Group
   hablo español  -  je parle français  -  jeg lærer norsk
chaals@opera.com          Try Opera 9 now! http://opera.com

Received on Saturday, 5 August 2006 04:54:37 UTC