[webkit-dev] Intent to Remove: Legacy Client Hint Mode

269 views
Skip to first unread message

Ari Chivukula

unread,
Mar 7, 2022, 10:54:29 AMMar 7
to blink-dev, Jade Kessler, Mike Taylor

Contact emails

ari...@chromium.org, jadek...@chromium.org, mike...@chromium.org


Design Doc

https://docs.google.com/document/d/1igtMPtVTiX24bVaUo6tBgx3B16-HmUVPG7iDP5HkzD0/edit


Specification

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


Summary

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.

 

Blink component

Blink>Network>ClientHints

 

Motivation

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.


TAG review

N/A (this change brings Android behavior in line with the spec and better preserves privacy)


Compatibility

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.

 

Interoperability

Gecko: Client Hints not yet implemented (considered non-harmful)

WebKit: Client Hints not yet implemented

Web developers: No feedback yet


Debuggability

N/A


Is this feature fully tested by web-platform-tests?

New WPT will be added to ensure these hints are not delegated by default.


Tracking bug

https://crbug.com/1227043


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5694492182052864



Ari Chivukula

unread,
Mar 7, 2022, 10:57:11 AMMar 7
to blink-dev, Jade Kessler, Mike Taylor
Fixing the subject prefix, apologies.

Daniel Bratell

unread,
Mar 9, 2022, 8:49:29 AMMar 9
to Ari Chivukula, blink-dev, Jade Kessler, Mike Taylor

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?

/Daniel

--
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.

Ari Chivukula

unread,
Mar 9, 2022, 2:39:40 PMMar 9
to Daniel Bratell, blink-dev, Jade Kessler, Mike Taylor
I haven't had issues loading those sites on Firefox mobile (which doesn't have client hints), but haven't specifically tried loading them on Chrome Android w/o hints enabled. It's true that we're betting on lower dependency given this change only affects Chrome on Android (where the default delegation was enabled), but it's worth asking a few CDNs to see if this was a feature being depended on that HTTP Archive isn't surfacing.

Is there a good way to reach out to them? I can see documentation from Cloudflare, CloudinaryImageKit, ImgIXKeyCDN, and Peakhour in search results. I could try tagging some of them in a GitHub issue but wasn't sure if there's a better way to reach a wider audience.

