rowan_m

This is a staged rollout with Chrome 80 as announced, so any current plans you're making for this change should stay as is. If you're looking to know if your specific browser instance is enforcing the new behaviour you can check https://samesite-sandbox.glitch.me

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.

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

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.

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.

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.

Correct, in that I think of a "Site" as an entity defined a layer above the "Domain". However the "Domain" attribute and the "SameSite" attribute control different behaviour.

"SameSite" affects sending the cookie in situations where top-level site in the browser context is different from the target site of the request where the browser is determining if it should send cookies. e.g. on example.site with an iframe to widget.site

"Domain" determine the the highest level domain to which cookies should be sent, regardless of the browsing context. e.g. on example.site an iframe on widgets.example.site or top-level navigation to accounts.example.site

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Se... details: > * If omitted, defaults to the host of the current document URL, not including subdomains. > * If a domain is specified, subdomains are always included.

Users often get apps installed for them by the store at purchase. So, while they may have 3p apps installed it's not necessarily a good signal they will install more.