Re: Another view (sorry) on XBL and behaviours

The XBL implementation in Mozilla does allow you to disable the 
"script" portions of the behavior without disabling the rest of XBL.  
In fact, this is how themes work in Mozilla.  You can only write 
scriptless XBL for themes by default.

dave

On Tuesday, January 7, 2003, at 12:15 AM, C.Bottelier wrote:

>
> Ian Hickson wrote:
>>> From a security point of view, allowing links to active content in 
>>> styles is
>>> dangerous. Stylesheets are expected by many to be free of active 
>>> content,
>>> and are allowed in places such as user-submitted content, HTML 
>>> e-mail etc.
>>
>> This is a very valid concern, and is very much of interest to me.
>>
>> There are several possible solutions.
>>
>> One is to suggest to the XML team that a new attribute be introduced,
>> xml:scripting or some such, which could indicate that everything from 
>> that
>> element and deeper should be unable to execute associated script.
>
> <snip />
>
>> Another possible solution is to introduce some way of overriding 
>> style at
>> a higher level, so that embedding content could force 'binding' to 
>> 'none'
>> on the element and all its children.
>
> <snip />
>
>> I don't see XBL as introducing a larger security hole -- in fact I 
>> see its
>> standardisation as bringing to the table a problem which has been 
>> ignored
>> for too long.
>
> That there is a standardized way to to change the behaviour of the
> widgets
> is a great thing, one of the side effects is that it introduces yet
> another
> security hole. However there is a slight difference between (most)
> existing
> ones and this new XBL hole.
>
> (Most) previous standards (some more or less) provide a much clearer 
> way
> how to patch it (like disable ... script) With XBL the choice is to
> disable XBL entirely, or only its scripting capability. The latter 
> would
> be
> preferred, but due the way XBL is intended (or to be used) this could
> pose
> risk. This risk being the changed behaviour to rely on the scripting,
> or in put other words if the scripting behaviour is disabled the 
> changed
> behaviour of a widget would be unclear or dysfunctional to the users
> point of
> view.
>
> It would / could be the task of the W3C to not make only the XBL
> recommendation, but also define how, where, and what should be disabled
> of the functionality of XBL by the UA. This to prevent non functional
> XBL when security is set to a strict model in the UA.
>
> Secondly it should be noted (or at least I feel it has to be) that 
> using
> CSS
> selectors (and/or XPath selectors) is a great way to bind the XBL. This
> for
> (at least) to reasons; the selectors are more than adequate to bind the
> XBL,
> authors are more or less already familiar to the syntax and workings.
> But this does _NOT_ require the also use CSS to bind the XBL. This 
> could
> be done in a separate linked document with its own mime type. But this
> is
> not required. But if the XBL bindings are from within CSS disabling CSS
> does disable XBL. The way to prevent this is to disable CSS using a
> cascaded
> style sheet marking _EVERYTHING_ !important. but is this desirable?
>
> Christian
>

Received on Tuesday, 7 January 2003 11:39:12 UTC