Hacker News Reader

Comment by vxNsr | Hacker News Reader

> https://github.com/WICG/ua-client-hints

I don't really understand how this will result in any real difference in privacy or homogeneity of the web. Realistically every browser that implements this is gonna offer up all the info the server asks for because asking the user each time is terrible UX.

Additionally this will allow google to further segment out any browser that doesn't implement this because they'll ask for it, get `null` back and respond with sorry we don't support your browser, only now you can't just change your UAS and keep going, now you actually need to change your browser.

And if other browsers do decide to implement it, they'll just lie and claim to be chrome to make sure sites give the best exp... so we're back to where we started.

View on HN

> I don't really understand how this will result in any real difference in privacy or homogeneity of the web.

It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies.

In any case I'm not sure privacy is the ultimate goal here: it's intended to replace the awful user agent sniffing people currently have to do with a sensible system where you query for what you actually want, rather than infer it from what's available.

The problem is that without User Agent sniffing in some circumstances there is no other way of working round a browser bug e.g. There are cases where browsers will report that it supports such feature using one of the feature checks but the implementation is garbage. The only way is to have a work around based on user-agent sniffing.

Sure a lot of developers abuse the feature but I fear this might create another set of problems.

The other way is not using that feature until all browsers you care about implement it correctly.

It is rarely an options. Additionally defects are introduced into features that have been supported for quite a while.

That’s not a pragmatic solution.

That requires running Javascript instead of having a server-side call.

> It does a little: sites don't passively receive this information all the time, instead they have to actively ask for it. And browsers can say no, much like they can with blocking third party cookies.

Lets run through that scenario:

sites that don't need this info still aren't gonna ask for it or use it. sites that want it will get it this way and even if you respond with "no" that's useful to them as well for fingerprinting and as a way to fragment features to chrome only. So, what's changed?

> sites that want it will get it this way and even if you respond with "no" that's useful to them as well for fingerprinting

To an extent, sure. But to follow the model of third party cookies, let's say client hints are used extensively instead of user agent and all cross-domain iframes are blocked from client hint sniffing. All the third party iframe is going to be able to detect is whether user has a client hint capable browser or not. That's a big difference from the whole user agent they get today.

The idea is that this won't be a Chrome-specific API. It's been submitted to standards bodies, but Chrome is the first to implement. For example, Firefox have said they "look forward to learning from other vendors who implement the "GREASE-like UA Strings" proposal and its effects on site compatibility"[1] so they're not dismissing the idea, they're just saying "you first".

https://mozilla.github.io/standards-positions/#ua-client-hin...

You could also not give the useragent to the iframes.

Who knows how many sites that would mess up, though. Backwards compatibility is both the web’s greatest strength and biggest pain point.

Switching it from passive to active means you can count it towards https://github.com/bslassey/privacy-budget . Yes, sites can ask for all sorts of things, but if they ask for enough that they could plausibly be fingerprinting you then they start seeing their requests denied.

(Disclosure: I work at Google, speaking only for myself)

Is the "privacy budget" an actual feature of chrome or just an idea? I've never heard of it until now.

It's a proposal for how to prevent fingerprinting: https://blog.chromium.org/2019/08/potential-uses-for-privacy...

It prevents others fingerprinting, not Google though. Isn't there that x-Client-Data header than chrome only sends to Google domains?

The X-Client-Data header is documented in https://www.google.com/chrome/privacy/whitepaper.html#variat... and Chrome uses it to run experiments to make the browser better. It's not used for fingerprinting.

(Still speaking only for myself)

So why not still send limitied information by default in the User-Agent header, and if they ask for it, send more information in User-Agent header? (keep everything in one spot?)

Why are we creating redundant headers?

If it's well designed, then the system will only be able to query for feature support rather than ask what browser is in use.

I have a feeling Google won't do it that way, because they intentionally gimp most of their apps on non-Google browsers for no reason other than to be dicks.

Reply on news.ycombinator.com