Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Intent to implement: Reporting API
150 views
Skip to first unread message
Andrea Marchesini
Nov 13, 2018, 4:33:53 AM11/13/18
to dev-platform
*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
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
Nov 14, 2018, 10:17:28 AM11/14/18
to Andrea Marchesini, dev-pl...@lists.mozilla.org
On Tue, Nov 13, 2018 at 4:33 AM Andrea Marchesini <amarc...@mozilla.com>
wrote:
> 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.
>
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,
--
Ehsan
wrote:
> 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.
>
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,
--
Ehsan
Tom Ritter
Nov 14, 2018, 10:59:08 AM11/14/18
to Ehsan Akhgari, Andrea Marchesini, Mozilla
On Wed, Nov 14, 2018 at 3:17 PM Ehsan Akhgari <ehsan....@gmail.com> wrote:
> 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
> 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).
same issues? Do we do anything special there?
-tom
Boris Zbarsky
Nov 14, 2018, 11:17:33 AM11/14/18
to
On 11/13/18 4:33 AM, Andrea Marchesini wrote:
> 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
> I decided to implement this API, because it is required in the
> web-platform-tests for FeaturePolicy.
tests: they should not be coupling the two specs together.
-Boris
Andrea Marchesini
Nov 14, 2018, 1:36:41 PM11/14/18
to Boris Zbarsky, dev-platform
> 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
> tests: they should not be coupling the two specs together.
>
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
Mats Palmgren
Nov 14, 2018, 8:11:08 PM11/14/18
to Andrea Marchesini, dev-platform
On 11/13/18 10:33 AM, Andrea Marchesini wrote:
> *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.
It is blatantly clear to me that the second part would be
> *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.
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
Mats Palmgren
Nov 14, 2018, 8:11:14 PM11/14/18
to Andrea Marchesini, dev-platform
On 11/13/18 10:33 AM, Andrea Marchesini wrote:
> *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.
> 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.
Ehsan Akhgari
Nov 14, 2018, 8:33:43 PM11/14/18
to Tom Lowenthal, Andrea Marchesini, dev-pl...@lists.mozilla.org
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.)
--
Ehsan
Ehsan Akhgari
Nov 15, 2018, 9:53:42 AM11/15/18
to Boris Zbarsky, dev-pl...@lists.mozilla.org
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.
--
Ehsan
Boris Zbarsky
Nov 15, 2018, 11:23:30 AM11/15/18
to
On 11/15/18 9:52 AM, Ehsan Akhgari wrote:
> 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
> The idea is to use Feature Policy in report-only mode
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
Nov 15, 2018, 4:17:47 PM11/15/18
to Boris Zbarsky, dev-platform
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.
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
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.
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Ehsan Akhgari
Nov 16, 2018, 10:03:11 AM11/16/18
to Andrea Marchesini, Boris Zbarsky, dev-pl...@lists.mozilla.org
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...
On Thu, Nov 15, 2018 at 4:17 PM Andrea Marchesini <amarc...@mozilla.com>
wrote:
> 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.
>
>
> On Thu, Nov 15, 2018 at 5:25 PM Boris Zbarsky <bzba...@mit.edu> wrote:
>
Ehsan
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...
On Thu, Nov 15, 2018 at 4:17 PM Andrea Marchesini <amarc...@mozilla.com>
wrote:
> 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.
>
>
> On Thu, Nov 15, 2018 at 5:25 PM Boris Zbarsky <bzba...@mit.edu> wrote:
>
> > _______________________________________________
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
--
> > dev-platform mailing list
> > dev-pl...@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
Ehsan
Boris Zbarsky
Nov 16, 2018, 10:50:29 PM11/16/18
to
On 11/15/18 4:17 PM, Andrea Marchesini wrote:
> I think we should implement this API for these reasons:
OK. I guess we should keep an eye on the privacy implications, but
> I think we should implement this API for these reasons:
otherwise probably fine to go ahead.
-Boris
0 new messages