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 <[email protected]> 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 [email protected] 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 [email protected] 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 <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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) < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, May 29, 2024 at 4:31 PM Mike Taylor <[email protected]> >>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> [email protected], [email protected], [email protected], >>>>>>>>>> [email protected], [email protected] >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 [email protected]. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 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 [email protected]. >>>>>>> >>>>>>> >>>>>>>> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/db4ebe23-fa81-4567-a4ee-6f2d9fb8c4abn%40chromium.org.
