This actually triggered a small internal incident at Datadog on a private API that wasn't set-up to handle Zstandard encoding properly.
So two things: 1. Firstly, thanks for bringing this this our attention! We were able to patch the error ahead of a more general roll-out to public users. 2. Is there a way we can explicitly opt in to these kinds of A/B tests to preemptively catch more of these breaking changes? This would be particularly useful to our synthetics. Thanks, Lee On Saturday, 15 July 2023 at 07:33:52 UTC-4 Nidhi Jaju wrote: > 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/f1dcf4a6-ef78-4c6a-9e76-d73e67c78c3bn%40chromium.org.
