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

[Ari Chivukula]

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]

Fixing the subject prefix, apologies.

[Daniel Bratell]

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]

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, Cloudinary, ImageKit, ImgIX, KeyCDN, 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]

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]

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]

@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 Cloudflare, ImageKit, ImgIX, KeyCDN, and Peakhour but haven't heard from them on this thread.

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

[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]

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]

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]

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]

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]

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]

LGTM1

/Daniel

[Philip Jägenstedt]

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!

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.

[Yoav Weiss]

LGTM3

Thanks for following up on this!!

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.

[Joe Medley]

Hi,

In which version do you intend to remove this?

Joe

[Ari Chivukula]

M104

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