Skip to main content ↑ ↓
Topic: ublock origin doesn't respect filters if DoH is used under firefox (Read 1525 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

ublock origin doesn't respect filters if DoH is used under firefox

Hello guys if you like ublock origin extension uBO like i do you must know as i opened a bug report over github and the conclusion is that when or if you use ff built in DoH (encrypted dns) uBO acts erratically but the problem seems not be uBO fault but ff. So tested with wireshark + nexdns (my favorite tool) and if DoH is disabled problem seems to go away and uBO works as intended. If you ask me  about this i think  is a major issue as many while we speak are not aware about this and they get tracked by third parties. So till this get sorted out i would disable that DoH as an "emergency" solution. Would be cool if you guys can check it out.
p.s also the developer of uBO saw this as a problem and hope soon will have a good solution for this one
       link to the issue

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #1 –
Mozilla Firefox is a known anti-privacy browser. Sources:

https://www.unixsheikh.com/articles/choose-your-browser-carefully.html#firefox
https://digdeeper.neocities.org/ghost/browsers.html#ff

Those two websites have more in-depth information for those who are concerned with privacy. Basically, the "least evil" is ungoogled-chromium. Librewolf, the closest to "de-Mozilla'd" Firefox, still "phones home".

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #2 –
Yeah i know it phones home by default but managed to block with hosts file those ~10 domains that ff hammered all the time. Now the only issue is about this DoH thing and even  Raymond Hill the uBO dev is puzzled about this unexpected behavior of ff.

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #3 –
Quote from: Surf3r – on
managed to block with hosts file those ~10 domains that ff hammered all the time
What exactly are those domains? I wanna apply such a config too :)

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #4 –
Those domains at this date are as follow:
(you have to add 0.0.0.0 in front of each domain)

content-signature-2.cdn.mozilla.net
detectportal.firefox.com
shavar.services.mozilla.com
firefox.settings.services.mozilla.com
normandy.cdn.mozilla.net
aus5.mozilla.org
versioncheck.addons.mozilla.org
versioncheck-bg.addons.mozilla.org
services.addons.mozilla.org
publicsuffix.org
example.org
example.com

Reboot the system for that list to become actively blocked

Some of this domains are "legit"checks for extension updates or "antitracking" lists but i found rather rudimentary those lists compared to uBO capabilities so i can skip that one without any doubt. For the first one i can update my uBO via github so don't need mozilla repo for that. If you use any other extension you should either update it via github or from developer website but i won't recommend any other extension but uBO. Also you can disable ocsp responders that still work over port 80 and it's obsolete  technology (see wikipedia). Personally i got rid of google "safe browsing". So that's about it. uBO list updates are not affected by those blocked domains so you're safe.

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #6 –
Yeah i got Steven Black lists too on my nextdns. I prefer to block with hosts file only those domains that hammer DNS and can't be blocked by uBO and those that occur more random get blocked by nextdns filters.

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #7 –
Quote from: Surf3r – on
Some of this domains are "legit"checks for extension updates or "antitracking" lists but i found rather rudimentary those lists compared to uBO capabilities so i can skip that one without any doubt. For the first one i can update my uBO via github so don't need mozilla repo for that. If you use any other extension you should either update it via github or from developer website but i won't recommend any other extension but uBO.
Thank you! I don't use much extensions save uBO. The one I use and do like is "What font" (which helped me to configure font rendering in browsers and in Linux in general), and the other one is h264ify for youtube videos. But I'm pondering about deleting it and disabling hardware acceleration in browsers, because is somewhat violates your security and privacy, because you need to grant the browser access to your hardware for that.

Recently I was tinkering with apparmor and writing profiles for browsers (firefox and chromium) and I made some discoveries which kinda shocked me. I can tell you that hw video acceleration in the modern versions of FF is much less secure than corresponding feature in chromium. For example, on a laptop with dual graphics (nvidia optimus) FF wants access to the nvidia card via pci and configures nvidia proprietary driver via invoking nvidia-modprobe (with suid privileges and setuid capabilities!) and lets this program to open files opened and locked by FF itself in /tmp. And this is done despite of the fact that internal intel GPU is used, and NVidia card is turned off by bumblebee. Without access to all this shit FF refuses to implement hardware acceleration on intel card. I consider this as a quite serious security breach.

