-
Notifications
You must be signed in to change notification settings - Fork 233
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't stop Firefox background connections #509
Comments
Have you manually disabled tracking protection? Even after that Firefox seems to make some automatic connections to places like You can check the DNS queries made before those connections for more clues what are those particular connections. |
Have you manually disabled tracking protection?
I have all these:
user_pref("privacy.trackingprotection.annotate_channels", false);
user_pref("privacy.trackingprotection.enabled", false);
user_pref("privacy.trackingprotection.pbmode.enabled", false);
user_pref("privacy.trackingprotection.fingerprinting.enabled", false);
user_pref("privacy.trackingprotection.socialtracking.enabled", false);
user_pref("privacy.trackingprotection.cryptomining.enabled", false);
Even after that Firefox seems to make some automatic connections to places like `detectportal.firefox.com`.
So what should one do?
Are you sure those are from Firefox as `tcpdump` shows all connections from your host?
Yes, I am sure. I have taken care to test correctly.
|
Can anyone please suggest how to block all background connections?
|
Can you provide the DNS requests happening before these connections so we can narrow down the culprits? |
Could you explain how to do this?
|
Hi, I can't see browser.selfsupport.url in current user.js BTW for a non-backgorund connections setup, check about:networking while disconnected; then remove URLs via about:config |
Hi, I can't see **browser.selfsupport.url** in current user.js
According to [mozilla support](https://support.mozilla.org/en-US/questions/1076594) that entry is responsible for startup persistent connections.
I tested that too. It changes nothing (plus the setting seems outdated). Background connections still happen.
BTW for a non-backgorund connections setup, check **about:networking** while disconnected; then remove URLs via about:config
I played a lot with that and unfortunately background connections still happen.
My findings:
1. Disabling (and setting URLs to empty strings) anything pocket-related doesn't stop the background connections.
2. Setting network.dns.disabled to false stops background connections, but it stops DNS resolving too, so practically the browser becomes useless.
Using -jsconsole command line option to see exactly what happens I noticed XHR connections to https://content-signature-2.cdn.mozilla.net/chains/remote-settings.content-signature.mozilla.org-2021-06-11-15-04-32.chain on each browser start (and afterwards too). I couldn't find a similar URL in about:config. It seems some certificate file is downloaded and I have no idea why it should be requested again and again.
To rule out any possibility of another *.cdn.mozilla.* URL affecting this I replaced all "cdn.mozilla" with "xdn.mozilla" in about:config. Even that didn't help, so I restored them.
After all that I "took the big hammer" and edited my /etc/hosts adding a line:
0.0.0.0 content-signature-2.cdn.mozilla.net
Result: no more background connections to that host.
I understand this is an ugly approach and I wish there was a more elegant one. Unfortunately I couldn't find any. I hope someone more knowledgeable can look into this and probably propose a better solution.
* During one of my tests I also noticed connections to 1.2.3.4.bc.googleusercontent.com (1.2.3.4 being some other IP address). I have no clue what this might be related to. All this happened without opening any URLs at all.
|
|
tcpdump -i any -n 'port 53' -t
gives:
wlan0 Out IP 192.168.43.196.44037 > 192.168.43.1.53: 43937+ A? content-signature-2.cdn.mozilla.net. (53)
wlan0 In IP 192.168.43.1.53 > 192.168.43.196.44037: 43937 5/0/0 CNAME d2nxq2uap88usk.cloudfront.net., A 52.84.118.59, A 52.84.118.121, A 52.84.118.42, A 52.84.118.5 (157)
|
[https://content-signature-2.cdn.mozilla.net/chains/remote-settings.content-signature.mozilla.org-2021-06-11-15-04-32.chain](The URI) lists 3 certificates: remote-settings.content-signature.mozilla.org You can view source and check CRT with these services: You may get errors in the future when the Certificates expire. |
Thanks for the links. The main issue remains though:
I don't want to tell Amazon (or anyone else) each and every time I run my browser "Hey, I am online, here is my IP address and the exact time I connected for your needs". That's personal data and as per GDPR I have the legal right NOT to give it to Amazon without that affecting the way I use my browser to connect to non-Amazon hosts. A browser like Ungoogled Chromium (or lynx) does not connect to anything in order to function without any errors due to expiry of a certificate. Why should the "privacy respecting" (and additionally fine tuned by this user.js) Firefox made by the "non-profit" Mozilla Foundation do the opposite? There must be a way to avoid that without privacy or security compromises. Would you agree?
|
Totally.
|
Thanks for the info.
- reduce the trustwothiness of the many certificates present by default
How do I do this?
Same goes with systems as a whole, see here
That article is for Windows. How do I do this on Linux?
- The best source I have found about this is @ScottHelme , who says that revocation-checking-is-pointless
I don't see content-signature-2.cdn.mozilla.net on any of his lists. Or what am I missing?
Will any of the things you mention remove the unwanted background connections Firefox makes?
|
Short answer: you can use firewall rules or modify hosts file, See: You may also look at athe aliases with the nslookup command: |
|
DNS/hosts file level filtering is indeed the simplest way to prevent these connections. Firewall/IP-based level filtering is extremely hard to enforce unless you know in advance to which IP these names will resolve (frequently changing IP addresses/CDN)
I don't think Firefox uses the OS certificate store though? Trusted certificate authorities are hardcoded in https://github.com/mozilla/gecko-dev/blob/master/security/nss/lib/ckfw/builtins/certdata.txt |
I was referring to the OS, incidentally Arch uses CA certificates from Mozilla CA Certificate Store as a default On topic, these connections are security related as insure that the Mozilla services delivered to the browser are indeed legitimate and there's no man-in-the-middle. It's called Autograph I personally have no use of any service within the broswer, so I'd like to stop all of this.
Sorry, but it's an old user.js applied on a non-updated firefox. Also, this entry is widely available with a search like this that focuses on kinto, the server used for global synchronization. Devs insert a dummyServerURL instead. The orginal URL to a chain of certificates that link to a trusted root is called x5u |
This pref is still present for me (Firefox ESR It seems there is some related documentation at https://remote-settings.readthedocs.io/en/latest/ and https://docs.kinto-storage.org/en/latest/tutorials/synchronisation.html#polling-for-remote-changes @emanruse does changing this pref to a dummy URL such as To make your research easier I suggest enabling logging of DNS queries. If you are using a Linux distribution with network-manager you can create [main]
dns=dnsmasq (make NetworkManager use a local, caching DNS server, maybe it is already setup this way on your distribution, check with Then setup dnsmasq to log queries in
|
Is there a reason why there is no about:config setting for this? Is there an upstream bug for this, or was it rejected for some reason? |
On Thu, 16 Sep 2021 05:09:25 -0700 ghffhbfghdhdfhf wrote:
Then Firefox can either be build by yourself after applying the patches, or is offered as a reproducible build. Patches need to be maintained with every Firefox release, obviously (maintaining software is the most burden). Easy.
Perhaps the most suitable project for this could be IceCat. But IIRC even some versions of IceCat didn't have all these home calls disabled completely.
|
As per: Do you agree that pursuing the Radio Silence feature (no phone home, no background connections by default) is a laudable goal for a browser dedicated to enhancing user privacy? In other words, can this ticket still being open be interpret as this being a good development goal, yet not done because it is difficult to implement? |
a browser dedicated to enhancing user privacy?
Firefox is obviously not that browser.
Just read the "privacy" policy of Mozilla - it is a data sharing policy. Nothing to do with privacy.
In other words, can this ticket still being open be interpret as this being a good development goal, yet not done because it is difficult to implement?
Since it is impossible to do this through user.js (i.e. through any form of user-side configuration), this may need source code patching, which seems beyond this project's scope. Maybe if the devs are interested in widening the scope...
|
definitely out of scope in my opinion
I think yes. It is likely we will need an automated test environment setup for this (e.g. start tcpdump and firefox with the latest user.js in parallel, investigate packet captures, improve user.js, rinse and repeat until there are no more unwanted outgoing connections in the capture) |
Using tcpdump I notice that Firefox continues to make background connections regardless of the fact that I use this
user.js
. I even tried the additional privacy settings suggested at https://wiki.archlinux.org/index.php/Firefox/Privacy (except those for omni.ja) but still, the moment I start Firefox (which shows nothing but about:blank tab) tcpdump shows:Why is this happening? (even without extensions)
I don't want to announce to Amazon (or anyone else) "Hey, I have just started my browser, here is my IP address (personal data as per GDPR) for your purposes". I want to connect only to the websites I explicitly type in the URL bar.
The text was updated successfully, but these errors were encountered: