Closed Bug 966030 Opened 11 years ago Closed 11 years ago

Implement navigator.mozAppDetails and expose the property on white-listed domains

Categories

(Core :: DOM: Core & HTML, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: kohei, Unassigned)

References

Details

(Keywords: privacy-review-needed)

+++ This bug was initially created as a clone of Bug #952549 +++ http://www.mozilla.org/en-US/firefox/new/ has a warning for people who are using older Firefox releases, but we have realized there's no way to detect ESR builds. Firefox 24.2.0 ESR is exposed as 24.0 in navigator.userAgent (Bug 870868). While we still can detect dot releases using navigator.buildID, this property is also at risk (Bug 583181). It would be nice if Firefox has the exact version number and release channel, so we'd like to propose a new read-only property: navigator.mozAppDetails = { 'channel': 'nightly', 'aurora', 'beta', 'release' or 'esr', 'version': a full version like '24.2.0', 'buildID': currently exposed as navigator.buildID (Bug 583181 will hide it) } It should be exposed only on white-listed domains, *.mozilla.org in particular, to prevent fingerprinting attempts. We believe it would contribute to improving user security.
Also, it would be nice to expose the plug-in details. navigator.plugins is no longer enumeratable (Bug 757726) but we need it for the plug-in check page. navigator.mozAppDetails.plugins could be the enumeratable version of navigator.plugins.
> but we need it for the plug-in check page. Actually, we don't. We can make the checks on the client-side and get the data from the server. It's a completely different architecture, but it works. That's what bug 938885 and bug 956905 are about.
Oh, so basically [type.enabledPlugin for (type of navigator.mimeTypes)] works. It's a loophole of Bug 757726...
Would be nice to cover everything needed for bug 732527 with this same API.
Blocks: 732527
Severity: normal → enhancement
sstamm suggested in bug 732527 comment 5 to use both a whitelist and an additional user confirmation. The text shouldn't sound scary, but I think that confirmation is an important piece.
Blocks: 789731
Instead of adding an API for this, can't we use the UA override mechanism implemented in http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/UserAgentOverrides.jsm to send a special user agent string to a specific Mozilla server and do this detection on the server side based on the additional information exposed in the user agent? It seems to me that if we just expose the build ID in the user agent string that way, it should address the use case in comment 0.
(In reply to :Ehsan Akhgari from comment #6) > Instead of adding an API for this, can't we use the UA override mechanism Ah cool! I know it has been used for the mobile site compat efforts. It should satisfy at least our needs.
Looks like the current UA overrides are simple replacements. http://mxr.mozilla.org/mozilla-central/source/b2g/app/ua-update.json.in We probably need parameters that can be found in http://mxr.mozilla.org/mozilla-central/source/netwerk/protocol/http/UserAgentUpdates.jsm to build a custom UA string.
Should we close this as WONTFIX then?
I'll file a new bug for the new UA override. Thanks :Ehsan for the tip!
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
No longer blocks: 789731
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.