I want to state what I need for my adding of Jabber functionality to
Mozilla via my in-progress XPCOM code.
Here is an example that explains it all:
1. http:// Web page that has CSS to a chrome URL like:
chrome://jabberxm/skin
I really don't care about calling bindings specifically via my own CSS.
2. jabberxm.css has the definitions of my bindings, and also uses chrome
URLs like:
chrome://jabberxm/content/roster.xml
3. roster.xml instantiates my JabberXM component (written in
JavaScript). It does this in the binding's constructor
4. roster.xml can work with the function in the JabberXM component, like
the tcp socket, JabberXMSax parser, in-memory RDF datasources, etc. I
may add disk access functions to the component in the future.
The purpose of this example is to display a user roster in web content,
with all the functionality happening in the component. If the person has
JabberXM installed in their browser, they can see their roster, if not,
then they won't see anything.
Hopefully something can be worked out before Mozilla 1.0 so that I can
do stuff like this... there are a lot of possibilities...
Eric
Stuart Ballard wrote:
> First off, I'd like to clarify that I don't know first-hand the security
> model that XBL is using. However, from discussions on the XBL newsgroup
> and some brief experimentation, the rule appears to be that any content
> built by XBL inherits its security principal directly from the document
> _into which the anonymous content is being added_, regardless of the
> security principal associated with the XBL document itself. If this is
> wrong, please let me know and then disregard this entire email as the
> rantings of a moron.
>
> I claim that this model is the Wrong Thing, and also potentially harmful
> in many ways.
>
> Firstly and most obviously, this behavior prevents some potentially
> useful applications of XBL. The example that led me to this realization
> is an attempt to use XBL to bind a JavaScript action onto the html
> <link> element in order to add that link to a toolbar (yes, the infamous
> bug 2800). While it is possible to bind to <link> with XBL, the code you
> write has no permission to access the toolbar, because it only runs with
> the permissions of remote HTML. This, of course, is a pain. Another
> possible blue-sky application of XBL that is ruled out by this security
> model is the idea of implementing *all* of HTML using XBL - for example,
> a constructor on the <title> element would set the title of the window
> to "Mozilla - " plus the content of the title. Doing this with the
> current security model would mean exposing the raw window-title-setting
> function to remote HTML, which would mean that such HTML could remove
> the "Mozilla - " string. I honestly believe that every html-specific tag
> could be implemented by a combination of CSS and XBL, but only if the
> security model is changed.
>
> There is a more subtle issue, however. This model also potentially
> *introduces* security holes. For example, currently a skin has to be
> trusted, because it can provide XBL that binds into chrome:// documents
> that are unrestricted. If XBL inherited its security principal from the
> XBL document instead, the skin could be untrusted and javascript in
> bindings provided by that skin would have no power to do harm.
>
> 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?
>
> Thanks,
> Stuart.
>
