Hacker News Reader

Comment by untog | Hacker News Reader

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

View on HN

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?

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.

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

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.

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

Reply on news.ycombinator.com