Skip to content

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

Open

Description

@maudnals

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?

  • If not: Why not?
  • If yes: Would it make sense to start making available in the requests sent by the browser new fields that match Sec-CH-UA?
    Example values:
Sec-CH-UA: "Chromium";v="93", "Google Chrome";v="93", " Not;A Brand";v="99"
Sec-CH-UA-Mobile: ?0-
Sec-CH-UA-Platform: "macOS"

By default, Chrome already returns all of these in regular requests.

Benefits of this could be twofold:

  • Help existing report collectors get ready for upcoming changes in Chrome and other browsers.
  • Make it easier for report collectors and custom endpoints to parse and the UA information, and make it useful.

Activity

  1. maudnals commented on Nov 3, 2021

    @maudnals
    Author

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

  2. chrisn commented on Nov 3, 2021

    @chrisn
    Member

    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?

  3. clelland commented on Jan 12, 2022

    @clelland
    Contributor

    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?

  4. yoavweiss commented on Jan 13, 2022

    @yoavweiss
    Contributor

    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

  5. agektmr commented on Feb 10, 2022

    @agektmr

    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.

  6. self-assigned this
    on Aug 15, 2022
  7. nicjansma commented on Nov 22, 2022

    @nicjansma

    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?

  8. nicjansma commented on Sep 16, 2023

    @nicjansma

    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

  9. clelland commented on Sep 16, 2023

    @clelland
    Contributor

    Created https://crbug.com/1483711

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions