"This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl,
It's ok, sure it's stressful when something like this happens. Software is a hard field and the amount of things that can go wrong is immense. When I think about how few errors and downtime some of the larger services have I realize how much work must be involved.
What I don’t understand is why this isn’t just a rollback, or at worst a revert commit and redeploy. I can forgive an issue with a slightly obscure browser, but the fix should be trivial for Google engineers?
If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
(Submitted title was "Google breaks search for Firefox users because of bad UA string sniffing")
This reminds me of a blog post a former exec of Mozilla put out saying Google had been intentionally breaking things to get users to jump ship to Chrome.
Is that what you think happened here? Google made the search page blank for Firefox users to get them on Chrome? Or perhaps it's the work of Hanlon's razor.
This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl and it seems that this affects all UA strings with versions >= 65. <=64 work.
It's interesting if you remove "Android" from the UA, then it sends more, but remove "Mobile" it still sends only the "doctype", and removing "Firefox" fixes it entirely.
Is there any legitimate use for UA string sniffing vs feature detection? And what could a search engine possibly do that's so bleeding edge it doesn't work in all browsers?
There've been a few, but the first one that impacted me was Chrome's switch to requiring the SameSite=None flag on Set-Cookie headers[1] in a third party context.
> Warning: A number of older versions of browsers including Chrome, Safari, and UC browser are incompatible with the new None attribute and may ignore or restrict the cookie.
This caveat meant that UA sniffing was the only reliable means of setting cookies that were guaranteed to work properly.
We’ve seen browsers behave differently in subtle ways. To mitigate impact while we figured out the correct fix, we’ve served different content to them so those users still get a working experience while we figure out and fix the underlying issue.
This had nothing to do with feature detection, so the usual suggestions simply won’t work.
One notable thing about the Google search homepage is how fast it is. It's gob smackingly quick. It responds to the initial key press under in under 200ms with 10 suggestions that include text and pictures, and keeps doing it. My round trip time to www.google.com is around 20ms, so at least 100ms of that time is swallowed by the internet.
You don't get that sort of speed without heavy optimisation. In fact I'd be amazed if www.google.com isn't the most heavily optimised page on the internet. So it's not at all surprising to me that they optimise based on what browser is asking.
basically you can send slightly less data by only sending the relevant layout/js code etc. with the first request instead of sending some variation which then the browser selects/branches one
most likely a terrible optimization for most sides maybe not google search due to how much it's called
but then Google is (as far as I remember) also the company which has tried to push the removal of UA strings (by fixating all UA strings to the same string, or at least a small set of strings)... so quite ironic
Given Google's size and market share, they should be fined whenever they break access to a competitor's website (e.g. Chrome update breaks access to DDG) or if their websites break in competitor's browser (e.g Google breaks on Firefox). They have more than enough resources to run automated checks on this, so it's hard to not see malice instead of incompetence in this case.
What if it is done during testing as a beta release? If that's acceptable, Googs will just turn into one of those companies that never releases full versions and is always just in some form of beta release
It's fascinating how people clamor for more government regulation and control at the first sign of trouble, without reasoning about the implications of those things, despite a history replete with examples of power abuse from the same.
Somewhat related fun fact: if you send the Google search home page an unknown UA string (e.g. curl/8.5.0) from a German-speaking country, Google will serve a latin-1 encoded page declared as UTF-8 in a meta tag. (I spent quite a while trying to fix this on my end before realizing what was going on.)
The latest comment on the issue states that Mozilla has a patch that can be emergency-deployed as a patch release. The proposed patch literally overrides the UA string for Google.
Is it just me, or is this absolutely insane? When Google ships a bug, it's suddenly the responsibility of browser vendors to "fix" it at the browser level?
It's not the responsibility of the browser vendors. But they have an interest in un-breaking the experience for their users. In a sense, Google is too big to fail, so users want it to work any way possible.
It happens all the time, you probably just don't realize it. There is special code in Windows for supporting/un-breaking popular applications, same with Android and iOS.
Google has marginal incentive to not kill Firefox (antitrust), they have no incentive to make sure they provide a good experience on Firefox, let alone test with it.
The issue seems to be isolated to the search home page, and Google Search hasn't exactly been associated with "quality" in several years. Internal rot and disinterest gradually chip away at QA.
Not explicitly anyway. Google's testing strategy is as it has always been: do some in-house burn-in testing, then launch to a small number of users and check for unexpected failures, then widen the launch window, then launch to 100%.
In this case, the user base in question is so miniscule that no bugs probably showed up at the 1%, 10%, and 50% launch gates.
I think it changes your user agent string to something that doesn't say "mobile", and the device "inner resolution" or something like that to make it zoom out.
[+] [-] kramerger|2 years ago|reply
"This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl,
and it seems that this affects all UA strings with versions >= 65. <=64 work."[+] [-] ethbr1|2 years ago|reply
Whatever UA string Firefox Mobile sends in desktop mode returned fine.
[+] [-] stuaxo|2 years ago|reply
[+] [-] andrelaszlo|2 years ago|reply
https://camo.githubusercontent.com/16a554571b3cea973d2b73464...
[+] [-] kreeben|2 years ago|reply
[+] [-] _____-___|2 years ago|reply
[+] [-] dannysullivan|2 years ago|reply
[+] [-] QuinnyPig|2 years ago|reply
[+] [-] jedahan|2 years ago|reply
[+] [-] Uptrenda|2 years ago|reply
[+] [-] andrelaszlo|2 years ago|reply
[+] [-] donny2018|2 years ago|reply
[+] [-] Thorrez|2 years ago|reply
Disclosure: I work at Google but not on this. This was linked from the Bugzilla bug.
[+] [-] robin_reala|2 years ago|reply
[+] [-] dang|2 years ago|reply
If you want to say what you think is important about an article, that's fine, but do it by adding a comment to the thread. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...
(Submitted title was "Google breaks search for Firefox users because of bad UA string sniffing")
[+] [-] WhackyIdeas|2 years ago|reply
https://news.ycombinator.com/item?id=38349357
[+] [-] forward1|2 years ago|reply
[+] [-] mozvalentin|2 years ago|reply
This is entirely server-side UA sniffing going wrong. You get an empty HTML doc, only a doctype, with a Firefox Android UA. You can reproduce this with curl and it seems that this affects all UA strings with versions >= 65. <=64 work.
[+] [-] aragilar|2 years ago|reply
[+] [-] rendaw|2 years ago|reply
[+] [-] RulerOf|2 years ago|reply
> Warning: A number of older versions of browsers including Chrome, Safari, and UC browser are incompatible with the new None attribute and may ignore or restrict the cookie.
This caveat meant that UA sniffing was the only reliable means of setting cookies that were guaranteed to work properly.
1: https://web.dev/articles/samesite-cookies-explained
[+] [-] throwaway167|2 years ago|reply
[+] [-] scott_w|2 years ago|reply
This had nothing to do with feature detection, so the usual suggestions simply won’t work.
[+] [-] xcdzvyn|2 years ago|reply
[+] [-] rstuart4133|2 years ago|reply
You don't get that sort of speed without heavy optimisation. In fact I'd be amazed if www.google.com isn't the most heavily optimised page on the internet. So it's not at all surprising to me that they optimise based on what browser is asking.
[+] [-] dathinab|2 years ago|reply
basically you can send slightly less data by only sending the relevant layout/js code etc. with the first request instead of sending some variation which then the browser selects/branches one
most likely a terrible optimization for most sides maybe not google search due to how much it's called
but then Google is (as far as I remember) also the company which has tried to push the removal of UA strings (by fixating all UA strings to the same string, or at least a small set of strings)... so quite ironic
[+] [-] PlutoIsAPlanet|2 years ago|reply
[+] [-] Jenk|2 years ago|reply
[+] [-] leosanchez|2 years ago|reply
Just an evil company really.
[+] [-] Symbiote|2 years ago|reply
[+] [-] doublerabbit|2 years ago|reply
However wanted to screw Firefox users the same way as the YouTube slowdown.
[+] [-] lopis|2 years ago|reply
[+] [-] dylan604|2 years ago|reply
[+] [-] forward1|2 years ago|reply
It's fascinating how people clamor for more government regulation and control at the first sign of trouble, without reasoning about the implications of those things, despite a history replete with examples of power abuse from the same.
[+] [-] shiomiru|2 years ago|reply
[+] [-] fxtentacle|2 years ago|reply
[+] [-] jraph|2 years ago|reply
[+] [-] Fatnino|2 years ago|reply
[+] [-] lopkeny12ko|2 years ago|reply
Is it just me, or is this absolutely insane? When Google ships a bug, it's suddenly the responsibility of browser vendors to "fix" it at the browser level?
[+] [-] oh_sigh|2 years ago|reply
It happens all the time, you probably just don't realize it. There is special code in Windows for supporting/un-breaking popular applications, same with Android and iOS.
[+] [-] datadrivenangel|2 years ago|reply
[+] [-] genevra|2 years ago|reply
[+] [-] ryukoposting|2 years ago|reply
Google has marginal incentive to not kill Firefox (antitrust), they have no incentive to make sure they provide a good experience on Firefox, let alone test with it.
The issue seems to be isolated to the search home page, and Google Search hasn't exactly been associated with "quality" in several years. Internal rot and disinterest gradually chip away at QA.
[+] [-] shadowgovt|2 years ago|reply
Not explicitly anyway. Google's testing strategy is as it has always been: do some in-house burn-in testing, then launch to a small number of users and check for unexpected failures, then widen the launch window, then launch to 100%.
In this case, the user base in question is so miniscule that no bugs probably showed up at the 1%, 10%, and 50% launch gates.
[+] [-] _flux|2 years ago|reply
[+] [-] ale42|2 years ago|reply
[+] [-] dathinab|2 years ago|reply
at least not for firefox mobile
they probably test for chrome (desktop+mobile), safari (desktop+mobile), edge(desktop) and maybe Firefox (desktop) but probably no other browser
[+] [-] ranting-moth|2 years ago|reply
[+] [-] conradfr|2 years ago|reply
I never actually looked at what this does.
[+] [-] andirk|2 years ago|reply
https://www.google.com/search?q=what+is+my+user+agent+string
https://www.whatismyscreenresolution.org/