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 or to specific sites), and sites (including Google properties) being broken 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 (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).
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 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.
(*) 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
Firefox: Public support 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 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 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
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 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
Hey Yoav, Aaron:Glad to see the CH-UA intent to out to ensure that similar information is provided no matter where this intent lands. Can you confirm that, if given approval for this, you will not take action to change UA behavior until CH-UA is shipped?
Presumably, in the context of privacy budgets, a model has been developed that discusses the bits of entropy reduction by default that are gained and the performance tradeoffs of requiring Accept-CH redirectors on nearly all top-level entrypoints for major services that wish to avoid overpolyfilling. Can you publish that analysis?
What work has gone into discussing this change with latency-sensitive properties and services? I'm aware that other UAs have implemented similar changes, but they have also been UAs that tend to benefit from high-end devices and networks by dint of their users being wealthy. If this change had been made 2 years ago, what would the polyfill bloat impact be on our user-base for those serving optimally (e.g., using polyfill.io)?
--
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/fbfd9b0b-97a4-4775-b4e2-a4da9f87660f%40chromium.org.
a) If the server doesn't get the info on first hit isn't there a performance penalty in that it has to respond with what it wants, then wait for the response just to give the optimal experience?
b) I'm a little unclear on mobileness, what values should be given for a phone, tablet, desktop?
c) Depending on b), it would be nice to at least have resolution buckets so we can return the most appropriate experience. Right now the experience for universal applications having to leverage UA sniffing (server) and resolution (client) is really bad.
On Tuesday, January 14, 2020 at 5:22:00 AM UTC-6, Yoav Weiss 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 or to specific sites), and sites (including Google properties) being broken 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 Clicsscssent 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.
--
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/5e5bd3db-0662-4de7-8bbb-004091b780f9%40chromium.org.
Hey Conrad,I think it's a little clearer in the explainer: https://github.com/WICG/ua-client-hints#a-proposal proposes exposing a NavigatorUAData interface via navigator.getUserAgent()
On Tue, 14 Jan 2020 at 17:08, conrad via blink-dev <blink-dev@chromium.org> wrote:
Thanks for sharing this. Maybe I missed this in reading through the spec, but is the same information as sent via the Sec-CH- headers going to be available to JavaScript running on the page?
I ask because at Superhuman we parse the userAgent string client side for several things:
1. If the operating system is Linux or Windows we increase the contrast of the CSS to better fit with user expectations.
2. Depending on the device (e.g. iPhone vs Android) we display a different error message to users, and to direct them to the appropriate App Store.
3. We use the minor version number of the browser to block known ‘bad’ versions of Chrome Canary and explain the situation (in the rare cases it contains bugs that break Superhuman fundamentally)
Currently we load the HTML and JavaScript from Google Cloud Storage, and so this logic could not live on the server for us.
--
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 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/5e5bd3db-0662-4de7-8bbb-004091b780f9%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8a0dbd52-2793-4398-ac15-bb9afe64769b%40chromium.org.
You received this message because you are subscribed to a topic in the Google Groups "blink-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/blink-dev/-2JIRNMWJ7s/unsubscribe.
To unsubscribe from this group and all its topics, 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/CA%2BjkKumWa7az2jgGLNbyXAkLyeAffLwdh0gOeN80boRZMc4yCA%40mail.gmail.com.
Can you point where the API meets the //content code for this path? I'm fairly sure that this would overwrite the frozen string, but I can make sure for you. I'm just not as familiar with the webview part of the codebase.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJwB4XarrBWCMpAPEkD3PCL29bwnzCQ2Ah%3DJK7JHwssRL5FQJQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CA%2BjkKukk_NJbJZz7W-yrm3wUCkXfxEj6Mioe9Yxr94U_3%3DmFww%40mail.gmail.com.
Summary
We want to freeze and unify (but not remove) the User Agent string in HTTP requests as well as in `navigator.userAgent`
--
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%3DBEjpz2AZ4x5nVm8X5%2BHrjdzH1-7f5y7qf6CmGMLTFVU4CQ%40mail.gmail.com.
I'm glad to see an effort towards freezing the UA string and finding alternatives. UA sniffing is at the root of countless web compat issues and these disproportionately affect browsers the developer didn't test in or think about.At the same time, this header has been evolving and mutating since Mosaic, and freezing it is bound to have effects all across the ecosystem and cause a lot of frustration. I'd like to see some of the risks explored more. Some concrete concerns:This depends on Intent to Ship: Client Hints infrastructure and UA Client Hints, but even if that ships first I don't think we can be confident that this alternative will be sufficient. Would it not be more prudent to ship that first, and work with a number of real sites to see what kind of issues come up?
That's not going to shake out some of the long tail issues, but would reveal any common problems. Seeing other vendors adopt UA Client Hints would also help a lot.
The timeline for this seems a fair bit too short given that it's a non-trivial change and can span multiple layers of software, and so need trickle through multiple planning and release cycles. What are the tradeoff of letting this bake 6 months vs. 1 year, say? (Chrome 99 around mid-2022 seems like an upper bound because Chrome 100 will very likely break some sniffing code, just like how Opera's UA string got stuck at 9.)
Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)
How essential is it to have this message? It looks like Safari doesn't have a console warning.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJwB4XaR92xCbfp3emxkfRHG7y2Ns%3DCLYJcvL1eXv3oCw7-_KA%40mail.gmail.com.
Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)If they'd use `getUserAgent()` for that, that's a win, no? :D
}
if(/Mobi/.test(navigator.userAgent) && !/^iPad/.test(navigator.platform) || window.operamini) {
/* linkify phone numbers */
No need to change this code, no reason for a spammy warning.
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`
FYI, there is also the "viewport-width" client hint, which will tell you the CSS px width of the viewport. If you want to go even crazier, you can request the "model" client hint, get the device model, and look up the width, height, and any other information based on that. That's not as recommended though unless you need very fine-grained information, as it's always better to get the least amount of entropy needed.
I am trying to understand that: The data about the browser is still available, but we have to send an additional request (for Sec-CH) to the user-agent? Or can the (Accept-CH) header be sent right away during the initial server response?
How and why is this preventing finger printing?
Contact emails
yoav...@chromium.org, aaro...@chromium.org
On Wed, Jan 15, 2020 at 11:45 AM Philip Jägenstedt <foo...@chromium.org> wrote:I'm glad to see an effort towards freezing the UA string and finding alternatives. UA sniffing is at the root of countless web compat issues and these disproportionately affect browsers the developer didn't test in or think about.At the same time, this header has been evolving and mutating since Mosaic, and freezing it is bound to have effects all across the ecosystem and cause a lot of frustration. I'd like to see some of the risks explored more. Some concrete concerns:This depends on Intent to Ship: Client Hints infrastructure and UA Client Hints, but even if that ships first I don't think we can be confident that this alternative will be sufficient. Would it not be more prudent to ship that first, and work with a number of real sites to see what kind of issues come up?It certainly would be more prudent. The urgency comes from the fact that right now, we are broadcasting a lot of information about our users, in clear text, to all servers. We would like to stop doing that.Our assumption was that 4 releases (between shipping UA CH and unifying the UA string) would be enough time for us to make sure the replacement is sufficient before pulling the plug on the legacy string.
That's not going to shake out some of the long tail issues, but would reveal any common problems. Seeing other vendors adopt UA Client Hints would also help a lot.I agree that other vendors adopting would help. Unfortunately, Mozilla don't seem to be interested in implementing the CH part. I've asked Apple to re-review, so one can remain hopeful.
The timeline for this seems a fair bit too short given that it's a non-trivial change and can span multiple layers of software, and so need trickle through multiple planning and release cycles. What are the tradeoff of letting this bake 6 months vs. 1 year, say? (Chrome 99 around mid-2022 seems like an upper bound because Chrome 100 will very likely break some sniffing code, just like how Opera's UA string got stuck at 9.)Letting this bake for a year would mean continuing to send user information, in the clear, to all servers, for 6 more months.
Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)If they'd use `getUserAgent()` for that, that's a win, no? :DHow essential is it to have this message? It looks like Safari doesn't have a console warning.We want to let developers know that the API they are using is about to become useless and move them to the new API. Are there other tools that fit that purpose other than console warnings?
Some additional issues with WebView here:1) I don't think that client hints are fully implemented in WebView right now (I don't think it is wired up to store the requests for hints from servers anywhere), so we might need to deal with that before shipping?
2) WebView apps which override the user agent string might be doing so in order to *conceal* information that's present by default, which might mean that they would also want to control what's exposed via client hints - we might need to consider exposing APIs for that.
3) In general many WebView apps aren't prepared for potentially-breaking changes to web-facing behaviour like this one, and the developers of those apps might not be participating in the larger web ecosystem in a way that would give them any visibility into these kinds of upcoming changes. This is not to say that we shouldn't make this change for WebView, but it may be riskier.
4) WebView's useragent string format is prescribed by Android's Compatibility Definition Document (CDD) and Compatibility Test Suite (CTS). We can't ship changes to WebView that would violate the rules set out in CDD/CTS unless we first update them, which in almost all cases is only permitted for *future* versions of Android not yet released, and can't be changed retroactively unless it's to fix actual errors in the definitions/tests. Freezing most aspects of the UA at their current values without changing the format would not violate the current implementation of CDD/CTS, with one exception: the Android version is expected to be the same value that's exposed to Android apps in general (i.e. something like "Android 5.1" - not a specific build ID or anything, just the "marketing" version number of the OS).
5) There's been past discussion about removing the Android device model name from the UA for either/both of WebView and Chrome on Android, but last I checked this hasn't been resolved. Will the freezing proposal have any impact on this?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAEV-rjf-bMK9sUqYgZ8PQ1V2GH8EeFChMEJ7w_JnUnoJqgfFng%40mail.gmail.com.
From a light reading, this seem detrimental to the "Chromium forks". There are many rebrandings of "Chromium" (Edge and Opera being some of the more prominent examples) that we simply ignore and use the Chromium versioning. It seems, as I've read it, to force browsers forks to masquerade as Chrome if they can't be recognized as part of the Chromium family. Did I miss something that would allow this grouping of "families"? Generally, server side rendering requires a reasonable user-agents identification.
I'm also concerned that "freezing" the UA prevents folks from getting the feedback that you need to validate that you have solved the right problems (as nothing is broken "today").
--
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/7b2fd069-ab61-4257-bc8c-0b5d73a6bb1e%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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/62082d91-ce30-4455-806a-0b68eee531ab%40chromium.org.
A second roundtrip to get more information is definitely a performance issue especially with high latency times. From our perspective the platform e.g. win or macos would be helpful as default information as certain things behaves differently on the platform. Just to make a very simple example tooltips/menu entries for hotkeys (like ctrl+s) are differently on a mac or win (ctrl vs. cmd key) and already part from server in the first roundtrip.
Depending whether the frozen UserAgent string and JS interface remains it is highly incompatible and would result especially for enterprise customer to upgrade the complete landscape. 3 months are maybe enough to implement but not to update a large onprem landscape with hundreds of mission critical servers. We currently have this issue with the dismissal of syncXHR.Enough time between releasing the new interface and deprecation of the old behavior would be necessary to give enterprise customers enough time to upgrade their systems or like in the syncXHR a possibility to opt-in the user-agent via flag and group policy
--
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/98bb9c26-91c5-47b6-8165-dea0b2b4c7aa%40chromium.org.
> 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.
This drawback seems significant and ought to block the release of this feature until it is solved.
Moving fast and breaking things is not the way of the web.
--
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/d7deba3b-2075-4759-81b5-e0c41b944539%40chromium.org.
Apologies if this is the wrong place to post feedback, please point me to somewhere more appropriate if it exists.
I have a few points of feedback:
1. It seems here as if there are still unanswered questions about how to achieve parity with the features provided by the UA like how to get browser version on the first pageload, which seems like a very important use case.
2. The use case of preventing fine grained fingerprinting via CH is a good goal, but can't that be addressed by freezing the UA except for vendor, OS, and version, similar to Safari?
3. The public consensus section seems to indicate that FF and Safari have possibly different approaches in play or in mind, that would be compatible with partial UA freeze but not with CH.
4. The fact that freezing the UA is BC is good, but there's tons of existing material and libraries for parsing UA. Switching browser detection mechanism is a significant piece of churn for the Platform, and thus should come with a big benefit that can't be achieved otherwise.
Taking these points all together, it seems the main benefit of switching to CH over partial UA freeze is "drops legacy bits of text from the string" and "provides better ergonomics for sniffing". Neither of these IMO seem like a high enough bar to introduce a second system here and invalidate all of the existing libraries and documentation on the web. Secondly, it would seem you should solve the "first pageload" problem first.
Thanks for considering these points, and I'm happy to hear counterpoints and be convinced this feature is worth the churn.
--
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/927e2f0a-bbc1-4a2c-9cbe-ea05f59afb78%40chromium.org.
FYI polyfill.io currently serves 38 billion requests per month, which depend on accurately identifying browsers (including minot version) via the UA string.
--
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/d5087dcc-aa14-4907-85c2-085a5ca3b5b5%40chromium.org.
Yoav,Would the freezing of the UA and introduction of Client Hints assist in anyway of combating the fraudulent use of stolen fingerprints? I am assuming that the server requests to the browser for more detailed information which the "illicit" browser would provide would therefore not go towards helping prevent such fraudulent use?If this is the case, are there any plans to help prevent this type of activity?
--
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/4733a289-7417-4c96-8758-ef1578ca2142%40chromium.org.
On Tue, Jan 14, 2020 at 7:26 PM <fer...@gmail.com> wrote:> 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.
This drawback seems significant and ought to block the release of this feature until it is solved.The thought is that the parts that are sent by default (UA brand and meaningful version, as well as most-probably the mobileness bit) would be sufficient for most cases of UA based content negotiation to not require any delays.Do you have common use-cases where this information will not be sufficient?
On Wed, Jan 15, 2020 at 9:42 PM Yoav Weiss <yo...@yoav.ws> wrote:On Wed, Jan 15, 2020 at 11:45 AM Philip Jägenstedt <foo...@chromium.org> wrote:I'm glad to see an effort towards freezing the UA string and finding alternatives. UA sniffing is at the root of countless web compat issues and these disproportionately affect browsers the developer didn't test in or think about.At the same time, this header has been evolving and mutating since Mosaic, and freezing it is bound to have effects all across the ecosystem and cause a lot of frustration. I'd like to see some of the risks explored more. Some concrete concerns:This depends on Intent to Ship: Client Hints infrastructure and UA Client Hints, but even if that ships first I don't think we can be confident that this alternative will be sufficient. Would it not be more prudent to ship that first, and work with a number of real sites to see what kind of issues come up?It certainly would be more prudent. The urgency comes from the fact that right now, we are broadcasting a lot of information about our users, in clear text, to all servers. We would like to stop doing that.Our assumption was that 4 releases (between shipping UA CH and unifying the UA string) would be enough time for us to make sure the replacement is sufficient before pulling the plug on the legacy string.It could be enough time to show that migrating is possible in most scenarios before the UA string freezes, but it would also be unsurprising if trying to migrate a real-world complex case will reveal a number of issues that need to be resolved. Before we have confidence in CH as a replacement, I don't think we should be deciding on a timeline or communicating dates for UA freezing to web developers.That's not going to shake out some of the long tail issues, but would reveal any common problems. Seeing other vendors adopt UA Client Hints would also help a lot.I agree that other vendors adopting would help. Unfortunately, Mozilla don't seem to be interested in implementing the CH part. I've asked Apple to re-review, so one can remain hopeful.Paging +Michael Taylor to clarify the linked issue. Would Mozilla consider freezing the UA string and only provide the same information via JS APIs? That seems pretty risky to me...The timeline for this seems a fair bit too short given that it's a non-trivial change and can span multiple layers of software, and so need trickle through multiple planning and release cycles. What are the tradeoff of letting this bake 6 months vs. 1 year, say? (Chrome 99 around mid-2022 seems like an upper bound because Chrome 100 will very likely break some sniffing code, just like how Opera's UA string got stuck at 9.)Letting this bake for a year would mean continuing to send user information, in the clear, to all servers, for 6 more months.Yes, it's 6 more months, but what is the tradeoff? How bad for users is the UA string vs. how many sad developers and broken sites? I get there's no exact answer, but the impact on the ecosystem looks like the more concrete risk.
It should also give us pause if other vendors aren't planning to freeze their UA strings, it calls the urgency into question.
Showing a deprecation message on 90% of page views is a lot. Sites will likely keep accessing navigator.userAgent if they've determined nothing will break, or they'd have to use another form of sniffing to avoid it. (I have found UA sniffing to avoid triggering deprecate messages in past httparchive digging.)If they'd use `getUserAgent()` for that, that's a win, no? :DHow essential is it to have this message? It looks like Safari doesn't have a console warning.We want to let developers know that the API they are using is about to become useless and move them to the new API. Are there other tools that fit that purpose other than console warnings?To spell out the concern, it is about warning fatigue. However, I have to agree that if we commit to a timeline, then we'll have to broadcast this very widely. A lot of the usage won't be practical to remove, however, so it would have to be for a limited time.
On Fri, Jan 17, 2020 at 11:56 AM Yoav Weiss <yo...@yoav.ws> wrote:On Tue, Jan 14, 2020 at 7:26 PM <fer...@gmail.com> wrote:> 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.
This drawback seems significant and ought to block the release of this feature until it is solved.The thought is that the parts that are sent by default (UA brand and meaningful version, as well as most-probably the mobileness bit) would be sufficient for most cases of UA based content negotiation to not require any delays.Do you have common use-cases where this information will not be sufficient?Learning about such use cases would be valuable, but I don't think we can assume the change to be safe in the absence of such examples. And at the scale we're talking about, usage doesn't need to be common to pose a serious compat problem.
Given that use counters will fail us here, some different form of compat analysis is needed. https://gist.github.com/foolip/38e3ea6f060bad4638c2aea6fac63e80 is an example of what this might look like, there varying the Accept-Language header and looking at how the result varies.
Rough sketch of what it might look like for the UA header, in line with Blink principles of web compatibility:
- Crawl the same sites with multiple forms of the UA header
- Identify the sites where some of the responses vary (could also compare code paths taken and rendering)
- Confirm the differences by re-crawling to reduce noise
- Look at a sample of the candidate sites, assessing the severity to users and the difficulty to fix for users
This is time consuming, but it's what it will take to understand the risk.
On Thu, Jan 16, 2020 at 4:22 PM Philip Jägenstedt <foo...@chromium.org> wrote:On Wed, Jan 15, 2020 at 9:42 PM Yoav Weiss <yo...@yoav.ws> wrote: