mozilla products phoning home all the time, violating privacy and security policy

Hi

You can read about the captive portal detection at:

https://support.mozilla.org/en-US/kb/captive-portal

And the DNS over HTTPS functionality at:

https://support.mozilla.org/en-US/kb/firefox-dns-over-https

The people who answer questions here, for the most part, are other users volunteering their time (like me), not Mozilla employees or developers. When a Mozilla employee jumps into a discussion, you'll see the Mozilla Staff label next to their name.

If you wish, you can leave feedback for developers on the Mozilla Connect website. Click the Firefox Menu button in the toolbar, click Help and select Share ideas and feedback…. Alternatively, you can use this link. Your feedback is collected by a team that reads it and gathers data on the most common issues.

You can also file a bug report or feature request. See File a bug report or feature request for Mozilla products for details.

Hi Paul,

Neither CP nor DoH seem to have any relevance to my original comment.

Captive portal detection is literally just a internet-connectivity test so any non-local URL that simply prints a known result ("success" in the case of firefox) can do it. See for yourself by visiting http://firefox-portal-detection.com/. So CP detection itself is not the issue, nor relevant in this context. What is relevant however is that CP detection in firefox uses a hard-coded URL and no way to change it or disable the test altogether. The result is firefox constantly phoning home to that hard-coded URL.

And DoH is also irrelevant in this context. Even if it were potentially relevant by phoning home to a mozilla-run DoH service (instead of letting Cloudflare do all the surveillance by default), it would still be irrelevant since the profile in this case is configured to use the local DNS setup. Means no DoH.

To clarify, it was your question that mentioned both FoH and captive portal detection.

If you do have feedback on the privacy preserving features of Firefox, I recommend that you raise it on our feedback platform as mentioned.

Yes, I did mention DoH, but not as the issue. Not sure why you even referred to it in your reply - I only mentioned it in the sense that it's disabled and that it's not really a privacy-oriented nor privacy-enhancing feature at all, contrary to the way Mozilla sells it. Same for captive portal functionality. It's only tangential to the issue in the sense that it *also* phones home constantly.

The issue, as pointed out in the original message, is that firefox and mozilla products in general seem to phone home all the time - at startup, during browsing and at the end of the session. And on attempting to inspect this data that is being phoned home, by sending it via a proxy, it stops, effectively and actively hiding it's phoning-home activity/data.

So it's not... "privacy preserving features"... but rather covert/clandestine surveillance misfeatures.

Does this clarify it?

The actual check on the new connectivity probe is not the 200 OK result you see when accessing via browser, but a 204 status of the initial exchange. It definitely is configurable in profile prefs, look for captivedetect.* and network.captive-portal-service.* keys.

DoH you can also prime with any custom endpoint (like I do, for example — or disable by your network using the RFC filtering probe domain resolution completely) — so that's something you can plug in via e.g. a policy or js config before even launching the profile for the first time if you wish.

You can check the source code for your MITM suspicion — there's actually a MITM protection in place, primarily to surface subsequent errors and probably not related to internal traffic backoff intentionally — there's a canary check to own services, and if the cert signatures appear later again, a MITM–themed TLS error is raised, so you might have triggered the canary bit. (I'm not sure if that's in Gecko code, or Necko/NSS offhand, but it will definitely take you back to the previous decade if you track the diffs.)

From the hosts you posted, the most obvious reasons for the four listed are: CRLite cert revocations diff, Support media, Addons checks, Service Workers backing API.

While the official documentation lists the minimum range of endpoints that are necessary for the browser to function reasonably, you should be able to "void the warranties" as much as you like and configure the profile to work around your blocked hosts.

The connection stall you see now might be due to, ahem, you blocking the factory endpoints that would serve some prefs flipped remotely. Look into disabling happy_eyeballs or http3 if your TLS inspection drops UDP/443 connections.

Hi jbr,

I've now tested this a bit more. I created a new, empty profile. Let me tell you: on startup there's a flood of connection attempts to all sorts of sites and services, both mozilla's and others. Like literally 100s. Addresses include:

location.services.mozilla.com mozilla.map.fastly.net firefox.settings.services.mozilla.com firefox-portal-detection.com push.service.mozilla.com accounts.firefox.com services.addons.mozilla.org update.googleapis.com etc.

This is only a sampling from the list as they just keep pouring. This is *all* from just creating this one new profile. Says: "Welcome to Firefox." Suffice it to say that I have no accounts on mozilla's servers, nor did I ask for one, nor did I select anything resembling one etc, likewise for google's servers. Haven't "managed diagnostic and interaction data" either, yet. Mozilla just took the liberty of doing it anyway without asking and before giving me a chance to say "no" to their dragnet. Unselected "Send technical and interaction data to Mozilla". Not that it matters much now that it has all been sent already. Or rather it would've been had it not been blocked. With extreme prejudice. Justifiably so too, it seems.

Is this what passes for "privacy-focused" these days?

More connection attempts: firefox-portal-detection.com ads.mozilla.org incoming.telemetry.mozilla.org support.mozilla.org

I thought I turned off "Send technical and interaction data to Mozilla" so why is it still trying to connect to Mozilla's dragnet telemetry sink?

"You're in safe paws. We protect your data and block companies from spying on your clicks - automatically."

LOL. I guess they don't include Mozilla in that.

"Make Firefox feel more like home".

100s of connection attempts by now. If I want to feel more like home, Mozilla will need to stop trying to ram the front door.

Skip this step. Skip. Skip. Start browsing.

