User.js: Q: What does NS have (or will have) that uBo+uM don't

[Thorin-Oakenpants]

Question: I still do not fully understand what NS offers that uBo+uM don't.

• Something about XSS (isn't that covered or is this some special NS thing)
• Something about ABE
• Something about ClearClick
• inclusion type checking?

People have suggested (eg reddit, and here) that you can use NS in global allow mode but leave those four items above as active. Personally I never got an XSS warning from NS (maybe one a year), and the new WebExt version (not sure where they are at) I do not really want to touch with a barge pole (yet, if ever)

Aren't these things in uBo/uM - if not, why not?

@gorhill @Atavic excuse my ignorance, ELI5

[Atavic]

uMatrix - NoScript
Related: https://github.com/gorhill/uMatrix/issues/297
NoScript info in italian.

[Thorin-Oakenpants]

XSS

To answer earthlng's q in the other thread - https://noscript.net/features#xss & also https://noscript.net/faq#qa4_1 . This is obviously the legacy version. I tend to just use XSS as a term to cover all third party scripts and I control it by default denying 3rd parties in uBo etc, and with uM.

In all my years of NS (which always got the requests first before uBo etc), I have only ever had a couple of warnings for this XSS

ClearClicking

https://noscript.net/faq#qa7_1

ABE

https://noscript.net/faq#qa8_1

[Thorin-Oakenpants]

A lot of this info is old. AFAIK clickjacking is nigh impossible now?

[claustromaniac]

I _think_ you don't have to worry much about clickjacking if you deny third-party frames (and/or javascript, of course).

EDIT: IIRC it was also tackled at browser-level at some point. Now I just have to remember where I read that...

EDIT 2: Well, yes and no. What I read was about the X-Frame-Options HTTP header which has been around for about 8 years (according to Wikipedia). Firefox did adopt this header, but it's only a server-side solution.

[Thorin-Oakenpants]

EDIT: IIRC it was also tackled at browser-level at some point

Yeah, I remember reading a couple of bugzillas that covered this. As for denying 3rd party iframes - that's just the first level of defence .. some sites you may need to allow those which means you are at risk (you cannot trust any site is my motto - its not IF but WHEN they get hacked)

[theWalkingDuck]

Sorry, I haven't used Noscript for a long time but are there any Noscripts ABE rules which can not be handled using uMatrix ?

for example the following is the default, may be the only and mostly used, ABE rule in Noscript.

# Noscript
# Prevent Internet sites from requesting LAN resources.

Site LOCAL
Accept from LOCAL
Deny

We can rewrite it easily in the uMatrix way:

[Source]              * -> any external resource 
[Destination] 127.0.0.1 -> which tries to access the localhost or local resources
[Content]             * -> whatever the request or the requested content is ..
[action]          block -> should be BLOCKED

# uMatrix
# Prevent Internet sites from requesting LAN resources.

* 127.0.0.1 * block
* localhost * block    
* [::1]     * block       // block access to ipv6 localhost
* 192.168   * block       // block access to LAN 192.168.x.x

The best practice is to use a separate browser for accessing local resources or using a temporary allow if needed ... but for those who need it permanently

# uMatrix
# Accept from LOCAL

127.0.0.1 127.0.0.1 * allow
localhost localhost * allow
[::1]     [::1]     * allow
192.168   192.168   * allow

btw, don't forget to remove the matrix-off: localhost true rule.

[gorhill]

don't forget to remove the matrix-off: localhost true rule

I have no idea why I added this built-in rule. I will remove it.

[Atavic]

Look for types of XSS here. OWASP has many info about it, mainly server-side.
Look at this PDF on page 24 for info about ABE Rules.

[Atavic]

Also here for OWASP info.

[Thorin-Oakenpants]

56743 .. warning! 17 years old :grin: - bit of a moot ticket for uM users => * * frame block

[Thorin-Oakenpants]

OK, this is good: http://vojtechruzicka.com/preventing-clickjacking/

[claustromaniac]

@Thorin-Oakenpants very nice, thanks!

[Thorin-Oakenpants]

FYI: what does uM have that NS doesn't? rhetorical question

add ability to block web workers on a per-site basis

• https://github.com/gorhill/uMatrix/commit/deeb211c5d489af02fabe419c33e3ae15d3d291e

[Thorin-Oakenpants]

FYI: note, I can't link to the individual review/reply (its on AMO's NS reviews page), so here's a cropped screenie

HOWEVER, if you're after security, you cannot rely on uMatrix over NoScript. For instance, even if you're blocking scripts with uMatrix on a site you don't trust, it can execute JavaScript by exploiting cross-site request vulnerabilities on a site you trust. This is prevented by NoScript's anti-XSS filter.

