Mike or other API Owners, still approved given that this is actually requesting a new OT?
Thanks, jason! On Wednesday, May 29, 2024 at 5:10:54 PM UTC-7 Tsuyoshi Horo wrote: > Ah, sorry for the confusion. > > This request is for the V3 Origin Trial. > > V1 OT was from 117 to 122. > V2 OT was from 122 to 125. > And this V3 OT is from 127 to 129. > > > On Thu, May 30, 2024 at 8:32 AM Patrick Meenan <pme...@chromium.org> > wrote: > >> Sorry, probably some confusion with the process. >> >> This is for the 3rd round of OT on the platform status entry >> (CompressionDictionaryTransportV3) so "extend" may not be the right >> terminology. V1 really ended at 122 and we had the same confusion the last >> time around and the V2 trial was created that went from 123-125 (and is the >> current active trial). >> >> I'll leave it to Tsuyoshi so I don't accidentally break anything, but I >> assume we need to mark the v3 trial as the active stage. >> >> On Wed, May 29, 2024 at 7:16 PM Panos Astithas <past...@google.com> >> wrote: >> >>> Hi Tsuyoshi, >>> >>> Is this a request to extend the V1 OT as it appears in Chromestatus and >>> in the title of this thread or are you trying to create a new V3 trial as >>> it seems to be the intent based on the content of your intent? Note that V1 >>> ended at M125, so teh extension would be for 4 milestones. >>> >>> On Wed, May 29, 2024 at 10:22 AM Mike Taylor <mike...@chromium.org> >>> wrote: >>> >>>> Thanks all. LGTM to extend from 127 to 129 inclusive. >>>> On 5/29/24 10:51 AM, Patrick Meenan wrote: >>>> >>>> On the spec side of things, there is one more issue outstanding in the >>>> IETF discussion but it's not API-impacting and we expect that this latest >>>> draft >>>> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/04/>, >>>> >>>> which this OT implements, has the final API shape. There will be some >>>> tweaks around the edges as we go through the final steps of the RFC >>>> process >>>> but the V3 OT will give sites something to test against that matches what >>>> we expect to ship. >>>> >>>> There are some fairly substantial changes from the previous OT that it >>>> would be useful to get feedback on. In particular, the change to the file >>>> format that embeds the dictionary hash into the file itself instead of >>>> being a separate response header. >>>> >>>> On Wed, May 29, 2024 at 10:37 AM Yoav Weiss (@Shopify) < >>>> yoav...@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> On Wed, May 29, 2024 at 4:31 PM Mike Taylor <mike...@chromium.org> >>>>> wrote: >>>>> >>>>>> Hi there, >>>>>> >>>>>> Would you mind commenting on progress for the following items, per OT >>>>>> renewal guidelines: >>>>>> >>>>> <API owner hat off / feature champion hat on> >>>>> >>>>>> Draft spec (early draft is ok, but must be spec-like and associated >>>>>> with the appropriate standardization venue, or WICG) >>>>>> >>>>> Recently published >>>>> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/> >>>>> with >>>>> above-mentioned changes. >>>>> +Patrick Meenan can probably add precision there, but it's making >>>>> good progress in the HTTPWG. >>>>> >>>>> TAG review (see exceptions) >>>>>> >>>>> https://github.com/w3ctag/design-reviews/issues/877 >>>>> >>>>>> bit.ly/blink-signals requests >>>>>> >>>>> Both Mozilla >>>>> <https://github.com/mozilla/standards-positions/issues/771> and WebKit >>>>> <https://github.com/WebKit/standards-positions/issues/160> are >>>>> positive (with ongoing discussion about some details with Mozilla folks). >>>>> >>>>>> Outreach for feedback from the spec community >>>>>> >>>>> Regular HTTPWG and WebPerfWG engagement. >>>>> >>>>>> WPT tests >>>>>> >>>>> >>>>> https://wpt.fyi/results/fetch/compression-dictionary?label=experimental&label=master&aligned >>>>> >>>>> >>>>>> thanks, >>>>>> Mike >>>>>> On 5/28/24 5:59 AM, Tsuyoshi Horo wrote: >>>>>> >>>>>> Contact emails >>>>>> >>>>>> ho...@chromium.org, pme...@chromium.org, yoav...@chromium.org, >>>>>> kenji...@chromium.org, deno...@chromium.org >>>>>> >>>>>> >>>>>> Explainer >>>>>> >>>>>> https://github.com/WICG/compression-dictionary-transport >>>>>> >>>>>> >>>>>> Specification >>>>>> >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ >>>>>> >>>>>> >>>>>> Design docs >>>>>> >>>>>> >>>>>> https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit >>>>>> >>>>>> https://github.com/WICG/compression-dictionary-transport >>>>>> >>>>>> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/ >>>>>> >>>>>> >>>>>> Summary >>>>>> >>>>>> We are running the second round of the Origin Trial until Chrome 125. >>>>>> The design of the feature has also evolved during the origin trial and >>>>>> RFC >>>>>> process. We’d like to run a third round of the Origin Trial to get more >>>>>> feedback on the updated >>>>>> <https://chromium.googlesource.com/chromium/src/+/d934bf37456735d9bc03107c577804f439f8a986/docs/experiments/compression-dictionary-transport.md#changes-in-m127> >>>>>> >>>>>> design. >>>>>> >>>>>> >>>>>> Blink component >>>>>> >>>>>> Blink>Network >>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork> >>>>>> >>>>>> >>>>>> TAG review >>>>>> >>>>>> https://github.com/w3ctag/design-reviews/issues/877 >>>>>> TAG review status >>>>>> >>>>>> Closed >>>>>> Risks Interoperability and Compatibility >>>>>> >>>>>> Interoperability and Compatibility risk are low. This feature >>>>>> introduces a new compression method for transporting resources over >>>>>> HTTP. >>>>>> Web sites can know the browser support for the new feature by checking >>>>>> `document.createElement('link').relList.supports('compression-dictionary')`. >>>>>> >>>>>> The feature is a negotiation between servers and clients that involves a >>>>>> server specifying that a resource should be used as a dictionary for >>>>>> future >>>>>> requests with a ‘Use-As-Dictionary’ response header. Clients that don’t >>>>>> support the feature will ignore the header and nothing further will >>>>>> happen. >>>>>> >>>>>> This feature is an opt-in feature. And the dictionary storage is >>>>>> isolated using the top level site and the frame origin as the key. That >>>>>> means, if there is no dictionary registered for the site, the behavior >>>>>> of >>>>>> Chrome will not change while browsing the site. Also this feature is >>>>>> only >>>>>> usable within a secure-context so this feature will not increase the >>>>>> risk >>>>>> of having network proxies meddle with the content’s encoding. For >>>>>> enterprises that have deployed HTTPS-intercepting proxies that do not >>>>>> properly handle unknown encodings there is an enterprise policy exposed >>>>>> to >>>>>> disable the feature. The feature is currently enabled only over >>>>>> connections >>>>>> using a well-known trust root for the secure connection which eliminates >>>>>> the risk of security devices and proxies breaking traffic. The roll-out >>>>>> plan for production has steps to remove the trust root restriction and >>>>>> enable support in enterprise environments where intercepting proxies are >>>>>> common. >>>>>> >>>>>> >>>>>> Gecko: Positive ( >>>>>> https://github.com/mozilla/standards-positions/issues/771) >>>>>> >>>>>> >>>>>> WebKit: Positive ( >>>>>> https://github.com/WebKit/standards-positions/issues/160) >>>>>> >>>>>> >>>>>> Web developers: Positive >>>>>> >>>>>> >>>>>> Other signals: >>>>>> >>>>>> >>>>>> Ergonomics >>>>>> >>>>>> To reduce memory usage in network services, dictionary metadata is >>>>>> stored in a database on disk. And to avoid performance degradation for >>>>>> normal requests that do not use a dictionary, the reading of this >>>>>> metadata >>>>>> is designed not to block network requests. In other words, if the >>>>>> reading >>>>>> of metadata from the database is not completed before the request header >>>>>> is >>>>>> ready to be sent to the server, the dictionary may not be used even if >>>>>> it >>>>>> is already registered in the database. >>>>>> >>>>>> >>>>>> >>>>>> Activation >>>>>> >>>>>> To adopt this feature, web developers need to make changes in their >>>>>> web servers or build processes for static resources. Currently there is >>>>>> no >>>>>> major server software which directly supports compression dictionaries. >>>>>> Some CDNs have shared interest in supporting shared dictionary >>>>>> compression >>>>>> (e.g. publicly mentioned >>>>>> <https://blog.cloudflare.com/this-is-brotli-from-origin/#:~:text=One%20development%20that%20we%27re%20particularly%20focused%20on%20is%20shared%20dictionaries%20with%20Brotli.> >>>>>> >>>>>> in a blog post by Cloudflare). >>>>>> >>>>>> >>>>>> >>>>>> Security >>>>>> >>>>>> Chrome registers the response as a dictionary only when the response >>>>>> is CORS-readable from the document origin. Also we use a registered >>>>>> dictionary to decompress the response only when the response is >>>>>> CORS-readable from the document origin. Additionally, the dictionary and >>>>>> the compressed resource are required to be from the same origin as each >>>>>> other. So this should not introduce any new attack vector of information >>>>>> leaks. The dictionaries are partitioned with the storage cache and >>>>>> are cleared whenever cookies or cache is cleared to ensure that the >>>>>> dictionaries can not be abused as a tracking vector. >>>>>> >>>>>> >>>>>> >>>>>> WebView application risks >>>>>> >>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>> that it has potentially high risk for Android WebView-based applications? >>>>>> >>>>>> No >>>>>> >>>>>> >>>>>> Goals for experimentation >>>>>> >>>>>> We would like to collect feedback on the updated API design of >>>>>> Compression Dictionary Transport feature. Also, we would like to >>>>>> continue >>>>>> some experiments using this feature to measure its performance impact. >>>>>> >>>>>> >>>>>> The difference from the previous Origin Trial: >>>>>> >>>>>> - Renamed the link rel attribute for fetching the dictionary from >>>>>> "dictionary" to "compression-dictionary". >>>>>> >>>>>> - Using "dcb" and "dcz" content encoding in place of "br-d" and >>>>>> "zstd-d". The new encodings incorporate the dictionary hash. >>>>>> >>>>>> - Removed the dictionary hash check logic using the >>>>>> "Content-Dictionary" response header, and instead checking the hash >>>>>> within >>>>>> the encoded response body. >>>>>> >>>>>> >>>>>> Ongoing technical constraints >>>>>> >>>>>> None >>>>>> >>>>>> >>>>>> >>>>>> Debuggability >>>>>> >>>>>> We have introduced chrome://net-internals/#sharedDictionary. Using >>>>>> it, web developers can manage the registered dictionaries. Also web >>>>>> developers can check the related HTTP request and response headers >>>>>> (Use-As-Dictionary, Available-Dictionary, Accept-Encoding, >>>>>> Content-Encoding). >>>>>> >>>>>> Any errors in processing responses as a result of dictionary >>>>>> compression issues are reported as issues in Dev Tools. This includes >>>>>> things like dictionary hash mismatches and cors-readability failures. >>>>>> >>>>>> >>>>>> >>>>>> 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/+/main/docs/testing/web_platform_tests.md> >>>>>> ? >>>>>> >>>>>> Yes. https://wpt.fyi/results/fetch/compression-dictionary >>>>>> >>>>>> >>>>>> Flag name on chrome://flags >>>>>> >>>>>> chrome://flags/#enable-compression-dictionary-transport-backend >>>>>> chrome://flags/#enable-compression-dictionary-transport >>>>>> >>>>>> >>>>>> Finch feature name >>>>>> >>>>>> CompressionDictionaryTransportBackend CompressionDictionaryTransport >>>>>> >>>>>> >>>>>> Requires code in //chrome? >>>>>> >>>>>> True >>>>>> >>>>>> >>>>>> Tracking bug >>>>>> >>>>>> https://crbug.com/1413922 >>>>>> >>>>>> >>>>>> Launch bug >>>>>> >>>>>> https://launch.corp.google.com/launch/4266286 >>>>>> >>>>>> >>>>>> Estimated milestones >>>>>> >>>>>> OriginTrial desktop last >>>>>> >>>>>> 129 >>>>>> >>>>>> OriginTrial desktop first >>>>>> >>>>>> 127 >>>>>> >>>>>> >>>>>> OriginTrial Android last >>>>>> >>>>>> 129 >>>>>> >>>>>> OriginTrial Android first >>>>>> >>>>>> 127 >>>>>> >>>>>> >>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>> >>>>>> https://chromestatus.com/feature/5124977788977152 >>>>>> >>>>>> >>>>>> Links to previous Intent discussions >>>>>> >>>>>> Intent to prototype: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/-qYpLo9DTjw/m/JX6kbUOtBQAJ >>>>>> >>>>>> Intent to experiment: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E/m/oup5DpbxAAAJ >>>>>> >>>>>> Intent to extend Origin Trial: >>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/7YdP2YxRQn4/m/9oPxLDdjAAAJ >>>>>> >>>>>> >>>>>> -- >>>>>> 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/CADk0S-UpM8k_NGuqbuA%2BNuC%2BTdGDjGzUt0Fp05Y8pHROjH-WZA%40mail.gmail.com >>>>>> >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-UpM8k_NGuqbuA%2BNuC%2BTdGDjGzUt0Fp05Y8pHROjH-WZA%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+...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f9f7a485-94d3-45cf-a0b1-3021c6d7526a%40chromium.org >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f9f7a485-94d3-45cf-a0b1-3021c6d7526a%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/f08c6f76-2e6e-4724-8d09-73d345b0882cn%40chromium.org.
