Hacker News new | past | comments | ask | show | jobs | submit login

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...




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.


You're not wrong, but there are still various functionalities that are not easily feature detected in browser especially in older versions and sometimes you need to err on the side of caution and tell the user their browser is unsupported (even if it may work)

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.


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?


> 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()


The hints do seem like a good approach, though scary from a fingerprinting side as they're much more fine-grained.


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.


> 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.


> 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.


> 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.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: