Contact emails victor...@chromium.org, miketa...@chromium.org, david...@chromium.org
Explainer https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md Specification https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability https://tools.ietf.org/html/draft-vvv-httpbis-alps https://tools.ietf.org/html/draft-vvv-tls-alps Summary Shipping a new code point (17613) for TLS ALPS extension to allow adding more data in the ACCEPT_CH HTTP/2 and HTTP/3 frame. The ACCEPT_CH HTTP/2 frame with the existing TLS ALPS extension code point (17513) had an arithmetic overflow bug <https://crbug.com/1292069> in the Chrome ALPS decoder. It limits the capability to add more than 128 bytes data (in theory, the problem range is 128 bytes to 255 bytes) to the ACCEPT_CH frame. With the new ALPS code point, we can fully mitigate the issue. Blink component Blink>Network>ClientHints <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints%2C&can=2> TAG review https://github.com/w3ctag/design-reviews/issues/549 TAG review status Closed Risks Interoperability and Compatibility This is switching to a new code point for the TLS ALPS extension. It won’t change the design of ALPS and ACCEPT_CH mechanism implementation. The main source of compatibility risk is that it causes conflicts with ALPS negotiation since some clients could still use the old code point while others are switching to use the new code point. The ALPS extension could be ignored if the code point doesn’t match during negotiation, which means the server's client hints preferences won’t be delivered in the ACCEPT_CH HTTP/2 and HTTP/3 frame. We mitigate this by enabling servers to support both code points, monitoring both code points usage and removing the old ALPS code point support in a future intent once the usage is low enough. We also split the rollout into two phases: we first start to enable the new ALPS code point for ACCEPT_CH with HTTP/3 frame in a slow rollout, and then eventually enable the new code point with HTTP/2 frame. Edge: No signals Firefox: Pending https://github.com/mozilla/standards-positions/issues/510 Safari: Pending https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html Web/Framework developers: https://twitter.com/Sawtaytoes/status/1369031447940526080 https://twitter.com/_jayphelps/status/1369023028735148032 Activation The site’s TLS and HTTP serving application would need to be updated to support this new code point. We aren’t aware of many sites using this feature yet, however. Debuggability No special DevTools support needed. The effects of the code point change of ACCEPT_CH frame will be visible in the DevTools’ network tab. Also, the NetLog will record the ACCEPT_CH frame value if TLS ALPS extension is negotiated successfully. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? Yes Is this feature fully tested by web-platform-tests <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> ? No, this feature is tested with browser-side tests. We can’t test TLS-adjacent features currently through web-platform-tests. See this issue: https://github.com/web-platform-tests/wpt/issues/20159 Flag name UseNewAlpsCodepointHttp2 UseNewAlpsCodepointQUIC Tracking bug b/289087287 Launch bug https://launch.corp.google.com/launch/4299022 Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5149147365900288 -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/2c1aac5d-163f-44e6-b16d-436bb3ea3c3an%40chromium.org.
