wicg / client-hints-infrastructure Goto Github PK

Hello!
I have a website that must work without JavaScript, and I am looking into server-side solutions to detect if cookies are enabled.
A solution may be to set a test cookie, use an internal redirect, and check if the cookie is there; but I believe it's possible to do better.

Client hints look like a natural fit: the server could explicitly ask if cookies (or more generally any storage) are enabled by the user agent. What is your opinion on this? How likely is it to add such a hint?

If we go into the details, there should probably be ways to ask more granular questions:

• storage shared between the client and server (e.g. cookies or the Accept-CH cache)
• client-side only storage (e.g. localStorage, indexedDb)

The Accept-CH header acts as a complete replacement for the client hints that the browser should send on subsequent requests. I'm unsure of the right process sites (especially larger site with multiple teams) should follow when managing a selection of hints across the lifetime of the session. This is especially pertinent as the selection of valid hints expands to cover a range of different functionality.

For example:

1. Browser requests /
2. Site responds Accept-CH: DPR, Width, Viewport-Width
3. Browser sends DPR, etc. on subsequent requests which get used for image optimisation
4. Browser requests /downloads
5. Site responds with Accept-CH: UA-Platform
6. Browser sends Sec-CH-UA-Platform which is used to customise download options, but no longer sends DPR, etc.

My thoughts for best-practice here is that while the hints are persisted for the session or until a new set is assigned, developers would do better to think of them as specified per navigation. In other words, always send the complete set of hints required for a given page.

Alternatively, use the hint on a given page to set some site controlled variable that can be persisted independently. e.g. a game uses its /detect-settings page to examine the Device-Memory hint and then sets its own internally managed "quality" preference.

This also allows for advising sending a blank Accept-CH header to "reset" state, for example perhaps when a user signs out of a site.

In contrast, I think it would be good to specifically discourage:

• just asking a big static list of all the hints required throughout the site because they're used at some point
• attempting to match incoming request headers to the relevant Accept-CH value in order to additively specify another hint

The documents include references to PRs that are no longer relevant as well as ACHL. They shouldn't.

To reduce header bloat, the approach of not sending headers by default whose value is ?0 seems reasonable. Fetch Metadata's Sec-Fetch-User header is a good example of this.

This might be a good rule to agree upon, and document both here in the infrastructure doc, and in the implementation of each low-entropy hint which might have a falsy value.

