> The model is quite simple. The principal associated with an XBL
> document is completely ignored. Methods and properties (as well as
> event handlers) use the principal of the document that corresponds to
> the element that has the XBL binding attached to it.
>
> So a remote HTML document that binds to privileged chrome URLs will not
> be able to install privileged code onto its elements and then invoke
> that privileged code from within the HTML document.
>
>
> > Can anyone comment on why the current behavior was chosen for XBL,
> > whether there are any plans to change it, and whether there are any
> > holes in my arguments?
> >
>
>
> No, there are no plans to change it, because to do as you suggest would
> create a gaping security hole. Consider a binding in a chrome URL of
> the form:
>
> <binding id="usefulFileUtilities">
> <method name="removeDir">
> ... code that accesses our file services and that deletes
> directories...
> </method>
> </binding>
>
> If you allow this code to be privileged when invoked from an element in
> remote HTML, then presto, you've just given all Web pages the ability to
> manipulate the user's file system.
Wouldn't it be possible to add something like the
nsISecurityCheckedComponent-model to XBL?
E.g. an attribute 'useXBLDocPrincipal' on each method/property that, when
set, applies the XBL doc's principal for those methods.
In that way XBL would be much less restrictive but still just as secure as a
compiled code.
Alex
