#549: Client Hint Reliability mechanisms
Discussions
Discussed
Aug 31, 2020 (See Github)
Yves: let's bump this
Discussed
Sep 14, 2020 (See Github)
[assigned to f2f
Comment by @amtunlimited Jan 26, 2021 (See Github)
Friendly ping. Is this one anyone's radar?
Comment by @hober Jan 27, 2021 (See Github)
Friendly ping. Is this one anyone's radar?
Yup! @ylafon, @kenchris, and I are looking at this today in our vF2F.
Comment by @hober Jan 27, 2021 (See Github)
I have a question about the example in Application-Layer Protocol Settings. The example contains this in the initial response:
+ alps=(https://example.com, Device-Memory)
But there doesn't appear to be any indication in syntax that this is an encoding of ACCEPT_CH. How is the client to know that?
Comment by @ylafon Jan 27, 2021 (See Github)
Hi, we took a look at this during our virtual f2f, with @hober and @kenchris . Having a client doing a redirect on a 200 instead of using a 3xx looks weird (even if it is a retry, it is still a kind of redirect with the goal of having more informations in the request), identifying on the initial request that the client supports and is willing to do such redirect would be good. Did you discuss your proposal with the IETF httpbis WG? Some question we had, what happens when the client hints uses greasing, is that impacting the 'critical' nature of it? (ie: would it remove the greasing part to be more accurate?)
Comment by @amtunlimited Jan 27, 2021 (See Github)
Thanks all for taking a look
I have a question about the example in Application-Layer Protocol Settings. The example contains this in the initial response:
+ alps=(https://example.com, Device-Memory)But there doesn't appear to be any indication in syntax that this is an encoding of ACCEPT_CH. How is the client to know that?
Did you discuss your proposal with the IETF httpbis WG?
@davidben for ALPS and procedure questions
identifying on the initial request that the client supports and is willing to do such redirect would be good.
I suppose the hope would be that any browser supporting Client Hints would also support this retry mechanism, but I suppose examining the browser vendor and major version would also do that
Some question we had, what happens when the client hints uses greasing, is that impacting the 'critical' nature of it? (ie: would it remove the greasing part to be more accurate?)
Not something we had considered, although an interesting idea. Currently there's not really a notion of a hint being critical or being given more than once changing the value of the hint (that form of state just isn't stored anywhere, nor is any hint being marked "critical")
Comment by @davidben Jan 27, 2021 (See Github)
But there doesn't appear to be any indication in syntax that this is an encoding of ACCEPT_CH. How is the client to know that?
None of that is the actual syntax. TLS, HTTP/2, and HTTP/3 are all binary protocols. The actual syntax would be a hex readout of bytes, which isn't useful in an example. :-)
This part is a protocol extension implemented by TLS and HTTP serving software, not the JavaScript/CSS APIs that are normally in explainers. We simply felt the explainer format was a useful way to convey, at a high level, how the pieces fit together. In particular, those diagrams are just shorthand patterned after the usual style in TLS-related specifications. The point is to convey what is sent in which round-trip.
As with other protocol extensions, the nitty gritty wire formats are in the protocol specifications, linked to from the explainer. Web developers don't interact with them, just as web developers don't parse TLS ClientHello messages. Though, for folks unfamiliar with how the IETF does things, draft versions are immutable, so any particular link may be stale. As the details here evolve, you'll need to check at the top of the page to make sure you're looking at the latest draft. At the moment, these are the latest ones: https://tools.ietf.org/html/draft-vvv-tls-alps-01 https://tools.ietf.org/html/draft-vvv-httpbis-alps-01 https://tools.ietf.org/html/draft-davidben-http-client-hint-reliability-02
Did you discuss your proposal with the IETF httpbis WG?
Yup. The documents were presented a few IETFs ago and we've started discussions at the httpbis and tls WGs for the HTTP and TLS portions, respectively.
Comment by @mikewest Apr 8, 2021 (See Github)
Friendly ping @ friendly TAGgers. This has been stalled for a while; are there still questions y'all would like answered?
Discussed
Apr 19, 2021 (See Github)
Tess: this is a network protocol level optimisation of client hints, under the assumption client hints is a thing and works as it was designed. Say a client requests a website for the first time, send a GET request, with no client hints becuase you don't know what the server wants yet. In the 200 reply it can say here are the client hints I'm interested in. Right now if a browser spports client hints it might retry and send client hints for maybe a better website. So it tries again and gets a different result. But that roundtrip sucks performance wise so they were trying to figure out how to optimise that away most of the time. Combation of TSL level change and HTTP/2 and 3 level change that accomplish that. New Header called critical-ch that say which client hints would result in very different responses. Mechanism to expose than in the initial TLS handshake. When client first connects to server it can say it wants an ecrypted connection the server says right aware here are client hints, before the first HTTP request has been made. In the initial http GET it can include the client ints it would have asked for, removing the round trip. It's very sensible as an optimisation mechanism. Fundamentally questions about client hints in general as a mechanism, and any specific client hint may or may not have concerns related to it. I don't think that's relevant here. if you presume client hints are a thing, this is a straightforward optimisation to make them less costly in the common case. I don't remember TAG's position on client hints in general, but as optimisation it seems fine. I don't want to say it looks fine without Yves saying he's okay with it. Plenary? Proposed closed and getting Yves confirmation in plenary? ... They want to ship some of it and it's been a while.
Dan: we don't have a general position on client hints. In Feb 2019 we had a proposal about migrating high entropy http request headers to client hints which we responded positively to.
Tess: we don't necessarily need a position on underlying mechanism to be positive on it
Hadley: do we need to take a position on client hints?
Tess: we probably should. There are specific client hints being proposed I'm not okay with, but some that are fine. General mechanism seems fine. there's been a lot of back and forth.. people working on it are responsive. Biggest concerns have been / are being fixed.
Dan: what's the current implementation status on client hints itself?
Tess: probably out of date - I understand it's still a single engine thing. Mozilla's position overall was "non-harmful". We were initially opposed but they've been very responsive on specific feedback. No implementation in Safari.
Dan: would it make sense to say if the implementation s ory is okay to say it makes sense as a mechanism but there should be some rule about things shouldn't be implemented as a client hint if they can be x or are intended to be y. Adds complexity, not something developers expect, not easily configurable in servers. Finding? Design principle?
Tess: one of the advantages of client hints as infrastructure is the shift of passive fingerprinting into active fingerprinting. One arguement is that it's a good idea because it improves the stuation fingerprinting-wise. Specific client hints that make things worse fingerprinting-wise subvert the entire mechanism and probably shouldn't be done. Ultimately it doesn't come into this specific design review.
Dan: in the spirit of spinning things into design principles, we might want to open a design principle issue
Tess: makes sense as a design principle for i fyou're thinking about adding a new client hint we can offer guidence about when it is or isn't appropriate. That's the case for many other mechanisms... http header? Propose close and I'll file a design principles issue
Dan: I'm doing it.
Lea: when I was reviewing the compute pressure we were discussing adding a principle about designing APIs in a low level way so we're stuck on hardware, do we have that?
Tess: we should have that
Discussed
May 1, 2021 (See Github)
Yves wanted to make sure they were talking to the right groups at IETF about this, and they are. Propose close.
Draft closing comment from @ylafon:
Thank you for those answers. From a TAG standpoint we are happy to let the discussion continue in the HTTPBis WG.
Comment by @ylafon May 13, 2021 (See Github)
Thank you for those answers. From a TAG standpoint we are happy to let the discussion continue in the HTTPBis WG. Happy to let this proceed.
OpenedAug 19, 2020
Hullo TAG!
I'm requesting a TAG review of Client Hint reliability mechanisms.
HTTP Client Hints can replace passive fingerprinting surfaces with server-requested (and potentially deniable) client headers. However, there’s no current way to guarantee the hints would be available to the server, for cases where they can materially impact the response sent. On the first page load, the client may not know to send any hints at all. The client may also have out-of-date information on the server preferences when it sends a request. The explainer below describes a pair of mechanisms to fix this:
Further details:
You should also know that...
This will help address one of the main areas of concern brought up by developers, namely that they wanted some hints available on first navigation request, and that the logic behind a retry would be needlessly complex and fraught with possible pitfalls if implemented on the server side.
We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @amtunlimited, @yoavweiss