1964249 - Add pref to disable CSP Level 2 Reporting

Status: RESOLVED FIXED

(Core :: DOM: Security, enhancement)

Description

[celenity [:celenity]]

While CSP level 3 reporting appears to respect the dom.reporting.enabled preference, there's currently no way to disable level 2 reporting. Being able to disable these reports would be beneficial to users for a number reasons:

• CSP reports have privacy/fingerprinting concerns (which is one of the primary reasons uBlock Origin blocks them by default, so this would be useful for privacy-conscious/advanced users.
• CSP reports consume extra network bandwidth and resources.
• Especially since these level 2 reports/functionality is marked deprecated (among other reasons), having the ability to disable them could also prove useful to both web and browser developers for testing purposes.
• Since level 3 reports can be enabled/disabled via the dom.reporting.enabled preference, (IMO) it only makes logical sense to also allow controlling level 2 reports.
• Per the Mozilla Manifesto - Individuals must have the ability to shape the internet and their own experiences on it. Not allowing the user to decide whether they want to send these reports seems to go against this principle and Mozilla's values/ideals, and I strongly believe that users should have a choice here. Adding a preference to control this behavior would be directly in line with Mozilla's mission.

To clarify, while I'm personally against the idea of CSP reports like this, I'm not asking for them to be removed or disabled by default, as I also understand the arguments in favor of them and the potential benefits they can provide to website operators. I just feel that having a preference for this would directly benefit users due to the reasons above (and after all, we are the user agent, thus we should act in the best interest of users and allow them to exercise their choice).

Thanks for your time and consideration.

Comment 1

[Daniel Veditz [:dveditz]]

The dom.reporting.enabled preference was a feature-gate, left over from when the Reporting API feature was under development and not yet ready to ship. It wasn't intended to be a privacy feature, and wasn't originally related to CSP's use of that API.

Not saying this isn't a valid enhancement request, but if we pursue it we should make sure the reporting API disabling pref sticks around, too. feature-gates tend to get forgotten about and live for a long time, and then someone will get the idea to clean up the code by getting rid of a bunch of old ones they think no one needs anymore.

Comment 2

[celenity [:celenity]]

Thanks for the quick response.

That makes sense - and I think we should definitely ensure the dom.reporting.enabled pref sticks around as well.

From the spec (9.4):

That said, it can’t be the case that this general benefit be allowed to take priority over the ability of a user to individually opt-out of such a system. Sending reports costs bandwidth, and potentially could reveal some small amount of additional information above and beyond what a website can obtain in-band ([NETWORK-ERROR-LOGGING], for instance). User agents MUST allow users to disable reporting with some reasonable amount of granularity in order to maintain the priority of constituencies espoused in [HTML-DESIGN-PRINCIPLES].

Comment 3

[Simon Friedberger [:simonf]]

So, the obvious patch just adds a condition to the reporting using the same pref. Would that be okay, Dan? What did you have in mind for making this prefence more meaningful?

Comment 4

[Simon Friedberger [:simonf]]

Also adding Tom.

Comment 5

[Tom Schuster]

We can't use the same preference (dom.reporting.enabled) for level 2, because we still haven't enabled the new report API by default. I personally think giving extensions the ability to disable these requests is good enough and we don't need to do anything here.

Comment 6

[celenity [:celenity]]

I agree it should probably be a different preference, but I strongly disagree with:

I personally think giving extensions the ability to disable these requests is good enough and we don't need to do anything here.

Extensions pose their own privacy and security concerns (as well as can harm performance, etc...), and it's generally a good idea (purely speaking from a privacy & security perspective) to keep them to a minimum. It's also my understanding that as the name suggests, extensions are meant to extend the browser and provide optional functionality. These reports are being generated and sent from the browser itself on the user's behalf, so I don't think it's reasonable to require an extension just to disable them. If we're going to require an extension to disable submission of these reports, perhaps we should require an extension to send them in the first place?

I'd be curious to hear more of the rationale behind your position on this as well.

Comment 7

[Tom Schuster]

Attachment: Bug 1964249 - Add pref to disable all CSP reporting. r?simonf

Comment 8

[Tom Schuster]

Attachment: Bug 1964249 - Add pref to disable all CSP reporting. r?simonf

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/7a11f77e4907
Add pref to disable all CSP reporting. r=simonf

Comment 10

[agoloman]

https://hg.mozilla.org/mozilla-central/rev/7a11f77e4907

Comment 11

[Daniel Veditz [:dveditz]]

(In reply to Simon Friedberger (:simonf) from comment #3)

So, the obvious patch just adds a condition to the reporting using the same pref. Would that be okay, Dan? What did you have in mind for making this prefence more meaningful?

A bit late, but no, I meant CSP reports should not re-use the Reporting API pref —but Tom covered that in comment 5.

We missed an opportunity on the naming, though. You could interpret the Reporting API spec's "reasonable amount of granularity" in different ways, but if we want to interpret that as "per feature" instead of "site by site" (which is unmanageable for most people) we could have dom.reporting.<feature>.enabled prefs, and then share dom.reporting.csp.enabled to cover both new and old reporting once we do hook up the Reporting API to CSP. But that's bikeshedding and unimportant. If we ever do implement the recommended granularity we can figure out pref names at that time.