Another thing surprised me a lot. There are helper apps which browsers and other programs use. When you click on downloaded files or torrent links, corresponding apps are opened. Chromium uses xdg-open for that. But FF invokes /bin/bash (or /bin/dash, if it finds this first)! This is another security breach as large as a truck.

With apparmor, you can restrict browsers in their possibilities to violate your security and privacy. By restricting access to /sys and /dev you can actually conceal you hardware setup from the browser (which by default looks even into your /etc/fstab), and by forbidding execution of lsb_release and FF's crash-reporter and restricting access to /proc you hide your software configuration.
 

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #8 –
Quote from: VictorBrand – on
With apparmor, you can restrict browsers in their possibilities to violate your security and privacy. By restricting access to /sys and /dev you can actually conceal you hardware setup from the browser (which by default looks even into your /etc/fstab), and by forbidding execution of lsb_release and FF's crash-reporter and restricting access to /proc you hide your software configuration.
For any binary blob, you can use https://wiki.archlinux.org/title/firejail (thanks @nous !).

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #9 –
Quote from: strajder – on
For any binary blob, you can use https://wiki.archlinux.org/title/firejail (thanks @nous !).
Yes, I use firejail too, but particularly for the browsers I prefer tight and strict apparmor profile. It allows you finer-grained tuning in what you allow the app to do and what not. And while creating this profile, you can make amazing discoveries on how the app exactly works.

Firejail, OTOH, gives you the opportunity to isolate network interfaces and restrict ports available to the app, which apparmor still can't do (but this feature is announced in the future).

Using FJ with chromium has the downside that you must allow rising privileges for the browser (it uses setuid sandbox while starting up). With apparmor you create a separate profile for chromium-sandbox, where you allow capability setuid, and for the chromium binary itself, you can deny this. I consider this as a more secure approach. (I prefer disabling privileges raising for the apps in FJ globally).

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #10 –
Fresh news. Now the issue from uBO turned into a full blown bugzilla report not yet confirmed but it will.
Also a fresh reddit thread has been opened regarding this firefox bug
It seems the bug is present on firefox for mac os too. Let's wait and see. Fingers crossed to be resolved soon.

EDIT: Hello guys discovered a new "feature" in firefox i'm gonna be quick. FF sends a dns query to "ipv4only.arpa" which resolves to a bogon ip addresses. Don't know what's the purpose of those addresses but can't be for a good reason. So quick fix add his to your hosts file  0.0.0.0     ipv4only.arpa. Or deny 192.0.0.0/24 with firewall
Will come back to update this when i have more info. Another ff  bug???

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #11 –
Firefox devs came up with a work around in order to have DoH and successfully blocking undesired requests (like uBO does). All you have to do is search in ff about:config "network.dns.upgrade_with_https_rr" and from true set it to false that way you''ll have DoH and a fully functional uBO, with antitracking capabilities of course like it should, win win. They gave priority P2 to this bug which means is second place in importance terms. So we can for sure expect in a short period a 100% proper fix.

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #12 –
Quote from: Surf3r – on
Yeah i got Steven Black lists too on my nextdns. I prefer to block with hosts file only those domains that hammer DNS and can't be blocked by uBO and those that occur more random get blocked by nextdns filters.

It's unfortunate that we have to do this to protect ourselves. It's easy for them to add/change to another domain/even IP in a new release. Then, we have to first notice, then block it. No wonder why FF keeps losing its users year after year. I am like you, trying to stay away from anything related to google, but sadly, not many options left these days. 

Re: ublock origin doesn't respect filters if DoH is used under firefox

Reply #13 –
Yeah they can change so that's why it 's very useful to check after ff update where it phones. didn't see any changes for the last 2 versions though