You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Adding to this question, if the reporting endpoint returns a Critical-CH header to request any of the "high entropy" UA Client Hint values, would the browser retry the request?
I'm not sure what the current interaction between CH and reporting is, although since it's specced in terms of fetch, my guess is that:
Any User-Agent header that is part of the POST request will be removed or frozen along with other requests from the browser.
We should ensure that the user-agent field in the report body matches that, and doesn't inadvertently disclose more information.
Low-entropy client hints (Sec-CH-UA, Sec-CH-UA-Mobile, Sec-CH-UA-Platform) would be attached to the outgoing reports in the HTTP headers.
(This is less certain, and I need to make sure that there aren't technical reasons not to do this) High-entropy hints should be subject to existing hint negotiation; if the generating page would have sent the hints in a resource request, then it should add them to the outgoing report headers
If the endpoint tries to insist on unsent hints through Critical-CH, then I think that the request would fail, in the same way that not abiding by CORS causes the request to fail. The browser might retry, in case it's a temporary server misconfiguration, but not with a modified request.
I suspect that the high entropy client hints should only apply to V1 reports, configured with the Reporting-Endpoints header. The batching of reports that happens with V0 might make it impossible to know whether a particular POST request should have hints or not, since it could include reports from different documents.
1-3 make sense to me.
RE 4, I'd expect the high entropy hints to be there IFF the reporting origin is delegated with them, using the relevant permission policy
I'm not sure about Critical-CH
Client Hints shouldn't differ based on Desktop mode/etc, correct?
So while we have user-agent in the report body, we wouldn't need Client Hints in the body right? We can just read them from the incoming HTTP request headers?
I've reviewed the current behavior here, and it doesn't appear (in Chrome 117) that any Client Hint HTTP headers are sent with Reporting API reports, even to a same-origin destination where Accept-CH has been registered and working for the same domain.
Activity
maudnals commentedon Nov 3, 2021
General question:
Should Reporting API requests look different from resource requests on the page?
If so, why?
chrisn commentedon Nov 3, 2021
Adding to this question, if the reporting endpoint returns a
Critical-CHheader to request any of the "high entropy" UA Client Hint values, would the browser retry the request?clelland commentedon Jan 12, 2022
I'm not sure what the current interaction between CH and reporting is, although since it's specced in terms of fetch, my guess is that:
user-agentfield in the report body matches that, and doesn't inadvertently disclose more information.Sec-CH-UA,Sec-CH-UA-Mobile,Sec-CH-UA-Platform) would be attached to the outgoing reports in the HTTP headers.Critical-CH, then I think that the request would fail, in the same way that not abiding by CORS causes the request to fail. The browser might retry, in case it's a temporary server misconfiguration, but not with a modified request.I suspect that the high entropy client hints should only apply to V1 reports, configured with the Reporting-Endpoints header. The batching of reports that happens with V0 might make it impossible to know whether a particular POST request should have hints or not, since it could include reports from different documents.
@yoavweiss can you confirm this?
yoavweiss commentedon Jan 13, 2022
1-3 make sense to me.
RE 4, I'd expect the high entropy hints to be there IFF the reporting origin is delegated with them, using the relevant permission policy
I'm not sure about Critical-CH
@maudnals - are you not seeing the 1-4 behavior?
/cc @miketaylr
agektmr commentedon Feb 10, 2022
I examined the HTTP header sent with reports on a demo and it was following:
{ connection: 'close', 'x-forwarded-for': '217.178.137.117,::ffff:10.10.11.202,::ffff:10.10.80.238', 'x-forwarded-proto': 'https,http,http', 'x-forwarded-port': '443,80,80', host: 'reporting-endpoint.glitch.me', 'content-length': '1115', 'content-type': 'application/reports+json', 'user-agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) ' + 'AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4878.0 ' + 'Safari/537.36', 'accept-encoding': 'gzip, deflate, br', 'accept-language': 'en-US,en;q=0.9,ja;q=0.8', 'x-forwarded-host': 'reporting-endpoint.glitch.me', traceparent: '00-378e03f773b3476fae213404d3650c96-acca84b4eb508495-01' }It was Chrome Canary Version 100.0.4878.0 (Official Build) canary (x86_64).
It doesn't seem to send
Sec-CH-UA-***headers.nicjansma commentedon Nov 22, 2022
Client Hints shouldn't differ based on Desktop mode/etc, correct?
So while we have
user-agentin the report body, we wouldn't need Client Hints in the body right? We can just read them from the incoming HTTP request headers?nicjansma commentedon Sep 16, 2023
I've reviewed the current behavior here, and it doesn't appear (in Chrome 117) that any Client Hint HTTP headers are sent with Reporting API reports, even to a same-origin destination where
Accept-CHhas been registered and working for the same domain.Simple repro: https://nicj.net/dev/reporting-api/
This demo page generates
Report-To,NELandAccept-CHheaders, then includes a 404 image so a NEL report is generated.The initial HTML navigation request (after a reload) sends the headers you'd expect (abbreviated list):
However the Reporting API reports the same (frozen)
User-Agentbut noSec-Ch-Ua-*headers.Here's the complete header set:
CC @clelland @miketaylr
clelland commentedon Sep 16, 2023
Created https://crbug.com/1483711
These reports are spec'd in terms of Fetch, and should have the same logic applied as other fetches.