I still fail to see what NS's so called anti-XSS offers that uMatrix (with all 3p blocked by default) doesn't. It is some special XSS type attack detection to block sh*t even when you allow it by default (I have no idea what NS's defaults are, but I would assume little breakage and not in a hard mode)

[gorhill]

I believe the scenario he has in mind is:

1. site X is suffering from an XSS vulnerability
2. victim allows script execution on site X
3. an attacker knows about this vulnerability
4. attacker controls site Y
5. victim visits site Y
6. attacker sends victim to vulnerable site X along with a malicious js payload which will be injected somehow by triggering the vulnerability
7. malicious javascript payload can then observe all what victim does on site X, including stealing victim's credentials if any

(in step 5-6, the victim could be simply given a specially crafted URL by the attacker, or by an innocent intermediate -- see https://excess-xss.com/).

So the way I understand, this requires to examine 3rd-party POST requests for main document (like when submitting a form).

I have collated cases regarding how blindly allowing 3rd-party frames is a security issue: https://github.com/gorhill/uBlock/wiki/Dynamic-filtering:-Benefits-of-blocking-3rd-party-iframe-tags#malware-protection. By no mean complete, these are just all cases for which I confirmed blocking 3rd-party frames would have foiled the attack (there is a case in there I emailed the author to confirm whether the attack was iframe-based, this was not clear from the article). There are more cases reported in the media I left out which required that 3rd-party scripts be blocked (that wasn't the topic of the wiki page).

The fact that he describes the blocking of 3rd-party scripts/frames as "disabl[ing] annoying stuff" means he is trying to belittle uMatrix -- there is no way to sensibly describe malvertising as "annoying" -- I don't think he is helping himself by describing the real actual ongoing threat of malvertising (again see list of actual cases above) as merely "annoying".

Now what I long for is such a list of real, actual documented cases where specifically _only_ NoScript's XSS would have protected its users. Whatever threat someone wants to be protected against, an important factor is for users to be able to assess the likelihood of it happening. Surely such a list of actual, real documented cases would be the best way to convince users of how the importance of the feature relative to other threats (3rd-party frames, scripts, etc.)

On my side, I will read more about all this and see what could be sensibly added to uMatrix.

[Atavic]

:+1: Malvertising could be more appropriate.

An example of such "annoying stuff" could be file-hosting sites like that old one, rapidshare.

[Thorin-Oakenpants]

From this thread: https://www.ghacks.net/2017/12/30/noscript-webextension-update-improves-user-interface/#comment-4325925

surrogate scripts ...

Essentially mirroring a library, or a modified version of a given library (e.g. mootools, or jquery). uBlock used to have this.

Decentraleyes does this, but that still doesn't stop the JS from executing

---

Now what I long for is such a list of real, actual documented cases where specifically only NoScript's XSS would have protected its users

As per Atavic's link, the last couple of comments from @berrythesoftwarecodeprogrammar (they're at the end) - https://github.com/gorhill/uMatrix/issues/297

The two XSS examples are hopefully still up and running, and maybe someone can work out what they are doing that NS picks up on and blocks

[overdodactyl]

Essentially mirroring a library, or a modified version of a given library (e.g. mootools, or jquery).

Decentraleyes does this, but that still doesn't stop the JS from executing

For what it's worth, Decentreleyes does have the option to block scripts when the necessary CDN resource aren't available.

Ultimately, you can make Decentraleyes block requests for any missing CDN resources, too. GitHub page

In settings, there's the option to "Block requests for missing resources - Cancel intercepted request if the required resource is not locally available."

uBlock used to have this.

As far as I'm aware, uBO still uses some local, neutered versions of some commons scripts, doesn't it?

[gorhill]

uBO used to have an experimental feature called "local mirroring" a long time ago. In the end I canned it, this is best left to a dedicated extension.

The current neutered scripts feature is really just scriplets served through redirection to local data: URIs, and it apply only to blocked requests, never to non-blocked requests.

[overdodactyl]

Thanks for the clarification @gorhill! I wasn't aware of the local mirroring feature

If you don't mind the follow up question, do you use Decentraleyes + uBO via the method mentioned on the Decentraleyes wiki page then? (set up noop rules, then enable the block requests for missing resources option)

[Thorin-Oakenpants]

Decentraleyes does this, but that still doesn't stop the JS from executing

Sorry, by that I meant if the user lets it thru

[Atavic]

The XSS tests are gone.

[gorhill]

do you use Decentraleyes + uBO via the method mentioned on the Decentraleyes wiki page then?

I currently use uMatrix and Decentraleyes, no other extension. I didn't read the wiki, I understand how it works. Personally I do not unblock any specific domain except to unbreak sites, and in that case I am happy whenever Decentraleyes catches something.

[overdodactyl]

Makes sense, thanks for the help!

I currently use uMatrix and Decentraleyes, no other extension

Was that a recent switch? I thought I had seen you mention only using uBO in the past

[gorhill]

Was that a recent switch?

I switched when I started to work more on it lately -- it helps to use what you work on to see what needs most attention. It has its advantages, like the quick overview of what goes on in a web page, the lower overhead. The overhead can be lowered in uBO too though when disabling generic cosmetic filtering. For now I am in my uMatrix phase.

[overdodactyl]

Good to know, thanks!

I haven't used uMatrix in a while, but I might have to venture back and give that a try for a little while

[Thorin-Oakenpants]

I'll just throw this in here: https://www.schneier.com/blog/archives/2018/01/detecting_adblo.html - I haven't read the paper or even found out what this adblocker ext in chrome is yet. The numbers are interesting - 30% of top 10K alexa sites use anti-adblocking (and of these 90% have no visible reactions to adblockers). These are staggering numbers - 30% .. holy cow

Edit: https://arstechnica.com/science/2018/01/academic-researchers-fire-latest-shots-in-ad-blocking-arms-race/ < more detailed

An alternative approach they tried was somewhat more precise. Since they could identify the condition that was being tested for, they could modify the variables used by the site so that the condition would always evaluate as if an adblocker was not present. This only requires a browser extension. And, in the 15 websites it was tested on, it worked every time. (emphasis mine)

Worked every time! Cool. But I don't even want to connect to these 3rd party scripts. I'm intirgued but default-deny is working well for me. I never see an anti-adblcoker message TBH

[ghost]

So what is the final answer - is there any additional benefit in using NS when one uses uMatrix or not?

[Atavic]

You can use both.

[ghost]

I know I can. The question is what benefit adds NS if I have uMatrix where I have disabled scripts (and where I can enable them selectively).

[Thorin-Oakenpants]

I'm still working on it :)

I haven't looked at the ABE stuff, and even the XSS claims are elusive to prove

AFAICT, if you're a savvy internet user, I doubt it offers anything except possible conflicts and overhead. My gut feeling is that any reward would be outweighed by this. Assumption: users would need to be using uM (& uBO) in some hardened config

[ghost]

Yes, I was asking with that assumption :)

