Re: [w3ctag/design-reviews] Partial freezing of the User-Agent string (#467)

> As @jyasskin pointed out, the examples there should clarify what we had in mind on that front
> 
> As for the Zamzung Zinternet case, I'd expect it to send out a set that looks something like `Sec-CH-UA: "Chrome"; v="70", "Chromium"; v="70", "Zamzung Zinternet"; v="10"`.
> That would enable sites that haven't bothered testing on it to consider it the same as they consider other Chromium browsers, enable sites that want to target it specifically, and will enable analytics (that are aware of it) to understand what specific browsers those users are coming from.
> 
> Does that help alleviate your concerns?
>
> Also, note that there's a discussion on maybe putting more emphasis on the engine vs. the UA brand: [WICG/ua-client-hints#52](https://github.com/WICG/ua-client-hints/issues/52)
> 
> To me, the Zamzung Zinternet case sounds like a good example in which we should prefer the current spec, over switching over to sending only the engine by default.

I think this will just lead to the point where all browsers will ship with `Sec-CH-UA: "Chrome"; v="70", "Chromium"; v="70"` in the set, including other browser vendors like Gecko, due to poor industry practices. This may become meaningless like `Mozilla/5.0` is in the current UA string... So honestly, no, it does not address this concern to me at all.

> An equivalent API will enable access to that information on the client. Access to low-entropy information will be synchronous, while access to high-entropy one will be through a Promise. (to enable browsers to take their time when considering if the site should really be granted to potentially fingerprintable info)

Can all of these "low-entropy" APIs be async ? It provides more flexibility for browser vendors (not just for privacy, but also for implementation) and doesn't necessarily add much effort for websites.

> By default, the browser will send Sec-CH-UA and Sec-CH-UA-Mobile headers to enable most cases of content negotiation. As those headers are low-entropy, we can afford that trade-off, privacy-wise. 

I also don't see a compelling reason to send those out by default, can't those be opt-in like all the others ? Websites receive less information by default, but can still opt-in into it, and it doesn't necessarily have to detriment the user experience as browser vendors may decide to grant that permission without asking the user.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/467#issuecomment-582254273