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)
Core
DOM: Core & HTML
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.
Reporter | ||
Updated•11 years ago
|
Reporter | ||
Comment 1•11 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.
Comment 2•11 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•11 years ago
|
||
Oh, so basically [type.enabledPlugin for (type of navigator.mimeTypes)] works. It's a loophole of Bug 757726...
Comment 4•11 years ago
|
||
Would be nice to cover everything needed for bug 732527 with this same API.
Blocks: 732527
Reporter | ||
Updated•11 years ago
|
Severity: normal → enhancement
Keywords: privacy-review-needed
Comment 5•11 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.
Comment 6•11 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•11 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•11 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•11 years ago
|
||
Should we close this as WONTFIX then?
Reporter | ||
Comment 10•11 years ago
|
||
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
Reporter | ||
Updated•11 years ago
|
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•