<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I would agree that going all-out and disabling remote XUL entirely makes the most sense, except in the cases you mention.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The one potential exception: would it make sense to allow it to be enabled (with it disabled by default) on copies of Firefox set up with Policy Engine, to allow those users the option?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 27, 2018 at 11:36 AM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu" target="_blank">bzbarsky@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Background: We currently have various provisions for "remote XUL", wherein a hostname is whitelisted to:<br>
<br>
1)  Allow parsing XUL coming from that hostname (not normally alllowed for the web).<br>
<br>
2)  Allow access to XPConnect-wrapped objects, assuming someone hands out such an object.<br>
<br>
3)  Run XBL JS in the same global as the webpage.<br>
<br>
4)  Allow access to a "cut down" Components object, which has Components.interfaces but not Components.classes, for example.<br>
<br>
This machinery is also used for the "dom.allow_XUL_XBL_for_file" preference.<br>
<br>
The question is what we want to do with this going forward.  From my point of view, I would like to eliminate item 4 above, to reduce complexity.  I would also like to eliminate item 2 above, because that would get us closer to having the invariant that XPConnect is only used from system principals.  These two changes are likely to break some remote XUL consumers.<br>
<br>
The question is whether we should just go ahead and disable remote XUL altogether, modulo its usage in our test suites and maybe "dom.allow_XUL_XBL_for_file" (for local testing).  It seems like that might be clearer than a dribble of breakage as we remove bits like items 2/4 above, slowly remove various bindings, slowly remove support for some XUL tags, etc...<br>
<br>
Thoughts?  My gut feeling is that we should just turn off remote XUL outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file" case.<br>
<br>
-Boris<br>
______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><br>Eric Shepherd<br>Senior Technical Writer<br>Mozilla<br>Blog: <a href="http://www.bitstampede.com/" target="_blank">http://www.bitstampede.com/</a><br>Twitter: <a href="http://twitter.com/sheppy" target="_blank">http://twitter.com/sheppy</a><br>
<a style="font-style:italic" href="https://freebusy.io/eshepherd@mozilla.com" target="_blank">Check my Availability</a><br></div></div></div>
</div>