Re: Intent to implement: report-to header as part of Reporting API
> > > Sorry for my laziness not having scanned through the links below to find > the answer to this question, but how does this interact with the > same-origin policy, if at all? And if it does, is enabling it in sandbox > iframes without the allow-same-origin token the right thing to do? > It's possible to have cross-origin endpoints. And yes, we should not send report in such sandboxed iframes. I'll file a spec issue if there is not one yet. I assume it is possible for foo.example to use this API to send a report to > thirdparty.example (let's imagine thirdparty.example isn't on the > Disconnect tracking proptection list.) What data is leaked to > thirdparty.example as part of those reports? Do we send > credentials/referrer? > A report contains the origin and the credentials, plus the body of course. This doesn't seem different than a . In general, I agree with your concern, and I would like more people to take a close look at how Reporting API can be abused. As I said, ReportingObserver seems fine. Report-to needs a better integration with url-classifier and content blocking before being shipped. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: report-to header as part of Reporting API
On Thu, Jan 10, 2019 at 7:27 AM Andrea Marchesini wrote: > Summary: Reporting API offers 2 ways to obtain reports: ReportingObserver > and Report-to Header. I implemented ReportingObserver months ago and I sent > a separate intent-to-implement email about it. This email is about > "report-to" header, which allows a server to specify a set of endpoints to > retrieve reports. This is similar to "report-uri" directive for CSP. > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1508310 > > Link to standard: https://w3c.github.io/reporting/ > > Platform coverage: All. > > Estimated or target release: The code is landed in 65, disabled by pref. I > would enable it in 67/68 if there are no objections. > > Preference behind which this will be implemented: > dom.reporting.header.enabled > > Is this feature enabled by default in sandboxed iframes? yes. > Sorry for my laziness not having scanned through the links below to find the answer to this question, but how does this interact with the same-origin policy, if at all? And if it does, is enabling it in sandbox iframes without the allow-same-origin token the right thing to do? > DevTools bug: Not yet filed. Would be nice to expose the reporting queue > per domain somehow. > > Do other browser engines implement this? Chromium is experimenting this > feature: > > https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/V38Q47CxTIY > https://developers.google.com/web/updates/2018/09/reportingapi > > web-platform-tests: just a little support. I wrote several mochitests which > can be converted to WPTs with a bit of effort. > > Is this feature restricted to secure contexts? yes. > > A bit of context: as you probably remember, I implemented ReportingObserver > because it was needed in order to run feature-policy WPTs. > ReportingObserver is still disabled by default in release and I haven't > sent a intent-to-ship email yet because I wanted to have a full > implementation of the reporting API before doing it. Now we have it and we > can discuss the next steps. > > ReportingObserver is definitely useful, in particular for > DeprecationReportBody. It could also be interesting to use > InterventationReportBody for the anti-tracking project to inform trackers > that their cookieJar has been blocked/partitioned, or to inform when > autoplay is disabled for media elements. > > Report-to is nice to have because it's similar to CSP "report-uri" > directive, which is already implemented and released (btw, CSP has > "report-to" directive to use the "report-to" header endpoints directly. > This is not implemented yet). A nice goal would be to unify reporting API > and CSP violation delivering in one single component. This could be a good > way to improve both features, for instance, using the URL-Classifier to > avoid the sending of reports to trackers. > I assume it is possible for foo.example to use this API to send a report to thirdparty.example (let's imagine thirdparty.example isn't on the Disconnect tracking proptection list.) What data is leaked to thirdparty.example as part of those reports? Do we send credentials/referrer? Experience on the web has shown that surveillance companies create dual-use widgets for web developers to do useful things such as provide analytics/reporting and at the same time collect vast amounts of user data such as browser history without informed user consent (which arguably in cases such as this API is probably impossible to obtain). It is important to avoid starting to leak any new sources of such data while we are working hard to close all of the existing sources of such leaks, since once such leaks are opened up, they will be abused sooner or later. Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: report-to header as part of Reporting API
We have some WPTs here: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/content-security-policy/reporting-api/ My tests are here: - gtests: https://searchfox.org/mozilla-central/source/dom/reporting/tests/gtest - mochitests: https://searchfox.org/mozilla-central/source/dom/reporting/tests On Thu, Jan 10, 2019 at 1:38 PM David Burns wrote: > > > On Thu, 10 Jan 2019 at 12:27, Andrea Marchesini > wrote: > >> web-platform-tests: just a little support. I wrote several mochitests >> which >> can be converted to WPTs with a bit of effort. >> > > There don't appear to be any WPT if I am looking in the right place[1]. > Since Google are experimenting it feels like we have some WPT from the > start, even if its a pure conversion of the mochitest, it would help make > sure we interoperable with them. > > [1] > https://searchfox.org/mozilla-central/source/testing/web-platform/tests/reporting/ > > David > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: report-to header as part of Reporting API
On Thu, 10 Jan 2019 at 12:27, Andrea Marchesini wrote: > web-platform-tests: just a little support. I wrote several mochitests which > can be converted to WPTs with a bit of effort. > There don't appear to be any WPT if I am looking in the right place[1]. Since Google are experimenting it feels like we have some WPT from the start, even if its a pure conversion of the mochitest, it would help make sure we interoperable with them. [1] https://searchfox.org/mozilla-central/source/testing/web-platform/tests/reporting/ David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: report-to header as part of Reporting API
Summary: Reporting API offers 2 ways to obtain reports: ReportingObserver and Report-to Header. I implemented ReportingObserver months ago and I sent a separate intent-to-implement email about it. This email is about "report-to" header, which allows a server to specify a set of endpoints to retrieve reports. This is similar to "report-uri" directive for CSP. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1508310 Link to standard: https://w3c.github.io/reporting/ Platform coverage: All. Estimated or target release: The code is landed in 65, disabled by pref. I would enable it in 67/68 if there are no objections. Preference behind which this will be implemented: dom.reporting.header.enabled Is this feature enabled by default in sandboxed iframes? yes. DevTools bug: Not yet filed. Would be nice to expose the reporting queue per domain somehow. Do other browser engines implement this? Chromium is experimenting this feature: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/V38Q47CxTIY https://developers.google.com/web/updates/2018/09/reportingapi web-platform-tests: just a little support. I wrote several mochitests which can be converted to WPTs with a bit of effort. Is this feature restricted to secure contexts? yes. A bit of context: as you probably remember, I implemented ReportingObserver because it was needed in order to run feature-policy WPTs. ReportingObserver is still disabled by default in release and I haven't sent a intent-to-ship email yet because I wanted to have a full implementation of the reporting API before doing it. Now we have it and we can discuss the next steps. ReportingObserver is definitely useful, in particular for DeprecationReportBody. It could also be interesting to use InterventationReportBody for the anti-tracking project to inform trackers that their cookieJar has been blocked/partitioned, or to inform when autoplay is disabled for media elements. Report-to is nice to have because it's similar to CSP "report-uri" directive, which is already implemented and released (btw, CSP has "report-to" directive to use the "report-to" header endpoints directly. This is not implemented yet). A nice goal would be to unify reporting API and CSP violation delivering in one single component. This could be a good way to improve both features, for instance, using the URL-Classifier to avoid the sending of reports to trackers. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
