Unable to allow a specific document domain via no-csp-reports

[NyanKiyoshi]

Prerequisites

• I verified that this is not a filter issue
  • Filter issues MUST be reported at filter issue tracker
• This is not a support issue or a question
  • Support issues and questions are handled at /r/uBlockOrigin
• I performed a cursory search of the issue tracker to avoid opening a duplicate issue
  • Your issue may already be reported.
• I tried to reproduce the issue when...
  • uBlock Origin is the only extension
  • uBlock Origin with default lists/settings
  • using a new, unmodified browser profile
• I am running the latest version of uBlock Origin
• I checked the documentation to understand that the issue I report is not a normal behavior

Description

Currently it seems it is not possible to allow a specific tab's hostname via custom rules without allowing the hostname of the CSP target for the report.

For example:

1. Current tab site to allow to send CSP reports: csp-ublock.vanille.bid
2. report-to for CSP: example.com

This rule will not work:

no-csp-reports: csp-ublock.vanille.bid false

This rule will work:

no-csp-reports: example.com false

A specific URL where the issue occurs

https://csp-ublock.vanille.bid

Steps to Reproduce

1. Open the uBlock logger,
2. Load the page, it will be blank,
3. Console should confirm that a <script> was blocked and reported (otherwise an alert() will fire),
4. Try to add a new rule (My rules, so) with: no-csp-reports: csp-ublock.vanille.bid false
5. Reload the page,
6. It should still be showing blocked in the uBlock logger instead of allowed,
7. Change the rule to no-csp-reports: example.com false,
8. Logger should show that it allowed it.

Expected behavior:

I would expect to not fully allow a given CSP ingesting service, e.g. example.com (or a real one: ingest.sentry.io/api/security/), rather be allowed to allow a given domain to send CSP reports to a specific target (e.g. csp-ublock.vanille.bid to send to example.com, or as well as a rule that would allow vanille.bid and its sub-domains to report to example.com).

Actual behavior:

Only the third-party CSP report destination can be allowed rather than the first-party itself (or both combined as a and condition).

Your environment

• uBlock Origin version: 1.32.4
• Browser Name and version: Firefox 86.0a1
• Operating System and version: Mac OS X 10.16

[gorhill]

I would expect to not fully allow a given CSP ingesting service, e.g. example.com [...] rather be allowed to allow a given domain to send CSP reports to a specific target

Why would you expect this? Why wouldn't the behavior you expect be similarly unexpected by somebody else?

[gorhill]

Maybe what you report here could have been debated back when the feature was developed.

The problem at this point is that you are asking to change a behavior that exists ever since no-csp-report was first introduced, it's too late for this as this could cause the expected blocking behavior of already existing installations to change without warning.

[gorhill]

Well, in this commit introducing the no-csp-report switch, I do use the hostname of the tab to lookup the state: gorhill/uBlock@95b25f7#diff-d88e38513efe4e855f66a53f0ba00fa16264d07f8d8fe7100cf3131a74fbe0b4R655

I will have to further investigate when this was changed and why.

[gorhill]

This was changed in gorhill/uBlock@75659a3, because of gorhill/uBlock#3260.

[gorhill]

Given that this was a deliberate decision as per above commit/issue, I can't change back the behavior.

[NyanKiyoshi]

This was not a feature request. But a request for more information about behavior and whether or not it might be possible to extend such rules.

Currently, we have a policy behavior that goes from one extreme "Block all CSP " to another extreme "Block CSP but allow all CSP going to that third party" rather than allowing more control and a smoother transition: "Block all CSP, but trust some first-party against a specific third party".

Just as lists give users control, rather than being blocked by rules that are too strict and too permissive - for which I assumed a lack of trust in the lists, why something like this could not be done directly by a custom rule in a local list.

One could not trust a particular third party that could be used by the whole Internet except against a particular first party that the user fully trusts. That is why we have so much control over the lists, users can have control instead of being locked between two extremes.

Having such a rule wide open goes against the privacy concern that leads uBlock to put in place this CSP feature–which is good and important in itself, just as is CSP, which reporting is and was made for.

However, from what I saw when I dug into the code before opening the issue, it would be too hard to change as the configuration does not seem to be very flexible; especially for the number of people who would consider adding such exceptions and people who understand the role and implication of these policies.

[gorhill]

too hard to change as the configuration does not seem to be very flexible

What you have in mind matches better a dynamic filtering rule, to be able to craft rules with both source and destination, i.e.:

* * report block
csp-ublock.vanille.bid * report noop

But it's not something I see worth being added, especially given I have resisted adding other more common types than the ones already in there.