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

Status: RESOLVED WONTFIX

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

Description

[Kohei Yoshino [:kohei]]

+++ 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.

Comment 1

[Kohei Yoshino [:kohei]]

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.

Comment 2

[Ben Bucksch (:BenB)]

> 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.

Comment 3

[Kohei Yoshino [:kohei]]

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

Comment 4

[Dave Garrett]

Would be nice to cover everything needed for bug 732527 with this same API.

Comment 5

[Ben Bucksch (:BenB)]

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.

Comment 6

[(no longer active)]

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.

Comment 7

[Kohei Yoshino [:kohei]]

(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.

Comment 8

[Kohei Yoshino [:kohei]]

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

[(no longer active)]

Should we close this as WONTFIX then?

Comment 10

[Kohei Yoshino [:kohei]]

I'll file a new bug for the new UA override. Thanks :Ehsan for the tip!