Reporting API

[bakulf]

Reporting API is a new feature which allows developers to define a way to receive reports about feature disabled, crashes, usage of deprecated APIs and so on. It's based on a new HTTP header.

• Specification Title: Reporting API
• Specification or proposal URL: https://w3c.github.io/reporting/
• Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1492036

[marcoscaceres]

@bakulf, anyone in particular you might want feedback from?

[bakulf]

I wonder if somebody has strong opinions about implementing or not this feature.

[tomrittervg]

[This is not an official Mozilla response to the draft]

I wonder why Key Pinning is used as an example, given Chrome is removing support for it.

Allowing a report queue to be emptied (if I understand that correctly) allows an attacker who achieves script execution to remove reports that potentially could be used to detect an attack. In the context of an interactive attack shell (like BEEF) this seems concerning.

I think I'm split on the notion of Intervention reports. On one hand, I appreciate the opportunity to tell the website that I have configured my browser in a way that supersedes their desires, and please stop doing something on your website I don't care for. On the other hand, I'm not sure I want to tell websites (potentially) about all the ways I am overriding their desires.

"oom" Crash reports seem like a way to determine users' memory usage. On the flip side, I'm not sure what's different about doing the same thing and detecting a websocket closure as the same signal.

Reports may indicators of attacker activity. It may be useful to acknowledge this and provide suggestions for preventing those reports from being blocked by the network. We addressed this concern in a different draft here: https://tools.ietf.org/html/draft-ietf-trans-gossip-05#section-11.1

[dbaron]

Maybe @ckerschb @dveditz @bzbarsky @martinthomson might have opinions about this?

[martinthomson]

Good grief, another HTTP header field.

This one doesn't seem to be justified either. Why not put something on a .well-known resource? If the browser wants to send a report, then it can fetch a document telling it how. Note that this means you don't get include_subdomains. We need less things that can expand outside of their origin.

