Intent to Implement: CSP: `report-to` directive.
331 views
Skip to first unread message
Mike West
May 26, 2017, 4:37:14 AM5/26/17
to blink-dev, Andy Paicu
Contact emails
Summary
The `report-to` directive wires CSP violation reports up to the Reporting API (https://wicg.github.io/reporting/), and deprecates the existing `report-uri` directive.
Motivation
Interoperability risk
Testing, however, is going to be difficult. Since part of the benefit of this feature is that reports are delivered in browser-controlled batches, out of band, it's going to be difficult to write web platform tests that verify much of anything. `setTimeout(verifyReportReceived, 10000000)` doesn't sound exciting. This isn't unique to CSP, however; any feature that uses this mechanism is going to have similar troubles. We'll have to put our heads together to see what we can do to ensure interop.
Spec
Summary
The `report-to` directive wires CSP violation reports up to the Reporting API (https://wicg.github.io/reporting/), and deprecates the existing `report-uri` directive.
`Content-Security-Policy: script-src 'self'; report-to default` will queue violation reports into the reporting group named "default", and the browser will deliver them in a batch, along with other reports from other APIs.
Motivation
CSP's existing `report-uri` mechanism is fairly naive with regard to it's behavior on the network. We send one POST per violation, which means that we're sending a _lot_ of requests in aggregate. `report-to` uses the Reporting API to batch up violation reports, and send them out of band, whenever the device is happiest sending reports. It should be friendlier overall, and gives us a path to deprecating `report-uri` in the future.
Interoperability risk
Firefox: No public signals
Edge: No public signals
Safari: No public signals
Web developers: No signals
Folks generally seem enthusiastic about the reporting API, but I don't think any vendors in WebAppSec WG have taken a close look at `report-to` yes. Hopefully this intent will give them reason to do so. :)
Testing, however, is going to be difficult. Since part of the benefit of this feature is that reports are delivered in browser-controlled batches, out of band, it's going to be difficult to write web platform tests that verify much of anything. `setTimeout(verifyReportReceived, 10000000)` doesn't sound exciting. This isn't unique to CSP, however; any feature that uses this mechanism is going to have similar troubles. We'll have to put our heads together to see what we can do to ensure interop.
Compatibility risk
The `report-to` directive is specified as overriding the `report-uri` directive, so developers can support both older and newer browsers by using both in a policy. This means that we should be able to both support a gradual migration from one to the other, and if we decide that this was a terrible idea and should throw the whole thing away, we'll be able to do so without breaking anyone.
Ongoing technical constraints
None
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes
OWP launch tracking bug
Link to entry on Chrome Platform Status
Requesting approval to ship?
No (if all goes well, we'll aim to ship this at the same time the Reporting API itself ships).
-mike
-mike
Philip Jägenstedt
May 29, 2017, 5:13:40 PM5/29/17
to Mike West, blink-dev, Andy Paicu
On the issue of testing, presumably it'd be possible that the right reports are delivered in aggregate, allowing for any batching that the spec allows for?
If the reports can be delayed arbitrarily, then perhaps a WebDriver extension that causes the report to be sent immediately would work? (Presumably there are already other events that cause that to happen, which aren't possible to tickle from a vanilla test.)
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3De%3D5xzf4ziDAcz-fHcoxqRAkeerRgLYDSPCb9gN1Q1Hxw%40mail.gmail.com.
Mike West
May 30, 2017, 3:25:40 AM5/30/17
to Philip Jägenstedt, blink-dev, Andy Paicu
On Mon, May 29, 2017 at 11:13 PM, Philip Jägenstedt <foo...@chromium.org> wrote:
On the issue of testing, presumably it'd be possible that the right reports are delivered in aggregate, allowing for any batching that the spec allows for?
The spec is fairly intentionally hand-wavey about how the UA is allowed to deliver reports. It basically boils down to "do whatever makes sense given all the conditions you care about". :)
In practice, a small timeout would probably do the trick. But that would almost certainly end up flaky.
If the reports can be delayed arbitrarily, then perhaps a WebDriver extension that causes the report to be sent immediately would work? (Presumably there are already other events that cause that to happen, which aren't possible to tickle from a vanilla test.)
It looks like rbyers@ is busy adding a JS interface to Reporting, so that might be a good-enough way to test that a given feature queued up a report to be sent. That might be enough for the `report-to` directive in particular, and matches how many CSP tests are written (we look for `securitypolicyviolation` events with correct values for most tests, and verify that reports are POSTed separately).
-mike
Philip Jägenstedt
May 30, 2017, 7:27:44 AM5/30/17
to Mike West, blink-dev, Andy Paicu
If the report endpoint URL is included in that API, that SGTM.
Reply all
Reply to author
Forward
0 new messages