LGTM3 Thanks for following up on this!!
On Wed, May 11, 2022 at 5:50 PM Philip Jägenstedt <[email protected]> wrote: > LGTM2 > > While usage going up > <https://chromestatus.com/metrics/feature/timeline/popularity/837> 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! > > On Wed, May 11, 2022 at 5:44 PM Daniel Bratell <[email protected]> > wrote: > >> LGTM1 >> >> /Daniel >> On 2022-05-10 23:32, Ari Chivukula wrote: >> >> 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 >> <https://docs.google.com/document/d/1igtMPtVTiX24bVaUo6tBgx3B16-HmUVPG7iDP5HkzD0/edit#heading=h.9km75afvbmv> >> has been updated) >> >> On Mon, May 2, 2022 at 1:35 PM Ari Chivukula <[email protected]> >> wrote: >> >>> 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) >>> >>> >>> On Fri, Apr 8, 2022 at 8:01 AM Ari Chivukula <[email protected]> >>> wrote: >>> >>>> 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 < >>>> [email protected]> wrote: >>>> >>>>> Thank you for the ping Eric. >>>>> For ImageEngine <https://imageengine.io/>, 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 [email protected] >>>>> wrote: >>>>> >>>>>> 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) >>>>>> >>>>>> >>>>>> On Thu, Apr 7, 2022 at 2:28 PM Eric Portis <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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 >>>>>>> <https://teams.googleplex.com/u/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 >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thursday, March 24, 2022 at 1:22:14 PM UTC-7 [email protected] >>>>>>> wrote: >>>>>>> >>>>>>>> @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 <https://blog.cloudflare.com/early-hints/>, >>>>>>>> ImageKit <https://docs.imagekit.io/features/client-hints>, ImgIX >>>>>>>> <https://docs.imgix.com/tutorials/responsive-images-client-hints>, >>>>>>>> KeyCDN <https://www.keycdn.com/blog/client-hints>, and Peakhour >>>>>>>> <https://www.peakhour.io/docs/responsive-design/client-hints/> but >>>>>>>> haven't heard from them on this thread. >>>>>>>> >>>>>>>> ~ Ari Chivukula (Their/There/They're) >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Mar 12, 2022 at 2:32 PM Ari Chivukula <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> 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) >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Mar 11, 2022 at 10:54 AM Eric Portis <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> 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. >>>>>>>>>> On Wednesday, March 9, 2022 at 11:39:40 AM UTC-8 >>>>>>>>>> [email protected] wrote: >>>>>>>>>> >>>>>>>>>>> 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 >>>>>>>>>>> <https://blog.cloudflare.com/early-hints/>, Cloudinary >>>>>>>>>>> <https://cloudinary.com/blog/client_hints_and_responsive_images_what_changed_in_chrome_67> >>>>>>>>>>> , ImageKit <https://docs.imagekit.io/features/client-hints>, >>>>>>>>>>> ImgIX >>>>>>>>>>> <https://docs.imgix.com/tutorials/responsive-images-client-hints> >>>>>>>>>>> , KeyCDN <https://www.keycdn.com/blog/client-hints>, and >>>>>>>>>>> Peakhour >>>>>>>>>>> <https://www.peakhour.io/docs/responsive-design/client-hints/> 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) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Mar 9, 2022 at 5:49 AM Daniel Bratell <[email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> 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 >>>>>>>>>>>> On 2022-03-07 16:56, Ari Chivukula wrote: >>>>>>>>>>>> >>>>>>>>>>>> Fixing the subject prefix, apologies. >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Mar 7, 2022 at 7:54 AM Ari Chivukula < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Contact emails >>>>>>>>>>>>> >>>>>>>>>>>>> [email protected], [email protected], >>>>>>>>>>>>> [email protected] >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> <https://wicg.github.io/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 >>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/JQ68cvYuiQU/m/bFjAWmy3AAAJ> >>>>>>>>>>>>> is now available to allow delegation via HTML instead of HTTP >>>>>>>>>>>>> headers. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Blink component >>>>>>>>>>>>> >>>>>>>>>>>>> Blink>Network>ClientHints >>>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> <https://w3c.github.io/webappsec-permissions-policy/#serialization> >>>>>>>>>>>>> or HTML >>>>>>>>>>>>> <https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit> >>>>>>>>>>>>> delegation of client hints. The design doc >>>>>>>>>>>>> <https://docs.google.com/document/d/1igtMPtVTiX24bVaUo6tBgx3B16-HmUVPG7iDP5HkzD0/edit> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> <https://mozilla.github.io/standards-positions/#http-client-hints> >>>>>>>>>>>>> ) >>>>>>>>>>>>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>> 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 [email protected]. >>>>>>>>>>>> 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 >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGpy5DJdHT1P-Dg%3DgmbkmA3K-HuDhg%3D1a0tVfv9c9g6wBHGCVg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>>> . >>>>>>>>>>>> >>>>>>>>>>>> -- >> 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 [email protected]. >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0f76e42f-d0f4-d43d-36aa-0907f8701e79%40gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 [email protected]. > 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 > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYcqmAjrWyhCWVcLiOJ-faL4Bef5ahbA%2Bu5ZyKqxENwoNw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVLz0zgCsbmLxHv%3DR49tsU9GayLeCzUDKvGFmWxjU8R%3Dw%40mail.gmail.com.
