[blink-dev] Intent to Deprecate: Standardize existing client hint naming

90 views
Skip to first unread message

Ari Chivukula

unread,
Nov 2, 2021, 12:14:44 PM11/2/21
to blink-dev

Contact emails

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


Design Doc

https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit

https://docs.google.com/document/d/1X5bEbIZ9U2DQhB_4yWxVuR9rGnnWjAOW-gSdlINbnNU/edit


Specification

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

https://wicg.github.io/responsive-image-client-hints/

https://wicg.github.io/savedata/#save-data-request-header-field

https://wicg.github.io/netinfo/#networkinformation-interface


Summary

Now that our implementation aligns with the Client Hint proposal and the new names for existing client hints with the `sec-ch-` prefix are launched, we should alert web developers to migrate to them. The best way to do this is by introducing a new Client Hints DevTool issue.


Blink component

Privacy>Fingerprinting


Motivation

Client Hints, a method to request information about the user's device or conditions, have been implemented in Chrome, but since the initial implementation the naming scheme has changed. If implemented, this proposal would alert developers using `dpr`, `width`, `viewport-width`, and `device-memory` to migrate to use `sec-ch-dpr`, `sec-ch-width`, `sec-ch-viewport-width`, and `sec-ch-device-memory` respectively. The three network related client hints with legacy names, `rtt`, `downlink`, and `ect`, will not be updated as they may be replaced by different hints in an independent process.


TAG review

Not needed


Risks

Only Blink implements client hints and we are not (yet) removing any current ones, just pushing developers to use the corrected names. If usage permits, we will remove the legacy names down the line in another intent.

 

Interoperability and Compatibility

Gecko: No official position; mild positive signals.

Firefox: UA Client hints considered non-harmful

Web developers: Positive interest from Cloudinary


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

N/A (the issues tab isn’t in other browsers)


Tracking bug

https://crbug.com/1227043


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/6658223894429696


Jeffrey Yasskin

unread,
Nov 2, 2021, 12:24:42 PM11/2/21
to Ari Chivukula, blink-dev
On Tue, Nov 2, 2021 at 9:14 AM Ari Chivukula <ari...@chromium.org> wrote:

Contact emails

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


Design Doc

https://docs.google.com/document/d/1yhVLyEIpDhhDQf698WkvXBiPcLwxEgCBI4o1FjvXwfM/edit

https://docs.google.com/document/d/1X5bEbIZ9U2DQhB_4yWxVuR9rGnnWjAOW-gSdlINbnNU/edit


Specification

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

https://wicg.github.io/responsive-image-client-hints/

https://wicg.github.io/savedata/#save-data-request-header-field

https://wicg.github.io/netinfo/#networkinformation-interface


Summary

Now that our implementation aligns with the Client Hint proposal and the new names for existing client hints with the `sec-ch-` prefix are launched, we should alert web developers to migrate to them. The best way to do this is by introducing a new Client Hints DevTool issue.


Blink component

Privacy>Fingerprinting


Motivation

Client Hints, a method to request information about the user's device or conditions, have been implemented in Chrome, but since the initial implementation the naming scheme has changed. If implemented, this proposal would alert developers using `dpr`, `width`, `viewport-width`, and `device-memory` to migrate to use `sec-ch-dpr`, `sec-ch-width`, `sec-ch-viewport-width`, and `sec-ch-device-memory` respectively. The three network related client hints with legacy names, `rtt`, `downlink`, and `ect`, will not be updated as they may be replaced by different hints in an independent process.


TAG review

Not needed


Risks

Only Blink implements client hints and we are not (yet) removing any current ones, just pushing developers to use the corrected names. If usage permits, we will remove the legacy names down the line in another intent.

 

Interoperability and Compatibility

Gecko: No official position; mild positive signals.


Note that this is Webkit rather than Gecko. :)
 

Firefox: UA Client hints considered non-harmful

Web developers: Positive interest from Cloudinary


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

N/A (the issues tab isn’t in other browsers)


Tracking bug

https://crbug.com/1227043


Link to entry on the Chrome Platform Status

https://www.chromestatus.com/feature/6658223894429696


--
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/CAGpy5DJq4f6LvkROvh83M%3D%2Bd85DMBYdS05ofjKj4VyRFtuGh4w%40mail.gmail.com.

Yoav Weiss

unread,
Nov 2, 2021, 12:30:27 PM11/2/21
to Jeffrey Yasskin, Mathias Bynens, Ari Chivukula, blink-dev
We were traditionally not excited about deprecations without removals, as we didn't want to fatigue developers with spammy deprecation messages that'd then reduce their tendency to pay attention.
I wonder if the move to DevTools issues should change that calculus though.

+Mathias Bynens for opinions. 

Daniel Bratell

unread,
Nov 10, 2021, 4:02:52 PM11/10/21
to Yoav Weiss, Jeffrey Yasskin, Mathias Bynens, Ari Chivukula, blink-dev

We discussed this at the API Owners meeting and we did not see that the move to a special tab in devtools changes the how to look at deprecations of an indeterminate length.

The problem with deprecations of an indeterminate length is two-fold:

* They can be around for a long time which will contribute to "warning fatigue" which makes developers in general less likely to notice the information we give them.

* Without a set date, it becomes hard for a developer to know when to act, and the result can be that they don't act at all which reduces the value of the warning.

/Daniel

Reply all
Reply to author
Forward
0 new messages