Tsuyoshi, Previously your third OT stage on ChromeStatus got associated with your second trial on OT Console. That is probably due to a bug in ChromeStatus. We'll look into that.
To let you continue with requesting this new trial, I have cleared out the trial ID for that third OT stage on ChromeStatus. Now you should see a "Request Trial Creation" button on that stage that looks like: https://screenshot.googleplex.com/4RZcpmCHJgxSnaT You will need to change some fields in the form to indicate that this is for your "V3" trial. Please note that each distinct trial requires a distinct trial name with an entry in https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/runtime_enabled_features.json5 The "Request Trial Creation" form handler now checks that file when you submit, so you may need to land a change to that file before you can successfully submit the form. Thanks, jason! On Friday, May 31, 2024 at 6:24:37 AM UTC-7 mike...@chromium.org wrote: > Thanks Domenic - I agree. > On 5/30/24 9:31 PM, Domenic Denicola wrote: > > 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 jrob...@google.com 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 <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/6291f89f-93be-45ba-b2a2-a73060c566f2n%40chromium.org.
