To be clarify, currently David is not working on the standardizing ALPS feature.
On Tuesday, January 23, 2024 at 11:27:41 AM UTC-5 Victor Tan wrote: > Hi Erik, > We are actively working on it, but we need to put more efforts to > standardization. > In the last serval IETF, David is the only person is talking about the > ALPS feature. We'd glad to combine more efforts to move it forward to > standardization. > > Bests, > Victor > > On Monday, January 22, 2024 at 5:24:25 PM UTC-5 Erik Anderson wrote: > >> Is the ALPS draft being actively worked on? >> >> >> >> Various teams at Microsoft that own web sites leveraging client hints >> have expressed interest in using it, but the lack of a finalized standard >> has significantly slowed conversations with the teams that own the server >> code that would need to add support first. >> >> >> >> Are you looking for help in moving standardization forward? >> >> >> >> *From:* Yoav Weiss (@Shopify) <yoav...@chromium.org> >> *Sent:* Monday, January 22, 2024 7:39 AM >> *To:* Victor Tan <vict...@chromium.org> >> *Cc:* blink-dev <blin...@chromium.org>; Chris Harrelson < >> chri...@chromium.org>; David Benjamin <davi...@chromium.org>; Mike >> Taylor <mike...@chromium.org> >> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point >> >> >> >> Is the old code point defined somewhere? Would it be possible to add such >> a definition to one of the I-Ds? Or is this something that's not >> traditionally defined in IETF drafts? >> >> >> >> On Mon, Jan 22, 2024 at 4:03 PM Victor Tan <vict...@chromium.org> wrote: >> >> Currently, It's on the code: >> https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247 >> >> Once we standardize the ALPS RFC draft, we can finalize the value. Hope >> this helps. >> >> On Saturday, January 20, 2024 at 7:50:46 PM UTC-5 Chris Harrelson wrote: >> >> Thanks for clarifying. Last question: where in the specifications is the >> new 17613 code point documented? >> >> >> >> On Fri, Jan 19, 2024 at 12:59 PM Mike Taylor <mike...@chromium.org> >> wrote: >> >> In our OWNERS meeting this week, there was some confusion on what's being >> proposed here (which is understandable, this isn't quite a typical intent >> for web exposed feature). Here's a summary of what we're trying to >> accomplish: >> >> 1) We shipped support for the ACCEPT_CH frame over h2 and h3 back in M96, >> which relies on the TLS ALPS protocol extension. >> 2) There are 2 parts to this: the client being able to understand >> ALPS/ACCEPT_CH (and in return do something useful), and the server being >> able to send it. >> 3) Because of a (long fixed) bug present in Chromium's implementation, >> it's risky for a server to send too much data via ACCEPT_CH, so it's >> usefulness is potentially limited. >> 4) In order to guarantee that older clients don't have this bug, we >> propose to rev the version (aka, code point) at the protocol layer. This >> way, if a server sends the new code point and the client understands it, it >> can send a larger payload without triggering the bug (which may result in >> sad things like a connection being refused). >> 5) This is sort of web observable, but right now if servers that support >> the old code point continue to send the old code point - nothing will >> break. Chromium will support both for now, with hopes to deprecate and >> remove the older one in the future when we're confident it won't result in >> performance regressions for servers sending ACCEPT_CH (since this is a >> performance optimization). >> >> I hope that helps clear it up, and I'm sure Victor or David will chime in >> if I'm getting something wrong. :) >> >> And to be clear - this isn't a request for a deprecation or removal >> (yet), but for shipping the new code point. >> >> On 1/17/24 11:16 AM, Victor Tan wrote: >> >> If the server received the new code point, while it doesn't support, the >> ALPS extension will ignore. This also mean client might not know the >> server's client hints preferences before the first request. Currently, only >> few sites using the ALPS extension. As TLS extension is negotiated, the >> server need to support both code points during the transition period, after >> some time, the server can drop the old one. >> >> >> >> On Wednesday, January 17, 2024 at 11:00:13 AM UTC-5 Yoav Weiss wrote: >> >> On Saturday, January 13, 2024 at 12:08:33 AM UTC+1 Victor Tan wrote: >> >> *Contact emails* >> >> vict...@chromium.org, mike...@chromium.org, davi...@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. >> >> >> >> Does the server have an indication if the client in question supports the >> newer code point? >> >> If not, what would we expect servers that support the newer code point to >> do? >> >> >> >> >> >> >> >> *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+...@chromium.org. >> >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org?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 blink-dev+...@chromium.org. >> >> To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJQu%2BjtN9hQ302XVW1_Y1b8BUYQUDr4ujMavPU1vU7%2Bzw%40mail.gmail.com >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJQu%2BjtN9hQ302XVW1_Y1b8BUYQUDr4ujMavPU1vU7%2Bzw%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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbfcefbb-637e-428b-9ca2-3c879e2af1e2n%40chromium.org.
