Ublock: NoScript WebExtension and its CSP reports

[salim-b]

Describe the issue

I've enabled _Block CSP reports_ so I got an entry no-csp-reports: * true in my rules. Today the NoScript WebExtension for Firefox 57+ came out and I noticed several CSP reports from the domain fake-domain.noscript.net appearing in uBO's logger, e.g.:

Then I found this interview with NoScript's main developer Giorgio Maone in which he says he would be using CSP reports in a "creative" way to rebuild certain of the old extension's features in the WebExtension:

Dynamic permissions for embedded JavaScript are not natively supported by WebExtensions. Rather than requesting a new API, I am using Content Security Policies (CSP), a Web Application Security standard, to control scripting execution and other security properties of the webpage.

Therefore I tried to set the explicit allow rule no-csp-reports: fake-domain.noscript.net false analogous to what's described in uBO's Wiki to allow CSP's for the domain fake-domain.noscript.net only. Now obviously this didn't work because the CSP reports still get blocked by the no-csp-reports: * true rule (at least that's what uBO's logger shows, the same as in the screenshot above).

I don't have enough understanding of the technical details involved to say what's going on/wrong here. As far as I can tell this hasn't caused any practical issue/limitation on my side. But on the other hand I'm still becoming accustomed to NoScript's new – let's say "in need of getting used to" – interface and can't really tell if it works completely as it should (i.e. provides all the protection it should).

Update:
When I allow steemit.com in NoScript, the NoScript CSP reports don't show up but ones from steemit.com instead:

So I guess uBO's logger "wrongly" allocates the Steemit's CSP reports to the NoScript domain/can't allocate them to the actual domain they're originating from?

