Can't stop Firefox background connections

[emanruse]

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:

...
IP mycomputer.53304 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 31
IP mycomputer.53302 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 24
IP mycomputer.53302 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.53302 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.53304 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.53304 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.53304 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.53304 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.53304 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.53302 > server-143-204-209-52.fra53.r.cloudfront.net.https: tcp 0
IP mycomputer.38710 > server-52-85-121-65.bud50.r.cloudfront.net.https: tcp 0
IP mycomputer.38710 > server-52-85-121-65.bud50.r.cloudfront.net.https: tcp 0
IP mycomputer.38710 > server-52-85-121-65.bud50.r.cloudfront.net.https: tcp 513
IP mycomputer.38710 > server-52-85-121-65.bud50.r.cloudfront.net.https: tcp 0
IP mycomputer.38710 > server-52-85-121-65.bud50.r.cloudfront.net.https: tcp 0
...

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.

[pyllyukko]

Have you manually disabled tracking protection? Even after that Firefox seems to make some automatic connections to places like detectportal.firefox.com. Are you sure those are from Firefox as tcpdump shows all connections from your host?

You can check the DNS queries made before those connections for more clues what are those particular connections.

[emanruse]

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.

[emanruse]

Can anyone please suggest how to block all background connections?

[pyllyukko]

Can you provide the DNS requests happening before these connections so we can narrow down the culprits?

[emanruse]

Could you explain how to do this?

[Atavic]

Hi, I can't see browser.selfsupport.url in current user.js According to mozilla support that entry is responsible for startup persistent connections.

BTW for a non-backgorund connections setup, check about:networking while disconnected; then remove URLs via about:config

[emanruse]

Hi, I can't see browser.selfsupport.url in current user.js According to mozilla support 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.

[pyllyukko]

Could you explain how to do this?

tcpdump -i any -n 'port 53' or using Wireshark.

[emanruse]

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)

[Atavic]

[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 Content Signing Intermediate/[email protected] root-ca-production-amo

You can view source and check CRT with these services: www.view-page-source.com/ www.sslshopper.com/certificate-decoder.html

You may get errors in the future when the Certificates expire.

[Atavic]

2nd CRT appears in autograph and everything is hosted by amazon

Reddit linked to this

[emanruse]

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?

[Atavic]

Totally. You can:

• reduce the trustwothiness of the many certificates present by default. Same goes with systems as a whole, see here
• The best source I have found about this is @ScottHelme , who says that revocation-checking-is-pointless
• Lastly, obfuscasting the User Agent String has lost interst for most people, but it's still useful in limited cases. Check Eclipsed Moon addon for Palemoon/Mypal in Smart mode if interested.

[emanruse]

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?

[Atavic]

Short answer: you can use firewall rules or modify hosts file, See: https://github.com/arkenfox/user.js/issues/917#issuecomment-609007023

You may also look at athe aliases with the nslookup command: https://github.com/uBlockOrigin/uBlock-issues/issues/1641#issuecomment-865151876

[Atavic]

How do I do this on Linux? https://wiki.archlinux.org/title/Transport_Layer_Security#Certificate_authorities

[nodiscc]

you can use firewall rules or modify hosts file

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)

How do I do this on Linux?

https://wiki.archlinux.org/title/Transport_Layer_Security#Certificate_authorities

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

[Atavic]

How do I do this on Linux?

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. In Firefox Zero there's an entry related to this:

user_pref("services.settings.server", ""); // Disable contacting settings server

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

[nodiscc]

services.settings.server

This pref is still present for me (Firefox ESR 78.12.0esr-1~deb10u1, Debian 10), it is set to the default value https://firefox.settings.services.mozilla.com/v1/

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 https://localhost change anything to the connections you are seeing in tcpdump/wireshark?

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 /etc/NetworkManager/conf.d/localdns.conf:

[main]
dns=dnsmasq

(make NetworkManager use a local, caching DNS server, maybe it is already setup this way on your distribution, check with grep -r dns= /etc/NetworkManager)

Then setup dnsmasq to log queries in /etc/NetworkManager/dnsmasq.d/options:

log-queries

[travankor]

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?

[emanruse]

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.

[adrelanos]

As per:

• https://github.com/arkenfox/user.js/issues/1807

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?

[emanruse]

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...

[nodiscc]

this may need source code patching, which seems beyond this project's scope.

definitely out of scope in my opinion

can this ticket still being open be interpret as this being a good development goal, yet not done because it is difficult to implement?

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)