One residue of the rapid Client Hints Infrastructure iteration is the concept of a `legacy` client hint. It’s a set of 4 hints (`dpr`, `width`, `viewport-width`, and `device-memory`) which have a default allowlist of `self` (meaning that they are not sent to third-party subresources unless delegated via Permissions Policy) but behave as though they have a default allowlist of `*` (meaning they are sent to third-party subresources as long as the first-party page requests them) on Android.
This `legacy` client concept on Android will be removed and a permissions policy will be required to delegate the 4 affected hints. As of M100, Markup based Client Hint Delegation is now available to allow delegation via HTML instead of HTTP headers.
We want to bring these 4 hints in line with the spec; fixing this will increase privacy on Android by requiring explicit delegation of these hints.
N/A (this change brings Android behavior in line with the spec and better preserves privacy)
Websites visited by android devices that request the legacy device-memory, dpr, width, and viewport-width would no longer have these hints delegated by default to third-party subresources. This would match the current behavior on desktop. Third-party subresources which need these hints would need to get the first-party that loads them to adopt HTTP or HTML delegation of client hints. The design doc has usage/top-site information, and outreach is underway to ensure third-parties expecting this information are aware of the change. The sites which require default third-party delegation of these hints are likely much lower than the sites which incidentally do so by default. As we encourage Client Hint adoption, we want to ensure dependency doesn’t form on legacy, non-compliant behavior.
Gecko: Client Hints not yet implemented (considered non-harmful)
WebKit: Client Hints not yet implemented
Web developers: No feedback yet
Is this feature fully tested by web-platform-tests?
New WPT will be added to ensure these hints are not delegated by default.
Link to entry on the Chrome Platform Status
How can we get a good grip on the web compatibility of this change? The use counters are a high, but as you point out, the number of sites that actually depend on the legacy client hints is lower. The question is just "how much lower?".
You listed a number of affected sites. Has anyone checked what happens to those with the hints removed?
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/CAGpy5DJdHT1P-Dg%3DgmbkmA3K-HuDhg%3D1a0tVfv9c9g6wBHGCVg%40mail.gmail.com.
Thank you for the ping Eric.For ImageEngine, the impact of removing the legacy delegation behaviour of dpr, width, viewport-width, and device-memory will be minor as ImageEngine has fallback mechanisms that will limit any negative impact.The challenge is more about how to communicate this to the users. Specifically, a clear migration path to "reenable" client hints. The recent support for markup based delegation will help a lot of course. Also, as another motivation to make the change, it would be interesting to know when the legacy key names dpr, width, viewport-width, and device-memory will not be supported anymore. I mean, fully replaced by the sec-ch- prefixed variants launched in M97.
Hi API Owners,
The goal of this intent is to remove the `legacy mode` behavior of four client hints (device-memory, dpr, width, and viewport-width). This `legacy mode`, only active on Android, auto-delegates client hints to third-party subresources if the first party requests the hint at all. This auto-delegation bypasses permissions policies, and we think it should be removed. Although usage of the four affected client hints has spiked in recent months (viewport-width is sent on 3% of chrome requests) we don’t have a good sense of how many requests depend on this Android-only auto-delegation behavior as any dependency lives server-side on third-party resources. I tried loading the top five hosts which receive each of these client hints on mobile and did not notice any issues when the `legacy mode` behavior was disabled.
To get a high-level sense of the impact removing `legacy mode` could have on common third-party subresource providers we reached out to six CDNs and asked for their input: Cloudinary, ScientiaMobile, CloudFlare, Akamai, Imagix, and Fastly. Cloudinary requested a quarter or two to mitigate any impact and communicate to their customers (M104 in Q3 was sufficient given notice in Q1); ScientiaMobile, CloudFlare, and Akamai did not anticipate impact or had ways to mitigate; Imagix and Fastly did not reply. The desired change planned for M104 is reversible via finch flag if significant unforeseen issues are encountered, and if none are the full codepath removal would be slated for M107.
Given this, I believe this intent is ready for your consideration again.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0f76e42f-d0f4-d43d-36aa-0907f8701e79%40gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcqmAjrWyhCWVcLiOJ-faL4Bef5ahbA%2Bu5ZyKqxENwoNw%40mail.gmail.com.