Firefox built-in spyware that cannot be disabled | Hacker News Reader

Firefox built-in spyware that cannot be disabled

60 pointsgamertime40 comments

Looking at about:networking I can see connections to pocket (despite me disabling pocket in about:config) as well as connections to "firefox.settings.services.mozilla.com".

And after research, it appears some of these are hard-coded into the source code on purpose for "security reasons" which is ridiculous.

Mind you, my browser is hardened to it's best.. just felt like sharing this for anyone unaware that even if you harden Firefox, even if you go the extra 10 miles and edit about:config, it will still spy on you!

View on HN

I swear there must be one person at Mozilla with power and a massive sunk cost complex surrounding their pocket acquisition. if they actually cared, it wouldn't be built-in and so offensively un-disableable.

Yeah pocket is such a useless tool.

I love a lot of their stuff like the containers and local translation but pocket is just spam.

I agree it should be an add on.

On uselessness - it’s my primary offline reader - have it installed on an eink boox device and send 20-30 articles per week from the browser to the boox.

But bundling it with the browser makes no sense.

This is why I use LibreWolf, which is a patched version of Firefox that removes pocket and stuff like this entirely, instead of regular Mozilla Firefox with something like arkenfox to harden it. There's only so much a config, no matter how extensive, can really do for you against what's been hard-coded into a program itself, and configs need personal maintenance, whereas a patch version of a piece of software can pull things out at the root, and will generally be maintained by people other than me. Yes, since it's a patched version there is some delay in receiving updates from upstream, but it's very small and they're extremely consistent about keeping up with new Firefox versions, since I believe most of their system is automated and it's basically the same set of patches every time. So it's no more of a risk than using a distro packaged version of Firefox instead of a Flatpak version, since distro packages add the same sort of patching by a third party delay. And most people are fine with distro packages for browsers, so there's no reason to balk here either.

LibreWolf is not a fork, and rather a Firefox profile with branding and UI fixes on top.

The patches do not remove any telemetry. [1]

OP's argument still stands, as LibreWolf's telemetry and normandy integrations are identical to upstream Firefox.

[1] https://codeberg.org/librewolf/source/src/branch/main/patche...

You are incorrect. Please take a look at the default preferences that they ship, as they are a large and important part of it.

Literally on the front page: https://librewolf.net

You're here to astroturf for Mozilla or Google, aren't you?

The settings is literally what OP changed, and mentioned that the _source code which needs patches_ contains the URLs, which is correct.

You can verify that easily by grepping the codebase.

