Intent to Ship: Client Hints infrastructure and UA Client Hints

3,572 views
Skip to first unread message

Yoav Weiss

unread,
Jan 14, 2020, 5:33:35 AM1/14/20
to blink-dev, aaro...@chromium.org, Yoav Weiss

Contact emails

yoav...@chromium.org, aaro...@chromium.org


Explainer

https://github.com/WICG/client-hints-infrastructure#readme

https://github.com/WICG/ua-client-hints#explainer-reducing-user-agent-granularity


Specs

https://wicg.github.io/client-hints-infrastructure

https://wicg.github.io/ua-client-hints/

https://httpwg.org/http-extensions/draft-ietf-httpbis-client-hints.html


TAG review

https://github.com/w3ctag/design-reviews/issues/320


Summary

The Client Hints infrastructure spec includes several improvements over the currently shipped Client Hints. In particular, it allows explicit delegation of Client Hints to specific cross-origin origins, using Feature Policies. That enables us to support Client Hints with cross-origin requests in a privacy preserving manner, and will enable us to backport the same approach to legacy Client Hints as well.


This new infrastructure enables features like UA Client Hints, which enable proactive content negotiation (using the user agent characteristics) without passively sending fingerprinting information to all origins, like the current `User-Agent` string does. The existence of such content negotiation mechanisms will enable us to deprecate and freeze the current User-Agent string (for which we’ll send a separate intent).


Motivation

The changes to the infrastructure are motivated by:

  • Improved user privacy while maintaining the use-case for cross-origin content negotiation - the previous design of Client Hints resulted in fingerprintable information sent on passive cross-origin requests. While we limited that exposure, we did that by removing support for new hints from cross-origin origins. The new infrastructure enables reinstating client hints support for cross-origin origins, depending on the page’s opt-in.

  • Desire for cross-browser implementation - while we don’t have positive signals from other implementers, the design for the new infrastructure received neutral signals from them, and would potentially make it easier for them to come on board in the future.


The UA Client Hints feature is motivated by the desire to eventually turn the fingerprintable information that the UA string passively exposes today into an active fingerprinting vector, forcing sites that rely on it to explicitly opt-in, and enable browsers and privacy researchers to keep track of the information’s usage. 

On top of that, we’re interested in experimenting with GREASEing the UA brand and version, to avoid web sites relying on allow-lists.

Link to “Intent to Prototype” blink-dev discussion

Intent to implement for UA Client Hints

We have not sent an intent for the Feature Policy related changes to the Client Hints infrastructure.


Link to Origin Trial feedback summary

N/A


Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes. 

On Android, there are some legacy Client Hints which are sent to cross-origin origins regardless of specific Feature Policy delegation. This was done to accommodate existing use by image CDNs. We chose to avoid changing that when shipping the infrastructure, but intend to deprecate that independently in the future.


Demo link

Nope


Debuggability

The UA Client Hints headers will be as debuggable as other request headers, through devtools’ network tab.


Risks

Interoperability and Compatibility

From a compatibility perspective, shipping the UA client hints doesn’t pose any new risk. Those are additive additions that web content can choose to rely on, but which are not likely to break existing content.


On the other hand, the new infrastructure does incur some risk:

  • In order to reduce the risk of server-side confusion when it comes to shipping new headers, and as security learning from e.g. allowing the User-Agent string to be manipulated by developers, we decided that all current Client Hint headers will be preceded by a `Sec-CH-` prefix.

  • That means that sites that currently rely on Client Hints will be forced to change their server side logic to address that.

  • We are in contact with the major users of the API (image CDNs), and they ensured us making such a change will not be a huge feat for them.


From an interoperability perspective, we are currently walking this path alone :/


The infrastructure changes we want to ship here have turned the previous Safari opinion of Client Hints being harmful to be less negative, but I don’t believe we have enough of their support to qualify that as “positive signals” just yet. We’ve asked for a re-review of the spec.


Regarding Mozilla’s, we have made great strides in convincing them that the infrastructure is not harmful and removed their previous resistance to the related IETF draft. Nevertheless, their opinion remains neutral (“non-harmful” for both the infrastructure and the UA Client Hints feature).


In contrast to that, Edge is publicly supportive of this effort.


As far as developer interest goes, image CDNs have been using image-related Client Hints features to optimize their user’s images: We have reports and tutorials from Cloudinary, Imgix, and Scientia Mobile.

Web developers have also been advocating for their usage.

While we haven’t heard demand from them to enhance the privacy of the Client Hints infrastructure, in conversations we had with them on the subject they showed understanding of the problem and willingness to modify their implementation of the feature to accommodate the improvements.


Edge: public support

Firefox: “Non-harmful”

Safari: Negative regarding the previous iteration of Client-Hints. We asked for a re-review of the changes we want to ship here.

Web / Framework developers: Positive.


Ergonomics

Depending on the usage, developers may need to opt-in to Client Hints as well as delegate them to specific third party services (e.g. image CDNs).

