-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of Client Hints for Chrome-facilitated testing #114
Comments
A draft traffic label proposal we can assess would be helpful. Today's "Chrome testing" post says
Are you describing just a new CH or a header and a CH? The hint probably shouldn't be reflected in 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. |
And just to complete the reference for anyone reading along, existing third-party cookies must already specify both |
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)? |
The announcement indicated it would be a "low-entropy client hint." They are safe to send by default. |
@rowan-m the initial responses and engagement were encouraging. |
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. |
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 |
Closing this issue now we have updated implementation guidance. As ever, feel free to open new ones if needed! |
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.
The text was updated successfully, but these errors were encountered: