1207321 - Stop exposing XPCWrappedNative (XPCWN) to the web

Status: NEW

(Core :: XPConnect, defect)

Description

[Boris Zbarsky [:bzbarsky]]

Obviously this depends on the various bugs that track things we still expose via XPCWN.  Added some of those, but some stuff listed in https://etherpad.mozilla.org/classinfo doesn't seem to have associated bugs yet.

Comment 1

[Bobby Holley (:bholley)]

Has the day finally come? :-)

Comment 2

[Boris Zbarsky [:bzbarsky]]

It depends on your definitions of "web", "expose", and "is".  ;)

The current state of things is that nsScriptSecurityManager::CanCreateWrapper allows creation in the following three cases:

1) This is a remote-XUL domain.  Hence my thread about removing remote XUL on .platform.
2) This is a global that did enablePrivilege.
3) This is a global that has the system principal.

What that means in terms of resolving this bug, I'm not sure.  I'm not even sure what it means in terms of resolving the bugs it blocks (e.g. can we get rid of XPCWN xrays given the above?  Replace them with opaque wrappers, presumably?).

Comment 3

[Bobby Holley (:bholley)]

Per vidyo discussion, I think we should:
* Remove the permission stuff around remote XUL, replace it with: IsFileURIWithPrefSet || IsInAutomation
* Move all web-related stuff to a separate object, only instantiate XPCWNScope for the cases where it's allowed, and kill the CanCreateWrapper stuff.
* Try to get somebody to do the work to remove enablePrivilege (see bug 1435113)

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, enablePrivilege is gone now. So the only weird case left here is the "remote XUL" bit.

Comment 5

[Bobby Holley (:bholley)]

Andrew, do you have the cycles to take this over? Seems like we can just drop the remaining remote XUL stuff and then make the data structures simpler and safer.

Comment 6

[Andrew McCreight [:mccr8]]

Sure.