That opt-in can be done using HTTP headers, which has been historically harder than markup changes. It remains to be seen if this deployment challenge is indeed a hurdle to adoption. A long-term solution may be an Origin Policy to provide the opt-ins.


Activation

Lack of cross-browser adoption would mean that the infrastructure would be useful for content optimization, but using it for essential content negotiation would require some combination of Client Hints logic with legacy means (e.g. UA sniffing).


Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

https://wpt.fyi/results/client-hints


Entry on the feature dashboard

https://www.chromestatus.com/features/5995832180473856


Yoav Weiss

unread,
Jan 14, 2020, 6:58:21 AM1/14/20
to blink-dev, aaro...@chromium.org, Yoav Weiss

Alex Russell

unread,
Jan 14, 2020, 10:17:55 AM1/14/20
to blink-dev, aaro...@chromium.org, yoav...@chromium.org
Howdy, all:

Looking briefly at the the UA-CH draft, it isn't clear what, exactly, we're shipping. The wire behavior? The new interfaces? Both?

Comparing UA-CH to UA strings, some information seems to have gone missing (including language preferences). How has the team validated that the design is useful for developers without this information?

Lastly, a justification in the TAG review for this design is that it prevents some information being sent over plaintext. What does this change gain us vs. simply restricting the availability of UA strings to secure contexts?

Regards

Yoav Weiss

unread,
Jan 14, 2020, 11:02:52 AM1/14/20
to Alex Russell, blink-dev, aaro...@chromium.org, Yoav Weiss
On Tue, Jan 14, 2020 at 4:17 PM 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:
Howdy, all:

Looking briefly at the the UA-CH draft, it isn't clear what, exactly, we're shipping. The wire behavior? The new interfaces? Both?

Both.
 

Comparing UA-CH to UA strings, some information seems to have gone missing (including language preferences).

Language preferences are typically a part of `Accept-Language` and this intent doesn't involve changing that (although there is a proposal on that front)
What other information do you find missing? 

How has the team validated that the design is useful for developers without this information?

Lastly, a justification in the TAG review for this design is that it prevents some information being sent over plaintext. What does this change gain us vs. simply restricting the availability of UA strings to secure contexts?

Restricting UA strings to secure contexts without freezing them is very likely to break legacy sites in non-secure contexts.
Otherwise, the design's improving on the User-Agent string in the following ways:
  • It is turning the passive fingerprinting vector that is the UA string into an active fingerprinting vector. Sites have to specifically opt-in to receive extra information beyond UA brand and version, and in doing so, they touch an active fingerprinting vector. That means that the browser can keep them accountable (a la privacy budget), researchers can forensically track them collecting that info, and the browser can lie if it considers the sites suspicious (exceeded its budget, known tracker, etc).
  • The information is provided in smaller increments, enabling sites to only "touch" the bits that they require.
  • The above also reduces the parsing and regexing a site needs to do in order to extract the information it needs, reducing UA string related "oopsies".
  • As a bonus, it enables us to shed some "Mozilla/5.0" and "KHTML" cruft from values developers need to wade through

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/18c26c94-9d1e-43f0-9e10-182eab2eca93%40chromium.org.

Philip Jägenstedt

unread,
Jan 15, 2020, 5:58:39 AM1/15/20
to Yoav Weiss, blink-dev, aaro...@chromium.org, Yoav Weiss
This is quite intertwined with Intent to Deprecate and Freeze: The User-Agent string, and what we ship here should be enough to make the UA string freezing very easy to adapt to.

I have concerns that there are many unresolved issues connected to how this will replace server-side UA string sniffing, and I'm not sure what the plan is for client-side UA sniffing. There are also inline issues in the spec, in particular https://wicg.github.io/ua-client-hints/#delegation is just a list of issues.

Of the open issues, these seem like ones especially important to address:

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEj9XvPGt49c7XC7kHtgEHBX3Qu32bXANuDN%3DhCKmzjw2w%40mail.gmail.com.

Yoav Weiss

unread,
Jan 15, 2020, 9:24:31 AM1/15/20
to Philip Jägenstedt, Mike West, blink-dev, aaro...@chromium.org, Yoav Weiss
On Wed, Jan 15, 2020 at 11:58 AM Philip Jägenstedt <foo...@chromium.org> wrote:
This is quite intertwined with Intent to Deprecate and Freeze: The User-Agent string, and what we ship here should be enough to make the UA string freezing very easy to adapt to.

Indeed.
 

I have concerns that there are many unresolved issues connected to how this will replace server-side UA string sniffing,

Many of those were opened as a result of sending the intents :) (which is great!)
 
and I'm not sure what the plan is for client-side UA sniffing.
 
The getUserAgent method should cover client-side: https://wicg.github.io/ua-client-hints/#interface

There are also inline issues in the spec, in particular https://wicg.github.io/ua-client-hints/#delegation is just a list of issues.

Thanks for pointing it out. This indeed require cleaning, but the processing for that is defined as part of https://wicg.github.io/client-hints-infrastructure/ (e.g. https://wicg.github.io/client-hints-infrastructure/#request-processing)


Of the open issues, these seem like ones especially important to address:

