Google and CMA reached an agreement on 4th February 2022 concerning Privacy
Sandbox and Topics. The agreement requires Google to train staff in Annex 3
<https://assets.publishing.service.gov.uk/media/62052c6a8fa8f510a204374a/100222_Appendix_1A_Google_s_final_commitments.pdf>,
and paragraph 4.119
<https://assets.publishing.service.gov.uk/media/62052c52e90e077f7881c975/Google_Sandbox_.pdf>
states, *“Google has committed to instruct its staff and agents not to make
claims to other market players that contradict the commitments, and to
provide training to its relevant staff and agents to ensure that they are
aware of the requirements of the Final Commitments”*.
Paragraph 21 of the agreement states *“During the standstill period, the
CMA may notify Google that competition law concerns remain such that the
Purpose of the Commitments will not be achieved. Google will work with the
CMA without delay to seek to resolve concerns raised and address comments
made by the CMA with a view to achieving the Purpose of the Commitments.
Google will inform the CMA of how it has responded to those comments”*.
The standstill period is defined in the agreement as is User-Agent
reduction.
Will Google representatives confirm they have approval from the CMA to
progress this proposal? If not then please can they confirm that the
proposal is now delayed until such approval is provided?
On Tuesday, 14 January 2020 at 11:22:00 UTC yo...@yoav.ws wrote:
> Contact emails
>
> yoav...@chromium.org, aaro...@chromium.org
>
> Summary
>
> We want to freeze and unify (but not remove) the User Agent string in
> HTTP requests as well as in `navigator.userAgent`
>
> Motivation
>
> The User-Agent string is an abundant source of passive fingerprinting
> information about our users. It contains many details about the user’s
> browser and device as well as many lies ("Mozilla/5.0", anyone?) that were
> or are needed for compatibility purposes, as servers grew reliant on bad
> User Agent sniffing.
>
> On top of those privacy issues, User-Agent sniffing is an abundant source
> of compatibility issues, in particular for minority browsers, resulting in
> browsers lying about themselves (generally
> <https://www.zdnet.com/article/vivaldi-to-change-user-agent-string-to-chrome-due-to-unfair-blocking/>
>
> or to specific sites
> <https://github.com/mozilla/webcompat-addon/blob/master/src/injections/js/bug1472075-bankofamerica.com-ua-change.js>),
>
> and sites (including Google properties) being broken
> <https://www.onmsft.com/news/google-has-apparently-blocked-its-stadia-cloud-gaming-service-on-the-chromium-based-microsoft-edge>
>
> in some browsers for no good reason.
>
> The above abuse makes it desirable to freeze the UA string and replace it
> with a better mechanism. There have been past attempts at UA string
> freezing from the Safari team, but without an alternative way to perform UA
> based content-negotiation, they had to be partially reverted.
>
>
>
> The User Agent Client Hints <https://wicg.github.io/ua-client-hints/>
> (UA-CH) feature provides an alternate source for the information the
> User-Agent string provides, both in its request header form as well as its
> JS API one.
>
> Its main advantages are:
>
> -
>
> It provides the required information only when the server requests it,
> over secure connections, making any fingerprinting that relies on it be
> active
> fingerprinting, which enables such use to be audited, as well as
> acted-upon by the browser (e.g. in a future implementation of the Privacy
> Budget <https://github.com/bslassey/privacy-budget>).
> -
>
> It provides the information in small increments, so servers are only
> exposed to the information they need and request, rather than being
> exposed
> to the full gamut of the UA string even if they are just trying to figure
> out one detail about the browser. (e.g. brand and major version)
> -
>
> Since it provides the information via dedicated fields, it enables
> better ergonomics and makes it less likely for servers to get it wrong and
> cause compatibility issues.
> -
>
> And finally, starting fresh will enable us to drop a lot of the legacy
> baggage that the UA string carries (“Mozilla/5.0”, “like Gecko”, “like
> KHTML”, etc) going forward.
>
>
> Once UA-CH ships
> <https://groups.google.com/a/chromium.org/d/msg/blink-dev/A4wxFpvqUfA/g7iccl9ICgAJ>
>
> as an alternative means for browser-specific content adaptation, we would
> like to freeze the User-Agent string.
>
> We propose to deprecate at M81 (starting to emit console warnings in pages
> that read that string in JS), freeze its version information at M83, and
> unify strings of different devices at M85. See detailed freezing plan
> below.
>
> This timeline provides 3 months for developers to move to the new
> mechanism for their future browser and OS version needs, and 6 months for
> more sophisticated OS or device specific targeting.
>
> Freezing plan
>
> Different parts of the UA string have different compatibility
> implications.
>
> Some parts of it, such as the browser version and the OS version, can be
> frozen without any backwards compatibility implications. Values that worked
> in the past will continue to work in the future.
>
> Other parts, such as the model (for mobile devices) and the OS platform,
> can have implications on sites that tailor their UI to the underlying OS or
> that target a very specific model in their layout. Such sites will need to
> migrate to use UA-CH.
>
>
> As such we are planning to freeze the parts that are amenable to freezing
> fairly early, and gradually unify the rest.
>
>
> Milestone
>
> Stable date
>
> Action
>
> M81
>
> Mid March ‘20
>
> Deprecate access to `navigator.userAgent`
>
> M83
>
> Early June ‘20
>
> Freeze browser version and unify OS versions
>
> M85
>
> Mid September ‘20
>
> Unify desktop OS string as a common value for desktop browsers.
>
> Unify mobile OS/device strings as a similarly common value for those at
> M85 (*)
>
>
> (*) For the mobile value, we may split it further based on common device
> dimensions, as a one-time exercise, to reduce the compatibility risk of
> unification.
>
>
>
> Interoperability and Compatibility Risk
>
> The compatibility risk varies at different stages.
>
> For the freezing planned for M83, the compatibility risk is low. Existing
> UA sniffing code will continue to work as expected. It is only future UA
> sniffing code that will need to change and use the UA client hints instead.
>
> For the unification planned for M85, the compatibility risk is medium.
> Some sites can modify their responses based on the OS and device model, and
> those sites will have to change their UA sniffing code to use UA-CH. We
> expect such sites to be well maintained (otherwise, how can they keep up
> with OS UI and device model changes?). Therefore, having 4 releases to
> modify their code seems sufficient.
>
> In the long term, we expect this change to improve compatibility, as UA
> sniffing based on UA-CH is bound to be more reliable than the current
> status quo.
>
> As for interoperability, we have other vendors on board with UA freezing,
> but not necessarily with the UA Client Hints mechanism, that is supposed to
> replace it. That can create a tricky situation, where developers would need
> to rely on the User-Agent string for some browsers and on UA-CH for others.
>
> Edge: Public support
> <https://twitter.com/_scottlow/status/1206831008261132289>
>
> Firefox: Public support
> <https://github.com/mozilla/standards-positions/issues/202#issuecomment-558294095>
>
> for freezing the UA string - “freezing the User Agent string without any
> client hints—seems worth-prototyping”
>
> Safari: Shipped to some extent. Safari has attempted to completely freeze
> <https://twitter.com/rmondello/status/943545865204989953> the UA string
> in the past, without providing an alternative mechanism. That got a lot of
> pushback, which resulted in somewhat reverting that decision. Nowadays,
> their UA string seems frozen, other than updates to the OS version and the
> browser major version.
>
>
> Alternative implementation suggestion for web developers
>
> For many (most?) uses of UA sniffing today, a better tool for the job
> would be to use feature detection. Where feature detection fails
> developers, UA Client Hints <https://wicg.github.io/ua-client-hints/> are
> the right path forward.
>
> Potential deployment hurdles compared to status quo:
>
> -
>
> Third party services that rely on the UA string would need to convince
> the sites that include them to delegate that information to them using
> Feature Policy.
> -
>
> The opt-in based mechanism of Client Hints currently suffers from the
> fact that on the very-first view, the browser have not yet received the
> opt-in. That means that requiring specific UA information (e.g. device
> model, platform) on the very-first navigation request may incur a delay.
> We
> are exploring options to enable the opt-in to happen further down the
> stack
> to avoid that delay.
>
>
> Usage information from UseCounter
> <https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/page/UseCounter.h&sq=package:chromium&type=cs&q=file:UseCounter.h%20Feature&l=39>
>
> If we were going to remove the User-Agent string outright, the answer to
> that would’ve been “a lot!!!!111”.
>
> Given that we are planning to freeze it, we expect the “removal” to be
> mostly backwards compatible, barring cases of specific OS or device
> adaptation.
>
> Client-side UA sniffing use counters
> <https://www.chromestatus.com/metrics/feature/timeline/popularity/2663>
> show it’s being used by ~90% of sites. But again, since we’re talking about
> freezing, it should not break most uses.
>
> Entry on the feature dashboard <https://www.chromestatus.com/>
>
> https://www.chromestatus.com/feature/5704553745874944
>
>
--
You received this message because you are subscribed to the Google Groups
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6e72d610-9978-4d7a-862a-5830edbf6b81n%40chromium.org.
