[HN Gopher] Version 100 in Chrome and Firefox
___________________________________________________________________
Version 100 in Chrome and Firefox
Author : TangerineDream
Score : 125 points
Date : 2022-02-15 18:08 UTC (4 hours ago)
(HTM) web link (hacks.mozilla.org)
(TXT) w3m dump (hacks.mozilla.org)
| allendoerfer wrote:
| What a great time to stop reporting them altogether to minimize
| fingerprinting for all future versions.
| arubania2 wrote:
| > What are browsers doing about it?
|
| I really hate this narrative. Why should the browsers give a
| damn? There should be nothing required of the browsers, the only
| ones to worry are the idiots writing faulty UA parsers and baking
| in their assumptions.
| freemint wrote:
| Be liberal in what you accept be conservative in what you
| produce.
| j1elo wrote:
| The topic about quality of software has been brought up several
| times in HN, and here we are. I'm ashamed that in our industry,
| we are still tripping over pebbles and writing code so utterly
| shitty that it breaks when _a number goes from 2 to 3 digits_ ,
| of all complex things that happen in our world.
|
| The bar was so extremely low, that I'd be OK letting parsers
| break due to their short sightedness. Not even in embedded space
| (where I've got some experience to know that computing resources
| are scarce) this would pass as understandable.
| samwillis wrote:
| In all seriousness can we please replace the user agent, and add
| a new header that is meant to supersede it. We can then freeze
| the current user agent at v99 with all the other rubbish that's
| still in it and put real correct date in a standard format in a
| new header.
|
| I know there are arguments that a new version will be abused just
| as much, but I think we should be able to find ways to elevate
| that by, for example, limiting the length of different fields so
| doubling up of information to mask the truth or detect as two
| different browsers isn't possible.
|
| We could even design this new system specifically to be
| fingerprint proof, just report the essentials which is pretty
| much just the browser engine (webkit/blink/gecko) and version.
| don't even need the actual browser and os.
| capableweb wrote:
| Everyone knows it's so easy to migrate a HTTP header that has
| been in use since basically forever (in internet time). It'll
| never be possible to completely change it to something else,
| just imagine all the software that assumes that header to be
| there.
|
| And for in-browser stuff (via JS), you already have an
| alternative that works perfectly fine, `window.navigator`, that
| looks something like this: {
| "permissions": {}, "mimeTypes": {},
| "plugins": {}, "doNotTrack": "unspecified",
| "maxTouchPoints": 0, "mediaCapabilities": {},
| "oscpu": "Linux x86_64", "vendor": "",
| "vendorSub": "", "productSub": "20100101",
| "cookieEnabled": true, "buildID": "20181001000000",
| "mediaDevices": {}, "serviceWorker": {},
| "credentials": {}, "clipboard": {},
| "mediaSession": {}, "webdriver": false,
| "hardwareConcurrency": 8, "geolocation": {},
| "appCodeName": "Mozilla", "appName": "Netscape",
| "appVersion": "5.0 (X11)", "platform": "Linux
| x86_64", "userAgent": "Mozilla/5.0 (X11; Linux
| x86_64; rv:97.0) Gecko/20100101 Firefox/97.0",
| "product": "Gecko", "language": "en-US",
| "languages": [ "en-US", "en"
| ], "locks": {}, "onLine": true,
| "storage": {} }
|
| Or is there something else you're missing from
| window.navigator?
| littlestymaar wrote:
| "appName": "Netscape", "appVersion": "5.0 (X11)",
|
| So, without checking the user agent string, window.navigator
| basically tells me that this browser is Netscape 5.0. How is
| that helpful?
| olex wrote:
| Looking at this, the actually useful information is still
| heavily obscured and hides in the same "userAgent" string -
| the "Firefox/97.0" at the end. One would expect this
| information to be in appName, appCodeName and appVersion by
| semantics - but those fields are useless, arguably
| misleading, with "Netscape" having seized to exist a long
| time ago.
| detaro wrote:
| that's what https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Client_hin... aim to do over time.
| hoten wrote:
| It's called Sec-CH-UA.
| samwillis wrote:
| This seems very overly engineered, I was thinking something
| far simpler and much more limited with no negotiation.
|
| I can see the use case for this. Maybe in parallel with a
| simpler header.
|
| https://developer.mozilla.org/en-
| US/docs/Web/HTTP/Client_hin...
| hoten wrote:
| I encourage you to review the decision making and engage in
| the discussion here: https://github.com/WICG/ua-client-
| hints
| samwillis wrote:
| Thank you for the pointer. I will happily read up on the
| thought process.
| WalterGR wrote:
| This reminds me of Microsoft skipping Windows 9 and going from
| Windows 8 to Windows 10.
| larrik wrote:
| At least that was linear.
|
| Their Xbox went to 360 second, then "One" third then "Series".
| Like that makes any sense at all.
| wnoise wrote:
| I'm really disappointed that after 360 wasn't delta.
|
| Then the series would spell out X # * [?] .
| BitwiseFool wrote:
| A pet peeve of mine is when corporations try to use "One" as
| a brand. Not only is it horribly uncreative, it's been done
| countless times by countless companies and it never sticks.
| They're trying to get across the idea that this one product
| does everything, or that different products/offerings are now
| unified. But "One" is lazy and unoffensive in the corporate
| world.
|
| Steve Ballmer wanted a "One Microsoft", SkyDrive being
| renamed to OneDrive was partly due to this, and was hoping
| people would call the XBox One "The One".
| skykooler wrote:
| Or, similarly, X. A few years ago, I had a OnePlus X and a
| Sony Xperia X. The iPhone X had just released, as had the
| Xbox One X, etc.
| SAI_Peregrinus wrote:
| USB went from 1.0, to 1.1, to 2.0, to 3.0. 3.0 got renamed
| 3.1 Gen 1, and 3.1 Gen 2 got introduced. Then 3.2 came
| around, which renamed 3.1 Gen 2 into 3.2 Gen 2x1, and
| introduced 3.2 Gen 1x2 and 3.2 Gen 2x2. USB 4.0 introduces
| USB 4.0 Gen 2x2 and USB 4.0 Gen 3x2.
|
| This is ignoring the battery charging, alternate modes, etc.
| Just the main USB versions.
| artursapek wrote:
| Imagine writing a user-agent parser and not foreseeing a future
| where they might have three digit numbers lmao
| fantyoon wrote:
| Huh, this is the first time I have heard about interventions.
| Checking about:compat on Firefox for Android reveals (perhaps
| unsurprisingly) multiple fixes for Google sites. I wonder what
| constitutes deploying an intervention versus letting the site
| break. I understand that part of the reason Google sites are
| being fixed by Mozilla is because they are popular.
| ethbr0 wrote:
| What kind of crap user-agent parsing library are people using
| that breaks from 2 to 3 digits?
|
| If that was a bug, I'd be pretty suspicious about the general
| software quality in the rest of the library.
| Someone wrote:
| I think you'll find all kinds of 'libraries' for doing that,
| especially in small embedded devices with a web front-end.
|
| I also fear there's software that correctly extracts all the
| digits of the version in the user agent, but then compares it
| _as a string_ with a given version. That would get you
| "100" < "99"
| cpeterso wrote:
| Here's a real example of that bug:
|
| Slack's message buttons (such as "Add reaction" or "Reply in
| thread") stopped working for Firefox versions >= 100 and <=
| 519. They mysteriously started working again for versions >=
| 520. The version string "100" compared as smaller than "52"
| in Slack's code, which activated some kind of webcompat
| workaround intended for Firefox versions < 52 that breaks on
| more recent Firefox versions.
|
| https://github.com/webcompat/web-bugs/issues/67866
| lmkg wrote:
| I wouldn't be so confident that the code is coming from a
| _library_. We take code distribution for granted these days,
| but some fraction of the web today was built when the only way
| to get anything done was hand-rolled perl scripts.
| petercooper wrote:
| I _admit_ it 's crap, but I once added a temporary fix to a
| system of mine that blocked clients with a user agent matching
| "Chrome 54" (at the string level) due to a bot (I know it's not
| ideal, but it worked in the moment, and genuine users were no
| longer using such an old version). I doubt Chrome 540 would
| turn up any time soon, but I _can_ picture other folks having
| done similar things with "Chrome 12", say, and wondering why
| things fail with Chrome 120(!)
| glandium wrote:
| That's the speculated reason why Microsoft had to skip
| Windows 9: because in the late 90s, software were checking
| for <<starts with "Windows 9">> to identify Windows 95 and
| 98... and some of those checks still exist and would had
| identified Windows 9 as Windows 95/98.
| pictur wrote:
| very optimistic point of view.
| samwillis wrote:
| This is the same field that thought they could save a year as
| two digits and didn't think their software would still be in
| use 30 years later.
|
| It's not crap, it's just short sighted.
| ethbr0 wrote:
| True, but user-agent was 1996(?). By then, we weren't talking
| about limited mainframe storage devices.
|
| It just baffles that someone can look at a monotonically
| increasing number, defined and incremented by a third party,
| and say "That will never be 3 digits."
| Beltalowda wrote:
| I'd wager it's mostly fixed string indexes, regular
| expressions ("\d{2}"), and things like that. Maybe also
| some people with a "varchar(2)" column in the database.
|
| A lot of software is written by junior programmers, not
| infrequently in a hurry. It's an easy mistake to make and
| if you've been bitten by it once you'll remember it, but
| many people have never been bitten by it.
| skykooler wrote:
| Well, keep in mind that major version numbers used to
| change slowly. In the first ten years Firefox existed, it
| went from version 0.1 to version 5.0. At that pace, it
| would have taken two hundred years to hit a three-digit
| major version. In my opinion, browser vendors brought this
| upon themselves by changing what "major version" meant.
| larrik wrote:
| To be fair, in 1970 those 2 digits were _very_ expensive. It
| was a calculated tradeoff at worst.
| cesarb wrote:
| > To be fair, in 1970 those 2 digits were very expensive.
|
| More than just "very expensive". Often, you were limited to
| exactly 80 columns for each record. If you had for instance
| three dates on one record, using 2 digits instead of 4
| digits saved 6 columns, which is over 7% of the available
| space.
| throwaway932489 wrote:
| "New dependencies need to be approved by xyz"
|
| "Ok"
|
| if(userAgent.includes("Chrome") && userAgent[whatever] >= 4)
| vdnkh wrote:
| A lot of people here are calling for the death of UAs, but this
| would be bad for video because capabilities are inconsistent
| across the web, and because APIs are incomplete or lie.
|
| For example, the "canPlayType" API for whether a codec is
| supported returns "probably" or "maybe". So we sometimes need to
| hardcode which browsers support which new codecs.
|
| Also, there are several bugs in past and present versions of
| decoder implementations, which are only discovered though manual
| testing, or by observing quality of service metrics split by
| browser version (Firefox does not handle bad audio packets as
| well as Chrome, for example). In IE and old Edge, the video
| readyState would always be "4" after playback beings, even during
| buffering, which is a blatant violation of the spec Microsoft
| refused to fix (as stated in their bugtracker).
|
| Browsers like Safari have subtly different event orders from the
| HTMLVideoElement which requires a burdensome workaround that us
| working in video just like to keep to Safari instead of poisoning
| other implementations.
|
| A final fun quirk is that not all browsers gave accurate HTTP
| timing information until recently (notably, Safari < 14) which
| make download timing for the purpose of determining bandwidth
| very inaccurate. This is why Twitch only recently supported low-
| latency playback for Safari. There is no other way to ask "do you
| support accurate timing" other than for an engineer to test it
| and hardcode an exception.
| Uehreka wrote:
| I feel like these arguments always break down along the same
| lines:
|
| - People who have recently run into an issue that required
| browser sniffing
|
| - People who haven't and feel sure that "things are better now"
| and the practice is no longer needed.
|
| I've gotten into these kinds of scrapes many times, and I can
| assure you all that philosophical arguments about browser-
| detection-vs-feature-detection don't work very well when you're
| trying to explain to a client why their web app that worked a
| week ago doesn't work today (due to a WebRTC bug in Chrome, for
| instance) and won't be fixed until the next Chrome version
| comes out in six weeks.
|
| To folks advocating "ripping off the bandage" as a solution,
| I'd note that the wound underneath has not stopped bleeding.
| DaleCurtis wrote:
| FWIW, MediaCapabilities is the new way to ask the "can I play
| this" question:
|
| https://developer.mozilla.org/en-US/docs/Web/API/Media_Capab...
|
| It returns a boolean for whether a codec is supported or not.
| mixedCase wrote:
| > For example, the "canPlayType" API for whether a codec is
| supported returns "probably" or "maybe".
|
| Great. You should be calling for the death of UAs too if you
| want the situation to improve.
| asddubs wrote:
| Not too long ago browser vendors decided to fuck up cookie
| backwards compatibility with "samesite" attribute so badly that
| you are literally forced to do browser sniffing to have your
| site work in both modern browsers and older versions of safari
|
| random article about it:
| https://catchjs.com/Blog/SameSiteCookies
| dangerlibrary wrote:
| Counterpoint: As a user, often the only way to get a video to
| play in any browser on linux is to modify the user agent. And
| then, when you do spoof the user agent, it works just fine.
| vdnkh wrote:
| This is probably due to DRM which is poorly supported by
| Linux (lazy devs will probably just exile Linux completely).
| But I do remember some linux-only decoder issues in the past.
| Decoder and codec support is just poorly signaled overall,
| even if an API says it supports it, it may not support a
| specific profile or even support it well.
|
| Some of our video test grid machines are Ubuntu, so from our
| end Twitch video should work pretty well on Linux :-)
| floatboth wrote:
| Can't say I've seen that _often_ , but there was a short
| period of time when Twitch refused to play on a FreeBSD user-
| agent. Spoofing as Linux or Windows worked. They did fix it.
| Osiris wrote:
| This was so common in Opera 12 that there was a dedicated
| button in the UI to change the user agent for a page.
|
| The browser also included a built-in user agent compatibility
| list and the user could manually add sites to use a specific
| UA string.
|
| Most sites would work fine in Opera with the correct UA. Many
| did not work when using the default UA with the word "Opera"
| in it.
| cpeterso wrote:
| Firefox has a built-in list of websites that need UA tweaks
| to work in Firefox. (In fact, Firefox's UA override feature
| was designed by ex-Opera engineers at Mozilla.) You can
| review the list (and toggle them) in Firefox's
| _about:compat_ page.
|
| A recent success story: Mozilla recently added a UA tweak
| to work around Slack's Chrome-only check for video calls.
| Slack engineers reached out to Mozilla and, just a few days
| later, Slack removed their Chrome check and now support
| video calls in Firefox without a UA tweak. :)
| heftig wrote:
| Except if your UA reports Firefox _on Linux_ , where
| calls and huddles remain unavailable to this day.
|
| I wouldn't call that a success.
| iib wrote:
| A very curious case is that huddles for me work in
| wayland (under sway), and don't work in X11 (under i3),
| for the exact same configuration otherwise. I have not
| investigated what exactly the browser sends.
| ljm wrote:
| I couldn't use those through Safari on a Mac either.
| Nothing really tells you that it's unsupported. I could
| search or figure it out but I don't wear my
| programmer/software tester hat all the time.
|
| Welp, better spend a few minutes downloading the same
| thing but in a Chrome sandbox.
| cpeterso wrote:
| Do the calls and huddles work in Chrome on Linux? Do they
| work in Firefox if you use a UA that doesn't mention
| Linux?
| tjoff wrote:
| In all an insignificant price to pay. And maybe it would
| highlight browser vendors to fix it instead and become more
| standards aware.
| vdnkh wrote:
| Getting a browser vendor to fix something takes a lot of
| effort, and doesn't immediately alleviate any impact on
| users. "if (browser.name === 'safari' && browser.version <
| 14)" does.
| [deleted]
| danShumway wrote:
| I go back and forth. I do web development, and I do
| occasionally rely on the user agent, I completely agree that
| there are some situations where there isn't really an
| alternative we can use. It's not necessarily just a problem of
| specification, sometimes there are browser-version specific
| bugs that just have to be accommodated, and there is no way to
| test for those bugs and there is no way to get a signal for
| those bugs because they're not specified behavior.
|
| However, I also browse the web on Linux, and there are also
| situations where sites just kind of decide that they do or
| don't support me based on whether or not I'm in an allow-list
| that was lazily cobbled together and that hasn't been updated
| in over a year. This seems to me to be the same category of
| problem; it _should_ be better, sites _should_ know not to do
| that, but they don 't. And sure, I can solve the problem
| specifically for myself by going though an annoying process to
| lie about my user-header, but it's a big damper on all of the
| other "users" (ie, random family members/friends) that I
| support who aren't able to do that. And it defeats the primary
| purpose of the user-agent if I'm lying to sites about it
| because they block off capabilities for no good reason from
| agents that they don't recognize. If I'm constantly lying about
| my browser as the "solution" to that problem, I'm already kind
| of breaking user-agents in the exact way you're worried about.
|
| And there are also obviously the privacy problems that come
| along with user-agents, which I'm not going to get into, but
| they're substantial and there is no way to solve them without
| making user-agents much less useful for website operators.
|
| So I don't know what the solution is, or even if there is a
| better solution available than what we currently have, but
| there are real downsides to the current setup. I think it's
| silly to pretend that browser vendors won't ever have quirks
| that make user-agents necessary. But I also think it's equally
| silly to pretend that website operators will ever use them
| responsibly, and equally silly to pretend that people won't get
| locked out of sites for no reason because of them.
|
| There is definitely some naivete in getting rid of user-agents,
| but there's also some naivete in keeping them, and the
| arguments for "well, they're still necessary" sometimes ignore
| just how much wasted effort and hacky crud goes into making the
| web work with them. At the same time though, there are bugs
| I've fixed in my day-job that could not be fixed without them.
| It's just, that doesn't mean the downsides aren't also there
| and that they don't also matter.
|
| I'm personally interested in how client hints progress. They're
| not perfect, but they seem to be decent, and for all of my
| criticism of Chrome's Privacy Sandbox concept, I think this is
| an area where it makes a lot of sense -- make certain hints
| possible to check, but have a cost associated. It's still not
| the exact browser version though, there are still bugs that I
| wouldn't be able to fix with that system. But there are some
| bugs that I use user-agents for that this system would work
| for, and I'm willing to make my job slightly harder if it makes
| a bunch of other things better. Or at least, I'm willing to see
| how client hints play out and see how much harder they do or
| don't make my job.
| t8e56vd4ih wrote:
| I just checked - both Firefox and Chrome are at version 97.
| that's sort of funny.
| mutatio wrote:
| Regarding the dropping of the user agent string, are folk not
| concerned that it would lead to future web development coalescing
| towards a Chrome "world view"?
| brutal_chaos_ wrote:
| Development seems to be moving in that direction already (see
| market share per browser and the number of "Chrome only"
| sites). How would removing UAs continue or hinder that trend?
| mutatio wrote:
| I just wonder if it would lead to further cementing the
| Chrome-first approach to web dev - in the context of browser
| sniffing in JS libs and even backend code. I guess this
| doesn't drop support for JavaScript navigator properties so
| maybe JS is fine.
| silvestrov wrote:
| Please, not another hack of the user-agent string.
|
| If sites break, let them break.
| yifanl wrote:
| Why is there version numbers for web browsers at all when
| version bumps are forced? To the average user, it's not a
| meaningful number at all. Breaking sites as a side effect for
| bumping a version number that can't not be bumped is a totally
| insane thing to me.
| peakaboo wrote:
| Completely agree.
| daveslash wrote:
| Yes. Agreed. Sites should be doing their best to avoid having
| to check the UA String.
|
| For some tightly-controlled environments (medical, aerospace,
| etc...) where all software components & tooling has to be
| qualified for use, I can see checking the UA in order to throw
| up a "your browser is not supported" banner ( _" not supported_
| usually means " _we haven 't tested it, so we can't assert this
| web app will work properly_", not so much " _our app won 't
| work_"). But sites should really avoid responding with
| different content/html, etc.... for different browsers (though,
| I have encountered sites that serve images as webp to chrome
| and jpg to IE...)
| silvestrov wrote:
| > tightly-controlled environments (medical, aerospace, ...)
|
| This are places where you don't automatically upgrade
| browsers but keep them at one specific version. No
| rocket/airplane wants to stop working because something
| changed.
|
| It is also places which are good at writing contracts that
| can ensure such things to work, so these places should not be
| a concern.
|
| It's likely cheap shoddy sites that will be a problem. The
| ones that think jQuery is too advanced tech.
| dgb23 wrote:
| The picture element let's you do that very conveniently w/o
| checking the UA. It's a bit like a switch statement.
| lcnmrn wrote:
| Jump from 99 to 109 then let them break. Internal sites of
| universities and corporations need to work until they get
| fixed.
| Hamuko wrote:
| If those internal sites are so crucial, then maybe they
| shouldn't build them like a house of cards.
| tpmx wrote:
| _If sites break, let them break._
|
| That's incredibly arrogant, IMO. Imagine the amount of
| pointless work that would cause world-wide, and the cumulative
| amount of pain experienced by readers of the web for years.
|
| It's pure value destruction on a global scale, just making
| things worse to prove a point.
|
| A better solution is to realize that the UA header has been
| completely broken for decades and do yet another compat hack,
| whilst transitioning to some more futureproof mechanism.
|
| The web needs a Linus occasionally screaming: don't break
| things for shits and giggles.
| coldpie wrote:
| Yes. Your software doesn't exist in isolation; you have
| users. Your #1 goal is not to make your software
| ideologically perfect. Your #1 goal is to make your software
| useful to its users. Sometimes you have to break things, yes,
| but these events should be strongly justified and impossible
| in practice to avoid. Bumping a version number in a user-
| agent string doesn't rise to that level.
| Beltalowda wrote:
| Some people relying on fixed width digits will happen anyway,
| no matter how you send the version. There's decades of
| experience with this. It has nothing to do with the User-
| Agent header as such.
|
| With the Chrome "backup plan" literally _everyone_ will have
| to modify their code to make it work, making it more
| convoluted in the process. With the "well, just break stuff
| then" only the small number of people who relied on a fixed
| width of the version will have stuff break. This seems like a
| decent enough trade-off, and will almost certainly _save_
| programmer time globally.
| coldpie wrote:
| > With the Chrome "backup plan" literally everyone will
| have to modify their code to make it work
|
| I don't understand. If you need to detect a >99 version,
| then yes, you'll need to update your code, but you'll need
| to do that anyway, to add your >99 logic in the first
| place. If you don't need to detect that, then no changes
| are needed, and as a bonus no poorly-coded sites will
| break.
| dtech wrote:
| The point is not necessarily that _this_ hack is too
| much, but it 's yet another hack on a system that is
| already so full of hacks that parsing it is incredibly
| complicated and error-prone, requiring more hacks in the
| future. It's a self-reinforcing loop. Do we ever say
| enough is enough?
| coldpie wrote:
| It seems people are working on this, yes. See other
| comment thread:
| https://news.ycombinator.com/item?id=30350659 Breaking
| existing websites is not an acceptable solution.
| Beltalowda wrote:
| My assumption is that everyone who does this will want to
| detect version >99 sooner or later.
| adamrezich wrote:
| I haven't parsed a user agent in about 15 years--what is the
| actual use case for doing so these days? it seems like it's only
| become less and less valuable of a thing to do over time.
| can16358p wrote:
| Me neither. But some do, especially if they 100% need features
| working that are half-supported/different for different
| browsers.
|
| Though, I don't find many examples of it and checking
| individual features for determining whether an API is available
| for example (doesn't apply to everything, yes I know) right,
| non-hacky way to go.
| asddubs wrote:
| here's my two use-cases: working around browser bugs, figuring
| out if it's a mobile device (e.g. to hide drag-and-drop
| features for file uploads)
|
| prominent example for a browser bug:
| https://catchjs.com/Blog/SameSiteCookies
| matyasrichter wrote:
| If you want to show the user a list of active sessions (and let
| them revoke one), it makes sense to try and parse the UA and
| show them a more readable device name.
| yread wrote:
| I have to reduce size/resolution of my canvas for iPad as
| mobile safari gets really slow with html canvases around 10k x
| 10k size. It's tricky because mobile safari has exactly the
| same UA as normal safari.
| asddubs wrote:
| doesn't it have ipad/iphone in the UA string?
| yread wrote:
| It did at some point but people were nerfing it so Apple
| got angry and ditched it
| asddubs wrote:
| well, that sucks
| gary_0 wrote:
| Last I heard, Chrome was phasing out user-agent strings
| anyways[0]. There's already a feature flag, and turning it on
| makes the user-agent "generic" so that specific browser and OS
| versions are rounded off and end with 0's. In other words,
| relying on browser version numbers is deprecated by Google fiat.
|
| [0] https://news.ycombinator.com/item?id=22685018
___________________________________________________________________
(page generated 2022-02-15 23:01 UTC)