CSP used for spying on blocked domains(?)

[pale guru]

As far as I understand Content Security Policy was designed as a security feature that is POSTing back certain domains that don't fit the rules.

The report-uri and report-to directives are a convenient way for a web site owner to debug errors and faulty setups, but (in my view) also for spammers to spy on what domains are blocked on a client's web browser (ie. etrias.nl which seems to be a fake shop with no imprint or address). Pale Moon dutifully POSTs back all (blocked) domains.

I saw there can be set security.csp.enable → false in about:config, but that obviously disables the whole CSP thing.

Is there any way to only switch off the POST reporting in Pale Moon (beside patching XUL)?

[Moonchild]

I'm not sure what your concern is here.

CSP has built-in reporting functionality, yes, but that only reports back what the server itself has supplied through the policy. So it's only able to verify what has been blocked from its own supplied page content based on its own supplied policy. It's not possible to suss out what a browser would block otherwise unrelated to supplied content and not resulting from the CSP.

[pale guru]

Afai understand, Site x.com sets CSP to google.com, and if the browser cannot access it, it reports it back to the web server?

Or does Pale Moon only report those domains that were blocked due to the defined CSP rules?

My concern is that I would like to switch off the report. Any chance to get a about:config pref for this?

[Moonchild]

Afai understand, Site x.com sets CSP to google.com, and if the browser cannot access it, it reports it back to the web server?

No

does Pale Moon only report those domains that were blocked due to the defined CSP rules?

Correct. as I already stated. Only content specifically blocked by applying the CSP rules will be reported.

My concern is that I would like to switch off the report. Any chance to get a about:config pref for this?

It's possible to do this, although I don't really see the point in switching this off. It will not provide you with any privacy or security benefit and actively harms webmasters in the process of rolling out/troubleshooting CSP on their sites.

[pale guru]

The thing is that I don't like to be the beta site tester of somebody else's website, and therefore like to switch off the CSP report.

[Moonchild]

The thing is that I don't like to be the beta site tester of somebody else's website, and therefore like to switch off the CSP report.

You would be, in that case, whether our reporting is on or off, and your experience will be "beta" either way if they do live beta testing. The only difference is that with it off, the webmasters will not get any information that something is wrong with their CSP. Especially if you're on a less than mainstream browser, this will only help you.

[Kris_88]

The thing is that I don't like to be the beta site tester of somebody else's website, and therefore like to switch off the CSP report.

@Moonchild
There is logic to this. Let's then automatically report problems in scripts and styles... I don't want the site owner to use my browser as a debugging device. If he includes someone else’s advertising on his site that violates CSP, then let him check it himself before including it, and not assign the role of the checker to me. Yes, the browser checks the CSP, but it is my free will whether I want to report problems or not. This is the same decision of mine as, for example, to allow or prohibit the execution of scripts...

[Moonchild]

... The whole point of CSP reporting existing is because webmasters can't test every conceivable combination before deployment.
It's not comparable to allowing or blocking ads or scripts, but I don't think it's easy to explain the difference in impact in a few paragraphs, if it's already difficult to explain to the OP what reporting does and does not do.
Like I said there's a way to do this and to block any and all reporting, and linking it to a pref. I just don't really see the point other than deliberately breaking with the spec for no gain whatsoever, just because you can (if I add it). As I already said, CSP reporting in no way impacts your privacy or security, because all it reports on is the supplied policy itself.

That being said, if there's enough people who want this, then we can make it even more "your browser, your way" by adding this knob to the platform.

[athenian200]

I think it's a very bad idea to allow turning this off.

For one thing, it makes us less spec-compliant. For another, we're a small browser that would actually benefit more from webmasters having more information to tweak their websites. Also, users who turn this off would help reinforce the idea that Pale Moon is a bad citizen that simply doesn't play by the same rules as other browsers, and thus isn't as trustworthy as something based on Chromium.

I know we're a bit more privacy-oriented than mainstream browsers, but I kind of think a line needs to be drawn somewhere, or people will start expecting us to be Tor Browser... I'm not so sure we want to be more attractive to that crowd.

[RealityRipple]

It's also conceivable someone would use the report system intentionally to confirm that the client is in fact a standards-following web-browser, and show captchas, bot block pages, or other unwanted behavior by creating and checking for an intentional failure.

[Kris_88]

and thus isn't as trustworthy as something based on Chromium.

Who and what will think - is his personal right ... but the user's right is to do as he considers necessary.

However, there is an important reason not to turn off the reports. If the banking site receives a report that something incorrect is added to the page, then the site will be able to warn the user about the possible hacking of the browser and not fulfill a dubious transaction.

[athenian200]

Who and what will think - is his personal right ... but the user's right is to do as he considers necessary.

I don't think a user's right extends to the point that developers are obliged to give them any option they ask for. That's just not how the world works. We do sometimes, as developers, make decisions rather than giving control to the user. Pale Moon may lean more on the side of giving control to the user than mainstream browsers, but that's not an absolute and never has been.

