Daniel wrote:
As an example, I have added some new entries where I changed the string accordingly with host I reach; general.useragent.override.google.com -- string set to: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0

I've done precisely this with Google.  That one clears the display quirk that's in Google's search bar. For some reason, Google doesn't like a Firefox UA that shows the name of Firefox-derived project. They want only stock Firefox. If I remember correctly, PaleMoon has the same issue as Seamonkey.

By-the By, it seems some sites would work correctly for

Mozilla/5.0  (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 Firefox/67.0 SM/2.53.1

whilst others would require

Mozilla/5.0  (Windows NT 6.1; WOW64; rv:67.0) Gecko/20100101 SM/2.53.1 Firefox/67.0

It seems it may matter which is first and/or which is last! Whilst others would work correctly for either!

Just curious -- are you abbreviating Seamonkey as "SM" in your own use, or are you just doing that for reference here?

Underneath, what's going on is sites that are checking for certain things, usually using scripting, but not always. Most tend to look just for an acceptable Firefox version. For some, having it anywhere in the UA string is acceptable, but some may be looking in a specific location, either at the end of the string (which is easier to find), but I suspect some want to see "Firefox" immediately following the Gecko designation (and nothing in-between). I haven't used PaleMoon enough to see how its default UA behaves, where "Gecko" is replaced with "Goanna" (a Gecko fork), followed by "Firefox", then "PaleMoon". And I haven't interacted enough with PaleMoon users to know if they have occasional need to do spoofing.

I noted that user agent sniffing normally is scripting based, because sites also tend to use the scripting to deliver a warning, often by redirecting to a full page. I probably don't see as much of that as I could, because of my liberal use of NoScript. However, there's other ways of sites blocking access to browsers they don't want to see. In server configs, there's a file called .htaccess that's used for a variety of things (especially page redirects), but it's also possible to use regular expressions to evaluate the presented User Agent string. If the string is deemed unacceptable, then the connection is simply dropped.

I use this methodology on the page I maintain. Our site gets a lot of bot-based traffic that shows forged UAs. And a lot of the forging is sloppy -- a common problem is misspelling, or improper punctuation or spacing, stuff that would never be found in a valid UA. One that I've seen a lot of traffic on is one that purports to be "Firefox/40.1". That version was never valid, and so I drop any connections where I see that designation. I also drop connections for really old versions of browsers, because chances are much higher that they're being shown by bots than than legitimate users.

This is one of the places where I find the ability to do spoofing on the fly to be really useful. If I'm testing my filters for UA handling, it's really easy to set a UA string for what I'm filtering for, and then I can actually test whether my server will accept or reject that particular string.

With this in mind, it's generally a good idea to not get too creative in what you put in a UA string. For some sites, a too-unique string might be something that a site admin decides is evidence of bot activity, and use that as a reason to drop or refuse your connection. And there's a few out there that are sensitive enough about tracking and personal identification issues that they either spoof all the time, or do random shuffling of UA strings, as a consideration of what ends up in server logs. I don't know that there's a way of doing that kind of thing in Seamonkey, but I do recall seeing somewhere that there are people who may be doing that with other browsers.

Smith
_______________________________________________
support-seamonkey mailing list
support-seamonkey@lists.mozilla.org
https://lists.mozilla.org/listinfo/support-seamonkey

Reply via email to