Re: Intent to implement: Reporting API
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 otherwise probably fine to go ahead. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
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 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 wrote: > > > 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 > > 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 > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
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 wrote: > 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 > 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 > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
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 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 dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On Wed, Nov 14, 2018 at 11:20 AM Boris Zbarsky wrote: > 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 > 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. -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On Wed, Nov 14, 2018 at 10:58 AM Tom Ritter wrote: > On Wed, Nov 14, 2018 at 3:17 PM Ehsan Akhgari > 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 > 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.) -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
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 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
> 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
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 tests: they should not be coupling the two specs together. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On Wed, Nov 14, 2018 at 3:17 PM Ehsan Akhgari 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 same issues? Do we do anything special there? -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Reporting API
On Tue, Nov 13, 2018 at 4:33 AM Andrea Marchesini 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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Reporting API
*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 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