However, there is an important reason not to turn off the reports. If the banking site receives a report that something incorrect is added to the page, then the site will be able to warn the user about the possible hacking of the browser and not fulfill a dubious transaction.

That's more along the lines of what I'm thinking. I am fairly sure I can imagine a user turning this on only to complain that their banking website doesn't work. Worse, if the banking website can tell they were using Pale Moon, such sketchy behavior might encourage them to put us on a blacklist that they share with others, should they think we're illegitimate. Those consequences might affect all users of the browser, not just those that want the feature, and I think it's safe to say that an individual's rights end where what they want might start to affect others in the same community.

[Moonchild]

Who and what will think - is his personal right ... but the user's right is to do as he considers necessary.

Not to the detriment of the overall ecosystem. CSP is an important and well-defined spec reviewed by many sec teams to make sure it strikes the balance between protecting against XSS and giving webmasters the tools to make sure their policies are applied as-intended.

But you will always have the right to patch it out yourself, build from source, and run your altered copy all day and all night.

[Enobarbous]

Not that I want to get involved in the discussion, but I think it's worth noting that uBlock Origin does have a "Block CSP reports" option...
Just saying)

[jobbautista9]

And it's enabled by default on Firefox because of scripts from extensions being able to trigger CSP violations... https://bugzilla.mozilla.org/show_bug.cgi?id=1588957

I think we already suppress CSP for scripts from chrome:// and file:///, right?

[athenian200]

Not that I want to get involved in the discussion, but I think it's worth noting that uBlock Origin does have a "Block CSP reports" option...
Just saying)

https://github.com/gorhill/uBlock/issues/3150

Checked, and they do seem to have an implementation of this. So this is technically a feature that is possible to implement in an extension... not sure how I feel about that, but that's out of our hands. Anyone who wants the feature can probably just use uBO anyway, which means we really don't need to imply endorsement for such an approach by having it out of the box.

And it's enabled by default on Firefox because of scripts from extensions being able to trigger CSP violations... https://bugzilla.mozilla.org/show_bug.cgi?id=1588957

I think we already suppress CSP for scripts from chrome:// and file:///, right?

Ah, it appears that bug is still unresolved? And also, it seems like it's about websites being able to see user scripts that are internal to the browser, which I think is probably an issue that came up for them because they switched to WebExtensions. I don't think it affects XUL, if I'm understanding correctly.

[Kris_88]

By the way, this bookmarklet, which speaks the selected text, does not work on the Google search results page.

Code: Select all

javascript:(function(){if(speechSynthesis.speaking){speechSynthesis.cancel();};var%20msg=new%20SpeechSynthesisUtterance();msg.text=window.getSelection().toString();msg.lang="en-US";speechSynthesis.speak(msg);})();

The script generates the following error:

Code: Select all

Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src 'nonce-li9-26DHld9LAi1HvnzvAg' 'strict-dynamic' 'unsafe-eval' 'unsafe-inline' https: http:”).

As far as I understand, CSP should not check bookmarklets?

As for reports, I observe a negative trend. If previously programs would at least ask the user for permission to send reports, now they send anything without user confirmation and sometimes this cannot be turned off at all. Software developers increasingly consider a user's computer to be their own when the user runs their program on it. And in this matter I will always be on the user's side...

[gepus]

I think it's worth noting that uBlock Origin does have a "Block CSP reports" option...

Not only that it has this option but it's also granular.
You can globally block while allowing for certain addresses or vice versa. You can globally allow while blocking for certain addresses.

[pale guru]

The reason why I am so mad about this CSP stuff are some sick implementations of sites like DHL.de. It's the same reason why you run (part) of this forum: Web sites get too complicated for no good reason. Every single CSP HTTP reply header of DHL.de counts 6531 bytes. For me it is a list of irresponsible outsourcing of responsibility and (in)security – until the next ransom attack, “data wealth” (as chancellor Merkel once called it), or their web site just “does not work”, such as their parcel tracking (which is rather an effect of the measurements against being tracked myself).

Pale Moon does have an about:config switch to turn CSP on or off completely. If you don't want to create another switch for the report, I'll be happy using the existing one for another checkbox on my Prefbar.

@Moonchild: You don't need to explain CSP. I implemented it on my web sites within 80 bytes. And Pale Moon will tell me if there is any problem. Btw, if you have an IBAN I can send you a few bucks.

[Moonchild]

And it's enabled by default on Firefox because of scripts from extensions being able to trigger CSP violations... https://bugzilla.mozilla.org/show_bug.cgi?id=1588957

I think we already suppress CSP for scripts from chrome:// and file:///, right?

AFAIK that is only an issue because WebExtensions aren't browser extensions and run in a (pseudo-)content HTML environment, so will be exposed to and subject to content rules (the "C" in CSP). CSP will, by design, apply to anything running in content, including injected scripting running in content (which is why bookmarklets are affected by some CSPs). file: URLS aren't affected because no servers (and therefore no server headers) are involved, through which CSPs are applied. chrome: is not a content environment.