My gut feeling is that because Firefox has no way to enable/disable JS per website (like Chromium) uBO and uM should be a mandatory part of it. Perhaps even the Tor project should adopt these 2 instead of NS.

[Thorin-Oakenpants]

I do not know why TBB (Tor is something else) used NS. The legacy extension didn't have (and still doesn't) anything near the ease of use, and granular control of uBO / uM. Not to mention the ability to block types of elements (images/css/xhr/large media, cookies, etc). NS-legacy is effectively just concerned with JS. I say "ease" because NS could allow per site granular control (but not via a simple effective grid).

The new NS (i.e Web Extension) I haven't followed too closely cuz reasons - it has I believe morphed into doing that (per domain control) by re-inventing what uM/uBO always had. I guess like any new interface and new features, it will take time to mature (lets face it, the first offering was a really shitty beta) and for users to come to grips with it's UI etc. And lets not forget that Mozilla has bent over backwards for NS, and it's still not ready(? wasn't a month ago). I wonder how the TBB guys feel about it - however, I feel that TBB will not introduce change for change's sake (let's just assume that both extensions do the job required), but that if they were, then NOW would be the time to do it .. i.e ESR60.. because NS-legacy->NS-webext is a massive change anyway. Any argument over confusing users if no argument.

At the VERY least, TBB should include uBO just for the adblocking, IMO.

[ghost]

I agree with everything you say.

Perhaps the only objection which TBB authors may have against uBO/uM is the 3rd party lists which require connections to specific hosts and that itself may create a traceable browsing pattern. Of course a user who is aware of that could probably turn off automatic list updates and update them manually in a dedicated TBB identity, then restart and continue browsing with another identity.

I am further questioning even the benefit of using HTTPS Everywhere. Apart from its function to block all unencrypted requests it seems uM with its forbidding of mixed content already does the rest. But of course that is not directly related to the topic of this issue.

[Thorin-Oakenpants]

connections to specific hosts

I didn't think of that. Imagine a Polish person subscribing to polish lists.

the benefit of using HTTPS Everywhere

The uptake of HTTPS is escalating (whether that be the number of sites eg in the top100000000 or the % of traffic which is easier to influence given the big players). The beauty of HTTPS-E is that it allows complex rules, rather than say an extension which simply tries HTTP->HTTPS.

It does no harm to keep it for another year or so. I dug out some FF telemetry figures a short while ago - I think from memory that a year ago it was 30-40% and now its 60-70% (whatever the metric was), and as I said its escalating. Both google + mozilla are waging a war against non-secure, and then there's EFF's Lets Encrypt. Just give it a little longer :)

[ghost]

Both google + mozilla are waging a war against non-secure

The wolf is guarding the sheep :)

[Thorin-Oakenpants]

related post & subsequent replies: Wilders

[earthlng]

new wiki page for uMatrix based on the comment by @theWalkingDuck. Thanks @theWalkingDuck

[crssi]

^^ Cool. Note that localhost is not only 127.0.0.1, but 127.0.0.1/8, so anything from 127.0.0.0 to 127.255.255.255.

Saying that might be more trough if * 127.0.0.1 * block would be * 127 * block and if 127.0.0.1 127.0.0.1 * allow would be 127 127 * allow

EDIT: 127.0.0.0/24 is wrong, 127.0.0.0/8 is correct

[ghost]

I use a custom TLD for my locally developed sites and I have been trying to figure how to block requests to that particular TLD but a rule like * customtld * block seems to have no effect when testing with some.customtld.

[ghost]

Testing also with * myrouter * block and then visiting https://myrouter - the request is not blocked.

[crssi]

^^@anchev because you have 1st party allowed.

[crssi]

@ anyone
What puzzles me is, if some JS on a page I am visiting starts XHR to LAN: what is the source?
The visited page/server or my browser/computer?

[ghost]

^^@anchev because you have 1st party allowed.

Even if I remove the lines:

* 1st-party * allow
* 1st-party frame allow

I can still access https://myrouter. How come?

The visited page/server or my browser/computer?

https://www.w3.org/TR/2009/WD-XMLHttpRequest-20091119/#origin-and-base-url

[gorhill]

@anchev I can't reproduce your issue. When I remove * 1st-party * allow, my access to the router is wholly blocked with * 192.168 * block.

[earthlng]

Note that localhost is not only 127.0.0.1, but 127.0.0.1/24, so anything from 127.0.0.1 to 127.0.0.255.

thanks @crssi. https://en.wikipedia.org/wiki/Localhost says:

IPv4 network standards reserve the entire 127.0.0.0/8 address block for loopback purposes. That means any packet sent to any of those addresses (127.0.0.1 through 127.255.255.255) is looped back.

so I changed it to * 127 * block

[crssi]

@earthlng yes, I have seen mistake (too early in the morning) and corrected the original post, just minutes before your post ;)

but if you would really like completeness, here it is:

0
10
100.100
100.101
100.102
100.103
100.104
100.105
100.106
100.107
100.108
100.109
100.110
100.111
100.112
100.113
100.114
100.115
100.116
100.117
100.118
100.119
100.120
100.121
100.122
100.123
100.124
100.125
100.126
100.127
100.64
100.65
100.66
100.67
100.68
100.69
100.70
100.71
100.72
100.73
100.74
100.75
100.76
100.77
100.78
100.79
100.80
100.81
100.82
100.83
100.84
100.85
100.86
100.87
100.88
100.89
100.90
100.91
100.92
100.93
100.94
100.95
100.96
100.97
100.98
100.99
127
169.254
172.16
172.17
172.18
172.19
172.20
172.21
172.22
172.23
172.24
172.25
172.26
172.27
172.28
172.29
172.30
172.31
192.0.0
192.168
198.18
198.19
255.255.255.255
[::1]
[fc00::]
[fd00::]
[fe80::]
[fe80::1%lo0]
[ff02::1]
[ff02::2]

With this you will completely cover home and enterprise users. ;)

But IPv6 range is very big, from fc00:: to fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. I don't believe anyone would even try to do a "scan" over that range.

I am using those in uM:

[::1] [::1] * allow
[fc00::] [fc00::] * allow
[fd00::] [fd00::] * allow
[fe80::] [fe80::] * allow
[fe80::1%lo0] [fe80::1%lo0] * allow
[ff02::1] [ff02::1] * allow
[ff02::2] [ff02::2] * allow
* [::1] * block
* [fc00::] * block
* [fd00::] * block
* [fe80::] * block
* [fe80::1%lo0] * block
* [ff02::1] * block
* [ff02::2] * block
* 0 * block
* 10 * block
* 100.100 * block
* 100.101 * block
* 100.102 * block
* 100.103 * block
* 100.104 * block
* 100.105 * block
* 100.106 * block
* 100.107 * block
* 100.108 * block
* 100.109 * block
* 100.110 * block
* 100.111 * block
* 100.112 * block
* 100.113 * block
* 100.114 * block
* 100.115 * block
* 100.116 * block
* 100.117 * block
* 100.118 * block
* 100.119 * block
* 100.120 * block
* 100.121 * block
* 100.122 * block
* 100.123 * block
* 100.124 * block
* 100.125 * block
* 100.126 * block
* 100.127 * block
* 100.64 * block
* 100.65 * block
* 100.66 * block
* 100.67 * block
* 100.68 * block
* 100.69 * block
* 100.70 * block
* 100.71 * block
* 100.72 * block
* 100.73 * block
* 100.74 * block
* 100.75 * block
* 100.76 * block
* 100.77 * block
* 100.78 * block
* 100.79 * block
* 100.80 * block
* 100.81 * block
* 100.82 * block
* 100.83 * block
* 100.84 * block
* 100.85 * block
* 100.86 * block
* 100.87 * block
* 100.88 * block
* 100.89 * block
* 100.90 * block
* 100.91 * block
* 100.92 * block
* 100.93 * block
* 100.94 * block
* 100.95 * block
* 100.96 * block
* 100.97 * block
* 100.98 * block
* 100.99 * block
* 127 * block
* 169.254 * block
* 172.16 * block
* 172.17 * block
* 172.18 * block
* 172.19 * block
* 172.20 * block
* 172.21 * block
* 172.22 * block
* 172.23 * block
* 172.24 * block
* 172.25 * block
* 172.26 * block
* 172.27 * block
* 172.28 * block
* 172.29 * block
* 172.30 * block
* 172.31 * block
* 192.0.0 * block
* 192.168 * block
* 198.18 * block
* 198.19 * block
* 255.255.255.255 * block
* localhost * block
10 10 * allow
100.100 100.100 * allow
100.101 100.101 * allow
100.102 100.102 * allow
100.103 100.103 * allow
100.104 100.104 * allow
100.105 100.105 * allow
100.106 100.106 * allow
100.107 100.107 * allow
100.108 100.108 * allow
100.109 100.109 * allow
100.110 100.110 * allow
100.111 100.111 * allow
100.112 100.112 * allow
100.113 100.113 * allow
100.114 100.114 * allow
100.115 100.115 * allow
100.116 100.116 * allow
100.117 100.117 * allow
100.118 100.118 * allow
100.119 100.119 * allow
100.120 100.120 * allow
100.121 100.121 * allow
100.122 100.122 * allow
100.123 100.123 * allow
100.124 100.124 * allow
100.125 100.125 * allow
100.126 100.126 * allow
100.127 100.127 * allow
100.64 100.64 * allow
100.65 100.65 * allow
100.66 100.66 * allow
100.67 100.67 * allow
100.68 100.68 * allow
100.69 100.69 * allow
100.70 100.70 * allow
100.71 100.71 * allow
100.72 100.72 * allow
100.73 100.73 * allow
100.74 100.74 * allow
100.75 100.75 * allow
100.76 100.76 * allow
100.77 100.77 * allow
100.78 100.78 * allow
100.79 100.79 * allow
100.80 100.80 * allow
100.81 100.81 * allow
100.82 100.82 * allow
100.83 100.83 * allow
100.84 100.84 * allow
100.85 100.85 * allow
100.86 100.86 * allow
100.87 100.87 * allow
100.88 100.88 * allow
100.89 100.89 * allow
100.90 100.90 * allow
100.91 100.91 * allow
100.92 100.92 * allow
100.93 100.93 * allow
100.94 100.94 * allow
100.95 100.95 * allow
100.96 100.96 * allow
100.97 100.97 * allow
100.98 100.98 * allow
100.99 100.99 * allow
127 127 * allow
169.254 169.254 * allow
172.16 172.16 * allow
172.17 172.17 * allow
172.18 172.18 * allow
172.19 172.19 * allow
172.20 172.20 * allow
172.21 172.21 * allow
172.22 172.22 * allow
172.23 172.23 * allow
172.24 172.24 * allow
172.25 172.25 * allow
172.26 172.26 * allow
172.27 172.27 * allow
172.28 172.28 * allow
172.29 172.29 * allow
172.30 172.30 * allow
172.31 172.31 * allow
192.0.0 192.0.0 * allow
192.168 192.168 * allow
198.18 198.18 * allow
198.19 198.19 * allow
localhost localhost * allow

