Re: [selectors-api] Security Considerations and stability

On Thu, 27 Jul 2006, Karl Dubost wrote:
> 
> Le 27 juil. 06 à 10:17, Ian Hickson a écrit :
> > > Note that we were more than happy to see a security section.
> > 
> > Personally I think that having a separate security section is a bad way of
> > designing a spec, since it doesn't encourage you to think of security the
> > whole time -- it's better, IMHO, to have security right at the core of the
> > specification text. But again, I'll leave that up to the editor.
> 
> Maybe, yes.
> 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.

   Authors may leave the foobar unset, and may set the foobar to A. 
   Authors must not set the foobar to any value other than A.

HTH,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'