DNS requests for tons of sites: www.wikipedia.org www.youtube.com www.reddit.com addons.mozilla.org support.mozilla.org dyna.wikimedia.org dualstack.reddit.map.fastly.net mozilla.map.fastly.net

Looks like the whole world has just been informed that I've created a new firefox profile. Or rather it would've been had it not all been blocked.

More connection attempts to incoming.telemetry.mozilla.org etc.

Let's just shut this thing down. Closing browser.

What's this? Hm: /usr/lib/firefox/pingsender https://incoming.telemetry.mozilla.org/submit/telemetry/<uuid>/event/Firefox/155.0.1/release/20260903215306?v=4 /<profile_path>/saved-telemetry-pings/<uuid> https://incoming.telemetry.mozilla.org/submit/telemetry/<another_uuid>/first-shutdown/Firefox/155.0.1/release/20260903215306?v=4 /<profile_path>/saved-telemetry-pings/<second_uuid>

Blocked. I mean *GTFO* BLOCKED.

Let's fire it up again, same empty test profile.

"Make Firefox your default browser? Get speed, safety, and privacy every time you browse."

Jokers LOL.

Missing button: NOT EVER. Don't show this message again. Check.

Empty tab. Connection attempts.. tons: firefox-portal-detection.com push.services.mozilla.com ads.mozilla.com incoming.telemetry.mozilla.org ...

I guess that setting that said "NO" to sending telemetry data to Mozilla didn't stick. Probably a bug, right? RIGHT? Rrrrrright...

Let's open an empty tab so that we have two empty tabs... DNS requests to www.wikipedia.org www.youtube.com www.reddit.com addons.mozilla.org support.mozilla.org

Connection attempts: firefox-portal-detection.com firefox.settings.services.mozilla.com incoming.telemetry.mozilla.org addons.mozilla.org

These just keep pouring. Haven't even done anything yet except opened two empty tabs...

I thought I turned off "Send technical and interaction data to Mozilla" so why is it still trying to connect to Mozilla's dragnet telemetry sink?

I guess it tries to send one last ping to inform Mozilla that you turned it off and that your data should be deleted from servers.

Yes, the ping scheduler will keep trying for 30days to deliver the UUID that should be removed from the dataset.

When you say "empty tabs", you mean about:blank pages, or the default home pages with shortcut tiles, favicons etc.?

The rest are pretty much speculative preloads for things. Remove search engines, remove autocompletion endpoints and type–ahead/suggest services, remove home tab content, remove webcompat interventions, remove bookmarks (with their favicons), host your own application–services with certificate updates etc., host your own updater endpoints, disable serviceworkers etc.

New profiles don't expect to do "no connections", quite the contrary as it will be priming about ~40MB of the usual caches for onboarding users — getting language pack lists from addons.m.o, available background collections for home tab and this kind of things — the diffs beyond what shipped in the offline copy built into the app bundle from weeks ago. If you want to launch new profiles already configured to NOT do the usual consumer stuff, feel free to familiarize yourself with the various prefs mechanisms that you can use to (pre–)configure your setup.

If you want to understand how that data content looks, check the telemetry dictionary, and read up on the OHTTP pings for how the connections are facilitated to not expose the consumer IPs.

None of the opt–outs mention you don't/won't need any of the endpoints listed in the docs earlier though. So if you're unable to actually send the opt–out due to your blocking, you'll have to see that hit for the next month until it gives up. It's your choice. And you have all the sources available to check how that's done.

Yes the uuid to be removed from the dataset is like the email address to be removed from the spam list. Pretty please, you know. But then again, the issue is that it was put in the dataset in the first place, not only without consent (never asked) but in fact against my will. And once harvested, you (I mean Mozilla) are now asking me to believe and trust you that it will in fact be removed from the dataset and that it will not be used. Like spam. Except a bit later you discover it in a different dataset. Did it get there from the original leak? Did the spammer pass it on? Was the dataset leaked unwillingly? No way to tell as a user. And dataset holder probably won't tell even if they know.

Therefore to avoid the issue, don't collect it at all. It's the ultimate privacy protection. You can't credibly tell me you're protecting my privacy and security while at the same time collecting all sorts of personal info, or info about my computer, or info about my location and so on... I didn't sign up for it, that's for sure. But once it's in your dataset, *I* can't remove it. And I don't trust you (by "you" I mean Mozilla) will do it either. Even if your intentions are in fact honest, which in this day and age seems to be a rather naive expectation, the dataset might have been mined already by a 3rd party unbeknownst (or not unbeknownst) to you - by some 3-letter MITM agency with access to gratuitously shared corporate TLS keys obtained by offers they can't or won't refuse, by some 3rd party no-goods, or perhaps just by plain old corporate or employee greed.

By "empty tabs" I mean whatever the default is, so yes, the default home pages probably. But this is in this empty, test profile. I wanted to see what the list would be there, without any addons etc, just the defaults. In the regular profile all this has been disabled. No weather updates, no search input box, no nothing, just a couple rows of shortcuts. And it still results in 8 connection attempts to firefox-settings-attachments.cdn.mozilla.net every time. Preloading? What? From firefox-settings-attachments.cdn.mozilla.net? What does firefox-settings-attachments.cdn.mozilla.net store that needs to be downloaded by the browser every time a new tab is opened? That is if we assume it's downloaded and not uploaded.

I don't know what you expect new profiles to expect or not expect. I expect it not to go out of its way to announce itself. That is if it is in fact respecting my privacy. That's what privacy is and what private means: something that is not shared with the whole effin' world. Right?