Intent to implement: Reporting API

[Andrea Marchesini]

*Summary*: Reporting API allows the page to receive notifications such as
the usage of deprecated APIs and FeaturePolicy violations.
I decided to implement this API, because it is required in the
web-platform-tests for FeaturePolicy.

Reporting API covers 2 different features:
a. reporting to the current page, via ReportingObserver
b. reporting to a remote server, known via 'report-to' HTTP header.
My implementation covers only the first aspect. However I also have patches
for the second part, not in review yet.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1492036

*Link to standard*: https://w3c.github.io/reporting/

*Platform coverage*: everywhere.

*Estimated or target release*: unknown yet.

*Preference behind which this will be implemented*: dom.reporting.enabled

*Is this feature enabled by default in sandboxed iframes?* yes. The reports
are per contexts. (but not for workers or worklets yet. See
https://github.com/w3c/reporting/issues/131

*DevTools bug*: no supports for devtools. I don't think we need to do
anything for devtools.

*Do other browser engines implement this?*
Chrome shipped it in 69:
https://www.chromestatus.com/feature/4672626140119040
No other browsers.

*web-platform-tests*:
https://wpt.fyi/results/feature-policy/reporting?aligned&label=stable
https://wpt.fyi/results/reporting?aligned&label=stable

[Ehsan Akhgari]

Post by Andrea Marchesini
a. reporting to the current page, via ReportingObserver
b. reporting to a remote server, known via 'report-to' HTTP header.
My implementation covers only the first aspect. However I also have patches
for the second part, not in review yet.

What are your plans with regards to implementing the second part? Can
these reports be sent cross-origin? (From the spec, it seems like the
answer is yes.) If so, how are you planning to handle issues such as
sending these reports to third-parties, including third-party trackers?
I'm worried about: a) sending these reports to a third-party not on the TP
list, b) sending these reports to a third-party on the TP list, and c) what
options we have to mitigate the tracking impact of these reports for both
of the previous cases, but especially for (b).

Also, do I understand correctly that ReportingObserver objects only receive
reports from the same origin as the context they're created in?

Thanks,

[Tom Ritter]

Post by Ehsan Akhgari
What are your plans with regards to implementing the second part? Can
these reports be sent cross-origin? (From the spec, it seems like the
answer is yes.) If so, how are you planning to handle issues such as
sending these reports to third-parties, including third-party trackers?
I'm worried about: a) sending these reports to a third-party not on the TP
list, b) sending these reports to a third-party on the TP list, and c) what
options we have to mitigate the tracking impact of these reports for both
of the previous cases, but especially for (b).

Is this a different situation than CSP, which seems to have all these
same issues? Do we do anything special there?

-tom

[Ehsan Akhgari]

Post by Tom Ritter

Post by Ehsan Akhgari
What are your plans with regards to implementing the second part? Can
these reports be sent cross-origin? (From the spec, it seems like the
answer is yes.) If so, how are you planning to handle issues such as
sending these reports to third-parties, including third-party trackers?
I'm worried about: a) sending these reports to a third-party not on the

TP

Post by Ehsan Akhgari
list, b) sending these reports to a third-party on the TP list, and c)

what

Post by Ehsan Akhgari
options we have to mitigate the tracking impact of these reports for both
of the previous cases, but especially for (b).

Is this a different situation than CSP, which seems to have all these
same issues? Do we do anything special there?

