As per comment#0 considering this issue as Feature Request and marking as Untriaged. 

+msramek@/engedy@ to triage from a privacy perspective, +juliatuttle@ for Reporting API: I vaguely recall some conversation about tying the reporting API to one of the privacy settings that controlled background requests. Did that happen?

Yes, we want to repurpose the background sync setting into a "sending stuff in the background" setting, which will basically apply to everything built on the Reporting API.

juliatuttle@ has a design doc (and I think a sketch of implementation too?).

Yes, I plan to implement this in Reporting. It's already implemented in Domain Reliability, which was the precursor to Reporting/NEL, so I'm vaguely familiar with how to do it.

Right now, I plan to unconditionally allow synchronous reporting (i.e. we start a "deliver this report" job right when a report is generated, it tries each of the endpoints in order, and if it doesn't find any working ones, the report is discarded and there's no retry later). There wouldn't really be a "don't send CSP reports" option, just a "don't let any kind of reports or JS or anything hang around and make requests in the background". Is that acceptable?

Re.#9

I am not sure. As per the opening post, the standard says:

"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]."

What you suggest ("any kind of reports or JS or anything") sounds like one single setting for various kinds of things which is not really granular (although it may be good for privacy).

Re. background requests and privacy please also look at  issue #795526  and consider if you can also provide a setting to block the background requests mentioned there.

 Issue #795526  is a wider UX issue that I can't really help with, but if the outcome there is that we add more granular settings for lots of background requests, I'll happily integrate my code with that. I'm just working on a single feature here, not setting browser-wide privacy policies.

What's the use case for, say, enabling certificate transparency violation reports but disabling content security policy reports?

Here is an use case which comes to mind:

A web developer testing a website may be willing to test how CSP reporting works for it. So he would go to the proper settings in chromium and enable CSP reporting for his particular site. Still he may not want to send CSP reports to other websites which he may browser during the development. So granularity may be similar to how one enables cookies/js/flash for a site or globally. Perhaps it makes sense to have separate group of controls?

The link to the standard does not mention certificate transparency explicitly. It does mention priority of constituencies (https://www.w3.org/TR/html-design-principles/#priority-of-constituencies). I am not aware what other granularity the document may be considering. Perhaps it makes sense to note that CSP and certificate transparency violations are reported to different entities, so one may be willing to control what to report to who.

From user privacy standpoint it makes sense to have all background requests disabled by default. That's why I mentioned  issue #795526 , so you could probably consider UI controls for grouping the granular privacy related toggles.

I completely agree that we should have per-origin controls for this, and that's what I'm implementing for Reporting. What I'm unclear on is, to quote your linked document, the "cost or difficulty" to the user if they can't disable some but not all of these types of developer-oriented error/violation/etc. reports.

One thing I haven't yet considered in Reporting is control over endpoints -- I've been focusing on allowing/disallowing origins from sending data, but it might be a useful knob to be able to disable background traffic sent to a particular analytics company whose privacy policy isn't great. I'll make a note of that in the other bug.

I'm not on privacy eng or UX, so I can't help with the granularity of or UI for other features' privacy controls.

They seem to recommend granularity as the factor which would ensure less difficulty to the general user but also provide more control to the advanced user *even if* such design is more difficult to the implementor. UI-wise (whoever is responsible for that) that should not be a problem as it is already available for cookies/js/flash etc. (global setting + individual black/white-listing per origin).

Agreed that this should be a content setting, which would automatically give us a global default setting as well as per-origin overrides. I think that is indeed an important dimension which to have finer granularity for.

On the other hand, given the site can choose between multiple APIs to send data in the background, I would argue that having an individual knob for each of those API would only add complexity, and would not have actual privacy/security benefits. Unless all APIs are disabled, the site could always just use whatever API is still enabled. I also believe that "sending data in the background after I close the tab" is a concept that is semantically clean and relatively easy for users to understand.

+1 to "sites can just try all APIs available, so restricting one isn't practically useful".

engedy@: This was a requirement from your privacy review, correct?

Assigning to dcreager@ for triage.

The per-origin "background sync" permissions check for Reporting, as described up-thread, is implemented.  If the user turns off background sync for an origin, Reporting will not upload any reports about that origin.  This currently applies to all report types; there isn't currently the ability to turn off (e.g.) CSP, but keep on NEL, for a particular origin.

If the privacy review also wants a separate option that lets the user turn off CSP for *all* origins, I would argue that should belong just to the CSP implementation — it wouldn't generate any reports or hand them off to Reporting if the user has activated the "no CSP" option.

I see, sorry for my confusion. I don't think we need a separate toggle for each reporting type, and I'm happy to hear that we have a global toggle for reporting already. If that's the case, and it's already wired up, then we can close this out.

> I'm happy to hear that we have a global toggle for reporting already

A global toggle doesn't really provide granularity. Additionally the text of chrome://settings/content/backgroundSync toggle says:

"Do not allow recently closed sites to finish sending and receiving data"

I don't know if CSP reports happen when the site is closed or while it is opened. The fact is - this setting does not provide even additional explanation. I think this may need more serious attention then simply mixing it with other udner-the-hood background syncs and burring everything under a common toggle. Please consider comments 12 and 14.