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

[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 )