225322 - navigator.platform should be configurable via a pref (about:config)

Status: RESOLVED INACTIVE

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

Description

[Kim Saunders]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Galeon/1.3.10 (Debian package 1.3.10-3)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031024 Galeon/1.3.10 (Debian package 1.3.10-3)

navigator.platform should be configurable (i.e., able to be overridden) via a
pref (through about:config).

Unfortunately, some websites use javascript to inspect navigator.platform, and
introduce undesirable effects based on the string returned. This has the
unfortunate effect that these websites will work on mozilla running on one
platform, yet fail deny access to users running the same version of mozilla,
with the same features, on another platform.

While this is undeniably an issue with the websites involved, it should be
possible for a mozilla user to override the string returned by
navigator.platform to spoof another platform as a last resort.

Ultimately, it should be possible to configure mozilla to be indistinguisable
from a given browser/platform an HTTP headers and javascript perspective -
mozilla implements this for the user agent string, but it remains possible to
determine the platform in a way that is not configurable via navigator.platform.

Reproducible: Always

Steps to Reproduce:
Enter the Javascript Console.
Inspect the string string returned by `alert(navigator.platform)'

Comment 1

[Simon Paquet [:sipaq]]

I think http://extensionroom.mozdev.org/#uabar or
http://extensionroom.mozdev.org/#useragentswitcher are what you're looking for.

-> INVALID

Comment 2

[Kim Saunders]

Unfortunately, neither of these extensions affect the string returned by
navigator.platform (implemented as GetPlatform in nsGlobalWindow.cpp).

Comment 3

[[e-mail]]

Note that some chrome code depends on the value of navigator.platform ...

Comment 4

[Kim Saunders]

Attachment: proposed patch implementing general.useragent.oscpu pref

This patch implements a pref, general.useragent.oscpu, which allows the user to
supply an oscpu string to use instead of the operating system provided string.

If the pref doesn't exist, or is empty, then the existing behaviour is
preserved. If the string is set and not empty, then that string is used as the
oscpu value that is returned by navigator.platform and navigator.oscp, as well
as the platform component of the user agent string.

Comment 5

[Darin Fisher]

in fact there's quite a bit of Mozilla JS code that relies on navigator.platform: 

http://lxr.mozilla.org/mozilla/search?string=navigator.platform

how badly do you need this?  i don't think we want to officially support a
preference to change this value.  i fear the strange bugs that might result if
someone goes and tweaks this value and then forgets about it.  that said, it's
not like we don't have other prefs that can be seriously misused...

i almost wish we had a separate notion of UA for chrome (and other internal uses).

Comment 6

[Darin Fisher]

Comment on attachment 140059 [details] [diff] [review]
proposed patch implementing general.useragent.oscpu pref

i'll accept this patch if you clean out the tabs (always use spaces instead of
tabs in mozilla code) and indent things nicely (be consistent, make sure stuff
lines up)

thanks :)

Comment 7

[[e-mail]]

What about navigator.appVersion, can we rely on that instead?

Comment 8

[Kim Saunders]

Attachment: general.useragent.oscpu patch with correct spacing

New patch, as per 140059, but with spacing rather than tabs, and aligned in the
same manner as the pref code that surrounds it.

Comment 9

[Kim Saunders]

(In reply to comment #5)

> how badly do you need this?  i don't think we want to officially support a
> preference to change this value.  i fear the strange bugs that might result if
> someone goes and tweaks this value and then forgets about it.  that said, it's
> not like we don't have other prefs that can be seriously misused...

Personally - I need it fairly badly. I've been using it for several weeks now,
and a few collegues have applied it too, but it is of course rather inconvenient
having to compile mozilla using this patch on each workstation.

general.useragent.oscpu should be considered a last resort - one shouldn't
expect to be able to set it to any random string and have it not affect mozilla
internally. It's merely better than a "go and get IE" page - a last resort, not
something to play with.

> i almost wish we had a separate notion of UA for chrome (and other internal uses).

I think the moral of the story is that everything that is sent to a webserver,
or accessible with client-side code, should be configurable. And accordingly,
perhaps chrome should _not_ rely on values which are accessible via normal js,
(and hence configurable)?

Comment 10

[ac]

I also would find this patch very useful as atm I am barred from using various 
sites which I find necessary to access with the default Mozilla. Currently I 
have been changing the hard coded string in the GetPlatform routine everytime I 
compile Mozilla. This is a lot of a hack and I would love to see a cleaner 
solution, like the one proposed, to be implemented.

Comment 11

[Darin Fisher]

Comment on attachment 141561 [details] [diff] [review]
general.useragent.oscpu patch with correct spacing

>+    // general.useragent.override
>+    if (PREF_CHANGED(UA_PREF("oscpu"))) {
>+        prefs->GetCharPref(UA_PREF("oscpu"),
>+                            getter_Copies(mOscpu));

nit: no need for linebreak after the ','

>+        mUserAgentIsDirty = PR_TRUE;
>+
>+        // redo InitUserAgentComponents to fetch OS supplied value
>+        if (mOscpu.IsEmpty())
>+            InitUserAgentComponents();

nit: since InitUserAgentComponents sets mUserAgentIsDirty to true,
you might want to write this instead:

	// redo InitUserAgentComponents to fetch OS supplied value
	if (mOscpu.IsEmpty())
	    InitUserAgentComponents();
	else
	    mUserAgentIsDirty = PR_TRUE;

comment: InitUserAgentComponents seems like a bad name for that
function, huh?	all it does is set mPlatform and mOscpu.  perhaps
those two tasks should be separated.  at any rate, that doesn't
have to happen for this patch.


r+sr=darin with those two nits fixed.

Comment 12

[Darin Fisher]

actually, have you tested this patch?  the code for navigator.platform uses
hard-coded values on many platforms:

NS_IMETHODIMP
NavigatorImpl::GetPlatform(nsAString& aPlatform)
{
  nsresult res;
  nsCOMPtr<nsIHttpProtocolHandler>
    service(do_GetService(kHTTPHandlerCID, &res));
  if (NS_SUCCEEDED(res) && service) {
    // sorry for the #if platform ugliness, but Communicator is
    // likewise hardcoded and we're seeking backward compatibility
    // here (bug 47080)
#if defined(WIN32)
    aPlatform = NS_LITERAL_STRING("Win32");
#elif defined(XP_MAC) || defined(XP_MACOSX)
    // XXX not sure what to do about Mac OS X on non-PPC, but since Comm 4.x
    // doesn't know about it this will actually be backward compatible
    aPlatform = NS_LITERAL_STRING("MacPPC");
#elif defined(XP_OS2)
    aPlatform = NS_LITERAL_STRING("OS/2");
#else
    // XXX Communicator uses compiled-in build-time string defines
    // to indicate the platform it was compiled *for*, not what it is
    // currently running *on* which is what this does.
    nsCAutoString plat;
    res = service->GetOscpu(plat);
    CopyASCIItoUCS2(plat, aPlatform);
#endif
  }
                                                                               
                                          
  return res;
}

in fact, the patch is no good for Windows, Mac, and OS/2.  It only works for
Linux and other X11-like platforms.

this makes me have second thoughts about accepting this patch.

Comment 13

[jag (Peter Annema)]

Is this code right?

    nsCAutoString plat;
    res = service->GetOscpu(plat);
    CopyASCIItoUCS2(plat, aPlatform);

Shouldn't that second line use |service->GetPlatform(plat);|?

Comment 14

[jag (Peter Annema)]

Ah, nope, see bug 47080

Comment 15

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.