Extraneous Product/Version Combinations in User Agent? (ex: Herring/94.1.8750.51, OpenWave/96.4.6033.34)

Firefox Development
#1

Recently we have been seeing a very small fraction of requests from Firefox with extraneous product/version combinations in the User-Agent header as well as in navigator.userAgent. They do not appear to be concentrated in a particular part of the world, and we see requests coming from IPs within residential ISP space.

These random product/version combinations take the form <Label> /XXX.X.XXXX.X appended to the end of an expected firefox user agent, for example:

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:103.0) Gecko/20100101 Firefox/103.0 OpenWave/96.4.8603.4

The labels that we know of are:

  • Agency
  • AtContent
  • Config
  • GLS
  • Herring
  • LikeWise
  • OpenWave
  • Trailer
  • Unique
  • Viewer

A cursory google search for each of the different labels doesn’t bring up any mention of development chatter, or really any mention of this phenomenon at all. However, if you look at a few SEO junk sites listing common User Agent patterns, you can see some of these weird product/version patterns appear, ex: https://whatmyuseragent.com/browser/ff/firefox/103 - meaning that this isn’t happening on a few sites, this is likely happening across the broader internet.

From an external perspective, this could be some smoke test of UA sniffers, similar to TLS GREASE or User-Agent Client Hinting GREASE, but there’s no discussion of this anywhere that I can find. So my question is:

Is this an effort by Mozilla/Firefox Devs?

We’re mainly interested in finding out where this odd phenomenon is coming from, whether it’s from a browser-based experiment, from some strange extension, or from a specific actor.

1 Like
#2

In some cases, this might be caused by Avast AntiTrack or AVG AntiTrack or other security software or proxies. Add-ons might also be implicated.

1 Like
#3

We are seeing exactly the same issue. I have been able to connect to an offending machine, and ascertained that the issue is not in the web-browser. The issue affects Chrome, Edge and Firefox. You can hard-code the UA string in DEV tools, and when you inspect the network traffic in the browser, the UA is transmitted uncontaminated. But by the time it hits the server it has been tampered with. See below:

Transmitted by browser in headers:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36

Request 1 hitting the server:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 Trailer/90.3.4112.13

Request 2 hitting the server:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36 Agency/100.8.3787.88

I think AVG anti-virus is to blame. Once it was removed and replaced with BitDefender or Avast, the problem went away. I’m going to contact AVG now to see if they are the culprit. Hopefully other people will find this post and add to it and we can start to get to the bottom of the issue.

If the UA is used as part of your authentication / security then the change between requests is a real nuisance.

2 Likes
#4

I was looking to find someone discussing this issue. I was nowhere near pinpointing the possible source of this. I’ve had complaints from one of my colleagues that he was constantly being logged out of our back-office… the login uses the userAgent as part of its session fingerprint.

When checking the back-office logs I noticed that he was logging in and then kicked out immediately afterwards because on login the userAgent would have one of those suffixes but for whatever reason would revert to the vanilla userAgent on the next page which would regenerate the fingerprint and upon comparing to the session’s would kick him out.

After a dozen attempts somehow the suffix seems to have stayed in place during and after the login so he’s wasn’t kicked out again, but seems a bit random. I just found out now from what is discussed above, haven’t had the chance to check with him yet, but most probably he has Avast or some other weird software.

In my logs I’ve seen these from the same system, hours/days apart:

  • Trailer/90.3.1672.73
  • Trailer/97.3.5962.63
  • Trailer/91.3.4592.93
  • Herring/95.1.7770.71
  • Herring/93.1.6670.71
  • GLS/92.10.7639.40
  • GLS/93.10.8619.20
  • GLS/97.10.9069.70
  • LikeWise/100.6.6855.56
  • LikeWise/95.6.8655.56
  • Agency/92.8.5317.18
  • Agency/97.8.2227.28
  • Viewer/90.9.3138.39
  • OpenWave/96.4.9653.54
  • AtContent/90.5.8404.5
  • Unique/100.7.3606.7

Maybe this is some kind of privacy protection to confuse tracking? I’m thinking I may filter out, but shouldn’t take long for the suffixes to change, unless they just plan on jumbling the “version” number and nothing else.

#5

After testing we believe this is caused by CCleaner’s Kamo. This is not a Firefox-specific issue; rather, the data is appended to the user-agent of any browser on the system where Kamo is installed.

1 Like
#6

I’ve had a similar problem to the one described here and I’m very grateful to all that have contributed. You all helped me find the final step in fixing the problem.

In my example I had one user trying to access a web application. Most of it worked but one function consistently failed and the error message complained about a lack of permission. It was only him that had the problem. He normally used Firefox but had the same symptoms when using Chrome. If I used his credentials to log in from a browser on my machine everything worked fine.

I had no idea what was causing this so, as I had access to the PHP code, added debugging statements that wrote key information to a log file. It’s not great practice to do this but it was feasible in my case. By comparing a scenario that worked with a scenario that failed I eventually found that the difference between the two was in the HTTP user agent string. My application uses the HTTP user agent string as one of several components to identify a user.

My users’s machine was putting out the following user agent string:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36 Unique/97.7.6998.67

When the access failed the user agent string was:

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

You can see the addition of “Unique/97.7.6998.67”. None of the other users had this on the user agent string. Looking at this with the benefit of having fixed the problem I can see that the problem wasn’t caused by the presence of the very odd “Unique/97.7.6998.67”.
It was the fact that the user agent string changed between two consecutive accesses (one access had the string and the next one didn’t) that caused the failure with the permissions error, presumably due to a bug in the software that was adding it.

It was by doing a search for firefox, user agent string and unique that I ended up on this forum thread. This thread gave me the clue that the problem lay with anti-tracking software. I had a Zoom call with my affected user and he shared his desktop with me. On his start menu was AVG Anti Track so we went in there and added an exception to tell it not to run anti-track on my site’s domain. This fixed the problem. Thanks all.