Client Hint Reliability mechanisms

[amtunlimited]

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:

1. an HTTP-header-based retry to ensure critical Client Hints are reliably available
2. a connection-level optimization to avoid the performance hit of a retry in most cases

• Explainer¹ (minimally containing user needs and example code): https://github.com/WICG/client-hints-infrastructure/blob/master/reliability.md
• Security and Privacy self-review²: Security and privacy are covered for client hints. The reliability mechanisms don’t add any significant new information to be accessed, and don’t change who can access that information.
• Primary contacts (and their relationship to the specification):
  • Aaron Tagliaboschi (@amtunlimited) Google
  • Yoav Weiss (@yoavweiss) Google
• Organization/project driving the design: Google

Further details:

• I have reviewed the TAG's API Design Principles

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

[amtunlimited]

Friendly ping. Is this one anyone's radar?

[hober]

Friendly ping. Is this one anyone's radar?

Yup! @ylafon, @kenchris, and I are looking at this today in our vF2F.

[hober]

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?

[ylafon]

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?)

[amtunlimited]

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")

[davidben]

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.

[mikewest]

Friendly ping @ friendly TAGgers. This has been stalled for a while; are there still questions y'all would like answered?

[ylafon]

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.