Description of the issue:
The reporting api allows the UA to send reports to the report-to endpoint. the report-to endpoint is defined in a response header e.g.:
report-to: {“group”: “default”, “max_age”: 3600, “endpoints”: [{“url”: “https://subdomain.report-uri.com/a/d/g”}], “include_subdomains”: true}
Setting a corresponding header to enable CSP, expect-CT or NEL reports should then send the reports to the above endpoint when the page is visited.
Brave beta/dev respects the report-to endpoint and generates the raw reports, as can be seen in chrome://net-export, but does not actually send them; they are indefinitely queued until they expire.
Deprecated report-uri reports are transmitted and report-uri is unaffected.
An example site which sets both report-uri and report-to headers for testing can be seen at https://daniel.spilsbury.io
Steps to Reproduce (add as many as necessary):
- Enable network log exporting via chrome://net-export
- Enable a proxy tool e.g. burp/charles/fiddler.
- Visit a site that includes a report-to header and a CSP report.
- See that no report-to reports go out on the wire via the proxy tool.
- See in the net export that the reports are queued indefinitely.
Actual Result (gifs and screenshots are welcome!):
Proxy tools do not see any POST messages sent to the report-to endpoints.
No report-to reports are received at the report-to endpoint.
Net export shows the reports queued indefinitely (as per the screenshot).
Expected result:
Report-to reports are sent from the UA and received by the report-to endpoint.
Reproduces how often:
100%
Brave Version(about:brave):
0.68.116 Chromium: 76.0.3809.87 (Official Build) beta (64-bit)
0.69.99 Chromium: 76.0.3809.87 (Official Build) dev (64-bit)
Reproducible on current live release (yes/no):
Unknown, don’t use it.
Additional Information:
Chrome updated the reporting api in chrome 76+ but didn’t seem to document it in the changelog. Things like type changed from csp to csp-violation plus a few other elements changed without any obvious notification. Chrome 76+ seems to align to the w3c editors draft of the reporting api and cspv3 specs (as opposed to the working draft or published versions); this could be the cause of the issue.