The format has so many knobs. It takes the position that it needs to address the load balancing problems of the world in its own way (a way that borrows from SRV DNS records, where we have good experience suggesting that the load balancing stuff isn't that good). Maybe this could avoid re-implementing the more generic capabilities we have at other layers of the stack. As a bonus, it would simplify the spec. A lot. The fetch monkey-patching is an obvious win.

Reporting (provided that this is at the discretion of the user agent, with due consideration to what that does for privacy), is a fine goal. It lets browsers inform sites about problems. But it sure would be nice to see this scoped more appropriately.

[bakulf]

Report-to header can be controversial, but what about ReportingObserver?
ReportingObserver can be particularly useful to detect interventions such as autoplay or anti-tracking blocking. At the same time, it can be useful to detect deprecated APIs.

Note that, by spec, ReportingObserver receives only the reports generated in the current context. This means that there are no big privacy implications.

[dbaron]

also cc: @bdekoz and @mstange who are involved in the Web Performance WG where this is developed.

[annevk]

Some additional context that wasn't explicitly in OP: this functionality is implemented in Firefox, largely to make the Feature Policy test suite working, but also because it gives web developers some useful information about various mistakes that might have been made.

It's not shipped yet as it's unclear whether we're committed to the ongoing costs of such a feature and agree with its design. The hope is that this issue can shed some light on those aspects.

@bakulf please do correct me if I got any of this wrong.

[dbaron]

A few other thoughts:

• it seems like this is doing something valuable, and it's a dependency of things we care about (for at least a reasonably good reason, I think). I think that makes it at least worth prototyping, unless there's something harmful about it or we consider it to be excessively complex for what it's doing.
• how does it compare to the other reporting features that already exist on the web? I think CSP has one... are there others? Why aren't they unified? (Or are they?)

[bakulf]

* how does it compare to the other reporting features that already exist on the web?  I think CSP has one... are there others?  Why aren't they unified?  (Or are they?)

Reporting API can be used together with CSP already via 'report-to' directive, which specifies a reporting 'group'. See: https://w3c.github.io/webappsec-csp/#directive-report-to
'report-uri' is deprecated: https://w3c.github.io/webappsec-csp/#directive-report-uri

[dveditz]

In part this API proposal was a response to lots of other features wanting to grow their own CSP-like reporting mechanism. The current in-progress version of the CSP spec wants to deprecate the original 'report-uri' in favor of partaking in a common reporting mechanism. Mozilla folks have not taking a position on this in WASWG and we haven't implemented the new 'report-to' directive in CSP (unless baku slipped it into his feature-policy reporting implementation). It wouldn't make too much sense to support 'report-to' in CSP if we're not going to support the Reporting API more broadly. But since other features will want to partake in reporting it seems sensible to define a more common mechanism.

Supporting the mechanism does not mean we have to support the reporting of all errors every spec might want. Some will surely leak more information than we're comfortable with.

We should feel free to "lie" in reports based on user instruction. E.g. if ReferrerPolicy or user preference has suppressed or even spoofed referrer information, we should report the truncated or spoofed referrer if an spec says to report the referrer for some condition.

We may also want to give users the option to turn off reporting entirely, but that's not as important (to me) as the previous two issues.

[annevk]

I filed w3c/reporting#158 in the hope of moving this forward, since as others have pointed out there are quite a few cases where more reporting would be quite useful. The feedback I posted points out that where Reporting API went beyond CSP's report-uri functionality it did so in a way that would enable tracker abuse and ended up adding significant complexity. Depending on the outcome of that issue I think this would either be harmful or worth prototyping.

[dveditz]

Arno Renevier is an external contributor working on a patch for this so we should come up with our standards position pretty soon. https://bugzilla.mozilla.org/show_bug.cgi?id=1607364

@annevk @martinthomson

[annevk]

The latest here is that we've been able to work out a refactoring (in the same issue, w3c/reporting#158) with those working on Reporting API to reduce its scope and make it equivalent to CSP reporting (which Firefox ships).

It's worth prototyping therefore.

Note that the bug in OP is for the old Reporting API so this still needs implementation work in Firefox. And we need to figure out which features we would want to hook up to the Reporting API as well.

The bug dveditz pointed out is for crash reporting, which hooks into the Reporting API and is now a distinct (short) specification at https://wicg.github.io/crash-reporting/. That should probably be its own issue.

[sefeng211]

Currently Reporting API is disabled in Firefox Nightly because we had some concerns about the status of the API internally. We chatted about this and decided to continue the support of this API. One thing we agreed on was we need to have standard position for each reports, and might need to re-evaluate the Reporting part of them again.

Content Security Policy: CSP seems to be covered by this thread
Permissions-Policy: #24
Deprecated feature Usage: Also covered by this thread
COEP violation: #796
COOP violation: #795
Document Policy: #327
Intervention Reports: #797
Crash Reports: #288
Network Error Logging: #99

[martinthomson]

@sefeng211 Do you want to update our position on the dashboard to capture the general aspect of that conclusion?

I don't think that we need a dashboard entry for each of those other issues, but we might close them with a note pointing to this conclusion, rather than putting them on the dashboard. I agree that we need to assess each feature; there could be reasons that reporting something would be bad - consider a report that might include the content of the user's browsing history or password store.

[pcjmfranken]

None of these reports should ever be sent without user consent. Even Mozilla's own applications ask the user for permission before sending out exception reports¹², or at the very least let them opt-out³.

The events and circumstances that would be reported on through this reporting API could in the vast majority of cases only ever be the result of things existing way beyond the scope of the website itself.

Furthermore, whilst the implications of these exceptions and violations having occurred primarily and most immediately affect the user, it would be another entity entirely - one often unknown and barely trusted - that would have control over exactly which situations are considered "unexpected" or "disallowed", when they should like to be informed of those, and where in the world that information should be sent to, and how it will then be processed and kept.

This could be implemented similarly to how other site permissions work: The "Permissions" section on the browser's "Privacy & Security" settings page would provide controls for setting the global default and per-site session/permanent permission status, and a pop up with options shows for each attempt at sending a report when the user's choice for that specific site hasn't yet been established.

This is the user's browser, running on the user's device, and whether or some outside entity should be appraised when something they're interested in has happened in the user's local environment is for the user to determine.

Footnotes

1. https://support.mozilla.org/en-US/kb/mozillacrashreporter ↩

2. https://support.mozilla.org/en-US/kb/mozilla-crash-reporter-tb ↩

3. https://support.mozilla.org/en-US/kb/send-usage-data-firefox-mobile-browsers#w_how-do-i-turn-off-data-collection-and-reporting ↩

[sefeng211]

@pcjmfranken This is not formal reply to your message but I do want to ask - If Firefox only supports CSP, Deprecated Feature Usage, COOP and COEP violation. Do you still think an explicit user consent is still required for sending those reports?

[pcjmfranken]

@sefeng211 The question is much appreciated regardless of its officialism.

Providing user controls for those and preferably in such a way that those are configurable per site would be ideal. It would also adhere to my interpretation of the Mozilla Manifesto principles¹ 4 and 5.

My primary concern with those specific reports is that the user might have made their own modifications to the website as it is presented (i.e. through accessibility tools, userscripts, content blockers, etc.) that they wouldn't necessarily want the website operator to know about for various reasons.

Footnotes

1. https://www.mozilla.org/en-US/about/manifesto/details/#principles ↩