search

w3c / reporting

Reporting API
https://w3c.github.io/reporting/
Other
76 stars 36 forks source link

Report requests: use Sec-CH-UA? #246

Open maudnals opened 3 years ago

maudnals commented 3 years ago

As of today, requests sent by the browser to the defined endpoint(s) also include a user-agent field, as described here.

Each report has a user agent, which is the value of the User-Agent header of the request from which the report was generated.

With user-agent string reduction in mind, what are the plans for the user agent info in report requests? Will the approach here change as well?

Benefits of this could be twofold:

maudnals commented 3 years ago

General question: Should Reporting API requests look different from resource requests on the page? If so, why?

chrisn commented 3 years ago

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?

clelland commented 2 years ago

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:

  1. Any User-Agent header that is part of the POST request will be removed or frozen along with other requests from the browser.
  2. We should ensure that the user-agent field in the report body matches that, and doesn't inadvertently disclose more information.
  3. 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.
  4. (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
  5. 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.

@yoavweiss can you confirm this?

yoavweiss commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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?

nicjansma commented 1 year ago

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.

Simple repro: https://nicj.net/dev/reporting-api/

This demo page generates Report-To, NEL and Accept-CH headers, then includes a 404 image so a NEL report is generated.

<?php
header('Accept-CH: sec-ch-ua-platform-version');
header('Report-To: {"max_age":3600,"endpoints":[{"url":"https://nicj.net/dev/reporting-api/report.php"}],"include_subdomains":true}');
header('NEL: {"report_to": "default", "max_age": 2592000}');
?>
<!DOCTYPE html>
<html><head><title>Reporting API test w/ Client Hints</title></head>
<body>
    <h1>Reporting API test w/ Client Hints</h1>
    <p>The image below is a 404</p>
    <img src='missing.png'>
</body>
</html>

The initial HTML navigation request (after a reload) sends the headers you'd expect (abbreviated list):

...
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
...
Sec-Ch-Ua-Platform-Version: "12.6.6"
Sec-Ch-Ua-Platform: "macOS"
Sec-Ch-Ua-Mobile: ?0
Sec-Ch-Ua: "Google Chrome";v="117", "Not;A=Brand";v="8", "Chromium";v="117"

However the Reporting API reports the same (frozen) User-Agent but no Sec-Ch-Ua-* headers.

Here's the complete header set:

Host: nicj.net
Accept-Language: en-US,en;q=0.9,la;q=0.8
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36
Content-Type: application/reports+json
Content-Length: 888

CC @clelland @miketaylr

clelland commented 1 year ago

Created https://crbug.com/1483711

These reports are spec'd in terms of Fetch, and should have the same logic applied as other fetches.