[HN Gopher] Blink-Dev - Intent to Deprecate and Freeze: The User...
___________________________________________________________________
Blink-Dev - Intent to Deprecate and Freeze: The User-Agent string
Author : jasonvorhe
Score : 325 points
Date : 2020-01-14 12:13 UTC (10 hours ago)
(HTM) web link (groups.google.com)
(TXT) w3m dump (groups.google.com)
| buu700 wrote:
| There are many, many cases where UA sniffing is correct and
| required. Browsers are buggy, complicated pieces of software that
| don't always behave 100% as specified or expected.
|
| Feature detection is well and good, and should be the first line
| of attack; but sometimes you need to account for things like
| certain versions of Safari having WebRTC "support" that's
| actually completely broken, certain versions of Chrome crashing
| when certain WebAssembly features are used, and Firefox-specific
| CSS bugs. (All real examples I've run into.)
|
| It may not be the worst thing in the world if UA sniffing is
| broken for all existing web properties though, since anything not
| well maintained enough to migrate to a new API is probably either
| working off of outdated information or abusing UA sniffing where
| feature detection would have been more appropriate anyway.
|
| That being said, requiring a server to use User Agent Client
| Hints is stupid. What are client-side libraries like webrtc-
| adapter (https://github.com/webrtcHacks/adapter/issues/1017)
| supposed to do? I don't see any goals listed that wouldn't be
| addressed equally well while providing an equivalent JS API.
| crazygringo wrote:
| > _There are many, many cases where UA sniffing is correct and
| required._
|
| This times a million.
|
| Browsers have _tons_ of bugs /inconsistencies where knowing the
| browser+version is the _only_ way to work around them. Even
| when browsers fix them, you need to keep the workarounds for
| people still on the older versions.
|
| When I wrote a library that used the audio API, I couldn't
| _believe_ the number of browser+version-specific workarounds I
| had to code for.
|
| And it's not just "bugs" but things where the spec is unclear.
| I don't remember the exact specifics, but it was a lot of stuff
| like "if I send a pause command, will a stop event fire
| afterwards or a pause event or no event at all?" There were a
| lot of situations where there was zero overlap between
| browsers. Literally no choice but to use user agent sniffing.
| ronancremin wrote:
| The irony of Google purporting to protect users' privacy while at
| the same time:
|
| - Chrome is still shipping with 3rd party cookies turned on by
| default (Safari and Firefox have them off, by default)
|
| - Chrome usage stats are sent to Google including button clicks.
| This is admitted in the Chrome privacy policy.
|
| - Chrome on mobile _automatically_ shares your location with your
| default search engine i.e. Google
|
| - Chrome sort of forces a login ...which shares browser and user
| details history with Google
|
| - Google redirects logins through the youtube.com domain to
| enable them to set a cookie for YouTube as well as Gmail or
| whatever, every time you login. Naughty stuff.
|
| So the stated reason for the change doesn't appear to make sense,
| suggesting that something else is going on.
|
| It amazes me that more people aren't calling Google out on this.
| Ghjklov wrote:
| From my experience, I always needed to explicitly change
| Firefox setting to disable 3rd party cookies on a fresh
| install.
| jasonvorhe wrote:
| > - Chrome sort of forces a login ...which shares browser and
| user details history with Google
|
| This doesn't get more true by just repeating it over and over.
| If you login to Google it'll show up in Chrome next to the
| address bar but it doesn't enable any syncing to Google
| servers. That's a different step and it requires opt-in. You
| can also use Chrome without logging in to any Google services.
|
| I don't get why privacy advocates, who often have a point when
| talking about Google, have to rely on FUD.
| techntoke wrote:
| Because most of the negative attention that Chromium receives
| is FUD by people that rely on feelings and not facts.
| allovernow wrote:
| Invasion of privacy is a valid and serious concern. The
| fact is that Google is collecting sensitive information
| semi-consensually and semi-transparently and arguably
| shouldn't be.
| scarejunba wrote:
| Because let's be honest, most "privacy advocates" on HN are
| trying to be purer than the other guy. Ideological purity is
| what they're after, not privacy.
| dawnerd wrote:
| I don't know if google redirecting their logins through YouTube
| and gmail are as bad as you make it out to be.
| dhimes wrote:
| _- Chrome on mobile automatically shares your location with
| your default search engine i.e. Google_
|
| Holy fuck!
| czardoz wrote:
| > So the stated reason for the change doesn't appear to make
| sense, suggesting that something else is going on.
|
| That's unsubstantiated and dilutes the discussion IMO. If you
| read the post, the proposal outlines a bunch of good reasons to
| stop supporting UA strings (feature detection, etc)
| glogla wrote:
| Google is not protecting its users privacy, it is protecting
| their own business. They want everyone's ads to be worse than
| Google's, so you use Google. Hiding private data from everyone
| but themselves is part of the plan.
| HorstG wrote:
| Exactly. That is also why "logging in to Chrome" or rather
| Google is such an insidious misfeature. Soon they will be the
| only ones with cross-site tracking and third-party-cookie
| equvalents in the leading browser.
|
| That would be check mate for all other advertisers.
|
| I'm just not sure whether it's good or bad that antitrust
| regulators won't notice before it's too late.
| JohnFen wrote:
| I think that you're right. Regardless, these moves (as weak
| as they are so far) are beneficial for privacy in general.
|
| I'll take that benefit even if it tilts the advertising table
| in favor of Google. I don't care even a little about the
| overall health of the advertising/marketing industry.
| shadowgovt wrote:
| Blink is Chromium's rendering engine. It's separate from Chrome
| the browser application vended by Google.
| geofft wrote:
| Chrome also announced today a plan to get rid of third-party
| cookies: https://blog.chromium.org/2020/01/building-more-
| private-web-... And in fairness to them, Firefox and Safari's
| changes are very recent.
|
| Anyway, Google is a big company. Different teams have different
| priorities. Does the US government care about privacy? Depends
| - at the very least - whether you're the NSA or the FTC. Given
| the many signs in the past that parts of Google are willing to
| fight other parts of Google they disagree with, I think a
| better strategy for us as the community is to call the Chrome
| team out, specifically, on things under their control and
| otherwise not be excessive cynical about the fact that they
| along a hundred thousand other people work for Google, and some
| of those other people are bad.
|
| (Automatic login to Google _is_ a think I think we should call
| them out for, to be clear.)
| ronancremin wrote:
| I agree that the Firefox change is recent, but not Safari.
| Safari has had 3rd party cookies disabled for many years now.
| traek wrote:
| It's pretty silly to claim that the (admittedly bad) privacy
| policies of Google, or even Chrome, as a whole means it
| "doesn't make sense" for any team within Google to advance a
| pro-privacy or pro-WWW project.
|
| This all-or-nothing mindset ends up harming privacy in
| practice.
| [deleted]
| Ayesh wrote:
| This can have a huge impact.
|
| - Server log analytics will not be able to provide OS/Browser
| stats.
|
| - Default download pages (Detect OS automatically and redirect to
| the platform-specific download pages) would not work.
|
| - "m." Sites: there are still some sites that sniff the UA string
| and redirect users to mobile site. It's looking for patterns like
| "/mobile/" in UA, and don't require a lot of updates as the post
| argues.
| onion2k wrote:
| I think you'll still be able to tell what OS and browser it is,
| just not the specific major or minor version because they'll be
| 85.0.0 (if that's the version when this happens) forever. All
| of the examples you've put there will still be achievable with
| the out-of-date UA string.
| [deleted]
| tjelen wrote:
| And at the same time they recommend using UAs to detect agents
| incompatible with SameSite=None cookies (see
| https://www.chromium.org/updates/same-site/incompatible-clie...),
| including certain Chrome versions.
| ChrisSD wrote:
| > On top of those privacy issues, User-Agent sniffing is an
| abundant source of compatibility issues, in particular for
| minority browsers, resulting in browsers lying about themselves
| (generally or to specific sites), and sites (including Google
| properties) being broken in some browsers for no good reason.
|
| > The above abuse makes it desirable to freeze the UA string and
| replace it with a better mechanism.
|
| UA sniffing should have died out a long time ago. It's
| frustrating that it's 2020 and I'm still having my browsing
| experience broken for no other reason than the site doesn't like
| my UA.
| dTal wrote:
| Of course, when the User Agent sniffing messes up, you're
| perfectly free to change it, and see what else you can get the
| server to send you. Can you still do that with whatever crazy
| "feature detection" replaces it?
| DJBunnies wrote:
| I have some news for you about what year it is.
| ChrisSD wrote:
| Thanks, I've edited.
| cmsd2 wrote:
| i predict this comment will age badly.
| gsich wrote:
| Don't use $current_year argumentation.
| wruza wrote:
| It is a subjective version of "too long not fixed". Like gp
| remembers this exact problem in 1980/1990/2000 and still
| there it is. A specific year has nothing to do with it.
|
| So come on, it's 2020 and we still have to explain idioms to
| each other :)
| interfixus wrote:
| Don't _don 't_.
| sebazzz wrote:
| User agent sniffing is still sometimes required. Take the
| SameSite bugs that Safari had. On the server you needed to act
| on that based on User Agent sniffing.
| vdnkh wrote:
| Agreed. For media streaming UA sniffing is required because
| of quirks each browser has in decoding media. Safari has a
| few quirks about the MP4 packaging it likes via
| MediaSourceExtensions. Firefox's network stack includes a
| delay not related to the actual request because of its
| implementation[0] which makes timing of small downloads very
| inaccurate. None of these differences are discernible except
| by UA.
|
| [1] I believe FF includes in the download length the time a
| request spends sitting in the request queue, but I can't
| exactly remember.
| Macha wrote:
| I also remember a CSS bug Safari 4 or 5 had with tables and
| touch scrollbars that we had to resort to UA detection for -
| it's not always possible to feature detect bugs.
| nmadden wrote:
| Right, and it's not just Safari. This is the current
| complexity of User-Agent sniffing that the SameSite change
| requires if you need to disable it:
|
| https://www.chromium.org/updates/same-site/incompatible-
| clie...
| jerf wrote:
| I think it's distinctly possible that the current status quo
| may cause an overreaction. Feature detection is good. But we
| may also need the ability to do specific version checking
| sometimes.
|
| What I think would be best is two things: A feature
| advertising string (preferably with some versioning in
| itself), and a new User Agent string that is _just that_ :
| The user agent. As in, "This is Firefox 72.2.813". Maybe the
| OS in there too. I think a non-trivial part of the problem
| with the UA today is "Hey... I'm Firefox. Also, I'm Mozilla.
| Also, I'm edge 3, and Internet Explorer 6, and today I think
| I'm also Chrome. Also, I may be a monkey with a banana
| plugged in to an ethernet cable." Part of the problem is that
| people abuse the user agent, but part of the problem is that
| the user agent string is also a pack of outright, outrageous,
| self-contradictory lies. A _truthful_ field may still have
| significant utility.
|
| One of the things I've learned over the years in software
| engineering is that you should do you best to make sure that
| your system doesn't contain lies, or, failing that, treat
| them like any other issues that you should contain at the
| edges rather than letting it run riot through your system.
| For instance, if you decide to let customers have 10GB of
| bandwidth free before you start charging them, you should
| _never_ accomplish that goal by tweaking the bandwidth
| counting system to report 7.5GB of usage as 0GB. That is a
| lie. Tell the truth about the usage and let the billing
| system apply the discount, which is itself a truth as well.
| You _always_ pay for lies in the system in the long run. It
| is a very common pattern in coding as well where some
| function author figures out how to assemble the correct lie
| to some other function to make it do what the author things
| they want, but in the long run you 're better off telling the
| truth and fixing the code to work with the truth. Otherwise,
| well, you really do end up with a tangled web of code. Which
| is... exactly what we've gotten with UA-detection-based code.
| We won't necessarily get the same mess if there's a new UA
| that isn't a lie.
|
| I'm not claiming this will lead to utopia. Minority forks of
| popular browsers will fail to pick up the necessary ad-hoc
| bug fixes this way, for instance. My claim is more like in
| the _long run_ , the best thing for everybody is just to have
| a user agent that tells the truth, even if on occasion in the
| short term you experience occasional problems.
|
| (One way to at least partially achieve this is to standardize
| the new truthful agent string to something like (\w+)
| ((\d+.)+\d) (\w+), and specify it as "non-conforming true
| user agent strings MUST be entirely rejected and treated as
| being absent", so anyone who tries to be Firefox and Chrome
| and also a monkey ends up being nobody in particular.)
| ChrisSD wrote:
| But that's what this proposal is about. Instead of using
| the user agent string (which lies and needs to be parsed)
| you have some well specified variables to check.
|
| Also I think you're missing why the user agent lies now. It
| wasn't done on a lark. It's because it's been abused so
| much by web devs. Both by sloppy regular expressions and
| deliberately. For example, even big names like Microsoft
| and Google have at times used it to unnecessarily deliver
| poorer browsing experiences to people not using their
| browser.
|
| Sure browsers could have stuck to their guns and been
| "honest" about their UA. But honesty is no comfort to users
| of the browser when they find websites break for no reason.
| The average user is more likely to blame the browser than
| the website.
| jerf wrote:
| I am completely aware of why the user agent lies now.
| Didn't I explain exactly how it is broken in my post? I
| was basically there for when it broke; I remember when IE
| came out claiming to be "Mozilla" because otherwise a
| surprising number of sites wouldn't serve them the latest
| whizbang Netscape 3 HTML. (I thought it was a bad idea
| then, but with much less understanding of why.) This is
| why I kept calling what I'm asking for a _new_ field; the
| User Agent itself can 't be rehabilitated.
|
| The parent of my post is correct; in practice we're still
| going to need the occasional ability to shim in browser-
| specific fixes, because even if the browsers do their
| best, they're going to _inadvertently_ lie in the future
| and claim to support WebVR1.0 in Firefox 92, but, whoops,
| actually it crashes the entire browser if you try to do
| anything serious in it. Or, whoops, Firefox 92 does do a
| pretty decent job of WebVR1.0 but I need some attribute
| they overlooked. Or any number of similar little fixups.
| We know from experience from the field in the real world
| that we 're talking about crashing bugs here at times;
| this is real thing that has happened. Whatever proposal
| gets implemented should deal with this case too.
|
| If we standardized on the format like I suggested at the
| end of my post, it would go a long ways towards
| preventing future browsers from mucking up the field. If
| you just get "$BROWSER $VERSION $OS" in a rigid
| specification, and if the major browsers are sure to
| conform to that, and the major frameworks enforce it,
| it'll be enough to prevent it from becoming a problem in
| the future. It won't stop Joe Bob's Bait Shack & Cloud
| Services from giving their client a custom browser and/or
| server that abuses it, but there's no stopping them from
| doing things like that no matter what you do, so _shrug_.
| ChrisSD wrote:
| Then I'm not sure I understand you. The proposal is
| clearly proposing new fields that are less susceptible to
| abuse (whether intentional or not). Your idea of parsing
| a "$BROWSER $VERSION $OS" string seems inferior to client
| hints that use structured headers.
| jerf wrote:
| I'm saying we still need a browser version field, _in
| addition to_ a feature field. Features would do on their
| own, if they were perfect, but we shouldn 't plan on them
| always being perfect. We have a demonstrated, in-the-
| field history of browsers claiming to support features
| when in fact they don't quite support them, and can even
| have crashing bugs. In the real world, supporting
| WebVR1.0 is more than just putting "web-vr/1.0.0" in the
| feature string.
|
| Culturally, you should prefer to use feature detection.
| Most developers would never need to use anything else.
| But when Amazon makes its new whizbang WebVR1.0 front-end
| in 2024, they may need the ability to blacklist a
| particular browser. Lacking that ability may actually
| prevent them from being able to ship, if shipping will
| result in some non-trivial fraction of the browsers
| claiming "web-vr/1.0.0" will in fact crash, and they have
| nothing they can do about it.
|
| Besides... they _will_ find a way to blacklist the
| browser. Honestly "prevent anyone from ever knowing what
| version of the browser is accessing your site" is not
| something you can accomplish. If you don't give them some
| type of user agent in the header, it doesn't mean the
| Amazon engineers are just going to throw their hands up
| and fail to ship. They will do something _even more_
| inadvisable than user agent sniffing, because you
| "cleverly" backed them into a corner. If necessary, they
| will examine the order of headers, details of the TLS
| negotiation, all sorts of things. See "server
| fingerprinting" in the security area. You can't really
| stop it. Might as well just give it to them as a header.
| But this time, a clean, specified, strict one based on
| decades of experience, instead of the bashed-together
| mess that is User-Agent.
|
| Or, to put it _really_ shortly, _the fact that a bashed-
| together User-Agent header has been a disaster is not
| sufficient proof that the entire idea of sending a User
| Agent is fundamentally flawed_. You can 't separate from
| the current facts whether the problem is that User Agent
| sniffing is always 100% guarantee totally black&white no
| shades of grey mega-bad, or if it's the _bashed-together_
| nature of the field that is the problem.
| xfalcox wrote:
| > SameSite bugs that Safari had
|
| Safari has SameSite bugs and it's infuriating that after
| years they don't even update the bug reports, let alone fix
| those.
|
| https://bugs.webkit.org/show_bug.cgi?id=200345
| JohnFen wrote:
| Working around browser bugs only helps to ensure that those
| bugs will never get fixed. Better that things like the UA are
| removed to make that impossible. In that world, sites would
| be best served be coding to the standard and putting the work
| of fixing incompatibilities/bugs back onto the browser makers
| where it belongs.
| LyndsySimon wrote:
| For context, as it's not immediately obvious at the link: Blink
| is Chrome/Chromium's rendering engine.
| ShinTakuya wrote:
| Thanks, I assumed so but it's useful to have this confirmation
| before I looked it up. Honestly this is a little surprising to
| me. Sites pulling shit like matching UA usually works out in
| Chrome's favour so it's nice to see them throwing the minor web
| browsers an olive branch.
| close04 wrote:
| Developers will still mostly target the most popular
| browser(s), particularly Chrome. It would be great if
| browsers like Firefox managed to implement a "feature
| detection spoof" that you can enable to still present
| yourself as Chrome (or other browsers) regardless of the
| actual features requested. More or less like changing the UA
| does now.
| GoblinSlayer wrote:
| That's Go Faster addon.
| close04 wrote:
| This looks like it's intended to fix specific issues, not
| for fingerprint blocking. I was thinking more like being
| able to present yourself as generic Chrome on Windows 10
| or Firefox on Android if you chose to, even with the risk
| of breaking the site.
| CodeWriter23 wrote:
| > It provides the information in small increments, so servers are
| only exposed to the information they need and request, rather
| than being exposed to the full gamut of the UA string even if
| they are just trying to figure out one detail about the browser.
|
| So, an extra RT if your app needs to sense which UA it's talking
| to.
| qwerty456127 wrote:
| > And finally, starting fresh will enable us to drop a lot of the
| legacy baggage that the UA string carries ("Mozilla/5.0", "like
| Gecko", "like KHTML", etc) going forward.
|
| Why not drop just that and leave nothing but the exact HTML and
| JavaScript engine names and versions like "Blink a.b, V8 x.y"?
|
| And what about robots? Will the Googlebot give the UA up as well?
| richthegeek wrote:
| There are plenty of unmaintained sites out there that do stupid
| things in reaction to UA strings, and one of the stupid things
| is using a regex that expects specific strings to exist.
|
| Using a completely new string format in the same field (or
| removing it entirely) breaks a lot of sites that'll never be
| fixed.
|
| Freezing it prevents this. And if we're freezing and creating a
| new system then why not go for something queryable without all
| the baggage?
| qwerty456127 wrote:
| How is something without all the baggage expected to help
| with the sites doing the stupid things?
| ajsnigrutin wrote:
| Users still want to see those pages. If browser X removes
| the UA string, that site brakes for them, and they change
| to browser Y that still has the old useragent.
| qwerty456127 wrote:
| But won't removing just the baggage parts of the UA
| ("like Gecko", "KHTML" etc) break those sites anyway?
| richthegeek wrote:
| The old UA will exist as it always has done - frozen,
| unchanged. Nothing will be removed from the literaly
| `user-agent` header value.
| GoblinSlayer wrote:
| Yep, they can receive those crazy UAs, see
| https://wiki.mozilla.org/Compatibility/Go_Faster_Addon
| userbinator wrote:
| I tried using _no_ UA header at all for a period of a few
| weeks, many years ago when "appsites" weren't as common, and
| yet a lot of sites failed to load mysteriously, showed odd
| server errors, or even banned my IP for being a bot.
|
| I expect no UA header to be even less usable now that sites
| are more paranoid and app-ified, so instead I use a random
| one. That still confuses some sites...
| Kaiyou wrote:
| A random one makes you unique and thus identifiable across
| sites.
| zzzcpan wrote:
| Random UA can get you outright blocked for looking like a
| bot. So is faking Googlebot and such.
| LeonM wrote:
| Good.
|
| The only legitimate use case I can think of is exception
| tracking, it is valuable to know which browser caused the
| exception.
|
| Beyond that, a website should never, ever rely on the UA for
| anything.
| qwerty456127 wrote:
| IMHO you're right but underestimate the value of what you have
| mentioned. It is VERY valuable to know which browser caused the
| exception.
| GoblinSlayer wrote:
| Hopefully people will think twice before doing stuff that
| depend on browser.
| jmcs wrote:
| Maybe after people stop using the user agent for stupid
| reasons it can be made useful again. User agents should be
| stuff like "Firefox 71.0" or "Chrome 79.0.3945", not "Mozilla
| but really AppleWebKit disguised as KHTML, but no really I'm
| Chrome but maybe I'm Safari"
| HorstG wrote:
| Yes, but unfortunately using the user agent for only non-
| stupid reasons is a postcondition for the hell freezing
| over.
| Tade0 wrote:
| Last time the UA string was useful to me was to show my SO's
| uncle that iOS Edge is just a "repackaged and watered down
| version of Safari".
| AgloeDreams wrote:
| In fairness, real (Trident) Edge fakes the Chrome UA. But
| yeah all iOS browsers are just WebKit.
| saagarjha wrote:
| My user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X
| 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko)
| Version/13.1 Safari/605.1.15". Clearly I'm running a
| repackaged Firefox browser?
| smitop wrote:
| It is still possible to determine what browser caused an
| exception. The "sec-ch-ua" header is used by Chrome (but only
| to HTTPS websites) to send the "real" user agent, which for me
| is "Google Chrome 79" (and I am indeed running Google Chrome
| 79).
| zzzcpan wrote:
| There are plenty of legitimate purposes. I use it to disable
| keepalive for POST requests, redirect to https:// for browsers
| known to be able to establish a secure connection, whitelist
| tor browser bundle, detect behavior of Accept: header, which
| differs even between browser versions, and some other things.
| thrower123 wrote:
| Realistically, we will just find another, more complicated and
| more opaque, and more error-prone, method of fingerprinting the
| browser version.
| ksec wrote:
| Google's _Good_ Intention were to support _privacy_ , and
|
| >the web should be is an _abundant source of compatibility
| issues. in particular for minority browsers, resulting in
| browsers lying about themselves (generally or to specific sites),
| and sites (including Google properties) being broken in some
| browsers for no good reason._
|
| Doesn't that mean every Web feature would be Google's way or the
| high way. Google, using Blink and Chrome would be dictating the
| web standards. And if it is incompatible, it would now officially
| be the browser vendors's fault and not the designer.
| trilliumbaker wrote:
| > Google's Good Intention were to support privacy
|
| I find this intent for be very difficult to believe. Chrome's
| privacy policy[0] already lists a ton of information that
| Chrome sends to Google.
|
| I am cynical and simply do not trust Google. I see this as a
| move for control rather than privacy.
|
| 0. https://www.google.com/chrome/privacy/
| smashah wrote:
| Is this going to make spoofing UA harder/redundant? If so it's
| bad news for a lot of projects.
| EGreg wrote:
| This is a terrible idea unless the better mechanism includes a
| way to determine at least basic things like whether this is a
| mobile browser! Determined web developers will still be able to
| detect the browser using Javascript and send the info to the
| server. And meanwhile, we won't be able to send resources
| optimized for eg mobile browsers vs desktop ones. Now we have to
| ship lots of crap from the server and hope JS is enabled to load
| the minimum. The whole deprecation movement has to stop breaking
| the web for activist reasons.
| zzo38computer wrote:
| The resource optimization is mostly needed only due to making
| stuff too complicated already. Simplify the document and then
| it should just as well either way.
| darrinm wrote:
| How will this affect caniuse.com? I use it every day.
| kerkeslager wrote:
| One problem with User-Agent strings is that they actually don't
| work for their intended use case. Nothing is stopping user agents
| from lying about who they are to the server, and many user agents
| actively do this.
|
| I've been on teams a few times that tried to use UA strings to
| try to serve up features per-browser. Trying to do this directly
| falls apart quickly. There are some libraries that handle the
| most common problems, but that really only delays the inevitable:
| eventually some critical user is using a browser that you are
| detecting wrong, and you end up lost in endless hard-coded edge
| cases. Using UA strings to determine functionality isn't an
| effective strategy.
| sergeykish wrote:
| How much of the web depends on User Agent header?
|
| Maybe it can be removed altogether with small whitelist of
| exceptions. Firefox about:config
| general.useragent.override, String, leave empty
|
| Looks fine so far
| close04 wrote:
| > It provides the required information only when the server
| requests it
|
| In the interest of fingerprinting a server would request this
| every time.
|
| > It provides the information in small increments, so servers are
| only exposed to the information they need and request
|
| Then the server would need and request the most comprehensive
| list possible in order to fingerprint someone with better
| granularity than a UA string could.
|
| I'm not against this as I appreciate the value of this kind on
| information for the developers. It would be done one way or
| another. But why is this billed as mainly a privacy move? Nothing
| suggests it intrinsically offers better privacy when facing a
| website configured to fingerprint you. It actually looks like it
| gives even more granular info over which the user has less
| control than they used to with the UA.
| anilshanbhag wrote:
| The trigger for this was most likely the Brave/Vivaldi browsers.
| Brave used to 'Brave/X.y' at the end of user agent. Whatsapp
| didn't work with that useragent. Now Brave uses Google Chrome's
| useragent.
|
| In my app Dictanote (https://dictanote.co) - which uses Chrome's
| speech-to-text API, I have no way to distinguish Brave/Vivaldi
| and user doesn't understand why its not working :/
| alehander42 wrote:
| so show this as a hint in the UI :) people can still solve
| problems better than machines often
| londons_explore wrote:
| I can imagine the popup now:
|
| "Somethings wrong! You might be using Chrome and having
| connectivity issues, or you might be using Brave who have a
| dispute with Google about usage of their speech recognition
| API. In the former case, get better WiFi, and in the latter
| case there's nothing you can do, switch browsers."
| RKearney wrote:
| Using user agents to detect features is the wrong way to do it
| because you'll have these exact problems.
|
| To determine if a browser has the text to speech API just check
| if the webkitSpeechRecognition object exists (if that's the one
| you're using). It will exist in Chrome and will not exist in
| other browsers that lack the feature.
| scarejunba wrote:
| > * It will exist in Chrome and will not exist in other
| browsers that lack the feature.*
|
| An incorrect assumption stated as fact with such great
| confidence. Good job.
|
| Even on the face of it, any engineer would know this can't be
| true.
| DarkCrusader2 wrote:
| Shouldn't you be using feature detection[1] here anyway? Making
| browsers unsupported in a blanket fashion via user-agent is the
| exact thing people should stop doing.
|
| [1] https://developers.google.com/web/updates/2014/01/Web-
| apps-t...
| anilshanbhag wrote:
| The webkitSpeechRecognition object shows up on both browsers.
| When you start recognition, it acts like you are not
| connected to the network. Not connected to the network is a
| common error , so you cannot fingerprint it to Brave.
|
| This specific API only works in Google Chrome unfortunately.
| So we need to stop people from trying in another browser and
| getting frustrated as to why its not working.
| exikyut wrote:
| IMO Brave should remove this API, then.
|
| - It's not likely to work anytime soon
|
| - "The property doesn't exist or throws an exception or
| does something else that Chrom{e,ium} doesn't do" provides
| the necessary fingerprinting
|
| - Adding the feature back later can just be chalked up to
| "growing pains", it doesn't really set especially unique
| precedent
| untog wrote:
| Absolutely they should. But they haven't. Checking the UA
| string allows a developer to get around the issue, but
| once it's gone an individual developer will be powerless
| to fix the issue for their users.
| ss3000 wrote:
| We should of course default to feature detection whenever
| possible, but non-standard behavior like this in certain
| browsers is exactly why feature detection alone is never
| going to cover 100% of current use cases for UA detection.
|
| To add to OP's point, this thing in Safari also comes to
| mind as an example of something that isn't easy to detect
| and address outside of UA detection:
| https://github.com/vitr/safari-cookie-in-iframe
|
| Deprecating UA Strings and moving towards UA Client Hints
| seems like a move in the right direction though.
| GoblinSlayer wrote:
| 3rd party cookies can be assumed to be always blocked, no
| need to detect anything.
| ss3000 wrote:
| Some pages are intended to be embedded in iframes (which
| have their own security context isolated from the
| embedding page), and happen to use cookies for
| authentication. Safari not allowing cookies from third
| party domains in iframes is the issue here.
|
| Assuming these iframes will never work means degrading
| the experience for all users, when only users on Safari
| are actually affected. Detecting the UA and branching
| based on that is a much more pragmatic solution.
| devit wrote:
| Just test whether the API works or whether the properties are
| missing or methods throw exceptions?
|
| The kind of testing you are complaining you can't do is exactly
| why user agent is broken, what if you test for Chrome and then
| Brave/Vivaldi start supporting the speech-to-text API and your
| broken website still says "sorry, you need Chrome" for no
| reason?
| anilshanbhag wrote:
| The webkitSpeechRecognition object shows up on both browsers.
| When you start recognition, it acts like you are not
| connected to the network. Not connected to the network is a
| common error , so you cannot fingerprint it to Brave.
| dbetteridge wrote:
| While the intent is good, didn't we recently see from the roll-
| out of secure/strict same-site cookies that feature detection
| isn't mature enough? Or does that not apply here.
|
| Getting rid of user agent strings is great, as long as we get a
| better way to determine browser capabilities that doesn't require
| some kind of special feature checking library...
| rowan_m wrote:
| For older browsers, the UA string remains - so that's still
| viable for compatibility issues. https://wicg.github.io/ua-
| client-hints/ will provide the cleaner, opt-in approach in the
| future.
| dbetteridge wrote:
| The hints do seem like a good approach, though scary from a
| fingerprinting side as they're much more fine-grained.
| rowan_m wrote:
| It changes the passive fingerprinting vector to an active
| one: https://github.com/bslassey/privacy-budget#passive-
| surfaces
|
| So, while UA hints could potentially supply more
| information than the current UA string - each item needs to
| be explicitly requested by the site meaning the browser can
| make a choice on what to return. This may depend on user's
| preferences, level of trust in a site, the amount of
| identifying information already provided to the site, etc.
| ori_b wrote:
| > _It changes the passive fingerprinting vector to an
| active one_
|
| You say this as though the ad industry cares.
|
| > _So, while UA hints could potentially supply more
| information than the current UA string - each item needs
| to be explicitly requested by the site meaning the
| browser can make a choice on what to return._
|
| Let me introduce you to useragent switchers.
|
| The replacement is strictly worse. Simply freezing the
| user agent solves things well.
| untog wrote:
| > You say this as though the ad industry cares.
|
| They don't have a choice? The point about passive vs
| active is that it places control with the browser/user
| where they didn't have it before. You'll be able to
| respond to some hints and ignore others.
|
| > Let me introduce you to useragent switchers.
|
| And what's the adoption rate of those, I wonder... less
| than 1% of users? This client hints standard will make it
| a lot more reasonable for non-power users to control what
| information is being disclosed, should they wish.
| ori_b wrote:
| > _They don 't have a choice? The point about passive vs
| active is that it places control with the browser/user
| where they didn't have it before. You'll be able to
| respond to some hints and ignore others._
|
| So, you are saying that every time someone wants to test
| browser compatibility, the browser will prompt the user?
|
| No, they're not doing that. Which means that the
| information is in the hands of anyone that cares. It just
| isn't in Apache server logs by default.
|
| > And what's the adoption rate of those, I wonder... less
| than 1% of users?
|
| About as high as the dynamic equivalent will be.
|
| Which is why not replacing the useragent string is the
| only option that makes things better.
| 1_player wrote:
| What's cleaner about this new approach? I can't see the point
| of it.
|
| It's exactly the same as the User-Agent header we had, but
| worse.
|
| UA was used for tracking? With this new standard, just ask
| the user agent to include all details in its Accept-CH
| header.
|
| UA was used for feature detection? People will use this new
| standard to do feature detection.
|
| And it's worse because there's legitimate uses of UA
| sniffing, and JS won't have access to it anymore - TFA wants
| to deprecate navigator.userAgent, so only the webserver would
| have access to user agent details? Why?
| rowan_m wrote:
| > With this new standard, just ask the user agent to
| include all details in its Accept-CH header.
|
| That becomes an explicit choice by the site to request more
| information, it's up to the client/browser how it responds
| to that. Fewer bits of information are exposed by default.
|
| > JS won't have access to it anymore - TFA wants to
| deprecate navigator.userAgent, so only the webserver would
| have access to user agent details? Why?
|
| I should have linked to the top-level repo with the
| explainer (https://github.com/WICG/ua-client-hints) as it's
| not immediately clear from the spec, but access to the hint
| values is provided via getUserAgent()
| pjc50 wrote:
| User-agent was never feature detection, only a proxy for it,
| and frequently resulted in preventing users from using things
| that the browser was capable of supporting.
|
| Why does edge say "Mozilla/5.0 (Windows NT 10.0; Win64; x64)
| AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102
| Safari/537.36 Edge/18.18362"? Because people kept abusing it
| for feature detection.
| josteink wrote:
| Ok. So how do we do OS detection then?
|
| How do I know which (binary) download to offer my users?
|
| Edit: How do I provide reasonable defaults when the user's OS
| actually matters?
| b99andla wrote:
| https://wicg.github.io/ua-client-hints/#examples
| zzzcpan wrote:
| Don't. That's an anti-pattern in UX. People download binaries
| for different OSes all the time, so list links for all OSes you
| support.
| josteink wrote:
| Giving people a reasonable default is bad UX?
|
| That's a load of horseshit if I've ever heard it.
| zzzcpan wrote:
| What reasonable default? You don't know where people want
| to install your binaries and you do want people to know
| what other OSes you support. In UX if the number of choices
| is very small, like those couple of OSes you support, it is
| always best to present them all.
| josteink wrote:
| Every major player provides the reasonable default when
| downloading binaries. Every single one. There's a reason
| for that.
|
| Regular users are not technical and if you ask them to
| make a choice based on technical matters (Windows, MAC,
| Linux, Apple AppStore, Android AppStore, Chrone WebStore,
| whatever), where you instead could have had -1 clear
| choice- already presented by default in a big nice
| button, you _will_ lose conversions or increase tech-
| support costs.
|
| The evidence for this is so overwhelming that knowingly
| trying to ignore that makes it look like you have an
| agenda or horse to grind.
| londons_explore wrote:
| A good chunk of users don't know what OS they're running.
|
| Perhaps you should propose a feature detection for it. It
| could look like the media source API for resolutions and
| formats for web video - except the same for binary
| formats for software.
| zzzcpan wrote:
| No, these are not UX metrics, these are commercial
| metrics. There is a reason conversions and tech-support
| costs and almost all a/b tests and all that are not even
| remotely good UX metrics, as they do not exist to measure
| anything users care about in the product, only what
| companies care about.
| josteink wrote:
| Okay.so let's hypothetically say I buy your argument that
| providing a reasonable default is bad UX.
|
| In what other places of application development should we
| also stop providing reasonable defaults and force the
| user to choose instead?
|
| - country? city?
|
| - localization?
|
| - number for local support hotline?
|
| - email of logged in user?
|
| - type of currency for payments?
|
| No? Then why is having a reasonable default for downloads
| bad?
| zzo38computer wrote:
| My "WebOptions" idea would permit the user to customize
| these and other settings (both globally and locally;
| there could be some set of "common" keys as well as
| supporting keys specific for the server), in a similar
| format to cookies, although the server and document
| scripts would not be allowed to set them, and the user
| only sets them explicitly. For email, there is a "From"
| header, so that can be used if it is available.
|
| But anyways, the service should not make it difficult to
| download if it detects a wrong computer; it should allow
| it always, and should not be so difficult by trying to
| hide it.
| abjKT26nO8 wrote:
| Websites presenting me with a big button to download a
| "reasonable" default and hiding everything else behind a
| small link that I have to go hunting gor is really
| annoying. There is nothing reasonable about it. Don't think
| that you know better what your users want then the users
| themselves.
| josteink wrote:
| Optimizing for the 99% use-case is fairly normal _and_
| reasonable.
|
| iOS users will almost always install apps via the
| AppStore. Most Windows-users are probably not interested
| in a DMG. Are you really going to argue against that?
|
| I agree that _taking away_ options based on OS-detection
| is a seriously nasty UX anti-pattern though.
| abjKT26nO8 wrote:
| _> iOS users will almost always install apps via the
| AppStore. Most Windows-users are probably not interested
| in a DMG. Are you really going to argue against that?_
|
| It may be true in the case of iOS and Android, because
| they are so locked down. However, on more powerful
| platforms that Windows, Mac and Linux are it isn't. I may
| want to run it in a VM, or not install it, but place it
| somewhere on a shared drive, or anything that a non-
| handicapped OS is capable of facilitating and many of
| these things will mean I will want a binary not meant to
| be run by my native OS. Sometimes it happens that one of
| my devices will break and so I want to use another one to
| download something that will help me fix the issue. But
| now I'm going to have to go full Sherlock Holmes on a
| website that thinks it knows better what I'm looking for.
| AgloeDreams wrote:
| In fairness, highlighting the right button for your OS
| and showing an 'other downloads' button is really a 'You'
| problem that probably only affects less than half of 1%
| of users. Almost all sites also show a 'other OS
| downloads' button. But this is all meaningless, as shown
| above, UA will be replaced by a client hint property.
| jamescun wrote:
| Feature detection isn't the only use case User Agent strings
| service, two I've seen frequently are:
|
| * Exception Tracking - The User Agent string is usually attached
| to exceptions to aid in reproduction.
|
| * Outdated Client Detection - Primarily in internal dashboards in
| BYOD environments, I've seen the server display an error when a
| known outdated/insecure browser connects.
| kalleboo wrote:
| When Safari froze their UA, another big one that came up was
| browser bugs. Specific versions of browsers on specific
| platforms have bugs, and you need to be able to tell your user
| to upgrade.
| clarry wrote:
| Please use the latest supported browser.
|
| There, I just told you to upgrade without sniffing UA.
| HorstG wrote:
| Also, "please upgrade, then call back" is always the first
| point on any support call checklist.
| tsegratis wrote:
| Possibly add a randomized date to new UA, in range from last
| fixed CVE, to browser compilation date
|
| That would avoid feature detection, but still create epochs to
| disallow insecure browsers
|
| --
|
| For exception tracking, the best I can suggest is getting
| screen size + other features; then storing them, ready to pass
| with the exception
| tsegratis wrote:
| I'd still like a way to feature detect, rather than make a round-
| trip to the browser. This would let me embed webasm rather than
| js+branch to begin a second download if feature found... etc
|
| I suggest UA string be a bitmask of features. Then feature
| detection should stop being broken
|
| Extra bits could be used for js-on/js-off, and is-bot/is-human
|
| --
|
| Ah I see they're kind of doing the bitmask, but keeping a round-
| trip, and making things complicated (though I realize latest http
| standards can probably remove those round-trips in the average
| case)
|
| I'd still suggest the bitmask for non-sensitive information, and
| have everything else simply js-tested as it currently is
|
| Maybe is-user-blind might be a nice bit too, since canvas based
| websites could switch to the dom, or whatever
| tsegratis wrote:
| Please could we also have a couple more privacy setting bits
| for i-accept-your-cookies and i-want-to-be-told-about-cookies-
| on-every-single-website-because-i-forget-what-they-are-and-
| really-want-to-click-through-to-your-privacy-settings
|
| If we have those bits, then the user can make a set of choices
| once, for every site, and we get rid of cookie pop-ups
|
| -- Websites could still ask if they want/need to do something
| that violates those choices
| zeven7 wrote:
| Or we can just assume like reasonable adults that websites
| are going to put cookies in your browser and promote privacy-
| oriented tech to users rather than trying to pretend that
| having every website ask for permission in order to enable
| basic functionality solves anything.
| [deleted]
| pjc50 wrote:
| > promote privacy-oriented tech to users
|
| Like what?
|
| > every website ask for permission in order to enable basic
| functionality
|
| I don't believe that purely functional cookies require GDPR
| permission - that's covered by "provide services to the
| user". It's the ones which are functionality to third
| parties _not_ the user which are the problem.
| zeven7 wrote:
| > I don't believe that purely functional cookies require
| GDPR permission - that's covered by "provide services to
| the user". It's the ones which are functionality to third
| parties not the user which are the problem.
|
| Ah, I didn't realize that. Well, that does sound much
| more reasonable.
| pjc50 wrote:
| Actually the ICO page itself presents a great example: if
| you go to https://ico.org.uk/for-organisations/guide-to-
| data-protectio... you get:
|
| > Necessary cookies
|
| > Necessary cookies enable core functionality such as
| security, network management, and accessibility. You may
| disable these by changing your browser settings, but this
| may affect how the website functions.
|
| > Analytics cookies [toggle On/Off]
|
| > We'd like to set Google Analytics cookies to help us to
| improve our website by collecting and reporting
| information on how you use it. The cookies collect
| information in a way that does not directly identify
| anyone. For more information on how these cookies work,
| please see our 'Cookies page'.
|
| The implication is that a consent dialog would not be
| required if they weren't using Google Analytics or any
| other third-party.
| jrockway wrote:
| That would be nice. I feel like the "cookie warnings"
| basically read as "this site doesn't actually need cookies to
| work, but we want to track you". We should just have some
| sort of "do not track" header that indicates we don't accept
| those terms, and then websites can badger us if they really
| need cookies, like for logins.
| toyg wrote:
| _> I feel like the "cookie warnings" basically read as
| "this site doesn't actually need cookies to work, but we
| want to track you"._
|
| I typically read those warnings as reminders that I should
| open the site in a FF container.
| mschuster91 wrote:
| > If we have those bits, then the user can make a set of
| choices once, for every site, and we get rid of cookie pop-
| ups
|
| That one was tried with the DNT bit - of course users ended
| up en masse setting it to "do not track" by default. Sites
| won't accept that.
| HorstG wrote:
| Sites need to be told to obey DNT with a legal
| sledgehammer. Still hoping...
| miohtama wrote:
| The proposed UA Client Hints is more privacy oriented way to
| get some diagnostics data and detection from browsers
|
| https://wicg.github.io/ua-client-hints/
| __s wrote:
| > This would let me embed webasm rather than js+branch to begin
| a second download if feature found... etc
|
| This is exactly what you aren't supposed to do
|
| Either send the wasm optimistically & fallback to js on error,
| or send it reactively with js+branch
| tsegratis wrote:
| Currently, yes, you are right. But what I'm suggesting is
| that current situation could be improved
|
| A http header bitmask set by javascript:testWASM(), would be
| equivalent to what you suggest...
|
| But avoid the js, and making a second trip to the server
| [deleted]
| sheerun wrote:
| Client Hints won't work with SSR because they are available only
| on second request... I hope they fix it before deprecating.
| JohnFen wrote:
| Removing the user agent string is something that I've wished for
| for decades. While we're at it, the browser should not be
| revealing anything else about it or our machines at all unless we
| consent to it.
| chrisweekly wrote:
| Must-read bit of webdev lore:
|
| https://webaim.org/blog/user-agent-string-history/
| jonarnes wrote:
| > The opt-in based mechanism of Client Hints currently suffers
| from the fact that on the very-first view, the browser have not
| yet received the opt-in. That means that requiring specific UA
| information (e.g. device model, platform) on the very-first
| navigation request may incur a delay. We are exploring options to
| enable the opt-in to happen further down the stack to avoid that
| delay.
|
| I'm surprised Google goes ahead with this without having a
| concrete plan to handle the first request to a page. I fear that
| will become an ugly mess of redirects, js hacks and broken pages.
| Think Google is under estimating how widespread device detection
| user User-Agent on the server side is...
| tracker1 wrote:
| I'm not sure I get the point of specifically requesting it...
| also, should have a DOM API to get this information spelled out,
| not sure where that is...
|
| Let alone requiring a round trip for the server to even see the
| information... does that mean a 302 to itself for initial data?
| What about a POST? The first render is where this kind of crap is
| most useful for server-side rendering.
|
| The fact is, in general, it would be nice to get the actual
| browser/version and os/version, and maybe have an engines list
| for cross-compatibility detection as a fallback.
|
| When you come across a bug that only effects a specific
| browser/version (or other browsers using that engine as a base),
| it's a pain to deal with... cleaning it up when fixed is another
| issue, or worse, when you target a specific version, then the
| next release doesn't fix the issue and you're scrambling to
| update your range for the fix.
|
| It isn't nearly as bad as the late 90's, but it's still pretty
| bad.
| dochtman wrote:
| Quite happy that the market leader is taking this step! Hopefully
| this will decrease the problems with lacking feature detection.
|
| I was surprised that the post doesn't contain any example user
| agent strings for a sample of how they are expected to look
| starting from the different milestones.
| zerotolerance wrote:
| I think the proposal is well-intentioned and shortsighted. Nobody
| ever plans for a junk drawer feature, but certain features are
| destined to be fragile fuzzy contracts regardless. Unless this
| proposal seeks to eliminate the differences between different
| user agents, it is proposing moving to a different but equivalent
| junk drawer. The change would create real pain for service
| providers and consumers alike and provide little benefit.
|
| From the implementation side, I would have preferred to see an
| OPTIONS request style solution similar to CORS to allow complying
| UAs to detect what if any UA information will be required.
| Izkata wrote:
| > I think the proposal is well-intentioned and shortsighted.
|
| Could also be evil and long-term: user agents won't matter
| anymore once everything is auto-updated Chrome, right?
| leeoniya wrote:
| https://wicg.github.io/ua-client-hints/
|
| the proposed implementation leaves me questioning how useful the
| CH headers are for initial impressions of a web property if only
| the browser and version are sent by default, and more info is
| only provided on follow-up requests, assuming the user agrees to
| some permission popup they don't understand. it'll be the "this
| site uses cookies" nonsense / nuisance all over again. it'll
| finally push end users to install the native reddit app without
| those constant annoyances.
|
| i have quite a few ux enhancements that need to know or
| guestimate the screen size, if the device is touch capable and OS
| (especially for form input styling). i dont see how it is
| possible without an additional delay, fetch request and some
| annoying permission popup to deliver a good experience in the
| brave new CH world.
| HorstG wrote:
| There is CSS media query for exactly your use-case. No need for
| sniffing, round-trips or any server-side activity at all.
| leeoniya wrote:
| a media query will not tell me what OS it is so i can infer
| the metrics of native fonts and form controls. i would have
| to use JS and create sentinel elements to make the
| measurements, which would still be a form of slower, shittier
| sniffing.
|
| also, a media query or any other client side method prevents
| me from delivering exactly the final content that's necessary
| and not have to do additional reflow-inducing js to get the
| end result.
| jchw wrote:
| 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.)
| kerkeslager wrote:
| > 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.
| pilif wrote:
| _> 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.
| shadowgovt wrote:
| 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.
| jchw wrote:
| 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.
| Zarel wrote:
| 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.
| JoshTriplett wrote:
| > 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.
| akersten wrote:
| > 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.
| robocat wrote:
| 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).
| shadowgovt wrote:
| > 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."
| Zarel wrote:
| 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!
| JoshTriplett wrote:
| > 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.
| Uehreka wrote:
| 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".
| jchw wrote:
| 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.)
| Zarel wrote:
| 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 [chi] instead of [chi] .
| phkahler wrote:
| >> 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.
| Zarel wrote:
| 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.
| mikewhy wrote:
| > 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.
| true_religion wrote:
| 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.
| bryanrasmussen wrote:
| 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.
| owenmarshall wrote:
| 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.
| cpeterso wrote:
| 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-...
| Lx1oG-AWb6h_ZG0 wrote:
| 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.
| StavrosK wrote:
| 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.
| jes5199 wrote:
| because adding that single header breaks the behavior on
| old browsers
| thayne wrote:
| 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.
| StavrosK wrote:
| I don't understand why you sometimes need to not send the
| header. What happens if you do, in those cases?
| yuliyp wrote:
| 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.
| StavrosK wrote:
| That seems like a pretty egregious bug, presumably
| there's a spec someone is in violation of?
| yuliyp wrote:
| 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 :-(
| bryanrasmussen wrote:
| 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.
| jackjeff wrote:
| 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.
| AdamTReineke wrote:
| +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.
| tbodt wrote:
| There's a proposed API for JavaScript to get the same
| information.
| AdamTReineke wrote:
| Oh, yup, I see that now. That was the next point after
| the headers one in the spec.
| kerkeslager wrote:
| 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...
| pornel wrote:
| 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.
| wvenable wrote:
| 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.
| dessant wrote:
| 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
| Lx1oG-AWb6h_ZG0 wrote:
| 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?
| microtherion wrote:
| For that to work, browsers would also have to accurately
| advertise their own bugs/quirks, which might be a
| difficult ask.
| ebiester wrote:
| Wouldn't those quirks be sufficient to fingerprint in the
| same way?
| microtherion wrote:
| What if the DOM looks perfectly normal, but doesn't
| render correctly?
| pixelbash wrote:
| 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).
| Kiro wrote:
| 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.
| wvenable wrote:
| 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.
| shakna wrote:
| Part of the proposed deprecation of the useragent is a JS
| API to expose the information.
| [deleted]
| Rebelgecko wrote:
| A JS API that tells you which bugs exist in the browser?
| shakna wrote:
| > 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.
| Jon_Lowtek wrote:
| > 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").
| shakna wrote:
| 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.
| pjmlp wrote:
| Great, now my server side rendering code needs to inject
| JS into the customer to feedback agent capabilities.
| shakna wrote:
| 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.
| Jon_Lowtek wrote:
| 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 :/
| shakna wrote:
| 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.
| Jon_Lowtek wrote:
| 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 ;-)
| Spivak wrote:
| 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.
| shakna wrote:
| > 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.
| kerkeslager wrote:
| 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.
| henryfjordan wrote:
| 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.
| jedberg wrote:
| > 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.
| pjmlp wrote:
| 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.
| danShumway wrote:
| Requires some complicated conversations about how client hints
| should work in a privacy-respecting way, but this is still
| unquestionably the right move.
|
| The arguments we're seeing are around what the replacement should
| be (or if there should be a replacement at all). But either of
| those scenarios are still better than keeping user agents as they
| are.
| arendtio wrote:
| As a KDE User, I am so happy every time I see 'KHTML' in one of
| those User-Agent strings, it would be horrible if Konquerors
| legacy would be removed one day ;-)
|
| So it is good they don't want to remove it, but just freeze it :D
| at_a_remove wrote:
| I have mixed feelings on this. On the other hand, I knew some
| people above me who are still stuck on useragent sniffing as the
| "way to go."
|
| On the other hand, I did use it in combination with other
| techniques to provide some real information. At one point I had a
| hard-to-even-track kind of problem, with difficulty even looking
| for common trends. I created a help form for the user. Please
| fill out when this occurred, where you were (this mattered), what
| OS were you running, what browser, and so forth. What I found
| using the UA (and backed by other tricks) was that many users,
| young users who were enrolled in college, were not only unaware
| of their browser or operating system version but the OS itself.
|
| Its utility began its decline when the browser makers began
| copying one another wholesale. It's kind of a shame. Capability-
| testing _is_ better but for some troubleshooting applications,
| having something particular to pin your problems to is handy.
| miohtama wrote:
| Please see UA Client Hints linked in the proposal
|
| https://wicg.github.io/ua-client-hints/
|
| You should still get this information, but more privacy
| oriented manner.
| earthboundkid wrote:
| I know no one RTFAs (I usually don't even RTFA), but in this
| case, it's really egregious. The whole discussion is going
| back and forth about UA sniffing with no one mentioning that
| the damn proposal is entirely based on adding UA Client Hints
| as a replacement. It makes this whole multi-hundred comment
| discussion pretty much valueless. Please, other commenters:
| read this link before discussing whether you're caremad about
| "like Gecko" in the UA string!
| mkl wrote:
| In this case, it seems like you didn't read the discussion
| either. Many people have been talking about UA Client Hints
| here, before you commented.
| saagarjha wrote:
| Safari tried to do this but had to walk back some of their
| changes: https://bugs.webkit.org/show_bug.cgi?id=180365.
| Currently, it reports the marketing OS and version of Safari
| truthfully, while lying about the bundled version of WebKit. For
| example, my user agent is "Mozilla/5.0 (Macintosh; Intel Mac OS X
| 10_15_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1
| Safari/605.1.15", but I am running Safari 13.1, WebKit
| 15609.1.13.4 on macOS Catalina 10.15.3.
| dangerface wrote:
| Safari is a broken mess, I have to detect and fix it more than
| any other browser, makes sense they would make it even more
| broken.
| Joker_vD wrote:
| Oh boy. Right now, I am implementing a workaround for
| websockets in Safari on iOS 13 -- apparently, they've somehow
| broken their already non-standard "x-webkit-deflate-frame"
| compression scheme and can't properly send fragmented
| messages anymore when it's enabled: they mess up the zlib
| stream at the start of the second fragment (or maybe at the
| end of the first fragment).
| realusername wrote:
| I agree with that, I don't know if it's a lack of manpower on
| Safari and Safari mobile or what but it's severely far behind
| the other browsers.
| londons_explore wrote:
| Being a monopoly on iPhones means the rest of the community
| has to work around their bugs. Why would they put any
| effort into fixing those bugs - web devs are working around
| them just fine?
|
| Safari could say "Sorry - <div> tags aren't working in the
| current release", and all big websites would switch to
| other html tags in a matter of weeks.
| AgloeDreams wrote:
| Well, Chrome was based on Webkit for a while and then they
| forked it and as a result stopped contributing to it. For
| Google, Chrome is a major product (as it forces their
| Search engine and products). For Apple, Safari is pretty
| minor. Apple simply doesn't have a reason to throw so much
| manpower at it.
| dmitriid wrote:
| Chrome published a draft of User-Agent Client Hints only a
| month ago. They are already moving ahead to deprecate user
| Agent string and saying "Where feature detection fails
| developers, UA Client Hints are the right path forward" (a
| thing that's not even a standard yet).
|
| Safari has been very wary of this break-neck speed of how
| Chrome imposes Google's view of standards onto the world.
| WebKit team has even walked away from proposals when
| concerns were not addressed (sadly, I can't find the link
| in GitHub issues right now. Edit: [1]).
|
| And yes, lack of manpower is another pressing concern.
|
| [1] https://github.com/WICG/construct-
| stylesheets/issues/45#issu...
|
| "Now I consider this issue as an absolute show stopper. I
| don't think we want to ever implement this feature in
| WebKit unless this issue is resolved."
| ksec wrote:
| And that is what I like about Safari, instead of blindly
| following every single proposal from Google. Many of them
| are not really well thought out.
| dijit wrote:
| Google recently introduced a new "secure" login page which forces
| my chromium based browser (qutebrowser) to fake a Mozilla firefox
| user agent in order to work.
|
| As such, I think if detection comes in some other form, it might
| be harder to trick some sites into working properly.
| magicalist wrote:
| > _Google recently introduced a new "secure" login page which
| forces my chromium based browser (qutebrowser)_
|
| That's an _embedded_ chromium browser and according to [1] you
| should really be switching to oauth for login, not faking a UA
| string.
|
| [1] https://security.googleblog.com/2019/04/better-protection-
| ag...
| The-Compiler wrote:
| It isn't - in that blogpost, Google describes:
|
| "However, one form of phishing, known as "man in the middle"
| (MITM), is hard to detect when an embedded browser framework
| (e.g., Chromium Embedded Framework - CEF) or another
| automation platform is being used for authentication. MITM
| intercepts the communications between a user and Google in
| real-time to gather the user's credentials (including the
| second factor in some cases) and sign in."
|
| In other words, the OAuth sign in is intended for
| applications which want to access the Google APIs in some
| way.
|
| qutebrowser (as an application) doesn't need access to your
| Google Account in any way. It doesn't care about your Google
| authentication data, and it doesn't use Google APIs.
| zzzcpan wrote:
| Despite all the PR about "privacy", they don't seem to intend
| to prevent detection at all and are introducing even more
| surface for detection with client hints. Basically the opposite
| of what the title implies.
| rowan_m wrote:
| Client Hints (https://wicg.github.io/ua-client-hints/) move a
| passive fingerprinting vector to an active one, i.e.
| information must be explicitly requested by the site and then
| the browser can choose how to respond.
|
| The default level of information exposed drops to just the
| browser name and major version, which is only sent to sites
| on HTTPS and with JavaScript enabled.
|
| Additional hints are only sent on subsequent requests by the
| browser if the site sends the matching header in its initial
| response and the browser chooses to send a value. The current
| set of proposed hints define the same amount of information
| exposed Chrome's User-Agent string.
| zzzcpan wrote:
| That's not an active fingerprinting vector, especially
| within the context of https, still passive one with a minor
| protocol detail.
| HorstG wrote:
| Yes, but the fear remains that all sites will just always
| request everything from ua-client-hints. It is also totally
| unclear how browsers will handle this. I think making this
| permissioned will just add to the PrivacyNagOverload. Also,
| browsers will continue to lie in the hints because sites
| will always make broken assumptions or even try to do
| mischief with the info.
|
| I think the only winning move is not to play: Freeze the
| User-Agent and do not provide a replacement. Or at the very
| least, make the replacement based on actual feature bits,
| not version numbers and device models.
| rowan_m wrote:
| This is part of what the Privacy Budget
| (https://github.com/bslassey/privacy-budget) proposal
| aims to tackle. Freezing the User-Agent string reduces
| the amount of information exposed by default. UA Client
| Hints means the site has to explicitly request the
| additional information. The browser makes a choice about
| how to allocate / enforce budget. You're right though
| about how that works and how it would be exposed to the
| user in their browser still being open questions! More
| permission pop-ups certainly aren't the answer.
| HorstG wrote:
| That would still cause pages to do evil things if users
| set their privacy budget to "0/paranoid" or anything
| below "11/just gimme all".
|
| Just as with adblockers users will be nagged about
| "please turn that dial to 11". On average nothing will
| improve except for users who are able enough to get
| around those shenanigans even now.
| danShumway wrote:
| I think there's a fundamental principle/security in
| privacy that we don't really understand broadly enough
| across the industry -- that if you allow someone to know
| whether or not you're hiding/disabling something, they
| can often just force you to change the setting.
|
| Just as one example, active-permissions that can be
| revoked after being granted aren't perfect, but are a big
| step up over manifests, because they're more work to
| exploit and often allow users to retroactively change
| permissions after an app checks if they're allowed.
|
| Not to pick on the Privacy Budget specifically, but I
| worry that proposals like this don't really _get_ that
| larger principle yet -- that it 's still something we
| haven't quite internalized in the privacy community. If a
| site exceeds the privacy budget, it shouldn't get told.
| It should just get misinformation.
|
| It's like autoplay permissions. Autoplay permissions on
| web audio are awful, because you can just keep trying
| things until you get around the restriction. What would
| be better is to auto-mute the tab, because that would be
| completely invisible to code running on the page.
| HorstG wrote:
| Agreed, for things like autoplay. But dual-use features
| like feature detection that also enables fingerprinting
| cannot be replaced by randomized misinformation because
| that would really randomly break legitimate stuff.
|
| The only privacy-conscious way would be no feature-
| detection at all or a very coarse-grained approach like
| "I support HTML2021".
| danShumway wrote:
| Sort of.
|
| You can't lie that you do support something, but you can
| lie in the opposite direction. And for sites that
| legitimately need that feature to function, you don't get
| much benefit -- if a site genuinely needs Chrome's Native
| File access, saying that you don't have it just means the
| site won't work.
|
| But there's a grey area past that, which is that sites
| that don't need a feature, but are just using it to
| fingerprint, can have that feature broken without
| repercussion. If a news site requests Native File Access,
| and I say "I don't support that", then whatever.
|
| This puts engineers in an interesting position. You can't
| just break your site whenever the full range of features
| that every browser supports aren't available, because:
|
| A) You want to support a wide range of browsers, and if
| your news site doesn't work with multiple browsers you're
| just losing potential market.
|
| B) A fingerprinting metric that just rejects every
| browser that doesn't support _everything_ is not an
| effective fingerprinter. At that point, we basically have
| the corse-grained approach you 're talking about.
|
| The problem with this approach is that when a site
| requests capabilities, you need some way to figure out
| whether or not they're actually required, and whether or
| not you can lie about them. Permission prompts are...
| well, there are probably UXs that work, but most of them
| are also probably too annoying to use. In practice, I
| suspect that manually tagging sites is not an
| insurmountable task -- adblockers already kind of do this
| today.
|
| One thing to push for with Client Hints is that it
| really, really needs to be an API that's interceptable
| and controllable by web extensions.
|
| The same thing is true of fonts today -- if you lie and
| say you already have a font that you don't,
| congratulations, your text rendering is broken. But you
| can still lie about _not_ having fonts, and you can still
| standardize your installed fonts to a smaller subset to
| make your browser less unique.
| ori_b wrote:
| > _Client Hints (https://wicg.github.io/ua-client-hints/)
| move a passive fingerprinting vector to an active one, i.e.
| information must be explicitly requested by the site and
| then the browser can choose how to respond._
|
| And how much of a hurdle is that, exactly?
| dangerface wrote:
| This is a backwards step, I get the user agent is revealing
| things it has no right to like os, but not all browsers are made
| equal I need to know what its capable of.
| AgloeDreams wrote:
| They are adding a property for this. A browser will expose a
| bunch of 'I Support this' flags and client hints rather than a
| browser version.
| shortercode wrote:
| This seems particularly unhelpful for bug reporting systems.
| Being able to see a specific bug is only happening on Chromium 78
| for Linux can save a lot of time and frustration. In theory the
| user can fill in the details on a bug report themselves, but it's
| hard enough to persuade them to copy paste the crash message we
| generate for them at the moment.
| penagwin wrote:
| There should be better ways to identify the browser than the
| user agent. The user agent is a legacy artifact, have you seen
| how many "compatibility" parts are in there? Like why does the
| chrome user agent say "Mozilla" in iy?
| samastur wrote:
| Yes, but do you know any?
|
| UA is the only thing I get in server logs to discover how
| much attention I should pay to support particular browsers.
| penagwin wrote:
| There's not really a good server side way to do it
| unfortunately. All the current alternatives to my knowledge
| require js.
|
| It depends on your application but the only real
| alternative is to use a js analytics library to collect the
| statistics. The good news is that they're more accurate,
| can give you more information, and there's plenty of self
| hosted options like Matomo.
|
| But it is yet another thing the client as to load, and
| adblockers will likely skew your metrics.
| miohtama wrote:
| User agent strings will be deprecated in favour of UA
| Client Hints, as mentioned in the proposal
|
| https://wicg.github.io/ua-client-hints/
| devit wrote:
| How about doing this but also NOT providing the client hints API
| and NOT providing any way for JavaScript to explicitly ask for OS
| and browser product name and version?
|
| While browser and JavaScript engines are likely to continue being
| detectable due to behavior and performance for the foreseeable
| future, it's probably possible to make the OS, browser frontend
| and exact engine version undetectable.
| tracker1 wrote:
| How do you propose, without some sort of browser and os
| detection and version to address specific bugs for those
| environments? Just leave a site/app broken for a few months
| until/if/when the browser fixes the bug?
| marcusarmstrong wrote:
| Browser vendor/version is hugely important information for
| triaging issues and implementing progressive enhancement
| approaches on large scale websites.
| tyingq wrote:
| Perhaps, but it invalidates most of their stated reasons for
| doing this. Which makes the post a confusing read.
| marcusarmstrong wrote:
| IMO it's explained better in the Client Hints
| specification.
| HorstG wrote:
| Client hints are not any more useful than traditional UA
| for privacy or progressive enhancement. Its the same
| content, just split up. Any browser not sending
| everything will have atrocious permission UX, nagging
| websites or just get the broken IE5 version.
|
| UA hints solve nothing, even after reading the spec
| magicalist wrote:
| > _it invalidates most of their stated reasons_
|
| The "main advantages" section for client hints all seem to
| apply there.
| [deleted]
| minitech wrote:
| Triaging issues, sure. Progressive enhancement? If you're
| parsing User-Agent to implement that, you're doing it wrong.
| (Feature detection is the correct approach, when necessary.)
| marcusarmstrong wrote:
| Can't feature detect during SSR, so making an educated
| guess and falling back gracefully (when possible--many
| times it just isn't, as with ES6 syntax) is important to
| get initial page load right by default.
| [deleted]
| zamadatix wrote:
| Because so many people abused the user agent header for
| things that could gracefully fall back (or they just made
| invalid assumptions from it) it was made an unreliable
| indicator for times you actually want to send shimmed
| content on first load.
| nicoburns wrote:
| There are cases like IndexedDB bugs in certain versions of
| Safari that are very hard to feature detect...
| grose wrote:
| Here's an official Google page telling you to sniff UAs or
| their new feature will break everything:
| https://www.chromium.org/updates/same-site/incompatible-
| clie...
|
| Edit: OK, this isn't progressive enhancement. But it's
| still a major problem you have to sniff the User-Agent for.
| I don't want to sniff UAs either but when Chrome is wont to
| change how fundamental parts of the web work like cookies
| it's sometimes necessary. I know UA hints will still allow
| you to do this, but requiring a second request is going to
| make things like redirect pages difficult to implement.
| minitech wrote:
| SameSite=None isn't progressive enhancement.
| grose wrote:
| You're right, I should have replied elsewhere. By the
| way, if anyone knows what this _is_ called I would be
| interested to know. As far as I can see it's basically
| feature detection with no other way of detecting it
| besides the UA.
| [deleted]
| pteraspidomorph wrote:
| Seems to be the Firefox plan according to the text.
| toast0 wrote:
| I may be cynical, but the Accept-CH proposal seems to me like
| something proposed for appearances only, not with any intent to
| actually implement.
|
| It just doesn't make sense from the perspective of HTTP. The only
| existing flow where an HTTP server passes context to the client
| and the client makes a new request based on that is HTTP
| authentication; but that's not intended to be optional ---
| generally servers don't provide good enough content with HTTP 401
| and expect clients to display it in case they don't feel like
| authenticating. In this proposed flow, the server would need to,
| at least, start sending the content on the original request, and
| then send it again in case the client actually sends a new
| request.
|
| If this is an HTTPS only feature, the server to client request
| could be moved up into the TLS handshake; the client could
| include an empty Accept-CH extension, and if present, the server
| could include an Accept-CH extension with the fields it wants in
| HTTP requests. Then the client would send the fields, or not,
| according to user preference. Zero added round trips.
|
| Otherwise, it might be better if the server were able to indicate
| to clients what its matching rules were. If the initial response
| returns best case data, and a list of exception rules, the client
| could send a second request only if the rules matched. Then you
| could say if it's a specific build of Chrome where important
| feature is present but broken[1], or Chrome version before X, or
| Chrome on mobile if ARMv5 or whatever, please disregard the
| content and refetch with more details provided to the server, so
| it could provide an appropriate page.
|
| [1] Let's say that particular version crashes when the feature is
| attempted to be used; it's plausible, and not really detectable
| from Javascript.
| peterwwillis wrote:
| It's going to be fun to watch all the product teams for all the
| web products stop all their active development so they can push
| through emergency fixes when this breaks their products. Just
| like Chrome 80's breaking of an established cookie use pattern is
| doing.
___________________________________________________________________
(page generated 2020-01-14 23:00 UTC)