~ Ari Chivukula (Their/There/They're)

Eric Portis

unread,
Mar 11, 2022, 1:54:53 PMMar 11
to blink-dev, ari...@chromium.org, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell
Speaking on behalf of Cloudinary:

- We've started treating the modern hints the same as the legacy hints, server-side
- We've identified which customers who are sending us legacy hints and are working on an outreach plan

It would be nice to have:

- some certainty about the new HTML syntax. Is it likely to change after TAG review or other-implementer feedback?
- a clear switch-off-date at least a quarter (or two!) out from the final modernized syntax shipping.

Basically what we'd like to communicate is a clear action item with a non-panicky due date, with some assurance of finality after customers make (and are able to test) the change.

Ari Chivukula

unread,
Mar 12, 2022, 5:33:12 PMMar 12
to Eric Portis, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell
The modern syntax (I assume you mean third-party delegation of client hints via HTML) is shipping in M100 (stable release at the end of March). There isn't a plan to remove any existing client hint names.

The question here is whether any websites are depending on dpr, width, viewport-width, or device-memory being auto-delegated to all third party sites when requested by a first party on Android. That's the legacy behavior that's being proposed for removal (ideally with M102).


~ Ari Chivukula (Their/There/They're)

Ari Chivukula

unread,
Mar 24, 2022, 4:22:14 PMMar 24
to Eric Portis, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell
@Eric Portis I wanted to get a sense of whether this narrow change (not delegating to third-parties by default for dpr, width, viewport-width, and device-memory on Android) would pose an issue for Cloudrinary and ask if you had contacts I could reach out to at other CDNs. I saw potential use from CloudflareImageKitImgIXKeyCDN, and Peakhour but haven't heard from them on this thread.

~ Ari Chivukula (Their/There/They're)

Eric Portis

unread,
Apr 7, 2022, 5:30:10 PMApr 7
to blink-dev, ari...@chromium.org, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell, Eric Portis
We have a non-trivial amount of usage which is relies on the legacy delegation behavior. We are working on outreach to will-be-affected customers, alerting them to the change and trying to get them to switch over to the new syntax. In at least a couple of cases the teams/devs that implemented Cloudinary + Client Hints originally are long gone, which makes things difficult... I think the most helpful thing for us would be a clear switch-off deadline for the legacy behavior, at least a quarter or two out, so that we can give customers a reason to make the change (but not panic about it).

I know a couple of Cloudflare folks have been active in standards discussions, and Jon Arne Sæterås at ScientaMobile has been an active participant in a few Client Hints discussions, specifically. I'll ping them on Twitter.

Eric Portis
Cloudinary

Ari Chivukula

unread,
Apr 7, 2022, 5:33:53 PMApr 7
to Eric Portis, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell
Right now it's on track for M103, which has a branch cut in May and a release in June. I have no issue pushing this back to M104 (branch in June and release in July) to get a full 3 month buffer.

Thanks for the outreach!


~ Ari Chivukula (Their/There/They're)

Ari Chivukula

unread,
Apr 8, 2022, 11:01:54 AMApr 8
to Jon Arne Sæterås, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell, Eric Portis
That's a good question! At the moment there isn't a plan to remove the legacy-named client hints (dpr, width, viewport-width, and device-memory). The messaging around this is a good opportunity to push users to the updated naming (sec-ch-dpr, sec-ch-width, sec-ch-viewport-width, and sec-ch-device-memory) as behavior is now identical, but until usage drops off no action will be taken. I doubt that will change until 2023.

~ Ari Chivukula (Their/There/They're)


On Fri, Apr 8, 2022 at 1:43 AM Jon Arne Sæterås <jon...@scientiamobile.com> wrote:
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.

Jon Arne Sæterås

unread,
Apr 8, 2022, 11:31:11 AMApr 8
to blink-dev, ari...@chromium.org, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell, Eric Portis
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.

On Thursday, April 7, 2022 at 11:33:53 PM UTC+2 ari...@chromium.org wrote:

Ari Chivukula

unread,
May 2, 2022, 4:35:26 PMMay 2
to Jon Arne Sæterås, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell, Eric Portis
We've heard back from Cloudflare and Akamai who don't seem to depend on this legacy Android behavior. This change is currently targeted for M104.

~ Ari Chivukula (Their/There/They're)

Ari Chivukula

unread,
May 10, 2022, 5:33:04 PMMay 10
to Jon Arne Sæterås, blink-dev, Jade Kessler, mike...@chromium.org, Daniel Bratell, Eric Portis

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.


(Note: The summary doc has been updated)

Daniel Bratell

unread,
May 11, 2022, 11:44:44 AMMay 11
to Ari Chivukula, Jon Arne Sæterås, blink-dev, Jade Kessler, mike...@chromium.org, Eric Portis

LGTM1

/Daniel

Philip Jägenstedt

unread,
May 11, 2022, 11:50:39 AMMay 11
to Daniel Bratell, Ari Chivukula, Jon Arne Sæterås, blink-dev, Jade Kessler, mike...@chromium.org, Eric Portis
LGTM2

While usage going up is concerning, I don't think we could improve our understanding of the risk with any additional metrics, since usage is on the server side. Testing of sites that receive the header is the best we can do, and you've tested "the top five hosts which receive each of these client hints on mobile", so given no obvious breakage the risk is likely lower than use counters would suggest.

Ultimately, since these client hints aren't available on all browsers/platforms, I think that hard dependencies on them are unlikely.

Rolling this out with Finch and being ready to revert sounds great. Hope it works out!

Yoav Weiss

unread,
May 17, 2022, 1:20:40 AMMay 17
to Philip Jägenstedt, Daniel Bratell, Ari Chivukula, Jon Arne Sæterås, blink-dev, Jade Kessler, mike...@chromium.org, Eric Portis
LGTM3

Thanks for following up on this!!

Joe Medley

unread,
May 17, 2022, 10:59:47 AMMay 17
to blink-dev, ari...@chromium.org, Jade Kessler, mike...@chromium.org
Hi,

In which version do you intend to remove this?

Joe

Ari Chivukula

unread,
May 17, 2022, 11:19:30 AMMay 17
to Joe Medley, blink-dev, Jade Kessler, mike...@chromium.org
M104


~ Ari Chivukula (Their/There/They're)
Reply all
Reply to author
Forward
0 new messages