The CSP report-uri mechanism is deprecated AFAIK (
https://w3c.github.io/webappsec-csp/#directive-report-uri) and is supposed
to be replaced with this new API, so I think it is important to get the new
API right from the privacy perspective even if we didn't get CSP reporting
right (which we didn't -- AFAIK we happily send the CSP violation reports
to wherever the site points us to.)

[Boris Zbarsky]

Post by Andrea Marchesini
I decided to implement this API, because it is required in the
web-platform-tests for FeaturePolicy.

Is it needed for any other reason? If not, this seems like a bug in the
tests: they should not be coupling the two specs together.

-Boris

[Andrea Marchesini]

Post by Boris Zbarsky
Is it needed for any other reason? If not, this seems like a bug in the
tests: they should not be coupling the two specs together.

Well, in this way, these 2 APIs can test each other: we could use
deprecated APIs to check ReportingObserver notifications, but there is not
a common set of deprecated APIs across browsers.
And ReportingObserver is an easy way to test any feature-policy blocking
with a common code base. See:
https://searchfox.org/mozilla-central/source/testing/web-platform/tests/feature-policy/reporting

[Ehsan Akhgari]

Post by Boris Zbarsky

Post by Andrea Marchesini
I decided to implement this API, because it is required in the
web-platform-tests for FeaturePolicy.

Is it needed for any other reason? If not, this seems like a bug in the
tests: they should not be coupling the two specs together.

It is. The Reporting API and Feature Policy are meant to be used
together. For example, developers may want to reduce the usage of sync XHR
on their website, but on a very complex site it may not be easy to figure
out where sync XHR is being used. The idea is to use Feature Policy in
report-only mode to report the usages of Sync XHR for example so that they
can fix them gradually without disallowing Sync XHR using Feature Policy
right off the bat.

[Boris Zbarsky]

The idea is to use Feature Policy in report-only mode

There is no report-only mode in the Feature Policy spec, nor in our
implementation. See the note at the end of
https://wicg.github.io/feature-policy/#reporting

So I'm back to my question: is this an API we actually want to
implement? It seems like a fair amount of complexity and overhead and
the one use case so far is for sites to have telemetry for when they're
ending up with feature policy violations, right?

-Boris

[Andrea Marchesini]

There is a proposal to support "report-only" violations for feature policy:
https://github.com/WICG/feature-policy/blob/824de86f89599240c24b5ae3cd58d25984446af5/reporting.md

I think we should implement this API for these reasons:

a. it unifies the reporting of violations and interventions. At the moment
we have FeaturePolicy, Interventions, crashes and deprecated APIs, but it's
easy to imagine reports coming from CSP violations, CORB, Origin-policy etc.

b. Often, when an intervention is made, the only thing a browser does is to
write a message in the console. autoplay heuristic and tracking protection
are just 2 examples. Here we can do something more: we can communicate
something to the page, using ReportingObserver.

c. it's a nice diagnostic tool for websites. In the 'report-to' HTTP
header, entry-points can be used as communication channel between the
browser and the server.

Post by Boris Zbarsky

The idea is to use Feature Policy in report-only mode

There is no report-only mode in the Feature Policy spec, nor in our
implementation. See the note at the end of
https://wicg.github.io/feature-policy/#reporting
So I'm back to my question: is this an API we actually want to
implement? It seems like a fair amount of complexity and overhead and
the one use case so far is for sites to have telemetry for when they're
ending up with feature policy violations, right?
-Boris
_______________________________________________
dev-platform mailing list
https://lists.mozilla.org/listinfo/dev-platform

[Ehsan Akhgari]

I think there is value in supporting this API, both for web developers and
for us (e.g. in order to help us deprecate and remove APIs more easily). I
go back and forth on the question of the privacy impact of the API, since
the fact that the reports are exposed both to JS and HTTP layers means that
protecting only the HTTP layer against e.g. cross-origin access wouldn't be
sufficient since JS code can just as easily be used to send the same data
cross-origin at least for reports coming the same global. What's not quite
clear to me is what kind of data this API would allow the page to access
which is currently hidden from it...

Post by Andrea Marchesini
https://github.com/WICG/feature-policy/blob/824de86f89599240c24b5ae3cd58d25984446af5/reporting.md
a. it unifies the reporting of violations and interventions. At the moment
we have FeaturePolicy, Interventions, crashes and deprecated APIs, but it's
easy to imagine reports coming from CSP violations, CORB, Origin-policy etc.
b. Often, when an intervention is made, the only thing a browser does is to
write a message in the console. autoplay heuristic and tracking protection
are just 2 examples. Here we can do something more: we can communicate
something to the page, using ReportingObserver.
c. it's a nice diagnostic tool for websites. In the 'report-to' HTTP
header, entry-points can be used as communication channel between the
browser and the server.

Post by Boris Zbarsky

The idea is to use Feature Policy in report-only mode

There is no report-only mode in the Feature Policy spec, nor in our
implementation. See the note at the end of
https://wicg.github.io/feature-policy/#reporting
So I'm back to my question: is this an API we actually want to
implement? It seems like a fair amount of complexity and overhead and
the one use case so far is for sites to have telemetry for when they're
ending up with feature policy violations, right?
-Boris
_______________________________________________
dev-platform mailing list
https://lists.mozilla.org/listinfo/dev-platform

_______________________________________________
dev-platform mailing list
https://lists.mozilla.org/listinfo/dev-platform

[Boris Zbarsky]

OK. I guess we should keep an eye on the privacy implications, but
otherwise probably fine to go ahead.

-Boris

[Mats Palmgren]

Post by Andrea Marchesini
*Summary*: Reporting API allows the page to receive notifications such as
the usage of deprecated APIs and FeaturePolicy violations.
I decided to implement this API, because it is required in the
web-platform-tests for FeaturePolicy.
a. reporting to the current page, via ReportingObserver
b. reporting to a remote server, known via 'report-to' HTTP header.
My implementation covers only the first aspect. However I also have patches
for the second part, not in review yet.

It is blatantly clear to me that the second part would be
a violation of the GDPR. I raised this issue in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1492036#c9
No one has yet responded.

It may very well be that the first part also violates the GDPR
if it gives the page access to data that it would not otherwise
have access to. Isn't the whole purpose of the ReportingObserver
to facilitate sending data back to an external server through
some other mechanism like XHR?


/Mats