[ghost]

My bad. I had other rules which allowed resources from 'myrouter'. Everything works as expected.

[ghost]

@crssi - you should probably suggest to @gorhill to make it built in as a single click option for all local resources (IP4 and IP6) rather than adding it to a list manually.

[ghost]

I have been banned from my very first time I tried to submit an issue (still don't know why). It was years ago. But I registered other accounts and submitted issues :D

So we have an anti-ban strategy lol.

[earthlng]

well thanks @crssi but in most cases there's nothing accessible in those ranges by default. I think it would be a bit too much to add all those. Most home routers/access points/etc I'd imagine use 192.168.x.x by default. uMatrix is explicitly for "advanced users" and they should know the network range they're in.
But I'll add a note to the page as a reminder and link to your comment. Thanks :+1: :)

[crssi]

A bit too much for uMatrix? Joke... we all know that those additional few lines are nothing for uM, which can handle a 1MIO lines easily.
But a note should be just fine. :+1:

[Thorin-Oakenpants]

FYI: click me, go on, I pinky swear its safe .. hidden pref to override restricted address/port

[Atavic]

The list of restricted ports:
https://dxr.mozilla.org/mozilla-central/source/netwerk/base/nsIOService.cpp#100

[crssi]

If someone uses uBO and not uM, is there any reason not to add those? Asking since here only uM is mentioned.
How do we add IPv6 to uBO?

[::1] [::1] * allow
[fe80::1%lo0] [fe80::1%lo0] * allow
* [::1] * block
* [fe80::1%lo0] * block
* [ff02::1] * block
* [ff02::2] * block
* 0 * block
* 10 * block
* 127 * block
* 172.16 * block
* 172.17 * block
* 172.18 * block
* 172.19 * block
* 172.20 * block
* 172.21 * block
* 172.22 * block
* 172.23 * block
* 172.24 * block
* 172.25 * block
* 172.26 * block
* 172.27 * block
* 172.28 * block
* 172.29 * block
* 172.30 * block
* 172.31 * block
* 192.168 * block
* 255.255.255.255 * block
* localhost * block
10 10 * allow
127 127 * allow
172.16 172.16 * allow
172.17 172.17 * allow
172.18 172.18 * allow
172.19 172.19 * allow
172.20 172.20 * allow
172.21 172.21 * allow
172.22 172.22 * allow
172.23 172.23 * allow
172.24 172.24 * allow
172.25 172.25 * allow
172.26 172.26 * allow
172.27 172.27 * allow
172.28 172.28 * allow
172.29 172.29 * allow
172.30 172.30 * allow
172.31 172.31 * allow
192.168 192.168 * allow
localhost localhost * allow

Cheers

[Thorin-Oakenpants]

I have * 1st-party * allow

So this renders the wiki rules moot in my case (I think). The * 1st-party * allow overrides eg a * 192.168 * block

In my default setup, I am beginning to wonder if 1st-party * allow would really save on any rules and if I should do away with it.

[crssi]

Do you have 1st-party * * allow or * 1st-party * allow?

[Thorin-Oakenpants]

The three green squares are as follows

* 1st-party * allow
* 1st-party css allow
* 1st-party image allow

soz, I missed the first * when copypasta'ing

[crssi]

I can't see any problems here.
@gorhill, a great guru, what is your opinion?

[gorhill]

I put this to test.

* example.com * block + * 1st-party * allow = http://www.example.com/ blocked from loading

* 192.168 * block + * 1st-party * allow = http://192.168.x.y/ not blocked from loading

* 192.168.x.y * block + * 1st-party * allow = http://192.168.x.y/ blocked from loading

This seems inconsistent. However if I remember correctly, the issue is to determine the 1st-partyness. Is 192.168.x.y first party to 192.168? Should every single IP address be deemed a unique origin? From my observations above, it seems I went with the opposite approach.

Now looking at this again this does not seem right, it seems to make sense to hold every distinct IP address as a separate origin, such that 192.168.x.y.

Correction: on second thought, the current behavior probably make sense, because:
* com * block + * 1st-party * allow = http://www.example.com/ not blocked from loading.
Sorry, I went through all this a long time ago, I lost track of all my thinking back then.

[Thorin-Oakenpants]

Not too worried about which takes precedence, but rather if this is necessary for me

In my default rules as per pic above, I only allow 1st party + 1st party css and 1st party images

So question: what the hell does this provide me that I don't already have covered

* 127       * block
* localhost * block
* [::1]     * block
* 192.168   * block

None of these can load as 3rd party (and doesn't FF itself blocks some of these as 3rd party?), but allow me to load my modem, router, privoxy, plex server etc

Or am I missing something?

And do I still need to remove matrix-off: localhost true (which I have done)?

[Remu-rin]

In my default rules as per pic above, I only allow 1st party + 1st party css and 1st party images
So question: what the hell does this provide me that I don't already have covered

In your case (blocking all 3rd-party) nothing, I think. Is uM blocking behind-the-scene requests for images (like favicons) for you?
Those rules are useful in case when 3rd-party css and images are allowed (default for uM and majority of users I think), as mentioned in https://github.com/gorhill/uMatrix/issues/961 with utorrent exploit. And even more useful if someone switches from default-deny to default-allow approach or allows XHR requests to 3rd-party (which would allow to exploit recent vulnerabilities in Transmission [1] and rTorrent [2] with DNS rebinding, if I understood them correctly).

[1] https://security-tracker.debian.org/tracker/CVE-2018-5702
[2] https://f5.com/labs/articles/threat-intelligence/malware/rtorrent-client-exploited-in-the-wild-to-deploy-monero-crypto-miner

[Thorin-Oakenpants]

That's what I thought, 3rd party is blocked so i'm good because I don't allow anything through uBo (default deny all 3rd party as well) unless I need to (pretty good practiced eye now on what is most likely to cause the breakage), then a refresh shows if any scripts/images are then needed to allow in uM - something like local would be a red flag

behind-the-scenes (I still don't understand what BTS actually is): i have

https-strict: * true
https-strict: behind-the-scene false

matrix-off: behind-the-scene true

referrer-spoof: * true
referrer-spoof: behind-the-scene false

That's it, just three rules. I don't know if that's default or I put them there. I am guessing mattrix-off BTS means everything is off BTS, so I guess I'm not blocking anything? How can I test a BTS favicon? I'm a bit worried about matrix-off: behind-the-scene true now - I'm beginning to feel like I have a naked behind

[Remu-rin]

How can I test a BTS favicon? I'm a bit worried about matrix-off: behind-the-scene true now - I'm beginning to feel like I have a naked behind

Open uM logger, then go to debian.org link from my previous comment for example (ideally in Private Window, so favicon won't come from cache if you visited site before), you should see BTS request(s) for favicon. Also you can click on BTS icon in the second column to open matrix popup and see what rules you have in force for BTS-scope and what requests uM had allowed/blocked in current session.
With matrix-off: behind-the-scene true (default) everything would be allowed. If it's false, then BTS-scope should inherit your other rules for 3rd-party (allowed images+css in my case).

[crssi]

What is the conclusion?
Should be matrix-off: behind-the-scene true or matrix-off: behind-the-scene false ?
Are there any other general uM preferences needing "special care"?

Oh, @Thorin-Oakenpants is there a special reason you have blocked media in upper screenshot?

[ghost]

In my uBO rules I have:

behind-the-scene cello.client-channel.google.com * block
behind-the-scene facebook.com * block
behind-the-scene plus.google.com * block
behind-the-scene twimg.com * block
behind-the-scene twitter.com * block
behind-the-scene youtube.com * block

because earlier I have noticed background connections to these hosts happening in Chromium.

[ganego]

@crssi regarding this post of yours: https://github.com/ghacksuserjs/ghacks-user.js/issues/319#issuecomment-364782222 - You forgot to add the * localhost * block rule in your list. Please edit it in in case anyone wants to copy/paste the list (as I did and discovered this :))

EDIT: In case anyone was interested - those rules also work when you enter the IP as decimal. For example 127.0.0.1 can also be written as 2130706433.

EDIT2: And one more thing: NS (old one with ABE) can block access to my router with default ABE rules. The router is accessed via DNS in this case (meaning http://router.box). uM cannot block access if I do not specify all the DNS names for the router. This ABE stuff is the only reason why I still use NS.

[crssi]

@ganego
Thank you but I haven't forgot, I have only not updated the list here, since here is just a debate... more is on wiki, but completeness was not accepted.
Just recently I have published my uM config here https://github.com/crssi/Firefox/blob/master/Config-uMatrix.txt
There are also a few allowed resources covered for Decetraleyes.
If you have something to add or remove, just open an issue on upper link and I will be happy so do so, if applicable.

Thank you and cheers
p.s. I will now update the comment you have mentioned, but I am not sure that will be maintained in the future... that should wiki page be for.

[Thorin-Oakenpants]

Good read on clickjacking etc here - https://blog.innerht.ml/google-yolo/

[gorhill]

Good read on clickjacking etc here - https://blog.innerht.ml/google-yolo/

[crssi]

I have taken a bit different approach... over uBO like: ||$third-party,subdocument
This way I can allow for example only google captcha: @@||google.*/recaptcha/$third-party,subdocument
without allowing whole google domain.
The other benefit is, that I have filterlist and if for example my mother gets a breakage, she let me know... I just update a list and she learned how to purge/refresh uBO list in case she needs it fast.

[vertigo220]

I'm confused about the rules for blocking sites' access to local LAN resources discussed here and in wiki section 4.2.3. uMatrix rules are all a single line, but @theWalkingDuck's description shows it as multiple lines, and it's not clear which part is supposed to be entered into uM, or how. Could someone please clarify this?

Also, I've been using the default setup for uM which allows everything for 1st-party, for four reasons:

1) if I'm at the site, I likely trust it for the most part, so it seems reasonable to allow it to do its thing (with some caveats, such as going to a malicious site, but then points 2 & 4 still apply);
2) it's been explained to me that just because you block JS, etc, doesn't mean a site can't still run code and do things without your knowledge, specifically with php pages, which you won't necessarily know you're on;
3) even without JS, etc, the site can still figure out a lot about you, since you're connecting to it; and
4) many people, including (supposedly) @gorhill himself, don't even bother with uM and only use uBO, and I see uM as more of an extension of uBO which allows more granular tweaking, so it seems the additional "risk" of allowing all first-party content shouldn't be that great.

After seeing @Thorin-Oakenpants' setup above, I decided to try it, and it didn't take long to realize this will cause a lot more breakage and, therefore, a lot more time spent fixing sites to make them usable. I'm curious what everyone's thoughts are considering all this, and if it's really worth the extra hassle for, what seems to me to be, little added protection.

And on a related note, I've also always used the default of allowing all css and images, which seemed perfectly safe, as those are (or so I thought) very low risk things, whereas blocking them breaks a lot. After seeing that Pants and others change this behavior, I looked a bit into it and see that CSS at least can be used for tracking (and I assume images can as well?). So again, I'm interested in what everyone thinks about this. Like most thinks, it's a balance between security/privacy and usability, and everyone is going to draw that line in a different place, but I'm just wondering if the default settings, and how I've been using it, is really a big hole in my setup, or if it's a minor thing that only the most gung-ho, looking to squeeze out every bit of potential protection regardless of the cost in effort, should bother with. IOW, what's the ROI of making these changes?

[2glops]

My actual usage is uBo for static filtering and uM for dynamic filtering.
uBo, I only have to toggle large media or remote fonts.
uM, I've been playing with several strategies, now only allowing css + images for 1st party on global scope.
New visited sites often breaks, partially (still legible) or totally. But, to unbreak these sites, if I decide to unbreak, it takes few seconds with the awesome matrix. As I used to unbreak sites, I've learn a lot to do that quickly.
When I visit a new site, I always look to the matrix, it is very interesting.

I don't know if the above add little or more protection, but I'm satisfied with the usability of my browsing.

[ghost]

A side note: Speaking of tracking, perhaps the new Privacy Badger's feature is also worth looking into:

https://www.eff.org/deeplinks/2018/05/privacy-badger-rolls-out-new-ways-fight-facebook-tracking

Any experiences with that extension?

[earthlng]

@vertigo220 wrote:

I'm confused about the rules for blocking sites' access to local LAN resources discussed here and in wiki section 4.2.3. uMatrix rules are all a single line, but @theWalkingDuck's description shows it as multiple lines, and it's not clear which part is supposed to be entered into uM, or how. Could someone please clarify this?

https://github.com/ghacksuserjs/ghacks-user.js/wiki/4.2.3-uMatrix - better now?

You can just copy-paste the full

# uMatrix
# Prevent Internet sites from requesting LAN resources.

block into your uMatrix rules. uMatrix will automatically remove the comments

[vertigo220]

@2glops wrote:

My actual usage is uBo for static filtering and uM for dynamic filtering.
uBo, I only have to toggle large media or remote fonts.

That's interesting, because I find most of my tweaking has to be done in uBO (of course, now that I've changed uM's setup, I expect I'll have to do a lot of tweaking in both. But I can't even use uBO in easy mode, because the static filtering blocks necessary stuff, which requires dynamic filtering to allow it. So ironically, "easy" mode is actually harder than medium mode. I guess it's meant to just whitelist sites if the static filters break them, and probably not meant to be used with very many filters (I use most of them), so that's probably my problem. I've been using the two for a few years now and am still learning.

@anchev said:

A side note: Speaking of tracking, perhaps the new Privacy Badger's feature is also worth looking into:
https://www.eff.org/deeplinks/2018/05/privacy-badger-rolls-out-new-ways-fight-facebook-tracking
Any experiences with that extension?

I use PB, and you can see my comment here regarding my opinion of its benefits even when using uBO/uM/NS/etc, though I'm going to try changing how I use uBO a bit (globally block facebook, google, yahoo, etc, then locally noop them on their own domains), so it won't be _as_ important, but still a good second line of defense. As for that new feature, I question its usefulness. It seems to do what extensions like ClearURLs and Neat URL do, but limited to specific sites. I've found that NS does an excellent job of cleaning google links, uBO prevents much of the tracking by simply blocking the requests (see this issue for more on this), and ClearURLs is good to have for anything not covered by those two. I question whether PB would add anything more to the mix.

@earthlng - Thanks. Updated my rules with it.

[gorhill]

But I can't even use uBO in easy mode, because the static filtering blocks necessary stuff

That is for filter list maintainers to fix, just report these false positives.

[Thorin-Oakenpants]

FYI: https://scotthelme.co.uk/xss-on-etherscan-io/ - interesting read - if I read it right, then disqus as third party (recipe) would have allowed this. The question is would ABP have stopped it, as it so often claims? - @gorhill

[gorhill]

would ABP have stopped it

I'm sure you meant NoScript? NoScript dev is best to answer this, without the test case itself (which has been fixed), difficult for outsiders to answer.

[Thorin-Oakenpants]

I'm sure you meant NoScript?

Yeah, sorry. I just wondered (because it's all greek to me) if that meant anything to you. Because our defense is to block all 3rd party, but NS (well at least for the legacy extension) claimed some special XSS protections, and here was a case that could have been tested (I know it was fixed but the info on how it did it was there, I think, and you code wizards love building PoCs). Anyway, nvm.

I still don't think NS (web ext) offers anything that uM doesn't

[gorhill]

My understanding of that case is that the alert box would have been shown with uBO/medium mode, because the code was executed as inline javascript in the site's context, i.e. as 1st-party code.

uBO/medium mode would have prevented the inline javascript payload from successfully loading javascript or embedded documents from a remote 3rd party under control of the attacker.

However, for example, theoretically the payload could install an event listener for keypresses, and send that information to a remote 3rd party server under control of the attacker. This scenario would be foiled however with uBO/hard mode, not with uBO/medium mode.

My understanding is that the site was injecting Disqus stuff directly in their DOM without sanitizing, because they assumed it was already sanitized by Disqus. So theoretically maybe someone can recreate the case and find out what was possible and what could have foiled the threat.

[crssi]

Guys, something is puzzling me about uBO dynamic filters.
If I use the rule * 192.168.2.129 * block then I can not browse to 192.168.2.129, which is expected.
But if I generalize to the whole 192.168 network with the rule * 192.168 * block, I can still browse to 192.168.2.129, which is not expected.
Wasn't this already fixed once in uBO?

[gorhill]

I can not browse to 192.168.2.129

You should be able to browse to, dynamic filtering block-rules never block whole document, just secondary resources.

[earthlng]

@crssi FYI * 192.168 * block in uMatrix blocks access to the main document as well

[crssi]

@gorhill and @earthlng: lol, you both must be a mindreaders... this is the answer to the next question I had in mind, but didn't ask yet. Thank you. :+1:

But still, shouldn't rule * 192.168 * block prevent secondary resources when visit 192.168.x.y (x,y=any address)?

[gorhill]

But still, shouldn't rule * 192.168 * block prevent secondary resources when visit 192.168.x.y

I thought this was supported in uBO but I just looked and I don't see code for this -- despite that I claimed I saw code for this here. Looks like I was confused back in that issue, I confirmed this is not implemented in uBO.

[Thorin-Oakenpants]

...aaaaand it's now fixed in the next release - https://github.com/gorhill/uBlock/commit/8f1b4b52fde58c60210bdd404c2c68211a66457f

[Thorin-Oakenpants]

Closing this. IMO, NS adds nothing that can't be covered by uM. I call NS's claims about some XSS protection exclusivity, a pile of marketing BS to talk the product up. I'll say the same can go for ClearClick and ABE - but do feel free to PROVE otherwise.

Should anyone ever be able to provide definitive proof, please let gorhill know in a new topic (at https://github.com/uBlockOrigin/uMatrix-issues )