We've discussed this internally and decided that we should not be blocking shipping the infrastructure here on resolving the "very first hit" problem.
Most use-cases for HTML adaptation based on the UA string can get by with brand, significant version (and maybe a mobileness bit, as we've seen on issue #15).
For the remaining cases, there's a tradeoff here between a (temporary, only on their very-first hit) performance regression for a small minority of sites vs. reducing the passive fingerprinting surface of all users.
We've decided that the latter gets priority.
At the same time, I'd love to collect use-cases where brand, version and mobileness are not enough, and see if there's something we can do on that front.


We indeed need to better define the brand as a set of values, to minimize parsing errors, enable browsers to claim equivalence groups while maintaining their identity, and enable future GREASEing.
 

I agree we need resolution there, but tend to agree with +Mike West. Returning a promise will indeed introduce some short-term pain when switching from the legacy UA string to `getUserAgent()`, but will enable future enforcement mechanisms a lot of flexibility as to what they can do when sites touch Too Many Bits™.

Domenic Denicola

unread,
Jan 15, 2020, 11:38:09 AM1/15/20
to Philip Jägenstedt, Yoav Weiss, blink-dev, aaro...@chromium.org, Yoav Weiss
I’d like to second Philip’s concern about the many unresolved issues. A lot of open design questions remain (including ones from before this thread was sent, such as the 9 inline issues in the spec and 7 on the issue tracker), and the README itself states

> (Note: This isn't a proposal that's well thought out, and stamped solidly with the Google Seal of Approval. It's a collection of interesting ideas for discussion, nothing more, nothing less.)

I would think before we get to the Intent to Ship stage, we would have all the open design questions resolved so that the spec could be interoperably implemented without fear of it changing in major ways, and something approaching the "Google Seal of Approval".

Maybe this is more of an Intent to Prototype at this stage?

ferdy.c...@gmail.com

unread,
Jan 15, 2020, 2:34:19 PM1/15/20
to blink-dev, aaro...@chromium.org, yoav...@chromium.org
Regarding opt-ins, I imagine pretty much any web property opting in, because browser type and version are absolutely essential data for the technical operation of any website. They are not optional, they are a must-have in my opinion:

- Developers need it to know which browsers to target/focus on
- Developers/Marketeers need it to understand mobile/device usage
- The alternative (feature detection) fails to acknowledge buggy browsers, where a browser claims support, yet breaks. Worse, browsers that don't support feature detection in itself.

So I imagine everybody opting-in, which brings me to my main question: what is the negative "cost" of an opt-in? Will this tell the user that you're "tracking" them? Does it require user permission? What is the practical consequence of an opt-in?

Jeffrey Yasskin

unread,
Jan 15, 2020, 4:28:09 PM1/15/20
to ferdy.c...@gmail.com, blink-dev, aaro...@chromium.org, yoav...@chromium.org
Note that https://wicg.github.io/ua-client-hints/#sec-ch-ua specifies
that the browser *always* sends the browser's type and major version.
(And see https://github.com/WICG/ua-client-hints/issues/23 for details
around Safari.) Sites won't have to ask for those.

Jeffrey
> --
> 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+...@chromium.org.
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3f65b62b-17c5-4890-a3cc-40ad0ab1ba3b%40chromium.org.

Philip Jägenstedt

unread,
Jan 16, 2020, 11:20:32 AM1/16/20
to Yoav Weiss, Mike West, blink-dev, aaro...@chromium.org, Yoav Weiss
On Wed, Jan 15, 2020 at 9:24 PM Yoav Weiss <yo...@yoav.ws> wrote:


On Wed, Jan 15, 2020 at 11:58 AM Philip Jägenstedt <foo...@chromium.org> wrote:
This is quite intertwined with Intent to Deprecate and Freeze: The User-Agent string, and what we ship here should be enough to make the UA string freezing very easy to adapt to.

Indeed.
 

I have concerns that there are many unresolved issues connected to how this will replace server-side UA string sniffing,

Many of those were opened as a result of sending the intents :) (which is great!)
 
and I'm not sure what the plan is for client-side UA sniffing.
 
The getUserAgent method should cover client-side: https://wicg.github.io/ua-client-hints/#interface

There are also inline issues in the spec, in particular https://wicg.github.io/ua-client-hints/#delegation is just a list of issues.

Thanks for pointing it out. This indeed require cleaning, but the processing for that is defined as part of https://wicg.github.io/client-hints-infrastructure/ (e.g. https://wicg.github.io/client-hints-infrastructure/#request-processing)

I'm not entirely sure what should be in that section, so I just filed https://github.com/WICG/ua-client-hints/issues/34 to keep track of it.

Of the open issues, these seem like ones especially important to address:

We've discussed this internally and decided that we should not be blocking shipping the infrastructure here on resolving the "very first hit" problem.
Most use-cases for HTML adaptation based on the UA string can get by with brand, significant version (and maybe a mobileness bit, as we've seen on issue #15).
For the remaining cases, there's a tradeoff here between a (temporary, only on their very-first hit) performance regression for a small minority of sites vs. reducing the passive fingerprinting surface of all users.
We've decided that the latter gets priority.
At the same time, I'd love to collect use-cases where brand, version and mobileness are not enough, and see if there's something we can do on that front.

Shipping UA client hints and getting some experience without resolving this is reasonable I think, but I think the UA string freezing will have to block on a resolution. Even a small proportion of use cases among UA string users will amount to a lot. Unfortunately use counters can not measure this at all, but crawling experiments with different strings are an option.


We indeed need to better define the brand as a set of values, to minimize parsing errors, enable browsers to claim equivalence groups while maintaining their identity, and enable future GREASEing.

This will be great :)


I agree we need resolution there, but tend to agree with +Mike West. Returning a promise will indeed introduce some short-term pain when switching from the legacy UA string to `getUserAgent()`, but will enable future enforcement mechanisms a lot of flexibility as to what they can do when sites touch Too Many Bits™.

In both cases the only options are to return a value or throw an error, but with a promise you could delay it without stopping the main thread. How concrete are these future plans, is there a roadmap of sorts?

Brad Lassey

unread,
Jan 16, 2020, 12:30:15 PM1/16/20
to Philip Jägenstedt, Yoav Weiss, Mike West, blink-dev, aaro...@chromium.org, Yoav Weiss
There are no current plans for interventions, but returning a Promise allows other UAs to make different decisions and for us to change our mind in the future.
 

Yoav Weiss

unread,
Jan 17, 2020, 12:58:48 AM1/17/20
to blink-dev, Philip Jägenstedt, Mike West, Brad Lassey, Aaron Tagliaboschi, Yoav Weiss
Thanks all for the great feedback here, on the repo, and elsewhere!

As a result, there are a bunch of things we feel we need to modify about the proposal:
  • Send the "mobileness" hint by default
  • Clarify the confusion about which parts of the version are sent by default and which parts aren't, as "major" and "minor" are not the right terms to convey "feature release" vs. "bug fix release".
  • Make sure that "brand" is a set, and make sure the JS API reflects that
  • Potentially provide a separate sync API for low-entropy hints
  • Avoid freezing the meaningful version of the legacy UA string, at least at first
  • Fix an issue related to Feature Policy delegation
  • Sort out the WebView situation, and potentially ship the feature there separately
Please consider this intent on hold until we'd sort these things out, and update the various specs and implementation.
I'll let this thread now when this has happened.

Philip Jägenstedt

unread,
Jan 17, 2020, 1:32:46 AM1/17/20
to Yoav Weiss, blink-dev, Mike West, Brad Lassey, Aaron Tagliaboschi, Yoav Weiss
Thanks Yoav, that sounds like a good plan to me!

On "Avoid freezing the meaningful version of the legacy UA string, at least at first", is the idea to follow the same approach as Safari? Can you elaborate on that on the other intent?

Yoav Weiss

unread,
Jan 17, 2020, 1:40:39 AM1/17/20
to Philip Jägenstedt, blink-dev, Mike West, Brad Lassey, Aaron Tagliaboschi, Yoav Weiss
On Fri, Jan 17, 2020 at 7:32 AM Philip Jägenstedt <foo...@chromium.org> wrote:
Thanks Yoav, that sounds like a good plan to me!

On "Avoid freezing the meaningful version of the legacy UA string, at least at first", is the idea to follow the same approach as Safari? Can you elaborate on that on the other intent?

You're right that this item should've been part of the other intent. I'll elaborate there.

jj

unread,
Jan 17, 2020, 3:43:19 PM1/17/20
to blink-dev, foo...@chromium.org, mk...@chromium.org, las...@google.com, aaro...@chromium.org, yoav...@chromium.org


Am Freitag, 17. Januar 2020 06:58:48 UTC+1 schrieb Yoav Weiss:
Thanks all for the great feedback here, on the repo, and elsewhere!

As a result, there are a bunch of things we feel we need to modify about the proposal:
  • Send the "mobileness" hint by default

This cries for compat trouble, assuming Mozilla doesn't implement it and most developers don't care (or don't know) about Firefox Mobile.

To unsubscribe from this group and stop receiving emails from it, send an email to blin...@chromium.org.

--
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 blin...@chromium.org.

Gil Meroz

unread,
Feb 18, 2020, 4:23:39 PM2/18/20
to blink-dev
i do not understand why platform, OS type and version are not sent by default on the original request.

That data is important for many servers. Some websites return different pages according to these fields either to bypass OS specific bugs or in order to optimize the result for user.

Specifically, this is important to support deep linking on mobile

Yoav Weiss

unread,
Feb 19, 2020, 2:24:03 AM2/19/20
to Gil Meroz, blink-dev
On Tue, Feb 18, 2020 at 10:23 PM 'Gil Meroz' via blink-dev <blin...@chromium.org> wrote:
i do not understand why platform, OS type and version are not sent by default on the original request.

A large part of the motivation behind UA-CH is to reduce passive entropy emitted by the browser, that is the distinctive values sent by default on requests.
Therefore, we chose to send by default only low-entropy values (browser, significant version and mobileness), and not values with higher entropy like the platform and its version.


That data is important for many servers. Some websites return different pages according to these fields either to bypass OS specific bugs or in order to optimize the result for user.  \

Those servers can opt-in to receive that information. 


Specifically, this is important to support deep linking on mobile

Can you clarify what you mean by deep linking? Would the "mobileness" bit not be enough here?
 

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/19ed667e-3a9c-401f-8b6b-9e4dc7a604ad%40chromium.org.

Gil Meroz

unread,
Feb 19, 2020, 10:50:57 AM2/19/20
to blink-dev, g...@appsflyer.com
There are various methods for deep linking. On Android there's the intent URI scheme, specific URI scheme and also App Links. Different apps support different methods. Even when for the same webview. In addition some Chrome versions or specific ROM may behave different. 

One example is that the intent URI works different on Chrome 80 compare to Chrome 79 and below when the Chrome browser is running on the background. The Chrome 81 beta behave like the 79 for now. 

Another example is that on some OPPO (very popular Chinese manufactor) and also some Samsung use custom Android versions where the webview behave different than usual and breaks deep linking. These requires the server to use specific redirection for those links.  

This shows how fragile deep linking is and why a sever should be able to identify the Chrome version and OS version. 

On Wednesday, February 19, 2020 at 9:24:03 AM UTC+2, Yoav Weiss wrote:
On Tue, Feb 18, 2020 at 10:23 PM 'Gil Meroz' via blink-dev <blin...@chromium.org> wrote:
i do not understand why platform, OS type and version are not sent by default on the original request.

A large part of the motivation behind UA-CH is to reduce passive entropy emitted by the browser, that is the distinctive values sent by default on requests.
Therefore, we chose to send by default only low-entropy values (browser, significant version and mobileness), and not values with higher entropy like the platform and its version.


That data is important for many servers. Some websites return different pages according to these fields either to bypass OS specific bugs or in order to optimize the result for user.  \

Those servers can opt-in to receive that information. 


Specifically, this is important to support deep linking on mobile

Can you clarify what you mean by deep linking? Would the "mobileness" bit not be enough here?
 

--
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 blin...@chromium.org.

mme...@google.com

unread,
Feb 19, 2020, 4:46:11 PM2/19/20
to blink-dev, g...@appsflyer.com
As noted upthread, browsers will continue to send major version.

Gil Meroz

unread,
Feb 21, 2020, 3:31:06 AM2/21/20
to mme...@google.com, blink-dev
It's the OS version and OS type needed for these situations.

usman...@tercept.com

unread,
Feb 28, 2020, 2:12:38 PM2/28/20
to blink-dev, g...@appsflyer.com
Will a version of UA-CH ship with Chrome 81 in March?


On Wednesday, February 19, 2020 at 12:54:03 PM UTC+5:30, Yoav Weiss wrote:
On Tue, Feb 18, 2020 at 10:23 PM 'Gil Meroz' via blink-dev <blin...@chromium.org> wrote:
i do not understand why platform, OS type and version are not sent by default on the original request.

A large part of the motivation behind UA-CH is to reduce passive entropy emitted by the browser, that is the distinctive values sent by default on requests.
Therefore, we chose to send by default only low-entropy values (browser, significant version and mobileness), and not values with higher entropy like the platform and its version.


That data is important for many servers. Some websites return different pages according to these fields either to bypass OS specific bugs or in order to optimize the result for user.  \

Those servers can opt-in to receive that information. 


Specifically, this is important to support deep linking on mobile

Can you clarify what you mean by deep linking? Would the "mobileness" bit not be enough here?
 

--
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 blin...@chromium.org.

Yoav Weiss

unread,
Feb 28, 2020, 2:35:05 PM2/28/20
to usman...@tercept.com, blink-dev, Gil Meroz
On Fri, Feb 28, 2020 at 8:12 PM <usman...@tercept.com> wrote:
Will a version of UA-CH ship with Chrome 81 in March?

Due to a lot of feedback on this intent and resulting work accommodating it, we did not hit the 81 milestone.
I'll update the thread when the feedback was fully addressed in spec and implementation.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1ad0f1dd-ae32-4095-8f77-dca727cad44f%40chromium.org.

usman...@tercept.com

unread,
Mar 2, 2020, 12:16:51 AM3/2/20
to blink-dev, usman...@tercept.com, g...@appsflyer.com
Thanks Yoav, I just had one more question. I've read elsewhere that it will be simple for a browser to detect and block any unnecessary UA-CH requests. Is this correct? If it yes, then what type of UA-CH requests do you anticipate will be blocked?

On Saturday, February 29, 2020 at 1:05:05 AM UTC+5:30, Yoav Weiss wrote:


On Fri, Feb 28, 2020 at 8:12 PM <usma...@tercept.com> wrote:
Will a version of UA-CH ship with Chrome 81 in March?

Due to a lot of feedback on this intent and resulting work accommodating it, we did not hit the 81 milestone.
I'll update the thread when the feedback was fully addressed in spec and implementation.


On Wednesday, February 19, 2020 at 12:54:03 PM UTC+5:30, Yoav Weiss wrote:


On Tue, Feb 18, 2020 at 10:23 PM 'Gil Meroz' via blink-dev <blin...@chromium.org> wrote:
i do not understand why platform, OS type and version are not sent by default on the original request.

A large part of the motivation behind UA-CH is to reduce passive entropy emitted by the browser, that is the distinctive values sent by default on requests.
Therefore, we chose to send by default only low-entropy values (browser, significant version and mobileness), and not values with higher entropy like the platform and its version.


That data is important for many servers. Some websites return different pages according to these fields either to bypass OS specific bugs or in order to optimize the result for user.  \

Those servers can opt-in to receive that information. 


Specifically, this is important to support deep linking on mobile

Can you clarify what you mean by deep linking? Would the "mobileness" bit not be enough here?
 

--
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 blin...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/19ed667e-3a9c-401f-8b6b-9e4dc7a604ad%40chromium.org.

--
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 blin...@chromium.org.

crypte...@gmail.com

unread,
Mar 4, 2020, 4:02:05 PM3/4/20
to blink-dev, usman...@tercept.com, g...@appsflyer.com
What are the new timelines?
Can somebody point me to a document if there is any?

Yoav Weiss

unread,
May 6, 2020, 3:57:34 PM5/6/20
to blink-dev

Hey folks!


I’d like to revive this intent, as we’re hoping to ship this for M84.

Notable changes since the original intent was sent, as a result of community feedback:

  • Many use-cases were gathered from the community and documented.

  • The mobile/desktop distinction is now considered “low entropy” and sent by default on all requests.

  • “Platform version” was split from “platform”, as their use-cases don’t entirely overlap.

  • The “UA full version” was split into a separate hint, to enable JS access to the significant version, in cases where the full version is not needed (which is most cases).

    • That also had the benefit of making the CH opt-in for that hint easier to explain (previously, an opt-in to `UA` augmented the hint to expose the full version)

  • The `NavigatorUAData.UA` attribute was renamed (twice!) to eventually land on `brands`. It’s also now a list, containing more than a single entry.

  • The `Sec-CH-UA` header is now a Structured Headers parameterized list. We’d like folks that are parsing those on the server side to use standard parsers (like this one).

  • The definition of GREASE in the context of UA-CH was refined - it now targets blocking the use of “allow lists” (by including unknown values in the set) and the use of non-standard parsers (by including values that are likely to break such parsers).

  • The JS interface is no longer guarded in its entirety by a Promise, only the call to acquire the high entropy values.

  • The processing model was revamped and improved.

  • The JS interface is now exposed to workers.

  • `http-equiv` based Client Hints are no longer persistent, to enable future architecture simplification where all hint parsing (for persistency purposes) is done outside the renderer.


The main remaining point of contention is around the `architecture` hint.

There’s ongoing debate on the language that will enable UAs that don’t want to expose it to avoid doing so. IMO, this debate should not impact the API shape.


Otherwise, there’s an issue suggesting we define the different CPU architectures so that the same string would mean the same thing on different platforms, which seems reasonable. I have a proposal on that front. Note that we’re planning to initially expose those values on Windows and Linux. We also plan to see if use-cases arise where this signal is not sufficient and potentially enhance it with a separate, higher-entropy hint.

I’m planning to land it (and related code changes) before M84 branches. If we fail to do so, I’m happy to ship most of the feature *without* the `architecture` bits, and ship them at a later date when everyone is happy with the proposed values.


Another point of note - currently the exposed `brands` and `Sec-CH-UA` values are not GREASEd. We’re planning to implement some version of GREASE before M84, and potentially improve on it later.


On the implementation & testing front, we also had bug fixes & spec alignment. Otherwise, the umbrella bug still includes a few blocker issues. We expect all of them (other than potentially ones mentioned above) to be fixed before branch point.


API OWNERS - what say ye?


Cheers :)

Yoav


Mike West

unread,
May 8, 2020, 3:10:10 AM5/8/20
to Yoav Weiss, blink-dev
LGTM1, with some caveats below:

* I see ongoing conversation both internally and externally around `Sec-CH-UA-Arch` and the related `architecture` attribute of the `UADataValues` dictionary. It's not clear to me that that's going to be in a shippable shape by the M84 branch point, and I'd prefer to see y'all work that out fully before pushing it out the door. If it's not ready next week, I'd suggest splitting it from this intent and sending another in the future when it's ready.

* I heard concerns around the split between synchronous and asynchronous getters for attributes exposed directly on `NavigatorUAData` on the one hand, and those exposed via `UADataValues`. I don't think those concerns are blocking, but I would like to make sure we have a consistent story for developers about how they should access information about the user agent in which they're running.

Otherwise, this seems like a good direction for us to move in, and I appreciate the work you've done to incorporate feedback received since the intent was originally sent in January.

-mike

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgN4PdQaEiU_ZtCH2s1kGfjpqKadApLRaNeyz%2B7np-TAg%40mail.gmail.com.

Chris Harrelson

unread,
May 8, 2020, 12:22:38 PM5/8/20
to Mike West, Yoav Weiss, blink-dev
On Fri, May 8, 2020 at 12:10 AM Mike West <mk...@chromium.org> wrote:
LGTM1, with some caveats below:

* I see ongoing conversation both internally and externally around `Sec-CH-UA-Arch` and the related `architecture` attribute of the `UADataValues` dictionary. It's not clear to me that that's going to be in a shippable shape by the M84 branch point, and I'd prefer to see y'all work that out fully before pushing it out the door. If it's not ready next week, I'd suggest splitting it from this intent and sending another in the future when it's ready.

I would prefer to decide this one way or the other before giving approval, so that it's clear what is shipping.

Yoav Weiss

unread,
May 8, 2020, 6:47:28 PM5/8/20
to Chris Harrelson, Mike West, blink-dev
On Fri, May 8, 2020 at 6:22 PM Chris Harrelson <chri...@chromium.org> wrote:


On Fri, May 8, 2020 at 12:10 AM Mike West <mk...@chromium.org> wrote:
LGTM1, with some caveats below:

* I see ongoing conversation both internally and externally around `Sec-CH-UA-Arch` and the related `architecture` attribute of the `UADataValues` dictionary. It's not clear to me that that's going to be in a shippable shape by the M84 branch point, and I'd prefer to see y'all work that out fully before pushing it out the door. If it's not ready next week, I'd suggest splitting it from this intent and sending another in the future when it's ready.

I would prefer to decide this one way or the other before giving approval, so that it's clear what is shipping.

Understood. I believe we are converging on that front, and the relevant PRs can land soon. 
I'll notify this thread when they either land, or we decide to go ahead and ship architecture with initially empty values, due to lack of agreement.

Yoav Weiss

unread,
May 12, 2020, 1:13:14 PM5/12/20
to Chris Harrelson, Mike West, blink-dev
On Sat, May 9, 2020 at 12:47 AM Yoav Weiss <yo...@yoav.ws> wrote:


On Fri, May 8, 2020 at 6:22 PM Chris Harrelson <chri...@chromium.org> wrote:


On Fri, May 8, 2020 at 12:10 AM Mike West <mk...@chromium.org> wrote:
LGTM1, with some caveats below:

* I see ongoing conversation both internally and externally around `Sec-CH-UA-Arch` and the related `architecture` attribute of the `UADataValues` dictionary. It's not clear to me that that's going to be in a shippable shape by the M84 branch point, and I'd prefer to see y'all work that out fully before pushing it out the door. If it's not ready next week, I'd suggest splitting it from this intent and sending another in the future when it's ready.

I would prefer to decide this one way or the other before giving approval, so that it's clear what is shipping.

Understood. I believe we are converging on that front, and the relevant PRs can land soon. 
I'll notify this thread when they either land, or we decide to go ahead and ship architecture with initially empty values, due to lack of agreement.

PR hasn't landed yet, but we do seem to have agreement on its direction. So, I'd like to go ahead with `architecture` included, assuming y'all agree that the risk here is low.

Otherwise, as discussed, I asked for opinions on webkit-dev, and got mildly positive ones.


 

* I heard concerns around the split between synchronous and asynchronous getters for attributes exposed directly on `NavigatorUAData` on the one hand, and those exposed via `UADataValues`. I don't think those concerns are blocking, but I would like to make sure we have a consistent story for developers about how they should access information about the user agent in which they're running. 

https://github.com/WICG/ua-client-hints/issues/108 is where Alex raised those concerns.
It seems like they could be solved by *also* exposing `brands` and `mobile` as part of the `getHighEntropyValues` getter.
That doesn't seem blocking, as the design is forward compatible.

Chris Harrelson

unread,
May 12, 2020, 1:57:28 PM5/12/20
to Yoav Weiss, Mike West, blink-dev
LGTM2

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiZYi%2BPMT2H5C%2BMMWSQy%3Dzw1Rh235ugM39RTxK57ye16g%40mail.gmail.com.

Yoav Weiss

unread,
May 12, 2020, 3:21:30 PM5/12/20
to Chris Harrelson, Mike West, blink-dev
One more complication I mistakenly left out in my previous update. (apologies!)

It seems like at least one site is broken by the UA-CH request headers, as a result of them being Structured Headers (the site seems sensitive to double quotes and question marks in request headers, presumably judging them suspicious).

Talking to the team, we were thinking that keeping close track of issues as this rolls into beta would be sufficient, and we can turn it off if it's revealed to be a more wide-spread issue.

Thoughts on that front?

Chris Harrelson

unread,
May 12, 2020, 3:32:20 PM5/12/20
to Yoav Weiss, Mike West, blink-dev
On Tue, May 12, 2020 at 12:21 PM Yoav Weiss <yo...@yoav.ws> wrote:
One more complication I mistakenly left out in my previous update. (apologies!)

It seems like at least one site is broken by the UA-CH request headers, as a result of them being Structured Headers (the site seems sensitive to double quotes and question marks in request headers, presumably judging them suspicious).

Talking to the team, we were thinking that keeping close track of issues as this rolls into beta would be sufficient, and we can turn it off if it's revealed to be a more wide-spread issue.

Thoughts on that front?

SGTM
 

Yoav Weiss

unread,
May 13, 2020, 2:37:42 PM5/13/20
to blink-dev, Mike West, Chris Harrelson, Alex Russell, Daniel Bratell
We're still missing one last LGTM. OWNERS?

sligh...@chromium.org

unread,
May 13, 2020, 7:39:47 PM5/13/20
to blink-dev, mk...@chromium.org, chri...@chromium.org, sligh...@chromium.org, brat...@gmail.com
LGTM3 per out-of-band discussion on API shape. Thanks for pushing this forward, Yoav!
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

Yoav Weiss

unread,
May 15, 2020, 1:15:08 AM5/15/20
to Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
Thanks all! The feature was enabled by default and should be available in the next M84 Canary build.

LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.

--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b29919d6-c72d-439d-b95d-bb1f5f3b8c6c%40chromium.org.

Heg7keg Fsjsftb

unread,
May 18, 2020, 12:39:45 PM5/18/20
to Yoav Weiss, Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
😀😀😘

เมื่อ วันศุกร์ที่ 15 พฤษภาคม ค.ศ. 2020, Yoav Weiss <yo...@yoav.ws> เขียนว่า:
LGTM2

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b29919d6-c72d-439d-b95d-bb1f5f3b8c6c%40chromium.org.

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjjGOWhk_d5KTovGQZDdUyXAaqECc6fXNPRz4ZTxkpOhQ%40mail.gmail.com.

Yoav Weiss

unread,
Jul 8, 2020, 9:01:59 AM7/8/20
to Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell

Hey all,


A quick note: due to site breakage issues we encountered, the feature will be slowly rolled out in M84, rather than enabled by default. Even though we’re only aware of one large site that still breaks when sent with new and exciting chars such as double-quotes in request headers, we prefer a cautious & slow roll-out to enable us to catch any cases that did not come up during Beta.


Thanks,

Yoav


Reilly Grant

unread,
Jul 8, 2020, 1:02:01 PM7/8/20
to Yoav Weiss, Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
How are we planning to make this change visible to administrators who may be encountering these issues on internal networks? Rolling out via a field trial can make it difficult to determine the cause of breakage because the failure state becomes non-deterministic.
Reilly Grant | Software Engineer | rei...@chromium.org | Google Chrome


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEitqF6HVipf7W%3DdovwFL8Z6ezB5USbbGUbFeq0-CCcGJA%40mail.gmail.com.

Lily Chen

unread,
Jul 8, 2020, 1:26:00 PM7/8/20
to Reilly Grant, Yoav Weiss, Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
It's currently possible but a bit inconvenient: you either have to capture a NetLog (which lists enabled features) or wade through chrome://version/?show-variations-cmd.


To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEmk%3DMYMtVcXG-oxdCXiVSn-pfbNGu2tv9LK26-UWt%3DTbrXQBQ%40mail.gmail.com.

Yoav Weiss

unread,
Jul 8, 2020, 5:23:10 PM7/8/20
to Lily Chen, Reilly Grant, Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
Regarding this specific change, it's easy for folks to diagnose if the feature is enabled or not, by checking outgoing requests headers in the devtools network panel - if the `sec-ch-ua` header is included in the request, the feature is enabled.

For folks that use Chrome's enterprise policy, we also added an enterprise policy flag to disable this feature, if they run into trouble with it. Since the issues we've seen come from WAFs, I'd expect breakage to come more from publicly visible sites than from internal ones.

Yoav Weiss

unread,
Sep 9, 2020, 5:01:40 PM9/9/20
to Lily Chen, Reilly Grant, Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
Hey folks,

After long delays due to compat issues, we’re now actually starting to rollout UA-CH to Chrome’s stable channel.
Updates on the rollout, as well as debugging info if you’re running into related compatibility issues can be found at https://www.chromium.org/updates/ua-ch.

Cheers,
Yoav

Christian Biesinger

unread,
Sep 10, 2020, 5:31:57 AM9/10/20
to Yoav Weiss, Lily Chen, Reilly Grant, Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
Out of curiosity, how were the site compat issues fixed? A change to
the standard (how)? Or did you reach out to site owners?

Thanks!

Christian
> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEjBBFOHK77%2Bv3-bg9zEpo5JmY_xAWiCeeM8rJwaeB8t6Q%40mail.gmail.com.

Yoav Weiss

unread,
Sep 10, 2020, 6:01:15 AM9/10/20
to Christian Biesinger, Lily Chen, Reilly Grant, Alex Russell, blink-dev, Mike West, Chris Harrelson, Daniel Bratell
The API and headers were not changed, and the compat issues were (mostly) resolved using outreach and the related sites fixing their WAF configurations.
Note that one large site is not yet fixed (it was fixed, but then regressed as the fix seemed to have been rolled back).
Reply all
Reply to author
Forward
0 new messages