LGTM2
On Mon, Feb 5, 2024 at 5:38 PM Yoav Weiss (@Shopify)
<yoavwe...@chromium.org> wrote:
LGTM1
Thanks for including these values in the I-D.
On Fri, Feb 2, 2024 at 9:17 PM Victor Tan <victor...@chromium.org>
wrote:
the code point PR is merged. Feel free to take a look again.
Thanks.
On Wednesday, January 24, 2024 at 3:34:44 PM UTC-5 Victor Tan
wrote:
create a PR for the code point change on the RFC draft,
will work on there:
https://github.com/vasilvv/tls-alps/pull/15, thanks.
On Wednesday, January 24, 2024 at 1:55:56 PM UTC-5 Erik
Anderson wrote:
Thanks, it will be helpful to make sure this is
documented outside of Chromium. I will also chat with
some folks on Microsoft’s end that both own server
implementations and have more IETF experience to
explore how we can help with moving things forward.
*From:*Victor Tan <victor...@chromium.org>
*Sent:* Wednesday, January 24, 2024 9:00 AM
*To:* blink-dev <blink-dev@chromium.org>
*Cc:* Yoav Weiss <yoavwe...@chromium.org>; blink-dev
<blink-dev@chromium.org>; Erik Anderson
<erik.ander...@microsoft.com>; Chris Harrelson
<chris...@chromium.org>; David Benjamin
<david...@chromium.org>; Mike Taylor
<miketa...@chromium.org>; Victor Tan
<victor...@chromium.org>; Rick Byers <rby...@chromium.org>
*Subject:* Re: [blink-dev] Re: Intent to Ship: New
ALPS code point
You don't often get email from victor...@chromium.org.
Learn why this is important
<https://aka.ms/LearnAboutSenderIdentification>
Rick, thanks for question, I will create a PR on the
ALPS RFC draft to document the new code point
regarding the early experiment.
On Wednesday, January 24, 2024 at 11:15:39 AM UTC-5
Yoav Weiss wrote:
On Wed, Jan 24, 2024 at 4:48 PM Rick Byers
<rby...@chromium.org> wrote:
Oof, I agree it's not good that the only
documentation for the actual code point value
is in Chromium code - that's the sort of thing
our blink I2S process is supposed to prevent.
In addition to confusion, there's also
potential IP-risk downsides to this. Our blink
process is generally to block shipping on the
existence of some specification for everything
necessary for a compatible implementation in a
forum that ensures IP protection. While this
isn't typically an adoption barrier for many
companies, I know it has been in the past for
some (including Microsoft). This doesn't mean
we have to block on getting consensus in the
"right" standards venue, we can just do a
monkey-patch spec in a venue like the WICG, or
an unlanded PR in a formal WG where the PR
counts as an IP contribution. Then we can ship
it as an "incubation" while doing the
standards maturation work in parallel. Erik,
can you comment on the extent to which such
incubation spec work would help with Microsoft
adoption?
Victor, is there any chance you can throw
something together quickly (spec PR or
monkey-patch) that would cover the gaps in
what's necessary for compatible
implementations? This particular delta seems
very tiny and straightforward to me, so I was
originally thinking I'd just approve it. But
in principle I don't think we should be
continuing to approve changes to APIs which we
realize are struggling with adoption due to
the standards work not quite being up to our
I2S bar.
+1 to defining these codepoints somewhere. Where
are such codepoints typically defined? I'd have
assumed they'd go into one of the relevant I-Ds..
Erik, thank you for your offer of help on the
standardization front! It definitely sounds to
me like we should be pushing on the full
standards effort in parallel to this specific
intent. Having Microsoft and Google work
together on that would hopefully be able to
accelerate it.
Rick
On Tue, Jan 23, 2024 at 11:40 AM 'Victor Tan'
via blink-dev <blink-dev@chromium.org> wrote:
To be clarify, currently David is not
working on the standardizing ALPS feature.
On Tuesday, January 23, 2024 at
11:27:41 AM UTC-5 Victor Tan wrote:
Hi Erik,
We are actively working on it, but we
need to put more efforts to
standardization.
In the last serval IETF, David is the
only person is talking about the ALPS
feature. We'd glad to combine more
efforts to move it forward to
standardization.
Bests,
Victor
On Monday, January 22, 2024 at
5:24:25 PM UTC-5 Erik Anderson wrote:
Is the ALPS draft being actively
worked on?
Various teams at Microsoft that
own web sites leveraging client
hints have expressed interest in
using it, but the lack of a
finalized standard has
significantly slowed conversations
with the teams that own the server
code that would need to add
support first.
Are you looking for help in moving
standardization forward?
*From:*Yoav Weiss (@Shopify)
<yoav...@chromium.org>
*Sent:* Monday, January 22, 2024
7:39 AM
*To:* Victor Tan
<vict...@chromium.org>
*Cc:* blink-dev
<blin...@chromium.org>; Chris
Harrelson <chri...@chromium.org>;
David Benjamin
<davi...@chromium.org>; Mike
Taylor <mike...@chromium.org>
*Subject:* Re: [blink-dev] Re:
Intent to Ship: New ALPS code point
Is the old code point defined
somewhere? Would it be possible to
add such a definition to one of
the I-Ds? Or is this something
that's not traditionally defined
in IETF drafts?
On Mon, Jan 22, 2024 at 4:03 PM
Victor Tan <vict...@chromium.org>
wrote:
Currently, It's on the code:
https://boringssl.googlesource.com/boringssl/+/master/include/openssl/tls1.h?pli=1#247
Once we standardize the ALPS
RFC draft, we can finalize the
value. Hope this helps.
On Saturday, January 20, 2024
at 7:50:46 PM UTC-5 Chris
Harrelson wrote:
Thanks for clarifying.
Last question: where in
the specifications is the
new 17613 code point
documented?
On Fri, Jan 19, 2024 at
12:59 PM Mike Taylor
<mike...@chromium.org> wrote:
In our OWNERS meeting
this week, there was
some confusion on
what's being proposed
here (which is
understandable, this
isn't quite a typical
intent for web exposed
feature). Here's a
summary of what we're
trying to accomplish:
1) We shipped support
for the ACCEPT_CH
frame over h2 and h3
back in M96, which
relies on the TLS ALPS
protocol extension.
2) There are 2 parts
to this: the client
being able to
understand
ALPS/ACCEPT_CH (and in
return do something
useful), and the
server being able to
send it.
3) Because of a (long
fixed) bug present in
Chromium's
implementation, it's
risky for a server to
send too much data via
ACCEPT_CH, so it's
usefulness is
potentially limited.
4) In order to
guarantee that older
clients don't have
this bug, we propose
to rev the version
(aka, code point) at
the protocol layer.
This way, if a server
sends the new code
point and the client
understands it, it can
send a larger payload
without triggering the
bug (which may result
in sad things like a
connection being refused).
5) This is sort of web
observable, but right
now if servers that
support the old code
point continue to send
the old code point -
nothing will break.
Chromium will support
both for now, with
hopes to deprecate and
remove the older one
in the future when
we're confident it
won't result in
performance
regressions for
servers sending
ACCEPT_CH (since this
is a performance
optimization).
I hope that helps
clear it up, and I'm
sure Victor or David
will chime in if I'm
getting something
wrong. :)
And to be clear - this
isn't a request for a
deprecation or removal
(yet), but for
shipping the new code
point.
On 1/17/24 11:16 AM,
Victor Tan wrote:
If the server
received the new
code point, while
it doesn't
support, the ALPS
extension will
ignore. This also
mean client might
not know the
server's client
hints preferences
before the first
request.
Currently, only
few sites using
the ALPS
extension. As TLS
extension is
negotiated, the
server need to
support both code
points during the
transition period,
after some time,
the server can
drop the old one.
On Wednesday,
January 17, 2024
at 11:00:13 AM
UTC-5 Yoav Weiss
wrote:
On Saturday,
January 13,
2024 at
12:08:33 AM
UTC+1 Victor
Tan wrote:
*Contact
emails*
vict...@chromium.org,
mike...@chromium.org,
davi...@chromium.org
*Explainer*
https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md
<https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md>
*Specification*
https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability
<https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability>
https://tools.ietf.org/html/draft-vvv-httpbis-alps
<https://tools.ietf.org/html/draft-vvv-httpbis-alps>
https://tools.ietf.org/html/draft-vvv-tls-alps
<https://tools.ietf.org/html/draft-vvv-tls-alps>
*Summary*
Shipping a
new code
point
(17613)
for TLS
ALPS
extension
to allow
adding
more data
in the
ACCEPT_CH
HTTP/2 and
HTTP/3
frame. The
ACCEPT_CH
HTTP/2
frame with
the
existing
TLS ALPS
extension
code point
(17513)
had an
arithmetic
overflow
bug
<https://crbug.com/1292069>in
the Chrome
ALPS
decoder.
It limits
the
capability
to add
more than
128 bytes
data (in
theory,
the
problem
range is
128 bytes
to 255
bytes) to
the
ACCEPT_CH
frame.
With the
new ALPS
code
point, we
can fully
mitigate
the issue.
*Blink
component*
Blink>Network>ClientHints
<https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3ENetwork%3EClientHints%2C&can=2>
*TAG review*
https://github.com/w3ctag/design-reviews/issues/549
<https://github.com/w3ctag/design-reviews/issues/549>
*TAG
review
status*
Closed
*Risks*
*Interoperability
and
Compatibility*
This is
switching
to a new
code point
for the
TLS ALPS
extension.
It won’t
change the
design of
ALPS and
ACCEPT_CH
mechanism
implementation.
The main
source of
compatibility
risk is
that it
causes
conflicts
with ALPS
negotiation
since some
clients
could
still use
the old
code point
while
others are
switching
to use the
new code
point. The
ALPS
extension
could be
ignored if
the code
point
doesn’t
match
during
negotiation,
which
means the
server's
client
hints
preferences
won’t be
delivered
in the
ACCEPT_CH
HTTP/2 and
HTTP/3
frame. We
mitigate
this by
enabling
servers to
support
both code
points,
monitoring
both code
points
usage and
removing
the old
ALPS code
point
support in
a future
intent
once the
usage is
low
enough. We
also split
the
rollout
into two
phases: we
first
start to
enable the
new ALPS
code point
for
ACCEPT_CH
with
HTTP/3
frame in a
slow
rollout,
and then
eventually
enable the
new code
point with
HTTP/2 frame.
Does the
server have an
indication if
the client in
question
supports the
newer code point?
If not, what
would we
expect servers
that support
the newer code
point to do?
*Edge*: No
signals
*Firefox*:
Pending
https://github.com/mozilla/standards-positions/issues/510
<https://github.com/mozilla/standards-positions/issues/510>*Safari*:
Pending
https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html
<https://lists.webkit.org/pipermail/webkit-dev/2021-April/031768.html>
*Web/Framework
developers*:https://twitter.com/Sawtaytoes/status/1369031447940526080
<https://twitter.com/Sawtaytoes/status/1369031447940526080>https://twitter.com/_jayphelps/status/1369023028735148032
<https://twitter.com/_jayphelps/status/1369023028735148032>
*Activation*
The site’s
TLS and
HTTP
serving
application
would need
to be
updated to
support
this new
code
point. We
aren’t
aware of
many sites
using this
feature
yet, however.
*Debuggability*
No special
DevTools
support
needed.
The
effects of
the code
point
change of
ACCEPT_CH
frame will
be visible
in the
DevTools’
network
tab. Also,
the NetLog
will
record the
ACCEPT_CH
frame
value if
TLS ALPS
extension
is
negotiated
successfully.
*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/+/master/docs/testing/web_platform_tests.md>*?*
No, this
feature is
tested
with
browser-side
tests. We
can’t test
TLS-adjacent
features
currently
through
web-platform-tests.
See this
issue:
https://github.com/web-platform-tests/wpt/issues/20159
<https://github.com/web-platform-tests/wpt/issues/20159>
*Flag name*
UseNewAlpsCodepointHttp2
UseNewAlpsCodepointQUIC
*Tracking
bug*
b/289087287
<http://b/289087287>
*Launch bug*
https://launch.corp.google.com/launch/4299022
<https://launch.corp.google.com/launch/4299022>
*Link to
entry on
the Chrome
Platform
Status*
https://chromestatus.com/feature/5149147365900288
<https://chromestatus.com/feature/5149147365900288>
--
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/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c704d985-a5cc-4e5e-99b0-1f78cc4428e6%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+...@chromium.org.
To view this discussion on the web
visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJQu%2BjtN9hQ302XVW1_Y1b8BUYQUDr4ujMavPU1vU7%2Bzw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJQu%2BjtN9hQ302XVW1_Y1b8BUYQUDr4ujMavPU1vU7%2Bzw%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/fbfcefbb-637e-428b-9ca2-3c879e2af1e2n%40chromium.org
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbfcefbb-637e-428b-9ca2-3c879e2af1e2n%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/CAOmohS%2B5KAs3j9izP4t1p%2B9cPAkQ_PJ1ffuWHxMnL08P60EmVw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohS%2B5KAs3j9izP4t1p%2B9cPAkQ_PJ1ffuWHxMnL08P60EmVw%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/CAM0wra8zuWnfXL_NP11_sE2GC97%2BA%2BPet4ywvzT1fzqPZsXjeA%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM0wra8zuWnfXL_NP11_sE2GC97%2BA%2BPet4ywvzT1fzqPZsXjeA%40mail.gmail.com?utm_medium=email&utm_source=footer>.