In the low entropy hint table you see the header listed as Sec-CH-Save-Data, however if you follow the link the header name is just Save-Data (see https://wicg.github.io/savedata/#save-data-request-header-field)

I just noticed that a worker's client hint is set at initialization, but workers can live beyond multiple top-level navigations. We should decide if/when/where a worker's client hint set is updated/reinitialized

Related to #41, we've got a few other goofy corners of redirect handling. The append client hints to request algorithm is attached to the fetch algorithm, which means it only happens at the start of a redirect chain. Then the remove client hints from redirect if needed algorithm removes hints as needed on cross-origin redirects, but I don't believe hints are ever added on redirect.

But if you navigate to A, which redirects to B, we probably want to pick up B's hint set.

Relatedly, if you make a subresource request from A which redirects through B and C, and A has delegated different sets of hits between B and C, does going from B to C recompute the hint set, or do we only subtract hints. (Right now we only subtract.)

Accept-CH from a server indicates the desired client hint headers. The client can then choose (or not) to send back some subset of the requested headers to the server in subsequent requests.

https://web.dev/user-agent-client-hints/ indicates that the set of headers specified in Accept-CH should last for the remainder of the session (until browser closes). I.e. the client effectively caches the request and keeps on attaching the set of requested client hints.
However the server can set a new value of Accept-CH to replace the original set.

What is inferred, but I would like to confirm, is that none of this applies to the low entropy hints. My assumption is that a low entropy hint will/should always be sent irrespective of what is specified in Accept-CH. So you can't, for example, specify an empty Accept-CH and expect to stop getting Sec-CH-UA

I THINK this is covered by "For each client hints token lowEntropyHint in the registry’s low entropy hint table, append lowEntropyHint to hintSet." - i.e. this happens after whatever else comes from Accept-CH.

This is the second half to WICG/ua-client-hints#221

What should happen if, for example, the CH requirements change midway through a long redirect chain? The way I see it, there's two options:

1. Restart the request you're currently on, just with the new hints
2. Restart from the beginning of the chain with the new hints

I don't know if there's any precedent to go off of here. 1 seems like the simplest to spec and implement, and is how I would interpret the proposal right now. Number 2 might have useful merits semantically, however. Are there any strong feelings one way or the other?

@davidben, who might have opinions.

I'm not sure if the frame handling is quite right, if I'm reading the spec correctly:

The algorithm for initializing the Client Hint set only fills things in on top-level frames. Which I think means that requests within subframes won't pick up any hints in step 1 of append client hints to request.

Additionally, step 2 says the Permissions-Policy check happens on subresource requests, but that doesn't include the subframe navigation itself.

Does it work to say that child documents inherit the top-level document's client hint set? Then we fix the check in step 2 to cover all requests but the top-level navigation? (Or can we just say all of them? I don't know how permissions policy works those requests given the document's still being created.)

These should have a Sec-CH prefix and currently they do not.

https://wicg.github.io/client-hints-infrastructure/#client-hints-token-definition

I can send in a PR.

We should allow permission policies to be set on Accept-CH meta tags to enable third party contexts to receive client hints. For example:
<meta name="accept-ch" content="sec-ch-ua-platform-version=('self' 'https://foo.bar')">

This would support cases in which third party content is adaptable to the client and such adaptations improve user experience. Variable fonts, color vector fonts, and responsive images could all be enabled by this change.

Here's an early design doc: https://docs.google.com/document/d/1U3P9yvaT1NXG_qRmY3Lp6Me7M5kTnd3QrBb1yFUVNNk/edit

Currently as written it's not correct: https://wicg.github.io/client-hints-infrastructure/#request-processing

I can send in a PR.

In Request processing the hints in the hintSet are checked against permission policy only if the request is a subresource request. Are hints expected to be checked against Permission Policy when the request is a non-subresource request (e.g., a request who's destination is iframe)? I would expect requests for embedded iframes to also check against Permission Policy and that's what I've observed when testing in Chrome.

It's possible I'm just misunderstanding the fetch definition of non-subresource request. What I've observed in testing matches my intuitive understanding of a "subresource" request as an embedded request and a non-subresource request as a top-level document request. But fetch's definition seems more narrow than that.

...in all the right places.

See WICG/ua-client-hints#250

Following WICG/ua-client-hints#213, https://wicg.github.io/client-hints-infrastructure/#ch-ua-platform should be '*' not 'self'.

Although most newer hints have the new sec-ch- prefix, many older ones are missing this. We should ensure standardized naming across all hints to avoid confusion.

Hi,
I am writing on behalf of the dedicated IAB France taskforce working on sandbox, we are having an issue to understand how you will define the Privacy Budget?

Per discussion with Yoav, that appears to be the intent, but not stated explicitly; it should be.

The current mechanism doesn't enable providing an opt-in to client hints before the navigation request to the very-first-view of a certain origin is triggered.

For hints that are critical for the generation of that navigation response, that may mean that the site would either forfeit the hints, redirect the browser in order to receive the hint, or will perform content adaptation on the client side. Neither of those is ideal.

We should provide a mechanism that enables very-first-view adaptation without the performance tradeoff.

Fortunately there is a lot we can already do to improve the accessibility of websites. Client hints may even provide another way to inform us of what a user needs. I do believe there is a risk to privacy (though it would be opt-in), but I believe the gains may be worth it. Hopefully this is the right place - and I didn't read over anything related - for such a discussion.

I'm thinking about headers such as Sec-CH-UA-Perceivable, Sec-CH-UA-Operable, etc. as per WACG

A few examples:

A webpage may use such information to pre-apply certain [changeable] preferences for users, such as font-size, contrast, item spacing. It could also provide a simpler layout, i.e. for screen readers and such. Certain JavaScript events such as mouseover could be adjusted to click, i.e. for certain motor disabilities this may be useful, etcetera.

FWIW, I'm not advocating that developers bypass the WACG or other standards.

• The spec (step 11) points to Permissions Policy's Parse a policy directive algorithm, which parses the HTML allow attribute.
• allow has a different syntax than the HTTP Permissions-Policy header, which relies on Structured Field parsing.
• Chrome is shipping with <meta name="accept-ch"> syntax that resembles Permissions-Policy/Structured Fields, with at least one subtle difference: origins can't be quoted, as sf-strings are.

Here's what I got to work in shipping Chrome:

<meta name="accept-ch" content="sec-ch-dpr=(self https://o.img.rodeo https://res.cloudinary.com), sec-ch-width=(self https://o.img.rodeo https://res.cloudinary.com)">

Here's what I would expect, based on the spec:

<meta name="accept-ch" content="sec-ch-dpr 'self' https://o.img.rodeo https://res.cloudinary.com; sec-ch-width 'self' https://o.img.rodeo https://res.cloudinary.com">

(although I'm not 100% on what quotes go where, honestly. luv 2 interpret ABNF...)

I see three ways forward:

1. Chrome changes its implementation to match the spec, using theallow parsing rules (too late?)
2. The spec changes, so that the content attribute is parsed using the Permissions-Policy sf-header rules, and Chrome updates its implementation to eliminate any subtle differences (e.g. sf-string quoting... perhaps others?)
3. The spec changes to document the <meta name="accept-ch"> parsing rules that are shipping in Chrome, which match neither allow nor Permissions-Policy.

I'd prefer 1 over 2 over 3, but if there's any usage, we may be stuck with 3.

The README.md says:

If a server's response to a navigation request includes the Accept-CH: foo, bar header, same-origin subresource requests on the page will include the Sec-Foo: foo-value and Sec-Bar: bar-value request headers.

Just looking at how this is implemented in Chrome v85. Seems to treat the "classic" client hints differently than ua-client hints. For ua-arch it is indeed prefixed by sec but also by by ch. The classic hints are not prefixed.

Like usual on the web, implementation trumps specification, but wanted to phrase the question too: Any reason why the "classic" (width, dpr, downlink,ect etc...) hints should be treated differently than the ua-client hints?

It doesn't look like the spec ends up populating the client hint set for navigation requests. The Accept-CH cache is queried at initialize the Client Hints set, which happens at document creation, after the fetch. I think we'd need to do the lookup before issuing the navigation.

In append client hints to request, we use the request's client's client hint set. I'm actually not sure what that is for navigations. Looks like it's based on sourceBrowsingContext? Is that the navigation initiator or the document currently in the window? Either way, probably not the set we want.

If any <{link}> or <{script}> elements have begun to execute, then return.
This should live on some env object so that it can be referred to here.

These new headers increase the size of an HTTP request and coupled with attacker-controlled headers or header values could be used to carry out certain cookie-size sniffing attacks.

Privacy measures in browsers might invalidate some of these attacks, but the privacy boundary is typically not the origin, at least in today's implementations.

Having to support <meta http-equiv> significantly complicates implementation in browsers (as it forces header parsing to happen in the renderer, resulting in browsers having to trust their renderers).

But:

• First party CH processing requires the first party to inspect headers, so likely means they can set them as well.
• Third party CH processing requires the first party to set Feature Policy opt-in headers, so they might as well also opt-in to CH using headers.

Given the above, it doesn't seem that adding a header requirement on the first party will impact deployment complexity (beyond taking legacy content, already opting in through <meta>, into consideration)

/cc @colinbendell & @eeeps for opinions

Hi

In Section 7.1 of the spec https://wicg.github.io/client-hints-infrastructure/

It says...
A client hints token is a byte-lowercase representation of one of Save-Data, DPR, Width, Viewport-Width, Viewport-Height, Device-Memory, RTT, Downlink, ECT, Sec-CH-UA-Arch, Sec-CH-UA-Bitness, Sec-CH-UA-Model, Sec-CH-UA-Platform, Sec-CH-UA-Platform-Version, Sec-CH-UA or Sec-CH-UA-Mobile.

But Sec-CH-UA-Full-Version is missing from the list.

Also not mentioned in Section 7.2 or 7.4 either.
Nor in the Section 9 Index.

It looks like sec-ch-ua-platform-version and sec-ch-ua-bitness are missing (oops).

There used to be an Issue block in the spec text, but this issue exists to track the fetch issue on Sec- prefixed headers and CORS safelisting.

#47 (comment)
whatwg/fetch#1000

The complexity introduced increases the learning curve for "do-it-yourself" or "individual" developers' when improving performance or optimising their websites. This does not seem to align with Ethical Web Principle "The web must enhance individuals' control and power".

There is a similar concern regarding Ethical Web Principle "The web is for all people". People "on low bandwidth networks and low specification equipment" will be particularly disadvantaged if website publishers lack the skills or time to modify their websites. The proposal risks essential services needed by economically disadvantaged people becoming unavailable. The justification for such impacts must therefore be very high indeed.

In time it will also be important to ensure broad W3C membership support to comply with Ethical Web Principle "The web is multi-browser, multi-OS and multi-device". A route to making this a mandatory standard for all browsers is needed to avoid encouraging "the creation of websites that work only in one browser".

Overall, there are a set of policy and governance questions to resolve prior to any further engineering work being performed on this set of proposals.

Could be helpful for a number of reasons, including deduplication for analytics and better handling of still-missing headers.

Could call it Critical-CH-Restart or something, I'm thinking along the lines of Service-Worker-Navigation-Preload.

Something we should make sure to get right, and also to write down in the spec:

The navigation timing API should reflect any time spent in Critical-CH retries so sites can monitor performance. Certainly navigationStart should start before all the retries. From there, given that retries can be interleaved with redirects, I'm thinking we can model these as self-redirect and include them in the redirectStart to redirectEnd block. Looks like Navigation Timing 2 extends this with a redirectCount property, which we'll need to define:
https://www.w3.org/TR/navigation-timing-2/

@yoavweiss, thoughts?

@johnwilander raises an interesting point in WICG/ua-client-hints#242 (the issue is not specific to UA-CH, hence moving this issue over here).

Should we partition the Accept-CH cache to be consistent with the rest of the storage/network partitioning that's happening elsewhere?

There are elements of the Critical-CH restart mechanism (from the client hints reliability explainer and HTTP experimental draft that would fit better in web-platform land than in HTTP land (similar to this draft vs RFC8942). @davidben has mentioned this before in davidben/http-client-hint-reliability#4, and the issues mentioned have since been resolved.

Does it make sense to start specifying the web-platform components of Critical-CH? More importantly, should that be an addition to this draft or a new draft that is dependent on this one?

If, on a top-level navigation, we get a redirect, I believe the spec currently will not pick up Accept-CH on those rounds, since that happens at create and initialize a Document object. (See https://wicg.github.io/client-hints-infrastructure/#document-init and https://wicg.github.io/client-hints-infrastructure/#abstract-opdef-initialize-the-client-hints-set.)

Probably it should happen earlier, maybe in process a navigate fetch?

In the spec, "client hint token" is defined but not exported. Is there any reason you don’t want to export it?

The remove client hints from redirect if needed algorithm uses the request's client's client hint set to determine the headers to remove. If that set has changed since the headers were added, this would miss some cases.

I'm not sure whether the set can change as currently written, but it may end up changing depending on how service worker contexts end up working. Either way, it seems more robust to just loop over all CH headers.

We need a registry of all the features that rely on CH in order to:

• Have their values be included as valid CH tokens
• Determine if they are high or low entropy, to know if they should be included by default or require an opt-in
• Define the related feature policies for HTML

Such a registry should be separate from the infrastructure spec, but can live under the same repo, to make things simpler.

Currently low-entropy hints are added directly to the header list. They should just be added to the client hints set so they can go through the "Should request be allowed to use feature?" algorithm, which is what was originally intended

Right now, in order to send third parties client hints, you must:

1. Allow the sending of specific hints to specific origins (via Feature-Policy) (by default, only the first party is allowed)
2. Opt into sending specific hints (via Accept-CH)

① alone does nothing. ② seems awful redundant, in third party contexts; why would I ever set something like:

Feature-Policy: ch-dpr image-host.whatever 'self'

without then doing

Accept-CH: DPR

?

Can we make ① do ②, automatically?

Hello all,

I was reading the Reliability draft here and was somewhat surprised to see ALPS listed as an alternative/option, but not the SVCB/HTTPSSVC draft (https://tools.ietf.org/html/draft-ietf-dnsop-svcb-httpssvc-03), nor could I find any mention here on github about DNS-based "solutions" to this problem. It seems there are at least some synergies between client hint reliability and the HTTPSSVC proposal. Has this been discussed elsewhere before maybe?

As I understand it, SVCB/HTTPSSVC records solve a similar problem in that they allow the client to have server-side information before the first real request on a connection to that server (e.g., proposed use cases are exchanging alt-svc information for QUIC or enforcing HSTS). I am however far from an expert on either client hints nor the DNS proposal, so it could be I'm missing something obvious. Still, I'd expect this alternative to be at least mentioned in the Reliability document, even if it can't/won't be used.

From my reading of the mailing lists and especially comments from people in the quicwg, it seems there is less enthusiasm for ALPS than there is for HTTPSSVC in the long run from implementers (again, I could be wrong in this). Given that the DNS-based proposal is picking up speed and being implemented/tested by e.g., Cloudflare and Apple (https://blog.cloudflare.com/speeding-up-https-and-http-3-negotiation-with-dns/), this seems like a good use case to try out as well.

Looking forward to hearing your thoughts on this!
With best regards,
Robin

Right now it's not as obvious as it could be.

Current spec says that low-entropy hints are sent without an opt-in only on navigation requests.

That can have multiple implications:

• First parties have to opt-in in order to get those hints for their subresources.
• Third parties require delegation in order to get those hints.

That seems overly restrictive, and doesn't match current implementation. I think we should change that.

Which comes from WICG/ua-client-hints#105 (and the linked PR).

It would be great to have input modality (mouse, touch, etc) be passed on each request by Chrome as a User Agent Client Hint (UACH). It would help in determining how people use sites and allows for different UIs and the like when users are using different input modalities.

Any interest in creating this as a UACH?