On Wed, May 29, 2024 at 4:31 PM Mike Taylor <miketa...@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 <pmee...@google.com> 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 > > h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org, > kenjibah...@chromium.org, denom...@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+unsubscr...@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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2BSQdt%2BydMG2uywbxeqi6V95SP5k1s%3DHH7JYCWcBGCUuw%40mail.gmail.com.
