navigator.buildID leaks true version even when UA spoofed

RESOLVED DUPLICATE of bug 417994

Status

()

Core
DOM: Core & HTML
RESOLVED DUPLICATE of bug 417994
12 years ago
8 years ago

People

(Reporter: dveditz, Assigned: zach)

Tracking

({privacy})

Trunk
x86
Windows XP
privacy
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

12 years ago
The new navigator.buildID reports the true buildID even when the user is spoofing the user agent. This value should have an override in the same way nsNavigator::GetAppName and GetAppVersion do.
(Assignee)

Comment 1

12 years ago
While I understand the concern, or at least I think I do, I'm not entirely sure how this should be implemented. 

Lots of other properties of the navigator object leak true version info even when the UA is spoofed, such as (at least in my experimentation on today's branch nightly) navigator.appVersion, navigator.oscpu, and navigator.appName. 

By an override, do you mean a hidden pref the user can set so that navigator.buildID returns whatever is in the pref? 

This seems like a much broader issue. To do this right, we would need overrides for pretty much all the navigator properties. Right now, you can just call navigator.productSub and get the partial build id (everything but the hour) even when the UA is spoofed.

Also, any real fix for this should presumably want navigator.buildID to work properly from chrome even when the UA is spoofed?
(Reporter)

Comment 2

12 years ago
> I'm not entirely sure how this should be implemented.

"the same way nsNavigator::GetAppName [does]":
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/dom/src/base/nsGlobalWindow.cpp&rev=1.876#7683

> Lots of other properties of the navigator object leak true version info even
> when the UA is spoofed, such as (at least in my experimentation on today's
> branch nightly) navigator.appVersion, navigator.oscpu, and navigator.appName.

there are separate prefs you need to set for each property (Not the way I would have done it, nor the pref names I would have chosen).

But you appear to be right about oscpu, so why bother to make the equivalent navigator.platform spoofable? Hmm

It looks like productSub is not set up to allow spoofing in this way, so I guess buildID isn't any worse. Maybe this bug should morph into a "why is this so inconsistent?" bug. Did they originally just do the minimum to get specific broken sites to work? Am I incorrectly assuming this ever had anything to do with privacy? If that's the case then I guess this doesn't matter all that much.

> Also, any real fix for this should presumably want navigator.buildID to work
> properly from chrome even when the UA is spoofed?

That's what the "if (!nsContentUtils::IsCallerTrustedForRead())" test is all about.

Comment 3

11 years ago
This should be fixed with bug 417994 ?
(Assignee)

Comment 4

10 years ago
This looks like it was fixed, as j.j. says, with bug 417994. 
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 417994
You need to log in before you can comment on or make changes to this bug.