On Thu, Jan 10, 2019 at 7:27 AM Andrea Marchesini <amarches...@mozilla.com> 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
