There is currently no filter option for cspreport with ABP filter syntax, and this means that if one wants to block all CSP reporting with a static filter, the other option has to be used, and this of course would probably lead to a lot of false positives since other is used for everything else which does not match one of the existing request types.
There are privacy considerations arising from CSP reporting, as spelled out in Reporting API / Privacy Considerations.
One key excerpt which explains well the rationale for the proposed new per-site switch (my emphasis):
That said, it can鈥檛 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].
I currently know no way in either Chromium or Firefox to "disable reporting with some reasonable amount of granularity", let alone do it easily.
I am also concerned that in the _Reporting API_ document, it is said that network requests of the new Reporting API are made "out of band", which I believe could mean "behind-the-scene" in uBO parlance, and which is of concern as behind-the-scene requests are not fed to uBO's filtering engine by default.
A per-site switch in uBO to disable/enable CSP reporting on a per-site basis would address the issue of "disable reporting with some reasonable amount of granularity".
For the time being, I wouldn't want to add yet-another per-site switch in the popup panel, as its purpose and the rationale might be more difficult to understand for majority of users.
However, I will make the option to globally disable CSP reporting in the _Settings_ panel along with other per-site switches -- with the usual link to the wiki explaining why one might one to globally disable CSP reporting. So any user would be able to easily disable/enable CSP reporting globally, and more advanced users could create more granular rules directly in the _My rules_ pane.
Ideally, I want this new per-site switch to be released at the same time as fix to #3140.
A setting such as "Disable CSP reporting" under Privacy would be preferable, if possible.
Good point. I will still implement it as a per-site switch internally, because maybe in some future I will come up with an idea how to make it available to the popup panel -- and in such case uBO would be able to report the number of CSP reports fired by a web page so that they are readily informed about this.
There is currently no filter option for cspreport with ABP filter syntax...
Why not add one? Combining with third-party may be more "polite", even as default.
Did you think about stripping report-uri(to) from header? Too much overhead?
Yes, that could also work. A directive like $csp_report, so users can blanket block via a static filter too.
Why not add one?
Modifying the static filtering engine is less trivial than adding a per-site switch, and having to craft a static filter is quite less user friendly than a point-and-click per-site switch. Also, in my opinion if one is worried about CSP reports, I don't see the distinction 1st/3rd party as being terribly useful (think of Twitter example). I also think that reverse-proxying such network requests could be a maybe-not-so-uncommon thing occurring out there. If one has privacy concerns with regard to CSP reports, it's then best to just block all of them.
Did you think about stripping
report-uri(to)from header?
That's what uBO used to do when it modified existing script-src directive to block inline scripting. This was an ugly solution which requires uBO to become a sort of CSP directives parser. This was refactored to take advantage of the comma separator, so uBO no longer needs to try to parse existing directives, it just appends its own with a comma as a separator. Beside, I like to have uBO keep its ability to report what sites do (or try to do) wherever possible, and stripping the report-uri would eliminate a source of information.
Most helpful comment
Modifying the static filtering engine is less trivial than adding a per-site switch, and having to craft a static filter is quite less user friendly than a point-and-click per-site switch. Also, in my opinion if one is worried about CSP reports, I don't see the distinction 1st/3rd party as being terribly useful (think of Twitter example). I also think that reverse-proxying such network requests could be a maybe-not-so-uncommon thing occurring out there. If one has privacy concerns with regard to CSP reports, it's then best to just block all of them.
That's what uBO used to do when it modified existing
script-srcdirective to block inline scripting. This was an ugly solution which requires uBO to become a sort of CSP directives parser. This was refactored to take advantage of the comma separator, so uBO no longer needs to try to parse existing directives, it just appends its own with a comma as a separator. Beside, I like to have uBO keep its ability to report what sites do (or try to do) wherever possible, and stripping thereport-uriwould eliminate a source of information.