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 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
<https://docs.google.com/document/d/1igtMPtVTiX24bVaUo6tBgx3B16-HmUVPG7iDP5HkzD0/edit>
Specification
https://wicg.github.io/client-hints-infrastructure/
<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
<https://crbug.com/1227043>
Link to entry on the
Chrome Platform Status
https://chromestatus.com/feature/5694492182052864
<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>.
