Hi Mike, The proposed experiment is to run an A/B experiment on Canary/Dev, Beta, and then 1% of Stable on M117.
Best, Nidhi On Sat, Jul 15, 2023 at 12:32 AM Mike Taylor <[email protected]> wrote: > Can you clarify the proposed experiment (presumably N% of stable?) and the > desired milestones? Thanks! > On 7/14/23 4:57 AM, Nidhi Jaju wrote: > > Contact emails [email protected] > > Explainer > https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing > > Specification https://datatracker.ietf.org/doc/html/rfc8878 > > Design docs > https://docs.google.com/document/d/14dbzMpsYPfkefAJos124uPrlkvW7jyPJhzjujSWws2k/edit?usp=sharing > > Summary > > Zstandard, or “zstd”, is a data compression mechanism described in > RFC8878. It is a fast lossless compression algorithm, targeting real-time > compression scenarios at zlib-level and better compression ratios. The > "zstd" token was added as an IANA-registered Content-Encoding token as per > https://datatracker.ietf.org/doc/html/rfc8878#name-content-encoding. > Adding support for "zstd" as a Content-Encoding will help load pages faster > and use less bandwidth. > > Blink component Internals>Network > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork> > > TAG review None > > TAG review status Not applicable > > Risks > > Interoperability and Compatibility > > Servers that have a broken implementation of zstd might exist, but the > risk of this is small. Additionally, middleware and middleboxes like virus > checkers that intercept HTTPS connections might not support zstd, but might > fail to remove it from the Accept-Encoding header in the request. > > *Gecko*: No signal ( > https://github.com/mozilla/standards-positions/issues/775) > > *WebKit*: No signal ( > https://github.com/WebKit/standards-positions/issues/168) > > *Web developers*: Positive (https://crbug.com/1246971) Facebook (Yann) > and Akamai (Nic) seem to be positive about zstd content-encoding in the > browser. Facebook is also excited to test the feature. > > *Other signals*: > > Security > > CRIME and BREACH mean that the resource being compressed can be considered > readable by the document deploying them. That is bad if any of them > contains information that the document cannot already obtain by other > means. An attacker may provide correctly formed compressed frames with > unreasonable memory requirements, and dictionaries may interact > unexpectedly with a decoder, leading to possible memory or other > resource-exhaustion attacks. It is possible to store arbitrary user > metadata in skippable frames, so they can be used as a watermark to track > the path of the compressed payload. It is important to note that these > concerns apply to all compression formats, not just zstd. > > To mitigate these risks, similar to Brotli, we'll be advertising support > for "zstd" encoding only if transferred data is opaque to proxy, to ensure > that resources don't contain private data that the origin cannot read > otherwise. > > Adding zstd to Chromium adds a large new code surface that processes > untrusted data, which inevitably brings risks of new security holes. > However, this is mitigated by the extensive fuzzing and security analysis > done on zstd by Google and other community members. > > 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? > > > Goals for experimentation Understand the impact of supporting zstd > content-encoding in the browser on performance and if there's breakage. > > Ongoing technical constraints > > Debuggability > > No special support needed. Zstd content-encoding support will be exposed > to the devtools protocol, so developers are able to override it and view > the headers from the inspector. > > 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> > ? No > > Flag name on chrome://flags enable-zstd-content-encoding > > Finch feature name ZstdContentEncoding > > Requires code in //chrome? True > > Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1246971 > > Launch bug https://launch.corp.google.com/launch/4266275 > > Estimated milestones > Shipping on desktop 117 > Shipping on Android 117 > Shipping on WebView 117 > > Link to entry on the Chrome Platform Status > https://chromestatus.com/feature/6186023867908096 > > Links to previous Intent discussions Intent to prototype: > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANd_E77W1ki--h_XJM-%2B_fA3w1CriGgJmnbh1N3LwRDtw%40mail.gmail.com > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- > 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/CAMZNYANR%3DisgShRGxHQMgn-2W1%2BteA81AtyRu14v7s_kk2C90Q%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMZNYANR%3DisgShRGxHQMgn-2W1%2BteA81AtyRu14v7s_kk2C90Q%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/CAMZNYANXMaVdvHKvgswVQpZKe3%2BE-mknMi%2B8X6kKpq%2BbZZfUig%40mail.gmail.com.
