If you use Mozilla Firefox or any Chromium-based browser, notably Google Chrome or Microsoft Edge, you’ll know that the version numbers of these products are currently at 97 and 98 respectively.
And if you’ve ever looked at your browser’s User-Agent string, you’ll know that these version numbers are, by default, transmitted to every web page you visit, as a kind of handy hint to say, “Look who’s coming to dinner.”
In an ideal world, the User-Agent header would be entirely redundant, given that websites are supposed to float disinterestedly above such petty details as which operating system you have, what CPU it’s running on, how many bits it works with, what graphics system you’re using, and which brand of browser you’ve chosen.
But here on Planet Earth, some websites need to know these details in order to adapt their behaviour accordingly, and many websites love to know them because…
…well, because from data like this you can mine information; from information you can infer knowledge; and knowledge, as the saying goes, is power.
What is your browser giving away about you?
If you’ve never seen your browser’s headers in real life, there are two easy ways to do so.
The first is to use your browser’s Developer Tools (try Ctrl-Shift-I), open the Network tab and then visit a website – the content of each outgoing HTTP request, including headers, and its related HTTP response, gets logged for you and can be examined at your leisure.
After loading the page, click on one of the requests, choose the Headers tab and scroll to the Request Headers section:
The second fun way is to watch from the other end of the connection by pretending to be a web server.
Install the Nmap toolkit from nmap.org, open up a command prompt (or a shell, or a terminal window, if you prefer those terms), and use the ncat command to listen for incoming local network connections, say on port 7777.
Then put the URL http://127.0.0.1:7777/ into your browser’s address bar, to tel your browser to connect to the listening ncat process, where the HTTP request will be received exactly as transmitted, and the headers therefore printed out on the screen in the order they arrived.
Here’s the current version of Firefox (97.0.1 on 2022-02-25T16:00Z) calling an ncat pseudo-webserver:
$ ncat -vv 127.0.0.1 -l 7777 Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Listening on 127.0.0.1:7777 Ncat: Connection from 127.0.0.1. Ncat: Connection from 127.0.0.1:54810. GET / HTTP/1.1 Host: 127.0.0.1:7777 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:97.0) Gecko/20100101 Firefox/97.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-GB,en;q=0.5 Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1 Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: none Sec-Fetch-User: ?1
(You’ll need to hit Ctrl-C in the ncat window to close the connection, otherwise your browser will sit there indefinitely, waiting for an HTTP reply that never comes.)
The current version of Edge, based on Chromium, is (by chance, not by design) one ahead, at 98:
$ ncat -vv 127.0.0.1 -l 7777 Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Listening on 127.0.0.1:7777 Ncat: Connection from 127.0.0.1. Ncat: Connection from 127.0.0.1:54738. GET / HTTP/1.1 Host: 127.0.0.1:7777 Connection: keep-alive sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="98", "Microsoft Edge";v="98" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Linux" Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.102 Safari/537.36 Edg/98.0.1108.56 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9
As you can see, there are plenty of different version numbers and other details that an interested web server could extract from those headers: a single-digit Mozilla number (5); a three-digit AppleWebKit and Safari number (537); two- and four- digit components in the Edg designator (56, 1108).
How hard could it possibly be for a modern website – one that is probably complex enough that is has funky JavaScript menus, third-party analytics and tracker addins, high-resolution images and perhaps even video and audio content – to make sense of a simple text string with an obvious textual pattern, such as the data you see in the User-Agent strings above?
Hard enough, apparently that both the Firefox and Chromium communities have been fretting about what to do when their respective browsers reach version 100, and the first part of any multi-part version number switches from two digits to three.
Amazingly, though thankfully quite rarely, there really are still websites that will get flummoxed when the switchover happens, and will make millennium-bug style blunders by failing to figure out the version number at all.
Some sites, indeed, are still making Y2K-type calendar miscalcuations by “figuring out” that any number of 100 or more “computes” as less than 99, or 98, or 97, or presumably any other positive integer all the way down to 1.
Given that the header processing is done on the server, we can only guess at how it works. So, it’s impossible to determine exactly what sort of bugs exist on servers with this sort of problem. Some servers might call v100 browsers “old” when they actually mean “we hit a parsing problem, so we’re blaming you and falling back on our default error page”. Others might interpret the string “100” as 10, if they simply chop off the end of the string to limit it to the usual two characters, or as 00 if they truncate it from the other end. Or they might end up with zero as a sort of uninitialised default, meaning “we hit an error but didn’t realise”. Because both 0 and 10 are a lot less than 97 or 98, the server might therefore settle for the convenient assumption that you haven’t updated your browser for a decade, rather than accepting that there could be a server-side bug and giving you the benefit of the doubt.
Surely some mistake?
We’d largely ignored this issue, which Firefox and Chrome alike have been testing for since 2021 by providing experimental settings for testers that made the browser report a major version of 100 ahead of time.
Firefox even has a special “compatibility” setting (visit the URL about:compat to see these), kicked off some three months allow, to build a list of known websites that might need lying to when version 100 rolls around for everyone.
Chromium browsers, likewise, introduced a special flag dubbed force-major-version-to-100 (visit chromium://flags or edge://flags to find it) so testers could try out a version number of 100 ahead of time.
Indeed, Chromium browsers even have special flag called force-minor-version-to-100, so that instead of, say, 98.0.4758.102, as you saw above, you’ll get something like 98.100.4758.102 (or the slightly weird hybrid version number 98.100.1108.56 on Edge) instead.
That “minor version” flag was put there specifically to test the viability of a third special flag workaround, which will be available when version 100 comes along: the “surely we don’t need something this silly in 2022” option called force-major-version-to-minor:
We didn’t think a hack of this sort would be useful, or even necessary, but we were forced, if you will pardon the poor pun, to explore this new option…
…when we noticed that the release notes for the latest developer version of Microsoft Edge, which came out last night, specifially mentioned that the new release:
Enabled a management policy from Chromium to force the major version number to the minor position In the user agent string, which is a temporary policy to freeze the major version number at 99 and place the actual version number in the minor position, for example turning version 101.0.0.0 into 99.101.0.0.
Edge-dev, as the Developer channel version is known, runs one major version ahead of Edge Beta, which runs one version ahead of Edge Stable, which is what most people use, especially on business computers.
Because Edge Stable is now at 98 (see above), that means Edge-dev is already at 100, as you can see from ncat here, when we visited with the latest Edge-dev version:
$ ncat -vv -l 7777 Ncat: Version 7.92 ( https://nmap.org/ncat ) Ncat: Listening on :::7777 Ncat: Listening on 0.0.0.0:7777 Ncat: Connection from 127.0.0.1. Ncat: Connection from 127.0.0.1:54746. GET / HTTP/1.1 Host: 127.0.0.1:7777 Connection: keep-alive sec-ch-ua: " Not A;Brand";v="99", "Chromium";v="100", "Microsoft Edge";v="100" sec-ch-ua-mobile: ?0 sec-ch-ua-platform: "Linux" Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4867.0 Safari/537.36 Edg/100.0.1169.1 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Sec-Fetch-Site: none Sec-Fetch-Mode: navigate Sec-Fetch-User: ?1 Sec-Fetch-Dest: document Accept-Encoding: gzip, deflate, br Accept-Language: en-US,en;q=0.9
The Edge-dev team clearly seem to think that there are still sufficiently many websites out there that aren’t Y2K, sorry, v100 ready that the Chromium “fallback plan”, as it’s known, hatched back in December 2021, can be considered vital rather than merely useful:
What could go wrong?
The website webcompat.com, which is monitored by Mozilla volunteers, amongst others, has a GitHub page where you can report numerous types of incompatibility, including web bugs relating to V1H problems.
(We’ve dubbed this the V1H bug, using H to stand for hecto-, from the Greek words fo 100, as in hectopascals, or hPa, used as a standard unit for barometric pressure, or hectare, denoting a land area of 100mx100m, echoing the way that Y2K used K for kilo-, meaning 1000).
We installed Edge-dev, and tried one of the sites recently reported in the Webcompat V1H list, namely daimler.com, which redirected us to a Mercedes-Benz page that decided our three-digit browser version was way out of date, rather than brand new:
With Edge Stable, currently at v98, the site worked fine, with the Mercedes-Benz redirect showing us a page to inform us that the company Daimler AG has, since the start of this month, been renamed to Mercedes-Benz Group AG.
Ironically, perhaps, the daimler.com site didn’t do any better when we activated the force-major-version-to-minor option, making the browser seem to be v99 with a minor idenfitier of 100, which suggests that a three-digit minor version number is beyond its comprehension.
what to do?
- If you’re a web user, the transition will probably be like Y2K: most sites will work fine, and many will never have had this as a potential bug anyway. But if there are problems with sites you need to reach, at least you know that there are workarounds anticipated by the browser makers to help you out.
- If you’re a web programmer, this sort of thing really shouldn’t be a problem for you. After all, if three-digit version numbers are beyond your grasp, what impression does that give your visitors about the reliablity of how you might process other variable-length data such as payment amounts, credit card details, postcodes and other personal information?
There are still a few weeks left before the general public starts calling you with Chrome 100, of Edge 100, or Firefox 100, so test your own web properties before it’s too late.
Now you know how!