As LibreWolf doesn't patch these hardcoded URLs out, their marketing is wrong and a fraudulous statement. They don't remove these features and they are also not stubbing out the APIs (e.g. like TOR's patchset does).

I'm not here to astroturf anything, maybe just get your shit together and stop accusing people randomly?

This is a patch file from the repo that you listed. Does it not remove the problematic hard-coded URLs?

https://codeberg.org/librewolf/source/src/branch/main/patche...

I need to know the outcome of this argument, and also the mistaken party's ultimate response to said outcome—whether he concedes gracefully, quietly ghosts away, commences all-out holy war perhaps—that I may quietly judge his character thereupon.

I would read a novel written by you. good sir.

I use libreworf and it it spends few minutes of startup connecting to some mozilla server on AWS. Then all webpages start loading. I tried removing every single setting related to telemetry, replacing servers and it still doesn't work, perhaps its indeed hardcoded somewhere deep.

I am on firefox 122 , binary from Mozilla, not from my distro's repos (debian) and I don't see any connection to pocket - at least some domain that has the name 'pocket' on it.

I noticed this as well and blocked it in my local DNS. I also disable DoH.

    grep firefox /etc/unbound/override/combined.conf 
     local-zone: "firefox-settings-attachments.cdn.mozilla.net" always_nxdomain
     local-zone: "firefox.settings.services.mozilla.com" always_nxdomain

Or even good old hosts or whatever.

> I also disable DoH

Why? DoH is good for privacy.

He needs to disable DoH in order to avoid firefox using HTTPS to conduct the DNS queries. This is needed if he wants to block the request through his system hosts files or firewall.

If I do not disable it then I can not block nefarious domains for all devices on my network and I can not monitor what devices are doing DNS lookups.

I do not agree that it is good for privacy. Maybe one day if ESNI is implemented everywhere then there may be some truth in the idea, but that also assumes that we are not just moving the resolver from the local ISP to the big centralized platforms like Cloudflare or Google. Cloudflare and Google are by far the biggest and juiciest targets for state sponsored monitoring, much more than each individual ISP's DNS. As I have no control over their data retention and usage policies I just run my own DNS that talks directly to the root DNS servers and pre-resolves/caches all the domains name-servers that I talk to regularly. At best my tiny ISP would see my batch queries that run on a schedule. If some day my tiny ISP became nefarious I would put them out of business and hope that whomever acquires their infrastructure may be better behaived.

How does an application-specific configuration in firefox do anything about other devices on your network?

I think "disable DoH" there means "block all DoH servers at the router", not "configure Firefox to not try to use DoH".

Yes, I disable it using the suggested method of returning NXDOMAIN for "use-application-dns.net". I do also disable it in applications such as the browser to avoid the log entries.

    grep appli /etc/unbound/unbound.conf 
     local-zone: "use-application-dns.net." always_nxdomain

And then I have about 80 IP's that I blackhole. People often counter that with, "but DoH can run on any HTTPS endpoint and you can't block CDN's", and whilst this is true I have never run across a CDN performing front-ending DoH and I am the type of person that will block a CDN. I can route HTTPS for specific applications through my own VPN mesh if it came to that and use Squid SSL Bump MiTM proxies to sanitize URL's which I have done in the past. It would just be a couple ACL's in Squid to block DoH end-points. The only domains I can not MiTM are those still using public key pinning such as Paypal which I will never use, eff.org, and a few Google sub-domains. There are probably a few others I have not run across on my Squid proxies.

As a side note, I think PiHole should consider adding a feature for Squid MiTM proxy mode so that more people can do this, with options like peeling off specific LAN clients to use the proxy or force everything through it.

Ahh I saw your other comment. Yes this makes sense. Most of them would use known domains.

I don't think pihole will be able to MITM though at decent speeds, if it's actually running on a raspberry pi.

Blocking DoH at the router is almost impossible because it looks exactly the same as other HTTPS traffic.

The only option is to do a man in the middle like some business firewalls (eg zscaler) do.

I don't like DoH much either because apps can use it to bypass my local pihole. But blocking it is hard when an app hardcodes its own DoH server.

DoH is really a solution for a US problem that we in Europe don't have. Here it's illegal for ISPs to use deep packet inspection to datamine their customers.

Blocking DoH at the router is almost impossible because it looks exactly the same as other HTTPS traffic.

I covered that in the comment next to this one.

One can still use a local dnsmasq and https_dns_proxy to leverage pure DNS on ones LAN but have the ISP only see DoH

Depends on who the upstream provider is. Having a pihole or opnsense with dnscrypt and/or unbound setup is best.

How is dnscrypt any better than DoH? And doesn't unbound still need an upstream resolver to talk to?

> DoH is good for privacy.

That depends on what sort of privacy concerns you. I think DoH is awful because it allows DNS lookups that I cannot observe/filter/respond to without going to great lengths.

Firefox's builtin DoH ignores /etc/hosts. I'd prefer systemwide DoH instead.

Is pocket actually spyware / telemetry or is this just conjecture?

Either way you wouldn't know. Anything that phones home could be spyware, the difference is on the far side. So it could start out as not spyware and then become spyware. Or it may sometimes be spyware and at other times it is not.

Browsers should only do what their users tell them to do. In fact: that goes for computers as a whole.

For those wondering like me, this is Mozilla’s official documentation page about network connections made by Firefox:

https://support.mozilla.org/en-US/kb/how-stop-firefox-making...

Here's your solution

https://librewolf.net/

Keeps version parity but removes all the nastiness with a lot of other beneficial config changes...and the ability to further customize in persistent js files.

Cachy Browser in CachyOS/Archlinux is more or less Librewolf with some other tweaks to make it faster.

That does sound appealing, but I don't see any information on who owns or maintains it.

You click "@ohfp" and it leads you to an incredibly empty github-ish thing with 7 total followers? That is not a good sign at all.

"About us" is completely missing, and that is extremely important to me.

I would need a bit more trust, maybe even something like EFFs blessing, to use this.

If you were being skeptical, would you trust them? Why?

You're right to be apprehensive and skeptical, most of the Firefox forks leave a lot to be desired. Usually maintained by anonymous randoms that most likely aren't experts on the technology. That's why I would instead recommend the Mullvad browser which is also a Firefox fork, but is being maintained by a profitable company with reputable engineers. Whose main product focuses around protecting your privacy and securing you.

https://mullvad.net/en/browser

The only potential issue with it is that it might be TOO good at anonymizing you, to the point that you set off security measures, ala Cloudflare, simply by NOT leaking any juicy data to identify you.

I wonder how much hidden telemetry is in Brave browser, if any. Has anyone with wireshark chops looked into it?

Mozilla CEO needs this for that sweet Google payout. This is how you prove to advertisers number of active installs.

This is the right answer. (The Vivaldi browser company too say the same thing in their forums when asked why "phoning home" cannot be completely disabled). It's also a bit frightening because this means Firefox collects enough data to fingerprint and uniquely identify every browser / user.

Hmm I wonder if it's possible to generate fake callbacks to this to mess up the data >:-] A bit like ad nauseam that tries to mess up advertisers' by taking a click on each ad without actually showing it to the user.

yes, ff does a ton of background connections. use wireshark to see what it is doing. i tried to block all that crap once but after a while i just gave up.

it is still my primary browser because it is now the only alternative to google's monopoly(even though mozilla is de facto living off of google's money).

They're not only living off google money, they also fired all their engineers, and google is required by court of law to supply money and engineers to help maintain Firefox, ridiculous!

Reply on news.ycombinator.com