I would agree that going all-out and disabling remote XUL entirely makes the most sense, except in the cases you mention.
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? On Tue, Mar 27, 2018 at 11:36 AM, Boris Zbarsky <bzbar...@mit.edu> wrote: > Background: We currently have various provisions for "remote XUL", wherein > a hostname is whitelisted to: > > 1) Allow parsing XUL coming from that hostname (not normally alllowed for > the web). > > 2) Allow access to XPConnect-wrapped objects, assuming someone hands out > such an object. > > 3) Run XBL JS in the same global as the webpage. > > 4) Allow access to a "cut down" Components object, which has > Components.interfaces but not Components.classes, for example. > > This machinery is also used for the "dom.allow_XUL_XBL_for_file" > preference. > > 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. > > 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... > > 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. > > -Boris > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > -- Eric Shepherd Senior Technical Writer Mozilla Blog: http://www.bitstampede.com/ Twitter: http://twitter.com/sheppy Check my Availability <https://freebusy.io/esheph...@mozilla.com> _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform