Hacker News Reader

Comment by jchw | Hacker News Reader

I wish people would stop trying to force inject cynicism into this because this is actually pretty amazing of an idea imo. If you look at browsers like Falkon or QuteBrowser they are perfectly serviceable browsers but actually using them can be annoying due to UA sniffing, even by Google. In theory this is the solution to that problem. Freezing and unifying the UA will prevent everyone, including Google, from using it to gate features.

I am a bit worried, though, about how we will continue to count marketshare. If the intent were to remove the UA it would be worse, but it does seem like browser marketshare analytics based on user agents may be coming to an end.

(Disclosure: I work for Google on unrelated projects.)

View on HN

Meanwhile, Google is forcing this massive change across the web right now by defaulting cookies to SameSite=Lax, something that breaks a lot of login scenarios. The only way to fix it is to start emitting SameSite=None. BUT WAIT, a lot of fairly recent browsers (e.g., iOS < 13, Chrome 51-66) don't support it, so you actually need to do this crazy user agent sniffing to not break things: https://www.chromium.org/updates/same-site/incompatible-clie....

I find it ridiculous that one part of Chrome is forcing me to add user agent sniffing while another part is trying to deprecate it. They need to get their act together: their decisions have massive consequences across the ecosystem and they need to be more responsible.

I've seen this complaint a lot, and to me it amounts to saying "this default is wildly insecure but is used by a tiny fraction of sites, so I'd rather keep the insecure default rather than ask those sites to add a single header".

Perhaps you can correct me on why that's not so.

because adding that single header breaks the behavior on old browsers

The problem isn't that they need to add a header. The problem is that they need to add the header _or not_ depending on which browser is making the request. Which means you have to sniff the user agent, even though pretty much everyone agrees browser agent sniffing causes problems, and the same browser that is pushing this change is also trying to get rid of the only way to know if that header should be set or not.

And I think the chrome team could have come up with a solution that didn't involve browser sniffing, such as sending a header in the request identifying that SameSite=Lax is the defualt, or that SameSite=None is accepted. But instead they recommended sniffing the user-agent string.

I don't understand why you sometimes need to not send the header. What happens if you do, in those cases?

https://bugs.webkit.org/show_bug.cgi?id=198181 . If you tell Safari SameSite=None it treats it as SameSite=Strict. If you tell Chrome a couple months from now without SameSite=None, you get SameSite=Lax. There's no way to do this without UA sniffing.

That seems like a pretty egregious bug, presumably there's a spec someone is in violation of?

The blame lies somewhere between Safari and Chrome. The "None" value was added after the Safari implementation, and then Chrome wants to do the default-changing this year now. Unfortunately it looks like the fix isn't going to get backported to iOS 12, so here we are :-(

Safari was not following the spec.

Depends on whuch spec you mean. Older versions of safari (anf chrome) were following the original proposed standard (rfc 6265), which said invalid values should be treated as strict. Later versions of Chrome are following a later internet-draft (rfc 6265bis, which I think was proposed by google), that introduced SameSite=none, and changed the behavior for unknown values to be the same as none.

The point is that UA sniffing provides a last resort way of dealing with bugs in browsers until they are properly fixed (if ever). Imperfect as UA sniffing is, it's a lot better than having literally no way to identify and fix an issue people are having.

The question here is whether the browser is a tool to solve your business issues, or whether it is a a service that is more similar to police, firefighters or healthcare. I am way more biased towards the second.

If you send SameSite=None, Chrome 51 through 66 ignore the Set-Cookie header. Chrome 80 requires SameSite=None for cross domain POSTs (e.g. authentication). Google is recommending removing the User-Agent header while Google websites use User Agent detection to workaround bugs in Google User Agents. See https://www.chromium.org/updates/same-site/incompatible-clie... for details of other incompatible User Agents.

Currently (unless this has change in the past couple weeks) if you add SameSite=None on Safari it will treat it as SameSite=Strict. https://bugs.webkit.org/show_bug.cgi?id=198181

So this means that if you need to use SameSite=None you cannot without UA sniffing, which I think is what the parent was complaining about.

I have been on receiving end of browser bugs, developing cutting edge JavaScript applications.

It's VERY useful to be able to use the UA string to do something like:

if (Chrome version X) then { do this crazy workaround because Chrome is broken }

No. People don't even necessarily update to the latest version. The "Samsung Browser" was notorious for seemingly always be some old fork of Chrome or Chromium that would never update.

That approach is fragile, because it won't stop applying the crazy workaround after Chrome version Y fixes the problem. You can't know which version it's going to be, and there's a chance you won't be maintaining that code anymore then.

But if you can't sniff the browser version, you might still have to apply the crazy work around forever because you have no way of knowing when to stop. It works both ways.

The correct approach is to use feature detection. There are libraries available for it, such as Modernizr [1].

[1] https://modernizr.com/docs/#what-is-feature-detection

You can't always feature detect bugs. I'm not sure why this entire thread is filled "use feature detection" when it's been historically clear that it isn't sufficient.

Part of the proposed deprecation of the useragent is a JS API to expose the information.

A JS API that tells you which bugs exist in the browser?

> Where feature detection fails developers, UA Client Hints are the right path forward.

UA Client Hints will provide: brand, major version, full version, platform brand and architecture, platform architecture, model and whether it should be treated as a mobile platform.

If you were using the UserAgent to guess if the browser was a particular version with a particular bug, now you don't have to parse something and probably get it wrong.

> UA Client Hints will provide: brand, major version, ...

It seems you are using "Mozilla 5.0". Your browser is really out of date!

Please consider updating to rand("Googlebot/2.1", "Version/7", "XUL/97", "HTML/5").

There's no guarantee the user's browser will just hand over that information with the new spec:

> User agents ought to exercise judgement before granting access to this information, and MAY impose restrictions above and beyond the secure transport and delegation requirements noted above.

Great, now my server side rendering code needs to inject JS into the customer to feedback agent capabilities.

Or check the proposed headers that will also get sent: Sec-CH-Arch, Sec-CH-Model, Sec-CH-Platform, Sec-CH-UA, Sec-CH-Mobile.

Sec-CH-Mobile ? - please tell me the meaning of this is "user agent changes position, refresh positional data often" (checks the specs)

  user agent prefers a "mobile" user experience.

the spec is a tautology using air-quotes :/

That makes sense to me. Different websites will have different expectations of what specifics a mobile experience will need. It may just be different style sheets, or the dev will need to take into account the activity of their particular site, such as reducing background connections to preserve battery life, etc.

Surprisingly i do know what >> "mobile" experience << means in this context and can therefor make sense of this, too. I am just making fun of it by pretending i am reading a technical document that is supposed to specify how to build a sane and reliable system ;-)

Which is silly since the information that's needed to work around version specific bugs is ($vendor, $version) so people will just end up depending on that and it will start the cycle again.

I appreciate the idealism of "if your standard's compliant site doesn't work in Chrome 142 then it's Google's problem" but I can't just throw up my hands and let my site be broken.

> so people will just end up depending on that and it will start the cycle again.

The User Hints spec specifically says that user agents aren't required to provide them in all circumstances, and that they shouldn't be provided in some.

> User agents ought to exercise judgement before granting access to this information, and MAY impose restrictions above and beyond the secure transport and delegation requirements noted above.

The message from Google is clear: Whilst we understand you want to work around bugs, and this is the only way to do it, you really should be second-guessing whether you need to touch this API at all.

You can't always detect browser version, either.

Hard problems are hard, but my experience, and the recommended approach by browser implementers, is that feature detection works better.

For that to work, browsers would also have to accurately advertise their own bugs/quirks, which might be a difficult ask.

Wouldn't those quirks be sufficient to fingerprint in the same way?

What if the DOM looks perfectly normal, but doesn't render correctly?

