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

RESOLVED WONTFIX

Status

()

Core
DOM
--
enhancement
RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: kohei, Unassigned)

Tracking

(Blocks: 1 bug, {privacy-review-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
+++ 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.
(Reporter)

Updated

4 years ago
See Also: → bug 952549
(Reporter)

Comment 1

4 years ago
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.
See Also: → bug 938885

Comment 2

4 years ago
> 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.
(Reporter)

Comment 3

4 years ago
Oh, so basically [type.enabledPlugin for (type of navigator.mimeTypes)] works. It's a loophole of Bug 757726...

Comment 4

4 years ago
Would be nice to cover everything needed for bug 732527 with this same API.
Blocks: 732527
(Reporter)

Updated

4 years ago
Severity: normal → enhancement
Keywords: privacy-review-needed

Comment 5

4 years ago
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.
(Reporter)

Updated

4 years ago
Blocks: 789731

Comment 6

4 years ago
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.
(Reporter)

Comment 7

4 years ago
(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.
(Reporter)

Comment 8

4 years ago
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.

Comment 9

4 years ago
Should we close this as WONTFIX then?
(Reporter)

Comment 10

4 years ago
I'll file a new bug for the new UA override. Thanks :Ehsan for the tip!
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
(Reporter)

Updated

4 years ago
See Also: bug 952549
(Reporter)

Updated

4 years ago
No longer blocks: 789731
No longer blocks: 732527
You need to log in before you can comment on or make changes to this bug.