Intent to Implement: Feature Policy Violation Reporting

[Ian Clelland]

Contact emails

icle...@chromium.org, paul...@chromium.org

Explainer

Explainer: https://github.com/WICG/feature-policy/blob/master/reporting.md

Design doc/Spec

Spec: https://wicg.github.io/feature-policy/#reporting

It's worth noting that this spec defines how violations are to be reported, but abstains from defining what constitutes a "violation" of any policy. We intend to enable reporting for most policy-controlled features, but PRs will have to be sent for each feature's spec to declare that a particular use of the feature should be reported as a violation.

Summary

This will enable violations of feature policy within a page to be reported through the Reporting API.

Motivation

In order to minimize compatibility issues, policy-controlled features are usually designed to fail when disabled in the same way that they would when any other error occurred: "fullscreen" rejects its promise; "sync-xhr" throws a NetworkError; "geolocation" acts as though the user denied permission; etc. This means that most failure paths will already be handled by existing code, but makes it difficult for developers to reason about *why* a particular API call failed, and whether the policy was responsible.

Additionally, reporting allows developers to gather data "from the field", to catch issues occurring on users' browsers which may never appear during development.

Finally, the "report only" mode (explainer only) will enable developers to try out policies and gather data on potential problems before enabling the policies in an enforcing mode. This should make adoption of feature policy much easier for much of the development community.

Risks

Interoperability and Compatibility

If other browsers do not choose to implement this, it may still be useful, as it can provide feedback to developers from Chrome users. The feature could be removed, though, and developers could fall back to in-band error detection and handling. (They would stop getting the out-of-band reports, and would have to notice that and change their code, though.) The feature policy JS API, once shipped, would make that an easier task.

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: Positive support; many developers have suggested that reporting is critical to adoption of feature policy for their sites. See comments on https://github.com/WICG/feature-policy/issues/142, and https://twitter.com/ChromiumDev/status/1014185185515012097, for instance.

Ergonomics

Are there any other platform APIs this feature will frequently be used in tandem with? Yes, by definition, this needs to be used in conjunction with Feature Policy, Reporting API, *and* the actual feature that developers are intending to control. This should be the natural intersection of those three, though.

Activation

This feature will help developers start to take advantage of feature policy. This reporting is no more difficult to use than the Reporting API generally.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes: This will be available on all platforms which support the Reporting API.

Link to entry on the feature dashboard

https://www.chromestatus.com/feature/6294138899136512

Requesting approval to ship?

No

[Harald Alvestrand]

In the explainer, I don't understand the aggregation server concept - where it lives, who runs it, and why it isn't itself a spy-point.

Is there a pointer available for more description of this concept?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK_TSXKWC1sHJZ%3D2Rq-Yd9yO-%3DQbTJ8yhs5PWfw44fu1rOC6tw%40mail.gmail.com.

[Ian Clelland]

Hi Harald,

The concept of an aggregation server was our best idea for a privacy-preserving method to allow reporting of feature policy violations which occur in third-party embedded content. The idea was originally presented as an extension to the Reporting API here (https://github.com/w3c/reporting/pull/75) but was removed after a number of people brought up concerns around privacy.

In a nutshell, the problem it was trying to solve is that we cannot report violations from within third-party embedded frames, because that can give away users behaviour on those third-party sites, and an attack can easily be scoped to a single person. We can't have the user agent sending the reports directly to the first party's reporting server, even if we've tried to anonymise them. This means that as a site owner, you can't tell whether a policy on your page is causing trouble in the wild because of content that you embed. It would be great to be able to tell that certain frames you're embedding are violating the policy you set, without violating the privacy of your users.

We introduced the idea that the browser vendor could run a service which would collect just the cross-origin violation reports from multiple clients, and only send an aggregated count to the original server once a sufficient number of reports had been received (from a large number of unique clients, so that a single user can't be targeted). Similarly to UMA services, the aggregation server itself would be hard-coded into the user agent, and would be subject to the same kinds of user consent. The data it collects, however, would only ever be relayed (after processing) to the original site-defined reporting endpoint. (That point, of course, is still subject to the "but what if it's really spying instead" question that can't be answered at the spec level.)

All that said, though, we're not implementing this right now. With the strong negative reaction from the Reporting proposal, we're concentrating on the first party cases exclusively. This intent is just for first-party reporting and report-only mode -- I should have made that clear in the original email, and I should mark the third-party section in the explainer as "potentially possible in the future, but not right now".

Ian

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Harald Alvestrand]

Thank you - "aggregation server is run by the browser vendor" is at least a well defined concept. If implemented, we would probably have to have user / site policies that turned off reporting to the aggregation servers, since some of our customers do *not* want to trust us with more tracking data than what they have to share already.

What's been the community reaction to "report-only mode"? Since that hasn't made it into the spec yet, I take it it's somewhat controversial.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.