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
<https://github.com/w3ctag/design-reviews/issues/877>
bit.ly/blink-signals
<http://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
<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
<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+...@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/f1463900-23c0-4b81-a883-29d0d7588cc2%40chromium.org.
