On Sat, 05 Aug 2006 00:22:10 +0300, Ian Hickson <[EMAIL PROTECTED]> 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
[EMAIL PROTECTED] Try Opera 9 now! http://opera.com
