OK, I think that I found the problem and fixed it in ChromeStatus database. I reran the cron job that previously overwrote my simpler fix and it did not overwrite my more-complete fix. So, you should now see the "Request Trial Creation" button on the V3 OT stage, and it should still be there until you press it and submit the form.
Thanks, jason! On Monday, June 3, 2024 at 12:01:10 PM UTC-7 Jason Robbins wrote: > Hmm, after I cleared out the wrong data, something filled it in again. I > will try to track down that ChromeStatus bug today. > > Thanks, > jason! > > On Sunday, June 2, 2024 at 4:59:33 PM UTC-7 Tsuyoshi Horo wrote: > >> Hi. >> >> On Sat, Jun 1, 2024 at 3:04 AM Jason Robbins <jrob...@google.com> wrote: >> >>> 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 >>> >> >> Sorry, I can't find the "Request Trial Creation" button. >> I still see the "Request a trial extension" button, not the "Request >> Trial Creation". >> https://screenshot.googleplex.com/9PNnFQLkQBTVwdU >> And the "View Origin Trial" button is linked to the previous V2 Origin >> trial console URL >> <https://developer.chrome.com/origintrials/#/view_trial/3693514644397228033> >> . >> >> >> >> >>> >>> >>> 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/1a9302f7-ad0d-47a2-8334-3d947531c975n%40chromium.org.
