Hi, blink-dev@ folks. Let me announce the start of the new Origin Trial for the Compression Dictionary Transport feature.
If you are already experimenting with it you'll need to register for a new token <https://developer.chrome.com/origintrials/#/view_trial/3693514644397228033> (CompressionDictionaryTransport*V2*). There were header changes since the first trial. So please check this list of changes <https://chromium.googlesource.com/chromium/src/+/main/docs/experiments/compression-dictionary-transport.md#changes-in-m123> if you have any trouble while experimenting with the Compression Dictionary Transport feature in Chrome 123. Thank you. On Thu, Feb 29, 2024 at 4:25 PM Tsuyoshi Horo <h...@chromium.org> wrote: > Thank you! > > On Thu, Feb 29, 2024 at 11:29 AM Domenic Denicola <dome...@chromium.org> > wrote: > >> This Intent did not show up on the API Owners dashboard, which probably >> explains the lack of responses. I'm unsure whether this is a bug in the >> dashboard, or if there's something on ChromeStatus that you need to do >> (e.g. some stage you need to set for extending the origin trial). >> >> LGTM to extend to M125, as that is within the guidelines of 6 milestones >> for M119 to M125. >> >> On Thu, Feb 29, 2024 at 9:13 AM Tsuyoshi Horo <h...@chromium.org> wrote: >> >>> Gentle ping. (Am I missing something?) >>> >>> >>> On Wed, Feb 21, 2024 at 10:57 AM Tsuyoshi Horo <h...@chromium.org> >>> wrote: >>> >>>> Contact emails >>>> >>>> h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org, >>>> kenjibah...@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 >>>> >>>> An Origin Trial for Compression Dictionary Transport was scheduled to >>>> start in Chrome 117 and end in Chrome 122. But due to a critical issue, we >>>> could >>>> not start >>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NgH-BeYO72E/m/G8fasgKdAQAJ> >>>> the Origin Trial until Chrome 119. The design of the feature has also >>>> evolved during the origin trial and RFC process. We’d like to continue the >>>> Origin Trial to get more feedback on the updated >>>> <https://chromium.googlesource.com/chromium/src/+/40d4e43a01431f680d5e682aaa2c4a543c8f0200/docs/experiments/compression-dictionary-transport.md#changes-in-m123> >>>> feature. >>>> >>>> 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 >>>> RisksInteroperability 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('dictionary')`. Also web >>>> servers can know the browser support by checking the `Accept-Encoding` >>>> request header and the new `Use-As-Dictionary` request header. >>>> >>>> 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. >>>> >>>> Gecko: Positive ( >>>> https://github.com/mozilla/standards-positions/issues/771) >>>> >>>> WebKit: No signal ( >>>> 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 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. >>>> >>>> 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, >>>> Sec-Available-Dictionary, Accept-Encoding, Content-Encoding). >>>> >>>> >>>> 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> >>>> ? >>>> >>>> No. We will rewrite some browser_tests to WPT. >>>> >>>> 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 >>>> >>>> 125 >>>> >>>> OriginTrial desktop first >>>> >>>> 123 >>>> >>>> OriginTrial Android last >>>> >>>> 125 >>>> >>>> OriginTrial Android first >>>> >>>> 123 >>>> >>>> >>>> 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 >>>> >>>> >>>> -- >>> 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/CADk0S-VPyLaum9rma1cpFZhUSF8FuBy3DBJFcwDUmabWE8VC5g%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADk0S-VPyLaum9rma1cpFZhUSF8FuBy3DBJFcwDUmabWE8VC5g%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/CADk0S-XEN%2BZFxmPeGRF-2WFeWUrRxuNwcWkWDWOrMObyCa-LVg%40mail.gmail.com.
