Jump to content

Spoofing Firefox 53 (and newer versions) on Windows 2000 and XP


Recommended Posts

43 minutes ago, Mathwiz said:

it works fine in St 52 (spoofing FF 60.9 as usual), but not in St 55
(snip)
pressing the branch button just shows a thin horizontal line and won't list your branches.
I'm really confused as to why, but anyway, I can use St 52 unless/until I find a workaround for St 55.

Latest Serpent 55/Moebius works fine on GitHub here, if the following SSUAO is employed for domain "github.com": 

general.useragent.override.github.com;Mozilla/5.0 (Windows NT 6.1; rv:53.0) Goanna/4.0 Basilisk/55.0.0

Proof (new clean profile, no extensions):

VDrTNnW.jpg

50 minutes ago, Mathwiz said:

Sorry to press the panic button prematurely.

Forgiven ;) ; but you did scare the cr*p out of me! :( I thought we were good at least until Quantum 60.x.x becomes EoS later in the year...

Link to comment
Share on other sites


Great! I'll put that right into effect; I hate having to use two different browsers.

I'd love to know why St 55 requires a different SSUAO than St 52, but as long as it works, that may just have to remain an unsolved mystery.

Link to comment
Share on other sites

13 hours ago, Mathwiz said:

I'd love to know why St 55 requires a different SSUAO than St 52

... Would you really? First, you'd have to acknowledge that Serpent 52.9.0/UXP and Serpent 55.0.0/Moebius are two different applications on two different platforms (because I often sense a notion, shared by many here, that they are, in fact, quite similar :no: ...); the former is under active development by the upstream devs, while the latter only receives the occasional "experimental" update by its current maintainer...

MCP have changed pref general.useragent.compatMode.version in St52 to value 60.9; this means that the Firefox portion of St52's UAS claims rv:60.9, this alone satisfies GitHub's needs and "github.com" should work out-of-the-box; with recent builds of St52, one does not need a SSUAO for Github per se:

(on Vista:) Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 Basilisk/52.9.0

unless the global UAS has been modified to something claiming older Firefox versions...

semi-OT: To ensure better compatibility with the largest number of sites, I have turned ON both Gecko and Firefox compat modes:

general.useragent.compatMode.firefox;true
general.useragent.compatMode.gecko;true

so my global St52 UAS reads:

Mozilla/5.0 (Windows NT 6.0; rv:60.9) Gecko/20100101 Goanna/4.2 Firefox/60.9 Basilisk/52.9.0

In the case of Serpent 55, the value of pref general.useragent.compatMode.version has remained at 55.0 (<60.0), additionally Gecko & Firefox compat modes are defaulted to true; this means github.com sees the client as Firefox 55:

Mozilla/5.0 (Windows NT 6.0; rv:55.0) Gecko/20100101 Goanna/4.0 Firefox/55.0 Basilisk/55.0.0

, hence it gets broken and doesn't work out-of-the-box there...

You have several options to restore GitHub on St55, the one I suggested was to use a SSUAO which doesn't contain any Firefox portions (github.com gets "confused" and serves moebius compatible code):

Mozilla/5.0 (Windows NT 6.0; rv:55.0) Goanna/4.0 Basilisk/55.0.0

... or you could modify pref general.useragent.compatMode.version to 60.0; in that case, the global UAS will read:

Mozilla/5.0 (Windows NT 6.0; rv:60.0) Gecko/20100101 Goanna/4.0 Firefox/60.0 Basilisk/55.0.0

and github will work (but "instagram", "player.pl" and possibly others will break...).

To conclude on this, my tests have shown that you can use in St55 the same SSUAO that works in St52 (which, as explained, doesn't necessarily need one!) to restore GitHub functionality; e.g., I just used

Mozilla/5.0 (Windows NT 6.0; rv:60.9) Goanna/4.2 Basilisk/52.9.0

successfully in latest Serpent 55.0.0 ;)

Edited by VistaLover
Link to comment
Share on other sites

I was going to run that experiment myself, in the hopes of finding a "universal" Github SSUAO to incorporate into myuseragents.js; thanks for doing that for me!

But here's what I'm really wondering. If you use St 52 (or FF 52), and a FF 60.9 user agent, Github serves up code that is compatible with FF/St 52, and works. But if you use a FF 60.9 agent with St 55, it doesn't work; even though Github is seeing the same user agent, and thus presumably serving the same code, as with FF/St 52.

Now I realize that St 55 was forked from FF 53, while St 52 was forked from FF 52 ESR, so there are bound to be differences in how javascript, CSS, etc. are handled. But the question I still have is, what kind of code works on FF 52, and on St 52, but doesn't work on St 55; and why?

Sounds to me like there's a regression somewhere in either FF 53 or St 55, but my troubleshooting skills aren't up to the task of finding it. And although I can't test it myself, probably doesn't work on FF 53 either, although it might have been fixed again between the fork point and the release build of FF 53.

Edit: Folks, I'm afraid further apologies on my part are necessary. It turns out that Github works just fine with both St 52 and St 55 (as well as FF 52, PM/NM 28, etc.) using a FF 60.9 user agent! This whole discussion has been a huge waste of time.

Well, maybe not a complete waste of time, because I did learn something. The culprit, it turned out, wasn't the user agent, or differences between St 52 and St 55, after all: it was a couple of user prefs I'd set to true: dom.webcomponents.enabled and dom.webcomponents.customelements.enabled. I had only set those to improve the score on html5test.com, but it turns out that if either of those is set, Github won't work! :blushing:

Edited by Mathwiz
Link to comment
Share on other sites

2 hours ago, Mathwiz said:

The culprit, it turned out, wasn't the user agent, or differences between St 52 and St 55, after all: it was a couple of user prefs I'd set to true: dom.webcomponents.enabled and dom.webcomponents.customelements.enabled. I had only set those to improve the score on html5test.com, but it turns out that if either of those is set, Github won't work!

Nice catch :thumbup (... and that's another reason why I always advise to check first on a new/clean browser profile in the case of found "issues" :P).

Edited by VistaLover
Link to comment
Share on other sites

Good advice; although that too let me down when I was troubleshooting.... If I went to about:profiles, created a new clean profile, and clicked "Launch profile in a new browser," it would indeed open a new browser window sans add-ons - but all the old profile's preferences were still in effect! To get a truly "clean" profile I have to instead click "set as default profile," then restart the browser (and then reverse the process when going back to "normal"). That silliness kept me from realizing it was a preference issue, until I tried your suggested SSUAOs and discovered it stlll didn't work :crazy:

Link to comment
Share on other sites

@Mathwiz

For troubleshooting purposes, things are much easier when using portable packages/installations; for example, official PM28 (recently updated to v28.5.1) is being distributed also as a WinPenPack portable "setup" (in reality, an extractor): 

NTYIgnn.jpg

You can substitute the contents of the "Bin" directory (respecting folder tree) with latest NM28 binaries... The portable package comes by default with an empty profile (found inside the User directory); by running the portable launcher, you instantly get a pristine/default browser profile to test with! NB that this portable installation does not interact with your "installed" NM28 version, but they shouldn't be run concurrently while testing...

When you want to start fresh with a new clean profile, just back-up/trash the previous one (while the browser is exited) and when you then re-launch Palemoon-Portable.exe, it's like the first time all over again :) ;)

Link to comment
Share on other sites

I use Mozilla series portable this way: install as normal, run  "<app> -p", that will let you manage profiles. Create one at your selected directory instead of the default random name, make that your default. Then go to <C:\Documents and Settings\user>\Application Data\<Mozilla\Firefox | Moonchild Productions\Basilisk> and check profiles.ini. Mine is like this:

[General]
StartWithLastProfile=1

[Profile0]
Name=Default User
IsRelative=0
Path=E:\Firefox
Default=1

The items are easy to understand except "IsRelative=0". I learned this trick from some mozilla doc, but cannot recall exactly what it means. Anyway it will let you put your profiles anywhere and move around freely. Just modify the "Path=<>" after moving. So you don't really need a separate "portable version"; just carry your profile with you.

Edited by luweitest
Link to comment
Share on other sites

  • 4 weeks later...

Bumping this thread to let everyone know I changed myuseragents.js on page 8 to spoof Chrome 49 for web.whatsapp.com, so it will work with FF and Serpent again.

Keep in mind Palemoon/New Moon have their own built-in SSUAO for web.whatsapp.com that will take precedence over myuseragents.js; for those browsers you'll have to change the SSUAO manually in about:config to:

Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/49.0.2049.0 Safari/537.36

 

Link to comment
Share on other sites

  • 3 weeks later...
On 3/23/2019 at 7:16 PM, Mathwiz said:

I tried site-specific overrides in about:config, a la New Moon/Serpent, with FF 52.9.1, but they didn't work for me, even though the general.useragent.site_specific_overrides about:config preference is present and set to "true." If there's some other preference or method required to make site-specific overrides work, please let us all in on the secret!

Once I installed the extension @Dave-H mentioned, I was able to do site-specific overrides via the extension's config page.

 

On 3/24/2019 at 2:12 AM, Sampei.Nihira said:

... to answer your question try to verify if what is written below can be useful:

http://forums.mozillazine.org/viewtopic.php?f=38&t=3031074

 

On 3/24/2019 at 11:04 AM, VistaLover said:

Many thanks @Sampei.Nihira :cheerleader:

By slightly modifying the instructions in the last post of the mozillazine thread you linked to, I was able to restore SSUAO functionality in Firefox 52.9.0[1] 32-bit on my VistaSP2 x86 laptop and bring it on par with the UXP browsers (i.e. SSUAO are now possible natively, without the need for extra extension(s)) :thumbup 

Full Guide (tested only in FxESR52, should work in other Fx versions):

1. Load "about:config?filter=site_specific" in a tab and make sure

general.useragent.site_specific_overrides;true (should be by default)

2. Exit Firefox

3. Create the following text file


pref("general.config.obscure_value", 0);
pref("general.config.filename", "config.js");

rename it to "config-prefs.js" (make sure no hidden .txt extension is present) and place it inside

<FirefoxInstalDir>\defaults\pref\

(a file named "channel-prefs.js" should already be there by default)

4. Create the following text file


// needs to start with a comment line
Components.utils.import("resource://gre/modules/Services.jsm");
Services.obs.addObserver(function (aSubject, aTopic, aData) {
  var chromeWindow = aSubject;
  chromeWindow.setTimeout(function () {
    Components.utils.import("resource://gre/modules/UserAgentOverrides.jsm", chromeWindow);
    chromeWindow.UserAgentOverrides.init();
  }, 1000);
}, "browser-delayed-startup-finished", false);

rename it to "config.js" (make sure no hidden .txt extension is present) and place it inside <FirefoxInstalDir>\ (i.e. in the same directory as firefox.exe). 

5. Launch Firefox; now you are ready to create SSUAOs inside about:config as you would do in New Moon and/or Serpent 52.

I think you'll find the above to your satisfaction... ;)

Wanted to revisit this issue briefly, but only to point out that the above rigamarole isn't needed with @roytam1's builds of FF 45 ESR (for SSE-only CPUs); SSUAOs work right out of the box (or out of the .7z). Not certain if that's also true of "stock" FF 45 ESR, if roytam incorporated a fix at some point that re-enabled SSUAOs, or if they're only enabled in "Nightly" builds (roytam's builds are based on nightly builds; the Firefox button even reads "Nightly" vs. "Firefox"); but I suspect the latter.

According to info gleaned from @Sampei.Nihira's link above, SSUAOs were disabled way back in FF 25 (!) for performance reasons, yet they work in FF 37 beta 4, but not in FF 54 (or 52.9, of course). So I suspect they're enabled in beta and nightly builds, but not in regular release or ESR builds since FF 25. (Info at the link above did hint that they were originally intended for testing.) SSUAOs work in all of roytam's browser builds; the code above is only needed to enable them in "stock" Firefox versions.

Link to comment
Share on other sites

Mathwiz said:


So I suspect they're enabled in beta and nightly builds, but not in regular release or ESR builds since FF 25. (Info at the link above did hint that they were originally intended for testing.) SSUAOs work in all of roytam's browser builds; the code above is only needed to enable them in "stock" Firefox versions.


I think you nailed it now. That's the point I kept overlooking, due to not using those builds myself:
in PURE Firefox site-specific useragents were re-enabled again after awhile - but NOT in regular releases, only in nightlies, betas etc.!
Just guess they disabled it in FF21 already, that's also why K-Meleon7x, which started with gecko24, had it unintentionally disabled too all those years. With no one even aware this very handy function exists and could work - until finally roytam1 came and initialized it. And after KG76 also in KG74.
Link to comment
Share on other sites

11 hours ago, Mathwiz said:

the above rigamarole isn't needed with @roytam1's builds of FF 45 ESR (for SSE-only CPUs); SSUAOs work right out of the box (or out of the .7z). Not certain if that's also true of "stock" FF 45 ESR, if roytam incorporated a fix at some point that re-enabled SSUAOs,

This was a @roytam1 implemented "fix":

https://github.com/roytam1/mozilla45esr/commit/0eaa212

(8 Jun 2018)

11 hours ago, Mathwiz said:

or if they're only enabled in "Nightly" builds (roytam's builds are based on nightly builds; the Firefox button even reads "Nightly" vs. "Firefox")

"Nightly" in this case is the generic app name given to the browser when Mozilla Firefox forked code has been built as an unbranded build; much like New Moon is the default "unbranded" name for Pale Moon forks; so "Nightly" doesn't necessarily always designate a nightly development branch...

12 hours ago, Mathwiz said:

yet they work in FF 37 beta 4, but not in FF 54 (or 52.9, of course). So I suspect they're enabled in beta and nightly builds, but not in regular release or ESR builds since FF 25.

10 hours ago, siria said:

in PURE Firefox site-specific useragents were re-enabled again after awhile - but NOT in regular releases,

I recollect reading/studying most SSUAO-related Bugzilla bugs one year ago or so, but blame the summer heat for me not wanting to search for/ track them down/ post them here :D; what I distinctly remember is that the SSUAO feature in desktop stable & ESR releases of Firefox was re-enabled starting with Firefox 55.0.x and is still present (with possible limitations) in Firefox Quantum (I remember ESR 60.x.x did work when I tested it on a borrowed Win7 machine...); since @Mathwiz has ready access to Win7 SP1, perhaps he could verify my recollections! :P

 

Link to comment
Share on other sites

I do have Firefox 60.8 ESR on my home Win 7 machine; I'll try SSUAOs with it and confirm that they work once again.

Edit: It works!

The whole thing seems odd to me; usually with these browsers, it's MCP removing some useful feature (like WebExtensions or container tabs), and we're begging @roytam1 to revert the change; but in this case it was Mozilla disabling a useful feature, and it was MCP (and roytam) who reverted the change!

Edited by Mathwiz
Link to comment
Share on other sites

  • 1 month later...

@Mathwiz

Saw your Github discussion from a while back because you credited me in an edit to an earlier post, thanks. :) Since I didn't notice you mentioning if you're already doing this or not, let me say just in case that you should probably use the same UA you have for github.com on githubassets.com and githubusercontent.com. The second one may be less important, but I experienced an issue not too long ago with spoofing FF 60.0 only on github.com and some UI script coming from githubassets.com not being in sync with that because of a different version in my non-site-specific UA.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...