Hi there,
Would you mind commenting on progress for the following items, per OT
renewal guidelines:
Draft spec (early draft is ok, but must be spec-like and associated with
the appropriate standardization venue, or WICG)
TAG review (see exceptions)
bit.ly/blink-signals requests
Outreach for feedback from the spec community
WPT tests
thanks,
Mike
On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:
Contact emails
h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org,
kenjibah...@chromium.org, denom...@chromium.org
*
*
Explainer
https://github.com/WICG/compression-dictionary-transport
<https://github.com/WICG/compression-dictionary-transport>
*
*
Specification
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/>
*
*
Design docs
https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
<https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit>
https://github.com/WICG/compression-dictionary-transport
<https://github.com/WICG/compression-dictionary-transport>
https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
<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
<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
<https://github.com/mozilla/standards-positions/issues/771>)
*
*
WebKit: Positive
(https://github.com/WebKit/standards-positions/issues/160
<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
<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 <https://crbug.com/1413922>
*
*
Launch bug
https://launch.corp.google.com/launch/4266286
<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
<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
<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
<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
<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+unsubscr...@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+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8ca535a6-f3e7-41f7-960d-a08bdec0173b%40chromium.org.
