LGTM2 On Mon, Feb 5, 2024 at 5:38 PM Yoav Weiss (@Shopify) <yoavwe...@chromium.org> wrote:
> LGTM1 > > Thanks for including these values in the I-D. > > On Fri, Feb 2, 2024 at 9:17 PM Victor Tan <victor...@chromium.org> wrote: > >> the code point PR is merged. Feel free to take a look again. Thanks. >> >> On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan wrote: >> >>> create a PR for the code point change on the RFC draft, will work on >>> there: https://github.com/vasilvv/tls-alps/pull/15, thanks. >>> >>> On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik Anderson wrote: >>> >>>> Thanks, it will be helpful to make sure this is documented outside of >>>> Chromium. I will also chat with some folks on Microsoft’s end that both own >>>> server implementations and have more IETF experience to explore how we can >>>> help with moving things forward. >>>> >>>> >>>> >>>> *From:* Victor Tan <victor...@chromium.org> >>>> *Sent:* Wednesday, January 24, 2024 9:00 AM >>>> *To:* blink-dev <blink-dev@chromium.org> >>>> *Cc:* Yoav Weiss <yoavwe...@chromium.org>; blink-dev < >>>> blink-dev@chromium.org>; Erik Anderson <erik.ander...@microsoft.com>; >>>> Chris Harrelson <chris...@chromium.org>; David Benjamin < >>>> david...@chromium.org>; Mike Taylor <miketa...@chromium.org>; Victor >>>> Tan <victor...@chromium.org>; Rick Byers <rby...@chromium.org> >>>> *Subject:* Re: [blink-dev] Re: Intent to Ship: New ALPS code point >>>> >>>> >>>> >>>> You don't often get email from victor...@chromium.org. Learn why this >>>> is important <https://aka.ms/LearnAboutSenderIdentification> >>>> >>>> Rick, thanks for question, I will create a PR on the ALPS RFC draft to >>>> document the new code point regarding the early experiment. >>>> >>>> On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5 Yoav Weiss wrote: >>>> >>>> On Wed, Jan 24, 2024 at 4:48 PM Rick Byers <rby...@chromium.org> wrote: >>>> >>>> Oof, I agree it's not good that the only documentation for the actual >>>> code point value is in Chromium code - that's the sort of thing our blink >>>> I2S process is supposed to prevent. In addition to confusion, there's also >>>> potential IP-risk downsides to this. Our blink process is generally to >>>> block shipping on the existence of some specification for everything >>>> necessary for a compatible implementation in a forum that ensures IP >>>> protection. While this isn't typically an adoption barrier for many >>>> companies, I know it has been in the past for some (including Microsoft). >>>> This doesn't mean we have to block on getting consensus in the "right" >>>> standards venue, we can just do a monkey-patch spec in a venue like the >>>> WICG, or an unlanded PR in a formal WG where the PR counts as an IP >>>> contribution. Then we can ship it as an "incubation" while doing the >>>> standards maturation work in parallel. Erik, can you comment on the extent >>>> to which such incubation spec work would help with Microsoft adoption? >>>> >>>> >>>> >>>> Victor, is there any chance you can throw something together quickly >>>> (spec PR or monkey-patch) that would cover the gaps in what's necessary for >>>> compatible implementations? This particular delta seems very tiny and >>>> straightforward to me, so I was originally thinking I'd just approve it. >>>> But in principle I don't think we should be continuing to approve changes >>>> to APIs which we realize are struggling with adoption due to the standards >>>> work not quite being up to our I2S bar. >>>> >>>> >>>> >>>> +1 to defining these codepoints somewhere. Where are such codepoints >>>> typically defined? I'd have assumed they'd go into one of the relevant >>>> I-Ds.. >>>> >>>> >>>> >>>> >>>> >>>> Erik, thank you for your offer of help on the standardization front! It >>>> definitely sounds to me like we should be pushing on the full standards >>>> effort in parallel to this specific intent. Having Microsoft and Google >>>> work together on that would hopefully be able to accelerate it. >>>> >>>> >>>> >>>> Rick >>>> >>>> >>>> >>>> >>>> >>>> On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan' via blink-dev < >>>> blink-dev@chromium.org> wrote: >>>> >>>> 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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbfcefbb-637e-428b-9ca2-3c879e2af1e2n%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+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B5KAs3j9izP4t1p%2B9cPAkQ_PJ1ffuWHxMnL08P60EmVw%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B5KAs3j9izP4t1p%2B9cPAkQ_PJ1ffuWHxMnL08P60EmVw%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/CAM0wra8zuWnfXL_NP11_sE2GC97%2BA%2BPet4ywvzT1fzqPZsXjeA%40mail.gmail.com.