[rowan_m]

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.

[HorstG]

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]

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]

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]

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]

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]

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]

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

[zzzcpan]

That's not an active fingerprinting vector, especially within the context of https, still passive one with a minor protocol detail.