The fundamental issue with this is it tells you about what's there when what you need to know is what's broken (not even necessarily what's missing).

But this is only accessible on the client side, what about all the other backcompat code on the server side (like the SameSite issue mentioned elsewhere in the thread?) Or server-side rendering? Are we not supposed to care about progressive enhancement anymore?

I build HTML5 games and I need to use very specific hacks for certain browsers, e.g. use a different offscreen canvas implementation for Safari due to performance. I can't use feature detection since it's not about a missing feature.

You can benchmark the alternatives for 2 seconds and choose the faster. Call it: performance detection

+1. The number of rendering invalidation bugs I had to work around in mobile Safari is crazy.

`if(affectedBrowserUA) { elem.style.transform = 'translate3d(0,0,0); elem.style.transform = ''; }`

Edit: I guess you can achieve the same thing through UA client hints. Just need to add a new JS file that reads the request headers and maps them into JS globals.

There's a proposed API for JavaScript to get the same information.

Oh, yup, I see that now. That was the next point after the headers one in the spec.

I'd argue that if you're doing this you can't have tested your JavaScript on many platforms. This breaks very quickly in my experience. Feature detection[1] is a much better strategy. That can get complicated too, but often there are third-party polyfills that can do that for you.

[1] https://developer.mozilla.org/en-US/docs/Learn/Tools_and_tes...

In the short-term this might be annoying, but in the longer term this is going to force browsers to adhere more closely to standards. When sites are less able to write different code for different browsers, the onus to fix inconsistencies will transfer from site-maintainers to browser-maintainers.

In 5 years you might look back and realize you no longer write browser-specific code any more.

I have been involved with Web development in some form since late 90's, nice utopia that will never happen.

Unless in 5 years we have only Chrome left, then surely.

> In 5 years you might look back and realize you no longer write browser-specific code any more.

We said the same thing when IE started losing market share a decade ago.

The problem is, everyone who makes a browser thinks they have the best ideas in the world, and then impliment them, but their users never blame the browser.

If someone is trying to access your site and it breaks, do you really think they're going to say, "dang, I should really tell Chrome to fix their incompatibility".

No, they will always assume the error lies with the site owner.

In such a world, it is not standards that win. It is the predominant browser that wins.

Are you old enough to remember the "best viewed with Netscape" badges that were everywhere in the 90s?

Haha, brings back the old days. I had my sites plastered with "best viewed with your eyes" badges, but that never took hold :)

Google can start by phasing out UA sniffing on their own websites, such Google Stadia blocking Microsoft's Chromium Edge users:

https://winbuzzer.com/2020/01/03/google-stadia-is-currently-...

Does this change allow for the server to refrain from having to do RPCs to the browser to get additional feature information to figure out what quirks the vended page / JS needs to be compatible with?

I'm all for more privacy, but IIUC the main reason big sites like Google still do any UA sniffing at all is to minimize the latency / byte cost for the client in vending a web site that is expected to work.

IMO: Old browsers will still send UAs, since obviously they’re not going to update for this change. New browsers should support enough of the web platform to obsolete this practice going forward.

New browsers still don't support everything. One of my biggest questions: "Does this device have a keyboard?" (relevant for "should I show hints for keyboard shortcuts?") is still straight-up unanswerable, and all I can do is guess from the UA.

Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc.

Ideally, imo, most sites should use the web platform as intended and their sites will work fine regardless of input device.

If you are using UA sniffing to determine if the device has a keyboard it will be wrong a lot of the time; you can’t tell if a Microsoft Surface has the keyboard attached or an iPad doesn't. you’d probably be no worse off trying to detect it by screen width, which is already a defacto way to detect mobile devices anyways, for better or worse.

(The right solution is probably a new kind of API or media query.)

I know, that's why I said "unanswerable" and "all I can do is guess".

The specific feature this came up recently is whether or not a chat app should autofocus the input box. Ideally, the answer is "yes" if you have a keyboard (lets you start sending messages faster) and "no" if you don't (the on-screen keyboard would cover up the conversation and be distracting).

There's, of course, no way to detect an iPad keyboard, so currently iPads miss out on autofocus.

Discord, incidentally, uses an alternate solution: "don't autofocus the textbox, but instead detect keypresses outside the textbox and manually insert the corresponding letters in the box". This, of course, completely fails for various non-Latin keyboards, such as Japanese: if you type "chi", it will insert 「cひ」 instead of 「ち」.

>> Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc

Why are you doing all that? Just offer the desktop version or Mobil version and be done with it. You dont need to figure out dev_caps in such detail.

Because I still believe in the ideals of responsive web design. If a desktop user wants to use my site in a tiny window (maybe to tile it next to another window), they should still be able to use keyboard shortcuts. And if a user with a large screen wants to use touch interaction (maybe they have a Surface Studio), they should be able to.

There's no reason to make multiple sites each with their own flaws, when you can just make one site that can do anything.

> One of my biggest questions: "Does this device have a keyboard?" (relevant for "should I show hints for keyboard shortcuts?") is still straight-up unanswerable, and all I can do is guess from the UA.

Mobile devices have keyboards. If you mean "does this device have a physical keyboard", you don't need to know that. If you mean "does this device have modifier keys like ctrl and alt", someone might have hooked up a bluetooth or USB keyboard to their mobile device.

If you're on a large screen, show hints if you have room. (You might also show such hints in tooltips, as devices with a concept of "hover" correlate well with devices where keyboard shortcuts make sense.) If you're on a small screen, provide a way for people to get those hints anyway via a help option.

> Other questions include "should I tell the user to drag-and-drop?" "should I tell the user to tap?" etc.

19-year-old advice that remains useful: https://www.w3.org/QA/Tips/noClickHere

You can't tell from the user-agent if, for instance, someone might be using a screen-reader or other assistive technology, or otherwise using an interface you don't expect. Tell people what option/link to use, not how to activate it. Help them out with things like highlights, or tours, or sample videos.

> 19-year-old advice that remains useful: https://www.w3.org/QA/Tips/noClickHere

Ah, my favorite aspect of the w3c process: responding to the need for perfectly reasonable UX discoverability for users unaccustomed to using browsers with "You don't actually want to do that."

There's a reason so much of the web development world considers the documents they make to be "take with a grain of salt and do what works for your users."

I'm moderately annoyed you think I don't already know all these things.

The problem isn't that I don't know these things, it's that I'm beyond those things and trying to add subtle things to improve quality of life.

> Mobile devices have keyboards. If you mean "does this device have a physical keyboard", you don't need to know that. If you mean "does this device have modifier keys like ctrl and alt", someone might have hooked up a bluetooth or USB keyboard to their mobile device.

Yes, and this makes the experience on mobile devices worse!

On a laptop, if you open Discord, click on your friend's name, and start typing, you'll send your friend a message.

On an iPad with a keyboard, if you open Discord, click on (tap) your friend's name, and start typing, nothing will happen.

You say "there's no way to detect an iPad with a keyboard" like it's a good thing, but it's clearly a bad thing!

I go over a similar problem here: https://news.ycombinator.com/item?id=22047246

> If you're on a large screen, show hints if you have room. (You might also show such hints in tooltips, as devices with a concept of "hover" correlate well with devices where keyboard shortcuts make sense.) If you're on a small screen, provide a way for people to get those hints anyway via a help option.

This is clearly a worse experience for the user because it means hints are shown to users for whom they make no sense.

Like, yes, that's what I currently do, and it sucks.

> You can't tell from the user-agent if, for instance, someone might be using a screen-reader or other assistive technology, or otherwise using an interface you don't expect. Tell people what option/link to use, not how to activate it. Help them out with things like highlights, or tours, or sample videos.

There aren't ways to detect if someone is using a screen-reader, but there are plenty of W3C ARIA tags screen-readers understand, which, if used correctly, can improve quality of life for them. I get a lot of feedback from screen-reader users that they love my graphical online video game, because I went out of my way to improve quality-of-life for them.

And now, I want to improve quality-of-life for users on iPads, and you tell me "no! everything must be the same on everything!" No! I refuse to accept that!

GitHub has a hint in their comment boxes that you can attach files by drag/drop or pasting. That's the sort of thing I'm talking about. It's miles away from a button labeled "click here". There's no need for this smarmy "don't tell the user how to activate a feature". Some features are subtle and need hints!

> I'm moderately annoyed you think I don't already know all these things.

I was not suggesting you didn't, but more than one person will read this conversation.

> This is clearly a worse experience for the user because it means hints are shown to users for whom they make no sense.

Or to users for whom you don't know that they do make sense. If you guess incorrectly that a device doesn't have a keyboard when it does, you'll prevent users from discovering your keyboard shortcuts.

I would also suggest that web standards need to improve, to make it easier to help figure out which hints to offer. For instance, I think it would be perfectly reasonable to offer a mechanism to detect "should I show hints for keyboard shortcuts", which desktop browsers would always enable, and mobile devices would enable if they have an attached keyboard or if the user is using another mechanism that might allow for shortcuts. And one day, perhaps we'll have a standard for keyboard shortcuts that will allow users to remap those shortcuts and allow the browser to provide "native" hints that those shortcuts exist.

I'm not trying to suggest that the current state is ideal, or that it can't be improved. I'm suggesting that user-agent-based detection is in some ways worse.

> no! everything must be the same on everything

That's not what I said. I'm suggesting that everything should be accessible on every platform. You might well make adaptations and hints based on screen size, or based on whether the user has previously typed keys directly at something other than a text box; just don't make assumptions the user can't work around or change if you've detected them incorrectly. I've dealt with sites that force the use of mobile if they catch the slightest whiff of "this might be a mobile device", and the mobile experience is far less capable. (That's leaving aside the anti-pattern of "are you sure you want to use a web browser instead of our app?".)

Personally, I would suggest detecting if someone "types at" the page without being in an input box, and offering to not only focus the input box but set a device-local preference to automatically do so in the future.

I think the thrust of GPs argument is "Before they take away the UA string (the one clumsy tool that I can use to half-accomplish my goals) I wish they'd add official APIs to detect these kinds of things".

> If you mean "does this device have modifier keys like ctrl and alt", someone might have hooked up a bluetooth or USB keyboard to their mobile device.

I'll take the liberty to say yes, that is what they mean, and that is their point: there is no way to detect whether those keys are available, so the best we can do is guess.

And yes, I might actually need to know whether there is a physical keyboard or not. For example, do I auto-focus the input field? For devices with OSKs, the keyboard will pop up right away and obscure most of the site on mobile. For devices where the OSK won't pop up, I want the focus to land there immediately for usability.

Agree. Also with a physical keyboard (PC) you can filter keypress events in an <input>, but with a virtual keyboard (Android) you cannot (keycode is always 0 due to IME).

A time entry input is a good example: on the PC you can accept valid [0123456789:.APMapm] characters as the user types, and have the HTML page do something sensible and show something sensible. On Android you either have an ugly time picker (they are all ugly!) or use hideous workarounds to try and detect keypresses.

Android and iOS have `inputmode=` but it is very restricted and there are wierd and sometimes incompatible differences between browsers or browser versions or OS versions. Custom data entry (e.g. time, date ranges, etc) is super ugly in HTML.

I have found many browser version and device specific bugs with virtual keyboards or PC keyboard entry that cannot be "feature detected" (browser version must be sniffed).

Please stop trying to do the browser developers' job. If focusing the input field opens the keyboard, that's the correct behavior, whether you agree with it or not.

> should I tell the user to tap

I always use the term "tap". MacBook / Magic trackpads literally have an option called "tap to click".

> should I tell the user to drag-and-drop

Both mobile and desktop support drag and drop, so not sure why you'd want to disable it for either.

Mobile browsers are space constrained so although you can drag and drop, practically speaking if your drop target is off screen, it’s a poor user experience.

> if the intent were to remove the UA it would be worse

That is hopefully the end goal. It's not worse, it's an ideal that goes hand in hand with reducing cookie usage, removing flash, mandating SSL, etc. The UA was an attempt to see if the ecosystem could cooperate to make apps more actively intelligent. This is a failed experiment. Security teaches us to reduce attack surface and we should not be using half-measures like a header-string to trigger naive/implicit client behavior. Behaviors should be explicit for safety.

It's a great technical decision that may hopefully drive sites towards web standards, but technical decisions don't exist in a vacuum and can't be analyzed in them.

The world's biggest advertisement provider's browser arm isn't going to turn off a source of fingerprinting data unless they simply don't need it anymore. It's far more likely that Google is pulling the ladder up behind them: they can identify users without that fingerprinting data, so it's beneficial to deny it to their competitors.

This can be simultaneously a great technical decision and a decision that entrenches Google.

> I am a bit worried, though, about how we will continue to count marketshare. If the intent were to remove the UA it would be worse, but it does seem like browser marketshare analytics based on user agents may be coming to an end.

I think there's an implicit assumption a lot of people (not you) are making: that there's no cost in collecting data. There is: often you change things by observing them, and that's not always a good thing.

There are big costs to UA strings.

> In theory this is the solution to that problem

How so? There is still an API to ask for more details, so you can continue to do exactly the same thing as before at the cost of a few additional API calls

What am I not seeing? To me this feels like just adding more complexity to still end up at the same spot we are now.

as I observed in the previous thread on this subject you will still be able to gate features, just you won't use the UA to do it. It might also be that being able to detect exactly what browser someone is using will become a much harder undertaking, requiring significant investment of developer hours, that only some companies will have the resources to invest.

Reply on news.ycombinator.com