Closed Bug 225322 Opened 21 years ago Closed 3 years ago

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

Categories

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

enhancement

Tracking

()

RESOLVED INACTIVE

People

(Reporter: kims, Unassigned)

Details

(Whiteboard: DUPEME)

Attachments

(1 file, 1 obsolete file)

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)'
Unfortunately, neither of these extensions affect the string returned by
navigator.platform (implemented as GetPlatform in nsGlobalWindow.cpp).
Whiteboard: DUPEME
Note that some chrome code depends on the value of navigator.platform ...
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.
Attachment #140059 - Flags: review?(darin)
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 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 :)
Attachment #140059 - Flags: review?(darin) → review-
What about navigator.appVersion, can we rely on that instead?
New patch, as per 140059, but with spacing rather than tabs, and aligned in the
same manner as the pref code that surrounds it.
Attachment #140059 - Attachment is obsolete: true
(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)?
Attachment #141561 - Flags: review?(darin)
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 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.
Attachment #141561 - Flags: superreview+
Attachment #141561 - Flags: review?(darin)
Attachment #141561 - Flags: review+
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Is this code right?

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

Shouldn't that second line use |service->GetPlatform(plat);|?
Ah, nope, see bug 47080
Assignee: general → nobody
QA Contact: ian → general
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.
Priority: -- → P5
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: