1018249 - navigator.* javascript fields (userAgent, mozId, mozContacts, mozPhoneNumberService) is impossible to remove or to customization in extension code

Status: NEW

(Core :: DOM: Core & HTML, defect, P5)

Description

[fdsc]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release)
Build ID: 20140506152807

Steps to reproduce:

1. In about:config set to true dom.navigator-property.disable.mozId, dom.navigator-property.disable.mozContacts, dom.navigator-property.disable.mozPhoneNumberService

2. In extension code do commands "delete navigator.wrappedJSObject.mozContacts", "delete navigator.wrappedJSObject.userAgent", "delete navigator.wrappedJSObject.mozId", "delete navigator.wrappedJSObject.mozPhoneNumberService"



Actual results:

1. In page code have all fields navigator.mozContacts, navigator.userAgent, navigator.mozPhoneNumberService is restored to initial value (example navigator.userAgent="Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0")

2. mozId, if dom.navigator-property.disable.mozId == true, is undefined, else restored to initial value.



Expected results:

Extension code must be able to substitute fields for increase privacy (user-agent information replacement).
1. All navigator fields must be initial correctly always
2. In extension code command "delete navigator.wrappedJSObject[fieldName]" must be work correctly.

Now work only
Object.defineProperty(XPCNativeWrapper.unwrap(navigator), fieldName, {value: undefined, enumerable : false, configurable : true});
but it is visible by Object.getOwnPropertyNames(navigator)

Comment 1

[Boris Zbarsky [:bzbarsky]]

This is only an issue for stuff exposed on navigator via the resolve hook and categories (which is why it comes back after delete).

The .disable prefs work if placed in the default prefs.  In user prefs they don't work, because those pref checks are done before the user pref file is loaded.

Maybe we should just add observers for that prefbranch to nsScriptNameSpaceManager.cpp as a quick fix?

Comment 2

[(no longer active)]

We're going to be porting these APIs to WebIDL, and that would make the prefs to not work either in the default prefs or the user prefs, right?

Comment 3

[fdsc]

Perhaps, I have not correct understand.

1. dom.navigator-property.disable.mozContacts setting is default to true in my browser. And not work (mozContacts is defined)
2. dom.navigator-property.disable.mozId option removes navigator.mozId

It seems to me that either everything must work, or everything must not work. It is strange that one field is removed, and the other field not

In addition, I necessary to exists function to correctly field deletion. And field must be added correctly by FireFox. Otherwise privacy is not provided. mozId field need for some sites, and some of it should be removed. This should do the extension, and it may not be able to do it only simple FireFox settings

Comment 4

[Boris Zbarsky [:bzbarsky]]

>1. dom.navigator-property.disable.mozContacts setting is default to true in my browser.
> And not work (mozContacts is defined)

Hmm.  mozContacts is added via a [NavigatorProperty] WebIDL annotation, not via the category.  And you're right that we don't honor the pref there.  Maybe we should.  Or maybe we should have a specific pref if that's something we want to make disable-able.  It's not clear that we want to have a generic set of prefs for all webidl navigator properties.

> 2. dom.navigator-property.disable.mozId option removes navigator.mozId

That's defined via the category, yes.

> It seems to me that either everything must work, or everything must not work.

The two fields are added to Navigator via totally different mechanisms.  You'll not that setting the dom.navigator-property.disable.onLine doesn't work either.  The "dom.navigator-property.disable.*" prefs disable things added via the navigator-property category, not arbitrary properties on Navigator.

> In addition, I necessary to exists function to correctly field deletion.

That basically requires completely changing how these properties are exposed on Navigator.  That's a long-term goal, but it hasn't been a super-high priority so far.

Comment 5

[fdsc]

> That's a long-term goal

I correctly understand, what I posting is not a defect, but I request new features?
Don't know how it tagged here.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> but I request new features?

Sort of.  The fact that deleting doesn't work is a defect, but low-priority.  The fact that there is no pref to control exposure of navigator.userAgent is a new feature.

Comment 7

[Peter Van der Beken [:peterv]]

(In reply to Boris Zbarsky [:bz] from comment #1)
> Maybe we should just add observers for that prefbranch to
> nsScriptNameSpaceManager.cpp as a quick fix?

I don't feel strongly care either way if we're not going to support this for WebIDL anyway.

(In reply to Boris Zbarsky [:bz] from comment #4)
> Hmm.  mozContacts is added via a [NavigatorProperty] WebIDL annotation, not
> via the category.  And you're right that we don't honor the pref there. 
> Maybe we should.  Or maybe we should have a specific pref if that's
> something we want to make disable-able.  It's not clear that we want to have
> a generic set of prefs for all webidl navigator properties.

I think we probably shouldn't. Reuben, it seems that the dom.navigator-property/global-constructor.disable.* prefs were added to help with testing B2G APIs. Given that we have generic mechanisms for that in WebIDL (explicitly added per interface though), do we need support for them for WebIDL-based DOM properties/constructors too?

Comment 8

[Reuben Morais [:reuben]]

(In reply to Peter Van der Beken [:peterv] from comment #7)
> I think we probably shouldn't. Reuben, it seems that the
> dom.navigator-property/global-constructor.disable.* prefs were added to help
> with testing B2G APIs. Given that we have generic mechanisms for that in
> WebIDL (explicitly added per interface though), do we need support for them
> for WebIDL-based DOM properties/constructors too?

I don't think so. If anything, we'll probably need the opposite, a way to enable prefs regardless of any "prefable things" attached to the interface, for testing. The fact that those prefs are still defined for mozContacts is a bug, I filed bug 1019159.

Comment 9

[Reuben Morais [:reuben]]

(In reply to Reuben Morais [:reuben] from comment #8)
> a way to enable prefs

Er, I meant a way to enable navigator properties and constructors.

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.