1120892 - Consider removing or standardizing navigator.oscpu

Status: UNCONFIRMED

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

Description

[Philip Jägenstedt [:foolip]]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2202.3 Safari/537.36 OPR/27.0.1689.2 (Edition developer)

Steps to reproduce:

console.log(navigator.oscpu)


Actual results:

It's a string like "Linux x86_64".


Expected results:

No other browser seems to have it. Investigate removal or standardization.

Comment 1

[Philip Jägenstedt [:foolip]]

Added in https://bugzilla.mozilla.org/show_bug.cgi?id=30067 15 years ago.

Comment 2

[:Gijs (he/him)]

Not sure if this is really better off on a mailing list... CC'ing some potentially interested parties to let them decide.

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

Given the mess Bug 679971 caused, we certainly need a telemetry probe for this first.

Comment 4

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

I looked into this once some years ago, and decided against it; I don't remember why, though.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yeah, a quick search with site:github.com shows crap like this:

  function what_browser() {
          var chromematch = / (Chrome)\/(.*?) /,
              ffmatch =     / (Firefox)\/([0123456789ab.]+)/,
....
          match = navigator.userAgent.match(chromematch);
          if (match && match[1]) {
              return {
                browser: match[1],
                version: match[2],
                oscpu: navigator.platform
              }
....
          match = navigator.userAgent.match(ffmatch);
          if (match && match[1]) {
            if (navigator.oscpu.match(/Windows /)) {
              return {
                browser: match[1],
                version: match[2],
                oscpu: navigator.platform
              }

(and then in IE it uses navigator.cpuClass + "/" + navigator.platform, and so forth).

How widely this sort of thing is deployed is unclear, of course, but it seems fairly likely that the compatible thing to do is to spec oscpu in some way, and we'd need telemetry data to prove otherwise.

Comment 6

[Philip Jägenstedt [:foolip]]

That's no too surprising. If you think that standardization is feasible, please CC me on the spec bug.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Done, https://www.w3.org/Bugs/Public/show_bug.cgi?id=27820

Comment 9

[j.j.]

This is specced for some time now as Gecko navigator compatibility mode
https://html.spec.whatwg.org/multipage/system-state.html#client-identification

So can we close this bug as FIXED?

Comment 10

[Thomas Wisniewski [:twisniewski]]

Do we want to continue shipping it as-is, or return the empty string to help with fingerprinting? Also, are we satisfied being the only browser using this compatibility mode, or should we try to align with the others?

Comment 11

[j.j.]

if the proposal "Remove browser and OS architecture from Firefox's User-Agent string?"
https://groups.google.com/forum/m/#!topic/mozilla.dev.platform/vEMIqgnMxRw

was done, at least the same removal had to be done in navigator.oscpu for fingerprinting reasons.

Comment 12

[Chris Peterson [:cpeterson]]

(In reply to j.j. from comment #11)

if the proposal "Remove browser and OS architecture from Firefox's User-Agent string?"
https://groups.google.com/forum/m/#!topic/mozilla.dev.platform/vEMIqgnMxRw

was done, at least the same removal had to be done in navigator.oscpu for fingerprinting reasons.

In that thread, dbaron asked if we should keep navigator.oscpu so sites can differentiate 32- and 64-bit OS (e.g. to offer compatible software downloads). That would still allow active fingerprinting, but JavaScript might be able to detect other differences between 32- and 64-bit browsers anyways. We could still remove the platform architecture from the UA string to limit passive fingerprinting by servers.

Alternately, we could support platform detection by making navigator.userAgent return a UA string with the platform architecture (like today's current UA string) while the User-Agent header sends a UA string without the platform architecture. Then navigator.oscpu could return the empty string "" because it wouldn't be needed.

I don't know which is approach is uglier. :) Every browser has a UA string, but only Gecko has navigator.oscpu. Returning an empty string "" from navigator.oscpu (and using different UA strings in the User-Agent header and navigator.userAgent) would be a path converging towards to other browsers.

Poking around on GitHub, I see quite a few scripts using navigator.oscpu as a fallback option for sniffing the platform, but the half-dozen or so scripts I looked at all verified that navigator.oscpu was defined before using it. So we might be able to make navigator.oscpu return an empty string "" (or just remove it and return undefined) without significant breakage.

Here is the Chromium issue to consider adding navigator.oscpu for Gecko compat:

https://bugs.chromium.org/p/chromium/issues/detail?id=602611