[webkit-dev] Request for position: ALPS and ACCEPT_CH HTTP/2 and HTTP/3 frames

Tue Apr 6 10:07:07 PDT 2021

(Oops, couldn't post to the list without being subscribed. Apologies for
the duplicate mail to anyone who got both!)

On Tue, Apr 6, 2021 at 1:02 PM David Benjamin <davidben at chromium.org> wrote:

> Hi Alex, thanks for the comments! Responses inline.
>
> On Mon, Apr 5, 2021 at 9:04 PM Alex Christensen <achristensen at apple.com>
> wrote:
>
>> I’m glad to see ALPS and bytes sent over the network used instead of
>> additional reliance on state on the client.  We don’t want to introduce a
>> super cookie on the client, and we want to minimize breakage when a user
>> agent decides to remove state to prevent tracking.
>>
>
> Well, with regards to cross-site tracking, I'll note that Accept-CH cache
> is already naturally partitioned because it only applies to top-level
> loads. Subresources follow a delegation model. But, yeah, one of the nice
> outcomes of Client Hint Reliability is it makes the Accept-CH cache
> *actually* a cache, so the UA can scope or clear it with less worry. I
> think reducing the performance and functionality gap between new and
> returning clients is generally valuable for this sort of thing. I hope
> Client Hint Reliability is useful in this regard.
>
> I can’t say I’ve followed this development closely or even thought through
>> it all completely, but here are some initial thoughts:
>>
>> My first thought is that it seems excessive to have a way to specify
>> support of client hints both in the TLS handshake and in HTTP/{2,3}
>> frames.  I guess that’s why you wrote
>> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#why-two-mechanisms
>
>
> I think you may have misunderstood the reference to two mechanisms. The
> TLS ALPS extension and h2/h3 frames are part of the same mechanism. It's a
> layering thing. TLS provides a generic spot to stick protocol-specific
> settings early enough in the handshake, and then HTTP/{2,3} define how to
> use it. (We don't want every new feature like this to require an update to
> the TLS server.)
>
> Rather, the reference is to (1) Critical-CH HTTP response *header* and
> (2) TLS ALPS + h2/h3 frames. I'd love to avoid the redundancy, but I think
> this is the best option given all the design constraints. And yeah the
> explainer discusses why.
>
>
>> I don’t think that requiring a site to be running software that supports
>> client hints is a good prerequisite to using client hints, so I don’t think
>> that’s a good reason to have two mechanisms.
>>
>
> I'm not sure I'm parsing this sentence right. It sounds like you both
> don't think server software changes are a good requisite, but also don't
> think it's good to have a mechanism with lower server software requirements?
>
>
>> Sites can change with open connections, but if a site changes its client
>> hints acceptance, wouldn’t that be a good reason to terminate all the open
>> connections and require renegotiation?
>>
>
> Sites don't really work that way architecturally. You may have, for
> instance, a CDN frontend handling TLS and H2/H3, but it contacts the origin
> server that developers actually upload content to. In such deployments,
> there usually isn't a way to signal an update to all connections like that.
> Moreover, there's a race condition here. The client may request the
> resource at the same time as the server signaling the new preferences.
>
>
>> Wildcard subdomains in the certificate is an interesting problem.
>>
>
> I'll add that cross-name pooling further complicates any hope of signaling
> existing connections above.
>
>
>> If it is decided that multiple mechanisms are necessary, their
>> interaction should be well defined.  What if the server said one thing in
>> ALPS but said something different in an HTTP/{2,3} frame?  What if I have
>> multiple connections open to the same server and get different client hint
>> headers?
>>
>
> Agreed it should be well-defined. I touched on this briefly
> in draft-davidben-http-client-hint-reliability-02, but not in full detail.
> The IETF and W3C/WHATWG split is a bit fun at the boundaries of the web
> platform and network protocols. :-) I think we'll probably put the full
> Fetch integration in https://github.com/WICG/client-hints-infrastructure,
> alongside the other Client Hints bits.
>
> The interaction we think works best is that ALPS/frames and
> Accept-CH/Critical-CH are conceptually two separate sources of hint
> requests, with the expectation that the former is an optimization for the
> latter. You end up roughly unioning them. This avoids weird behaviors when
> they mismatch and meshes well with the constraints that led to two
> mechanisms in the first place.
>
>
>> In
>> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#retry-limits
>> you specify that a client should not retry more than once per request to
>> avoid infinite loops, but in
>> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#server-triggered-retry
>> you use the possibility of infinite loops as a reason that a
>> server-triggered retry isn’t a good solution.  I think a server-triggered
>> retry is a good solution and we should be able to expect that if someone
>> wants their website to work, then they will do what it takes to make their
>> servers work correctly.  Don’t we have the possibility of infinite
>> redirects today?
>>
>
> Good question. While they're both "infinite loops", they're not really
> analogous. I think you want to look at what kinds of problems can lead to
> infinite loops (how likely are they), and what are the consequences of
> detecting one (how bad is it).
>
> Imagine the server-trigger retry. To make sure we're on the same page, by
> server-triggered retry, I mean server-side logic implements something like:
>
> if (RequestNeedsRetry()) {
>     return SelfRedirect();
> } else {
>     return ActualResponse();
> }
>
> The tricky part here is RequestNeedsRetry(). Suppose a privacy-conscious
> user has configured their browser to never send the Foo-Bar hint. Or
> suppose the browser just predates the Foo-Bar hint and doesn't implement
> it. Our desired outcome is the server gets the Foo-Bar hint if and *only
> if* the browser would have sent it when requested. That is a more complex
> query than checking if the header is present, and it's one every site would
> need to implement. If *any* site gets it wrong, they will return
> SelfRedirect() instead of ActualResponse() and privacy-conscious users
> infinite loop. The browser will detect it, but the page will simply fail to
> load because we never got a response.
>
> In comparison, consider Critical-CH. The server *unconditionally* sends a
> perfectly fine response, but says, "by the way, I can give you a better
> response, if you're willing to send me these hints". The browser can then
> decide whether to use the response as-is, or request a new one. The server
> needs no interesting logic, it's just static declaration of this resource's
> properties. If the server goes out of its way to misbehave (or we retry at
> the same time as a resource update), it can incrementally add one header at
> a time and trigger lots of retries. But the browser can detect this and
> just use the resource as-is.
>
> (Come to think of it, it's not even an infinite loop. Each retry must add
> at least one new header and there are a finite number of headers the server
> will request. Still, I think the browser should notice this and only retry
> once.)
>
> So we have one mechanism which makes it very likely that sites will
> accidentally break for privacy-conscious setups, and we have another which
> is much easier to get right and, either way, the site still works. I think
> there's a clear winner here. :-)
>
>
>> > On Apr 5, 2021, at 4:32 PM, Mike Taylor via webkit-dev <
>> webkit-dev at lists.webkit.org> wrote:
>> >
>> > Hi there,
>> >
>> > Complimentary to
>> https://lists.webkit.org/pipermail/webkit-dev/2021-January/031673.html,
>> Chromium intends to ship the ALPS + ACCEPT_CH HTTP/2 and HTTP/3 frames
>> portions of the Client Hints reliability proposal, and we would like to
>> solicit WebKit's position.
>> >
>> > As mentioned in the linked thread, the Client Hint Reliability proposal
>> is a set of features aimed at making Client Hints more reliably available
>> and mitigating mis-matches between a site's preferences and the preferences
>> stored in the browser.
>> >
>> > In particular, The ACCEPT_CH HTTP/2 and HTTP/3 frames, combined with
>> the TLS ALPS extension, are a connection-level optimization to deliver the
>> server’s Client Hint preferences in time for the first HTTP request.
>> >
>> > Specifications:
>> >
>> > https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability
>> (section 4)
>> > https://tools.ietf.org/html/draft-vvv-httpbis-alps
>> > https://tools.ietf.org/html/draft-vvv-tls-alps
>> >
>> https://github.com/WICG/client-hints-infrastructure/blob/main/reliability.md#connection-level-settings
>> >
>> > thanks,
>> > Mike
>> > _______________________________________________
>> > webkit-dev mailing list
>> > webkit-dev at lists.webkit.org
>> > https://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20210406/90b541ee/attachment.htm>