LGTM for a new OT from 127 to 129. (Speaking generally, I think starting new OTs is better than extending existing ones, so I am glad the team has taken this route. From an ecosystem perspective, new OTs make it easier for the team to make breaking changes, and encourages OT participants to continually re-engage with the process.)
On Friday, May 31, 2024 at 10:07:00 AM UTC+9 [email protected] wrote: > 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 <[email protected]> >> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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) < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Wed, May 29, 2024 at 4:31 PM Mike Taylor <[email protected]> >>>>>> 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 >>>>>>> >>>>>>> [email protected], [email protected], [email protected], >>>>>>> [email protected], [email protected] >>>>>>> >>>>>>> >>>>>>> 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 [email protected]. >>>>>>> >>>>>>> >>>>>>> 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 [email protected]. >>>> >>>> >>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/f8efa299-8132-45f2-80a5-9449704bcf1bn%40chromium.org.
