For embedding of the html content area, we'd like to be able to attach XBL/JS with the dragDrop handlers to the new window root node. However, this requires that we be able to access XPConnect (for the drag service, etc) and the context in which the XBL is inserted (the html content area) is untrusted.

this blocks dnd for embedding.

Your component merely needs to implement nsISecurityCheckedComponent, and not open any security holes (mstoltz should review the implementation closely!). See http://lxr.mozilla.org/mozilla/ident?i=nsISecurityCheckedComponent and DIY. /be

well, we can't bless the drag service. that would be a security violation. hyatt says he'll own this.

Hyatt, please don't open any new interfaces to untrusted XPConnect access without my review.

moz0.9, but no requirement for embedding d&d yet.

->future, per hyatt.

This bug is really limiting the usefulness of xbl for constructing new xml tags. You can't even return 'Components.results.NS_ERROR_FAILURE' from a method, since Components.results is not security checked! Has it been pushed back beyond 0.9 because it is technically difficult / timeconsuming or are there more fundamental security issues?

nsISecurityCheckedComponent is bad. Do the DOM class info instead. But. I wonder if something like baseURI should return the URI of the XBL file for a binding instead of the document URI, so that could be used for security checks. IIRC, the baseURI isn't the document URI for entities as well, though I can't paste the spec right now. If you want, I'll do that on tuesday. Axel

BTW, Components.results.WHATEVER is now exposed to all scripts. I made this change with mstoltz's approval as part of the xpcdom landing. I disagree with the statement "nsISecurityCheckedComponent is bad". We want something better. But nsISecurityCheckedComponent has the advantage of granular access control. nsIClassInfo.DOM_OBJECT allows total access of all methods and properties to all callers (and implies that the thing is a DOM object - even if it is not). If improperly applied this is worse than bad.

Yes, DOM_OBJECT should only be used for DOM objects - not as a convenient way to make objects fully scriptable. Use nsISecurityCheckedComponent.

Per discussion with Hyatt on n.p.m.xbl / n.p.m.security, I am posting this description of a possible security model that would address this issue. The Problem: Intuitively it should be possible to add trusted code via bindings in html.css, but because XBL uses the document's security principal, bindings to untrusted html documents are untrusted. The Proposed Solution: Instead of using the security principal of the document, we use the security principal of whatever makes the association from the document to the stylesheet. The Rationale For The Solution: There are three things that contribute to the intuitive fact that bindings from html.css should be trusted: 1) html.css is trusted 2) The XBL file that it binds to is trusted 3) The association of html.css to the untrusted html file is done by a trusted entity - specifically, mozilla. We can reduce this to the Proposed Solution above by applying the following logic: #2 is irrelevant given #1, because if we trust the CSS file, we can trust it not to bind to untrusted XBL; that would be Bloody Stupid. #1 is irrelevant given #3, because we can trust the trusted entity here to not be Bloody Stupid also. So this boils down to trusting bindings if the person (principal) that _makes_the_association_ from the document to the css file is trusted. Hence, the XBL should be executed with this security principal. There's an additional factor which suggests that this is a very reasonable model and will not introduce security holes: In 99% of cases, this association comes from a <link> or a <style src> or an <?xml-stylesheet?> in the document itself. So in *all* of these cases, we've reduced the logic down to "The security principal of the XBL and the CSS file is completely ignored, and the security principal of the document is used". It reduces to the current model! The *only* case where it doesn't reduce to the current model is when the CSS file is attached implicitly by Mozilla, or (perhaps theoretically) by some other trusted entity. This means, basically, html.css and very little else :) I'm not sure exactly how html.css gets associated with HTML files so I'm not sure whether there's an actual security principal floating around at that point to be used. But if not, it would be easy to create and use a trusted one. The cool thing about this solution is that it keeps the known-secure model for 99.9% of cases, while also opening it up enough for every single thing that I can imagine doing using XBL (they would *all* involve using html.css). And it provides a clear rationale for *why* this is the right thing to do.

Oh, one other issue that came up during the discussion: There is still a security hole if a document is able to access and modify/add rules within html.css through the CSSOM. Nobody jumped into the discussion to tell us whether this is currently true or not, but it seems reasonable to me not to allow access to html.css at all through the CSSOM.

This would be useful in XBL for editable iframes too.

See also bug 177639 and bug 172673.

See also bug 177640.

*** Bug 177660 has been marked as a duplicate of this bug. ***

*** Bug 219637 has been marked as a duplicate of this bug. ***

Not a blocker, I don't think ;)

Comment 11 seems sensible to me, assuming that we know that "trusted" bindings in question have no way of being leveraged to breach security...

Transferring dependencies from bug 177660

My 2c: bindings in html.css should at least be able to read user prefs via nsIPrefService. Especially for notorious <marquee> (see discussion at bug 163048).

As this is a really really old bug and yet still marked new, (and it is one I voted on a long time ago) what should be done about it?