|
|
Subscribe / Log in / New account

Mozilla on the coming version-100 apocalypse

Both Firefox and Chrome are racing toward releasing version 100 in the near future, and developers for both browsers are worried that web sites with naive code to parse the version number out of the user-agent string will break.

Every strategy that adds complexity to the User-Agent string has a strong impact on the ecosystem. Let’s work together to avoid yet another quirky behavior. In Chrome and Firefox Nightly, you can configure the browser to report the version as 100 right now and report any issues you come across.


to post comments

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 15:12 UTC (Wed) by mattrose (guest, #19610) [Link] (9 responses)

I'm reminded of the reason why Windows went from 8 to 10. Too many people had assumed a windows version that started with 9 to mean 95, or 98, and it would break too much stuff to not skip 9 with the new versioning scheme.

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 16:00 UTC (Wed) by unilynx (guest, #114305) [Link] (8 responses)

Was that ever a real thing ? Windows 95 would have reported its version as 4.xx in API calls, "Windows 95" was just its marketing name.

Windows 9X

Posted Feb 16, 2022 18:36 UTC (Wed) by stephen.pollei (subscriber, #125364) [Link]

From what I heard it depended on what API the program used. You are correct that there were APIs that gave an internal version number that was pretty sane. There was also an API call that gave what was suppose to be human readable. Allegedly, there was a lot of code in the wild that did : if(version.StartsWith("Windows 9")) { /* 95 and 98 */ } else {} . OperatingSystem.VersionString Property versus GetVersionEx()

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 19:17 UTC (Wed) by khim (subscriber, #9252) [Link] (4 responses)

You either weren't there or have forgotten about what was happening back then.

Yes, Windows 95 reported version 4.xx, but so did Windows NT 4.0 and they required wildly different code in many places.

The story repeats today with Windows 11. Apparently it reports the exact same version as Windows 10 just the build version is different.

Which means that we have, now, frozen Windows version and soon will need to invent another way to distinguish builds.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 2:42 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

Microsoft optimistically believes that people will stop using Windows 10 no later than October 2025. Or at least, that's what they say in public, anyway. I'm sure there will be long-term support for banks and other people with more money than sense, but that support will likely be just security patches and other critical updates. I'm not sure if they need to bump the version number for such updates...

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 9:44 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

Times when updates carried a sensimble major version numbers have come and gone. But till now different versions of Windows carried different minor versions. Windows 10 and Windows 11 carry the same major and minor versions, only build number is different.

The one which is usually updated each time CI system builds new image. The last Windows 10 version carries build number 19044 while Windows 11 release is 22000. At least there are a gap. But the whole thing is still stupid, they could have, at least, changed minor version number.

The official position is “developers shouldn't care about differences”. But of course developers do care because other people insist on that (e.g. they want to see where Windows 10 is installed and where Windows 11 is installed because they come with different licenses and different support periods). So now they are looking on build numbers. What's next? Neural networks to distinguish different versions of Windows?

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 9:53 UTC (Fri) by beagnach (guest, #32987) [Link] (1 responses)

> Windows 10 and Windows 11 carry the same major and minor versions, only build number is different.

But.. but... WHY???

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 10:15 UTC (Fri) by khim (subscriber, #9252) [Link]

I'm 99% sure that's to ensure old drivers and, more importantly, old driver installers work.

I have friend who uses Windows 11 on Lenovo ThinkPad 430s. That's 10 years old model by now. You can not, officially, install Windows on it but Rufus can alter install image and then it's installable. Everything works perfectly (except for some DRM feature which actually require TPM 2.0, I guess, but my friend had no need for them).

After installation it pulls drivers for all exotic hardware from Windows Update and everything works. All drivers predate Windows 11 creation and I suspect some would try to check both major and minor version of Windows during installation.

Thus hole was dug deeper and now build numbers only distinguish Windows 10 and 11.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 22:20 UTC (Thu) by bartoc (guest, #124262) [Link]

(I work for Microsoft, but don't have insider knowledge about this).

I think it was mostly a marketing thing, Windows is totally happy to lie to you about its version, and there is no API to get the "marketing" version (like, 10, 11, 8, 8.1, etc) afaik, there is only a way to ask if you _are_ a particular marketing version. You can get them as strings but have to associate things yourself or really go digging around. And Windows is happy to lie about registry and file system content to you as well.

If you don't manifest your app I think all these APIs will tell you you're on windows 8 by default

Mozilla on the coming version-100 apocalypse

Posted Feb 19, 2022 15:43 UTC (Sat) by jrtc27 (subscriber, #107748) [Link]

Some Java things do https://codesearch.debian.net/search?q=%22Windows+9%22&.... Whether or not those matter is a different question.

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 15:14 UTC (Wed) by stop50 (subscriber, #154894) [Link] (5 responses)

When does firefox renmove the header completly?

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 18:44 UTC (Wed) by flussence (guest, #85566) [Link] (4 responses)

When they provide some other way to differentiate between this week's browser and a really badly coded web scraper. Despite how ridiculous these things have become, they do serve that purpose.

If they're going to have a breaking change like that I'd really just prefer the default become "$product/$version" (and then implement the TLS GREASE scheme on top, so this situation doesn't recur). It'll never happen in a useful timeframe because useragents are considered a sacred cow of compatibility, but one can dream.

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 19:52 UTC (Wed) by nybble41 (subscriber, #55106) [Link] (2 responses)

> When they provide some other way to differentiate between this week's browser and a really badly coded web scraper.

A *really* badly coded web scraper would just send a User-Agent header matching a popular web browser, in which case the header doesn't add any value. (And the more you rely on the User-Agent header to determine your response the most likely this scenario becomes, as scrapers are forced to make themselves look as much like regular browsers as possible.)

I can see a compatibility argument against removing the header entirely, but IMHO the actual agent string should be locked to a single value matching one of the popular browsers and never updated again. The same goes for JS APIs to probe the user agent. Servers and client-side code should treat all user agents equally.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 7:52 UTC (Thu) by taladar (subscriber, #68407) [Link] (1 responses)

As a sysadmin I strongly disagree. The UA of bots is very rarely that of an actual, recent desktop browser. Yes, the bad bots do often copy it but they then never update it again so usually they look like severely outdated versions of the browser whose UA-String they copied. Freezing it would just serve to create that situation you think is already there.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 15:31 UTC (Thu) by nybble41 (subscriber, #55106) [Link]

> The UA of bots is very rarely that of an actual, recent desktop browser. … Freezing it would just serve to create that situation you think is already there.

That isn't actually a disagreement—you're just not seeing a lot of "*really* badly coded web scrapers". I never said that *most* bots did this today. The point was just that you can't rely on a client-selected User-Agent string to filter out bots reliably. It's an easy thing to implement so long as it's not over-used, so scraper authors don't have any reason to work around it, but if identifying as a bot (or an old browser) will get a scraper blocked or throttled then correcting the problem will take a few minutes of the scraper developer's time at best. And in the meantime, for non-scrapers, we ought to be targeting web standards and not implementing workarounds for specific browsers. *That* is the point of freezing the User-Agent string: force sites to serve the same versions of their resources to everyone so that they don't break or degrade when someone comes along with a standards-compliant user agent the site simply can't identify.

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 21:16 UTC (Wed) by stephen.pollei (subscriber, #125364) [Link]

Yes, it has gotten ridiculous. All of the UA strings start with "Mozilla/5.0" for backwards compatibility reasons. They should just use "Firefox/100.0 ()" and ClientHints

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 15:15 UTC (Wed) by mtaht (subscriber, #11087) [Link] (5 responses)

They could switch to hexadecimal.

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 15:27 UTC (Wed) by ErikF (subscriber, #118131) [Link] (4 responses)

I like Knuth's strategy of simply adding more and more decimal places to the version number (although I'm not sure that would make things any better, given the release cadence!)

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 2:00 UTC (Thu) by rsidd (subscriber, #2582) [Link] (3 responses)

Knuth's rationale for that was that the programs (TeX and METAFONT) were done and only bugfixes were going in after that point. Previously he numbered them the usual way (version 3.0 of TeX was in 1990; after 3.1, he started appending digits of π). So the version numbers, like the program, tended to perfection. Nobody would make that claim for Firefox or Chrome!

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 12:24 UTC (Thu) by excors (subscriber, #95769) [Link] (2 responses)

He also declared that on his death the version number will be changed to π, and the code will be frozen forever. "From that moment on, all “bugs” will be permanent “features.”" (https://tug.org/TUGboat/tb11-4/tb30knut.pdf)

He's not claiming that the software will have reached perfection at that point, merely that it will be a local optimum. Long-term stability is very valuable to users, and no bug that has gone unnoticed for >30 years will be important enough to be worth breaking that stability.

I think it turns out he was wrong. Nobody was asking for PDF or Unicode or OpenType support in 1990, but they became important over time, and those features had to be added in forks like e-TeX and pdfTeX and XeTeX and LuaTeX. Nowadays if you want to write a *TeX document or process someone else's *TeX document, you'll almost certainly have to use one of those other engines, and you'll probably end up reading outdated documentation and suffering package compatibility problems until you eventually figure out which is the right gigabyte-sized TeX distribution to download (TeX Live, MiKTeX, proTeXt, ...) and the right command to run (lualatex?). It's kind of a mess. That seems worse than having a single official continuously-developed project that is easy for users to follow, which can still aim to largely preserve backward compatibility and can let you download old releases when you really need perfect bug compatibility.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 12:59 UTC (Thu) by anselm (subscriber, #2796) [Link]

I think it turns out he was wrong. Nobody was asking for PDF or Unicode or OpenType support in 1990, but they became important over time, and those features had to be added in forks like e-TeX and pdfTeX and XeTeX and LuaTeX.

Remember that Knuth started TeX (and METAFONT) mostly because he was unhappy with the way his own books were being typeset. If you think of TeX as an engine for typesetting The Art of Computer Programming, it's probably fine to freeze it because at least the system is very well documented – as long as you have a way of putting black pixels onto a white sheet of paper, you'll always be able to use TeX and METAFONT to typeset Knuth's books, even if you're a space alien from the 43rd century. (I'm saying this as someone who spent quite some time developing DVI-to-device software in the late 1980s and early 1990s.)

PDF, Unicode and all that only come in if you insist on using fonts that aren't Computer Modern, or languages that aren't English. It's true that that applies to many if not most of us these days, but to be fair, it wasn't really part of the original specification. We can probably count ourselves lucky that the original system was open enough to admit that sort of radical change, and that now, 40 years after it originally came out, it is still a force to be reckoned with.

Mozilla on the coming version-100 apocalypse

Posted Feb 19, 2022 5:50 UTC (Sat) by rsidd (subscriber, #2582) [Link]

I agree with you, I myself use pdflatex or xelatex (the latter for unicode support which is indeed the way to go). And metafont was an interesting idea but far too slow because it uses cubic splines and it turns out quadratic (postscript, opentype) is good enough; more so, it doesn't directly render vector font outlines, but generates bitmaps for each size. So I think TeX should be regarded as a frozen base that can be built upon by other projects like luatex and xetex, and metafont is not even used by most TeX projects now and can be regarded as perfect, but dead.

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 15:57 UTC (Wed) by ldearquer (guest, #137451) [Link] (7 responses)

I had to check it is not April Fools' Day

I know I am being super pedantic, but from a systems engineer perspective, I still get astonished of how low the quality bar is (sometimes) on the web landscape.

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 16:25 UTC (Wed) by lostwizard (guest, #57225) [Link]

Indeed. I imagine there are still some sites left over that report the year as 19122....

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 7:58 UTC (Thu) by taladar (subscriber, #68407) [Link]

That is mostly because they never require strict adherence to any standards but attempt to work around peers which don't. That tends to lead to an absolute mess in the long-term.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 9:04 UTC (Thu) by shiftee (subscriber, #110711) [Link] (1 responses)

Didn't Linux add an option to keep reporting itself as version 2.x after the eventual change to version 3?

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 12:17 UTC (Thu) by farnz (subscriber, #17727) [Link]

Yes - the UNAME26 personality flag. On my Fedora 34 laptop, I can switch with either setarch or uname26:


$ uname -r
5.16.7-100.fc34.x86_64

$ setarch --uname-2.6 uname -r
2.6.76-100.fc34.x86_64

$ uname26 uname -r
2.6.76-100.fc34.x86_64

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 9:38 UTC (Thu) by Thomas (subscriber, #39963) [Link]

Thank you for this very sane assessment.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 10:51 UTC (Thu) by zdzichu (subscriber, #17118) [Link] (1 responses)

I was perplexed, too. How could simple numeral comparison work for 99 and do not work for 100? There aren't even any dots to consider. It is unimaginable to me.

Oh boy, how limited is my imagination:
https://github.com/webcompat/web-bugs/issues?q=label%3Ave...

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 11:23 UTC (Thu) by nye (subscriber, #51576) [Link]

"100" < "99"
true

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 16:26 UTC (Wed) by Bigos (subscriber, #96807) [Link]

Well, Google Chrome is currently identifying as:

1. Mozilla
2. WebKit
3. KHTML
4. Gecko
5. Chrome
6. Safari

I assume all but (5) is for compatibility reasons, each introduced on a different occasion in a different code base (like KHTML -> WebKit -> Chrome).

Mozilla on the coming version-100 apocalypse

Posted Feb 16, 2022 20:32 UTC (Wed) by KJ7RRV (subscriber, #153595) [Link]

How many sites would break with a completely new format?

<Rendering Engine>@<Version>/<Browser>@<Version>/mobile|desktop/<OS>[@<Version>][(<Variant>[-SubVariant]...[@<Version>])]

My user agent right now would be:

Gecko@93.0/Firefox@93.0/mobile/Android@11

My PinePhone running Arch Linux ARM might show:

Gecko@93.0/Firefox@93.0/mobile/Linux@5.16-ArchLinux-ArchLinuxARM

If I had LineageOS on my Android phone:

Gecko@93.0/Firefox@93.0/mobile/Android@11-LineageOS@18.1

My desktop running Mint 20.3:

Gecko@93.0/Firefox@93.0/desktop/Linux@5.16-Ubuntu@20.04-LinuxMint@20.3

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 0:14 UTC (Thu) by pabs (subscriber, #43278) [Link] (12 responses)

They should take a page out of the TLS 1.3 book and randomise the order of the components in the string. Or just randomise it or remove it entirely.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 7:48 UTC (Thu) by roc (subscriber, #30627) [Link] (5 responses)

Sure, if you don't mind the browser not working on a huge number of sites.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 7:59 UTC (Thu) by taladar (subscriber, #68407) [Link] (4 responses)

If browsers all did that, yes, a huge number of sites would have to be fixed once but after that the web ecosystem would be one step closer to sanity.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 12:44 UTC (Thu) by excors (subscriber, #95769) [Link] (3 responses)

Yes, a huge number of sites would have to be fixed, which means an enormous cost across the tens of millions of companies and hobbyists who have to debug and update their sites that would otherwise be working perfectly fine, and an enormous cost across the billions of users who will find that some sites they visit are broken for weeks or months or forever. It seems rather unethical for browser developers to collude and force that cost onto everyone else, when the main benefit is some abstract feeling of 'sanity' in one minuscule portion of the technology.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 21:22 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (2 responses)

Just out of curiosity, what kinds of things are browser UA sniffing used for these days? Wasn't there a push for feature detection years ago (i.e., testing if `window` or whatever has a specific attribute)?

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 18:38 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Part of the problem is that feature detection has been used for browser fingerprinting, so you need to be very careful about exactly what features you allow the site to detect.

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 20:18 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Sure. However, "Firefox on Linux" seems like way more bits of information than (I suspect) most feature detections would give over time (as "yes, supported" creeps its way across the browser/feature matrix). It is also something that changes in a way that can't necessarily be seen as I upgrade or switch browsers.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 10:08 UTC (Thu) by cthart (guest, #4457) [Link] (5 responses)

I'm with pabs here. Just bump the verison to 100 and let the fallout happen. We need to have more changes like this happen more regularly for folk to realise that they can't just make assumptions, and to learn from our past mistakes. We have a whole generation of programmers now that didn't have to deal with Y2K and they also need to learn its lessons.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 12:29 UTC (Thu) by mgedmin (subscriber, #34497) [Link] (4 responses)

Will websites care? "Firefox can't render our site? Just use Chrome."

Will users care? "Site works in Chrome, doesn't work in Firefox? I'll just use Chrome then! Firefox must be a bad browser."

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 12:30 UTC (Thu) by pabs (subscriber, #43278) [Link] (3 responses)

The post says that Chrome is coming up on version 100 too, and has also enabled the same option as Firefox.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 23:39 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

Then people would just take Chromium (or Firefox) sources and release version which “works”.

Remember how that happened with Flash last year?

With Flash that was a stop-gap solution because Flash required so many hacks in different parts of browser that it wasn't really practical to forward-port the change.

When you only need to change UA string… that “extra-compatible” browser can be supported for a very long time.

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 10:20 UTC (Fri) by rqosa (subscriber, #24136) [Link] (1 responses)

> When you only need to change UA string…

Aren't there simpler ways to accomplish that than recompiling the browser from source (which, if used by end-users outside of an intranet managed by an IT department, would presumably also require the end-users to download & install the resulting "alternate version" of the browser)? Such as: using Firefox's "general.useragent.override" setting in about:config, or using a Chrome extension or a Firefox add-on.

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 13:59 UTC (Fri) by geert (subscriber, #98403) [Link]

No need to recompile from source, a hex editor is all you need to change the User-Agent string.

Mozilla on the coming version-100 apocalypse

Posted Feb 17, 2022 21:52 UTC (Thu) by gdt (subscriber, #6284) [Link]

Same thing happened in networking.

Firewalls starting thinking the only IP packets were TCP or UDP, so new protocols are built over UDP. Some sites only pass HTTP traffic, so everything is made to fit in a HTTP wrapper. Then there's the poor configuration of firewalls concerning ICMP.

All this is aggravated by the use of the web for advertising. Some major networking companies won't allow even a small percentage of their user base to have poorer performance before they update infrastructure, as reducing the time for which advertising is displayed has corporate financial consequences.

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 0:08 UTC (Fri) by gmgod (guest, #143864) [Link]

Oh no, do you mean that "the web is universal" and "standards" are a lie? That developers "adapt" their website to devices instead of letting the browser doing it? What a world! This is "Father Christmas does not exist" all over again! T-T

Does it also mean that when I charge the laptop I'm using to write this onto the grid, my energy provider especially reduces voltage to 12V for me? The "charger" must be sending a special UA...

Oh hang on, that could explain very well how the dispenser in gas station magically "knows" when to stop! Oh everything makes sense now! My car must send a UA so that the dispenser can adapt itself! I suppose the kind of gas is also specially prepared for my car: there is no way my crappy car would really fancy my neighbour's Jaguar's favourite beverage...

Now that I think about it (as I'm taking notes), pens probably also implement something very similar... After all, writing on white paper is not the same as blue paper... or cardboard! There is no way there would be a universal way to write on all these with the same device if there is no such information exchange! How else do you expect a pen to work?!

I've been blinded for so long... but I've seen the light: standards and protocols are a lie since all devices/situations are different one can't expect to use the same abstract concept over all these peculiarities. After all Firefox on Linux, Osx and Windows don't use the same binary format! How could I expect they would interpret HTML, JS and CSS in the same way? They are not bit-to-bit identical to start with!

Now, more seriously, UAs need to die. I'm not saying they can just vanish tomorrow: I understand they currently have their use. However we should strive to make their use server-side obsolete. IE is dead, it is high time the last platform-specific issues are ironed out and with them the last use-cases for UAs.

Mozilla on the coming version-100 apocalypse

Posted Feb 18, 2022 21:32 UTC (Fri) by suckfish (guest, #69919) [Link]

Speaking of coming apocalypses:

Thu 17 Mar 2022 02:20:48 UTC is exactly 500 million seconds before the Y2038 apocalypse.

Anyone using 32-bit signed unix time who adds 500 million seconds to the current time (maybe "disabling" a timeout by making it now+500million), potentially has a problem on that date.

From memory, there were a few reports of problems at "Y2038 minus a billion seconds".


Copyright © 2022, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds