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 <miketa...@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) < > yoavwe...@chromium.org> wrote: > >> >> >> 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/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/CAJ8Nf21kqN%3DG0rfJTZXwoOQYXun6yJ-ix8RBf685ET6K8hHHUA%40mail.gmail.com.
