As an indication, a pure in-memory benchmark without web server, network or 
other overhead.
TurboBench: Dynamic/Static web content compression benchmark 
<https://github.com/powturbo/TurboBench/issues/43>

On Friday, July 14, 2023 at 10:57:47 AM UTC+2 Nidhi Jaju wrote:

> Contact [email protected]
>
> Explainer
> https://docs.google.com/document/d/1aDyUw4mAzRdLyZyXpVgWvO-eLpc4ERz7I_7VDIPo9Hc/edit?usp=sharing
>
> Specificationhttps://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 componentInternals>Network 
> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Internals%3ENetwork>
>
> TAG reviewNone
>
> TAG review statusNot 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://flagsenable-zstd-content-encoding
>
> Finch feature nameZstdContentEncoding
>
> Requires code in //chrome?True
>
> Tracking bughttps://bugs.chromium.org/p/chromium/issues/detail?id=1246971
>
> Launch bughttps://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 discussionsIntent 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/24d3ec63-b79c-4443-951c-05b62c141ef4n%40chromium.org.

Reply via email to