Hi. On Sat, Jun 1, 2024 at 3:04 AM Jason Robbins <jrobb...@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/CADk0S-WawZC4Vc87Ad-rJazCCU%3DSq4zO4sQOvKVGH7qFaomdGA%40mail.gmail.com.
