Use of Client Hints for Chrome-facilitated testing

[rowan-m]

Chrome is planning to use client hints to provide traffic labels for each of the testing modes. Do you have any concerns or feedback about using client hints for this purpose?

See https://developer.chrome.com/docs/privacy-sandbox/chrome-testing/ for context.

[dmdabbs]

A draft traffic label proposal we can assess would be helpful.

Today's "Chrome testing" post says

...via a new request header and low-entropy client hint.

Are you describing just a new CH or a header and a CH?

The hint probably shouldn't be reflected in NavigatorUAData since an entity wouldn't be able to detect the presence/absence (or inability to set) its third-party cookie until processing a request.

Client Hints are only sent on secure requests versus a garden variety header that would be available on all traffic. (Yes I agree that no one should be using insecure these days...)

[miketaylr]

Client Hints are only sent on secure requests versus a garden variety header that would be available on all traffic. (Yes I agree that no one should be using insecure these days...)

Yep, it's also true the the new APIs are restricted to secure environments, so I don't think this is a meaningful blocker.

[rowan-m]

new APIs are restricted to secure environments

And just to complete the reference for anyone reading along, existing third-party cookies must already specify both SameSite=None and Secure so will not be present in insecure (e.g. non-HTTPS) contexts.

[lbdvt]

Would the labels be only accessible through CH?

If so, I understand that an HTTP response has to be sent first with the proper Accept-CH header.

From a header bidding perspective, a bidder may not have had the opportunity to do so before its bidding endpoint is called for a bid request.

Indeed, the header bidding wrapper scripts may be hosted on the publishers' servers. In that case, Adding the Accept-CH header to an HTTP response and accessing the label in subsequent HTTP queries would require changes on the publishers' web server, correct? If so, it looks unlikely for this change to happen at scale.

Would you consider adding the header to all HTTP requests (without the need for the previous HTTP response with Accept-CH header)?

[dmdabbs]

The announcement indicated it would be a "low-entropy client hint." They are safe to send by default.

[dmdabbs]

@rowan-m the initial responses and engagement were encouraging.
We inquired in the recent WICG FLEDGE call, but understandibly that team can't speak to a cross-cutting concern like the testing scheme.
A proposal and a forum in which to discuss it would be welcome.
It is approaching six weeks since the announcement and these questions' posting.
Vacation season will hit full stride soon. We'll want time to get this into adtech engineering queues before Q4 lockdowns.

[rowan-m]

Appreciate the comments! We published https://developer.chrome.com/blog/privacy-sandbox-launch/#chrome-facilitated-testing-modes just recently and in there we're now on for providing an update on the testing modes in mid-August where I believe we will be able to provide more clarity on both the form and granularity of the labels.

[rowan-m]

Updating this issue with the implementation details available on https://developer.chrome.com/docs/privacy-sandbox/chrome-testing/#cookie-deprecation-value

We will not be using Client Hints to send the labels, but instead the current design relies on the presence of a specific cookie to opt-in to receiving the label in an HTTP header or calling a new JavaScript API.

We have also posted an initial Intent to Prototype to blink-dev: https://groups.google.com/a/chromium.org/g/blink-dev/c/8mlWTOcEzcA

[rowan-m]

Closing this issue now we have updated implementation guidance. As ever, feel free to open new ones if needed!