Besides that, I've noticed that when a site like Steemit is blocked in NoScript, noscript.net appears as a blocked third-party domain in uBO's panel (and allowing it doesn't do nothing, i.e. still red/blocked).

Update 2:

NoScript's CSP reports only fire when the first party domain is _not_ whitelisted in NoScript. This might result in fake-domain.noscript.net being able to reconstruct the browsing history as gorhill warns in this comment.

Update 3:

According to a statement from Giorgio Maone there's no privacy issue (browser history leakage):

"fake-domain.noscript.net", as the name implies, is a domain which does not resolve to anything, and since noscript.net is under my control I can make sure nobody makes it real domain. It's used as the report URI for the script-blocking CSP, in order to catch LOCALLY whatever has been blocked by NoScript and show it in the UI. As soon as the request is initiated, is processed LOCALLY by NoScript and blocked, so the information never leaves the browser. If, by accident (e.g. because you disable NoScript while a page with the CSP loaded is still active) the CSP report is fired and not caught, as I said the domain doesn't resolve and the request just times out.

One or more specific URLs where the issue occurs

E.g. this site: https://steemit.com/spanish/@vieira/el-materialismo-el-mayor-problema-de-la-sociedad

Your settings

• OS/version: Ubuntu 16.04 LTS x64
• Browser/version: Firefox 57.0
• uBlock Origin version: 1.14.18

Your filter lists

Enabled all built-in filter lists, minus:

• Adguard Mobile Filters​​​​​​​​​
• Fanboy’s Social Blocking List​​​​​​​​
• the country specific filters (except DEU)

Your custom filters (if any)

Disabled them all, issue still occurs.

Besides I'm using _"AAK-Cont Filter For uBlock Origin​"_ with Greasemonkey (the new WebExtension).

[gorhill]

So I guess uBO's logger "wrongly" allocates the Steemit's CSP reports to the NoScript domain/can't allocate them to the actual domain they're originating from?

How did you come to this conclusion?

Why not a more simple explanation which matches what logger is reporting you?

The report to steemit.com is the result of the server steemit.com asking to have CSP violations reported to its server. Your logger shows that uBO is injecting a neutered version of Google Analytics script, hence this triggers a spurious CSP violation: steemit.com serves a CSP header, and part of the CSP header is report-uri /api/v1/csp_violation (use the browser's network pane to see headers). This is what you see in the logger.

[salim-b]

The report to steemit.com is the result of the server steemit.com asking to have CSP violations reported to its server. Your logger shows that uBO is injecting a neutered version of Google Analytics script, hence this triggers a spurious CSP violation

This (which the logger only shows when a site is allowed by NoScript -> 2nd screenshot) I understand since I actually took the time to read the Wiki entry about CSP reports.

How did you come to this conclusion?

Ehm, looking at what the logger reports when a site is blocked by NoScript (1st screenshot)? I don't understand why fake-domain.noscript.net is reported as the domain. Also I don't understand why noscript.net appears as a blocked third-party domain in uBO's panel when a site is blocked in NoScript (this hasn't been the case before the transition to WebExtensions).

[gorhill]

By the way, when you use no-csp-reports: fake-domain.noscript.net false, it means _"do not block CSP reports when visiting fake-domain.noscript.net"_. These are per-site switches, where the "per-site" part refers to the site you are currently visiting.

So mainly this means that uBO's feature of blocking CSP reports is incompatible with NoScript's uses of CSP reports.

Not sure at this point how this could be made compatible, aside not using the feature to block CSP reports in uBO.

[gorhill]

Maybe I could change the semantic of no-csp-reports from testing 1st-party hostname to testing 3rd-party hostname. I have to think about it to see if this would be "ugly" conceptually. It does feel this would make sense.

[salim-b]

By the way, when you use no-csp-reports: fake-domain.noscript.net false, it means "do not block CSP reports when visiting fake-domain.noscript.net". So mainly this means that uBO's feature of blocking CSP reports is incompatible with NoScript's uses of CSP reports.

Ah, that at least clears things a bit up, thanks.

Maybe I could change the semantic of no-csp-reports from testing 1st-party hostname to testing 3rd-party hostname. I have to think about it to see if this would be "ugly" conceptually. It does feel this would make sense.

Unless you don't want to introduce a source-destination-semantic like in dynamic filtering rule syntax this sounds reasonable. But what do I know 🙈 Thanks for looking into this in any case!

[gorhill]

I will change the semantic, it makes more sense after all, and this is a good time to do it while the CSP report-blocking feature is really one single checkbox.

So this goes from

"Block all CSP reports when visiting such site"

to

"Blocks all CSP reports to such server"

[uBlock-user]

he would be using CSP reports in a "creative" way to rebuild certain of the old extension's features in the WebExtension

That's nothing more than PR BS. He's using CSP_reports to collect info for his own purpose, which is not a surprise[1] given how he tried to evade ABP filters[2] before. use uMatrix rather, offers far more useful functionality and free from any such abuse.

[1] - https://liltinkerer.surge.sh/noscript.html

[2] - https://adblockplus.org/blog/attention-noscript-users

[gorhill]

he says he would be using CSP reports in a "creative" way to rebuild certain of the old extension's features in the WebExtension

He didn't say he would use CSP _reports_ in a creative way, he said he would use CSP in a creative way. In other words, use CSP to control first party script execution, just like it has been done with uMatrix/uBO since the beginning (2013 with HTTPSB). See https://github.com/gorhill/httpswitchboard/wiki/Blocking-javascript-execution-reliably-in-Chromium-based-browsers.

He's using CSP_reports to collect info for his own purpose

Let's not spread misinformation here please, such claims should always be backed up by credible evidence. I can't find where I read this, but he explained somewhere why the use of fake-domain.noscript.net. Without knowing the details, I have no opinion on whether this is good or bad. Though I would wonder if the extension disables networkPredictionEnabled so as to avoid DNS pre-resolution and from connecting at all to noscript.net (browsers typically preemptively open TCP and SSL connections).

[salim-b]

which is not a surprise[1] given how he tried to evade ABP filters[2] before.

This was indeed an unacceptable (and stupid) episode. But it happened over 8 years ago, Maone soon realized his own failure back then, apologized and even seemed to deeply regret it. Since then I haven't heard of anything bad related to NoScript. And given its popularity (Tor Browser e.g.) I assume its code is subject to public scrutiny on a regular basis.

That's nothing more than PR BS. He's using CSP_reports to collect info for his own purpose

Do you have any information that actually proves this rather severe accusation? If yes, I'm very interested to learn more! If no, you're spreading nothing more than FUD. And regarding Wladimir Palant's blog post you've linked to: His criticism is hard to beat in hypocrisy given that ABP/Eyeo is doing just the same thing with its by-default-whitelisted acceptable ads program.

[uBlock-user]

Do you have any information that actually proves this rather severe accusation?

No I don't, but I don't trust him rather. You're quick to forgive him for what he did twice and is doing now, I can question that too. People like him lose my trust immediately and he did that intentionally just like he puts popups in his extension every time it updates to a new version which leads to his home-page filled with malware infested ads.

If you still support this guy after finding all this, I would say something's terribly wrong with you. Anyways, this is rather getting personal which is something I don't want to get involved as my post simply meant to advise you against using NoScript in the first place. If you still intend to do, best wishes.

[uBlock-user]

Let's not spread misinformation here please, such claims should always be backed up by credible evidence.

You remember that scott guy ? He was also collecting information just like this when someone visited his website, so what's different from this one ? They're both doing it for themselves, good or bad doesn't matter. It doesn't take a genius to realise that. This is simply tracking nothing more, nothing less, whether it's used in a constructive way or purely other purposes that remains to be seen.

[salim-b]

If you still support this guy after finding all this, I would say something's terribly wrong with you.

Well, I'm just no misanthropist. I try to form my opinions on the basic assumption that people make mistakes (since I do as well). You can call me naive for that, I don't mind. Regarding the actual situation you're referring to: I've read the arguments of both sides and came to the (personal) conclusion that Maone didn't act out of viciousness but was rather driven by his ego and maybe financial (ad income) reasons. Since he changed his mind about acting against ad blockers (and their users) I'm happy to "forgive" him. But my trust in NoScript is not only based on the integrity of its main developer but also the trust the Firefox AMO people (due to giving it the status of a "trusted extension") and the Tor Browser community have in the extension.

They're both doing it for themselves, good or bad doesn't matter. It doesn't take a genius to realise that. This is simply tracking nothing more, nothing less

Still you're not able to provide any evidence for these accusations. Why should I trust you and your statements in the first place?

[uBlock-user]

The evidence is the CSP_reports being fired without you being informed or asked for a consent or any kind of OPT IN feature. This is data collection and data collection is always expected to be OPT IN, not like this. If you still can't see this as evidence, then clearly there's no point in me further extrapolating it for you and it seems you have already made your choice too.

This is not a court of law, so I don't need to spell everything out, the evidence is there in the picture you linked here in the first post.

[gorhill]

As said I can't remember where I read about the fake-domain.noscript.net thing. Anybody has a link?

(please let's leave the off topic out of here, people have differing opinions on the topic, that is understood and endless debate about this here is just noise for me).

[uBlock-user]

Ofcourse, gorhill, I understand that, but he questioned me, so I had to justify it.

And yeah I can't find anything on fake-domain.noscript.net on Google either.

[salim-b]

The evidence is the CSP_reports being fired

That doesn't prove Maone is doing it only "for himself" as you claim. But gorhill is right of course, the discussion about the terms of trust is pretty off-topic.

All I can say is that the CSP reports to fake-domain.noscript.net only appear in the logger when a site (first party) is not allowed in NoScript. And they don't seem to be related to CSP reports that the actual site you're visiting might fire (as I first assumed).

[gorhill]

only appear in the logger when a site (first party) is not allowed in NoScript

So this probably means NoScript is injecting a CSP script-src directive to the response headers (like uMatrix/uBO have always been doing), but also a report-to (or to be deprecated report-uri) directive to cause CSP violation reports to be fired to fake-domain.noscript.net server (something I will never do).

With these CSP reports, you need to put a lot of trust in whoever owns the remote server, because these CSP reports leak your detailed browsing history. See https://github.com/gorhill/uBlock/issues/3140#issuecomment-337635414 (hence the purpose for the new _"Block CSP reports"_ in uBO).

[salim-b]

With these CSP reports, you need to put a lot of trust in whoever owns the remote server, because these reports leak your detailed browsing history

That sounds pretty serious! I've asked on the NoScript forum what those CSP reports are all about and referenced this issue. Let's see what they answer...

[gorhill]

That sounds pretty serious!

That's why I wanted to read about this. One possibility is that the extension itself is blocking these before they leave the browser, though as said DNS lookup and preconnection should also be prevented to be thorough.

[uBlock-user]

If you're not blocking CSP reports then yeah you will have to trust the remote server to which they're sent, that's the risk.

[darkred]

As said I can't remember where I read about the fake-domain.noscript.net thing. Anybody has a link?

@gorhill Here: https://hackademix.net/2017/11/21/noscript-1011-quantum-powerball-finish-and-rebooting/#comment-38450

Comment 105 (November 21st, 2017 at 6:44 pm)
_Giorgio says:_

1. "fake-domain.noscript.net", as the name implies, is a domain which does not resolve to anything, and since noscript.net is under my control I can make sure nobody makes it real domain. It's used as the report URI for the script-blocking CSP, in order to catch LOCALLY whatever has been blocked by NoScript and show it in the UI. As soon as the request is initiated, is processed LOCALLY by NoScript and blocked, so the information never leaves the browser. If, by accident (e.g. because you disable NoScript while a page with the CSP loaded is still active) the CSP report is fired and not caught, as I said the domain doesn't resolve and the request just times out.

[gorhill]

As soon as the request is initiated, is processed LOCALLY by NoScript and blocked, so the information never leaves the browser.

Well that answers the question: it never leaves the browser, so no worry.

[salim-b]

(...) It's used as the report URI for the script-blocking CSP, in order to catch LOCALLY whatever has been blocked by NoScript and show it in the UI. (...)

Well that answers the question: it never leaves the browser, so no worry.

So this essentially means that when _Block CSP reports_ is enabled in uBO the no-csp-reports: fake-domain.noscript.net false rule is required (which will actually work when https://github.com/gorhill/uBlock/commit/75659a3154e35274e8b6fd75c87560ffd50b37d2 landed in a release) for the NoScript UI to show correct information, right? (I've been wondering all day about the logic behind NoScript's symbols... 😝)

[gorhill]

the no-csp-reports: fake-domain.noscript.net false rule is required for the NoScript UI to show correct information, right?

I don't think so but that would need confirmation. With webext, all extensions are given the opportunity to block a network request. Even if uBO orders the browser to block a network request, the webext framework will allow other extension to examine and block the same network request.