LibreWolf

4227 readers

1 users here now

Welcome to the official community for LibreWolf.

LibreWolf is designed to increase protection against tracking and fingerprinting techniques, while also including a few security improvements. LibreWolf also aims to remove all the telemetry, data collection and annoyances, as well as disabling anti-freedom features like DRM. If you have any question please visit our FAQ first: https://librewolf.net/docs/faq/

To learn more or to download the browser visit the website: https://librewolf.net/

If you want to contribute head over to our Codeberg: https://codeberg.org/librewolf

founded 5 years ago

MODERATORS

fishonthenet@lemmy.ml

YSK that LibreWolf creates persistent connections to Mozilla (lemmy.ca)

submitted 1 week ago by observantTrapezium@lemmy.ca to c/librewolf@lemmy.ml

3 comments fedilink hide all child comments

Despite disabling most of Mozilla's telemetry and other phone-home functionality (such as captive portal), I found that a fresh LibreWolf profile makes quite a few connections on first startup (see list below), and some repeating every startup. One in particular is persistent: that is to push.services.mozilla.com and can be disabled by setting the dom.push.enabled configuration to false (I personally don't need push notifications in the browser; you can also set a custom URL).

What is particularly annoying is that some of these domains, related to "remote settings", are essentially hard-coded and cannot be disabled by changing configuration parameters. I now block these three in my /etc/hosts file.

firefox.settings.services.mozilla.com
firefox-settings-attachments.cdn.mozilla.net
content-signature-2.cdn.mozilla.net

Helpfully Mozilla lists domain to allow so you can find more domains to potentially block.

Here is the list of domains LibreWolf connected to at startup of a fresh profile. Some are understandable, some less so.

addons.mozilla.org
firefox.settings.services.mozilla.com
firefox-settings-attachments.cdn.mozilla.net
content-signature-2.cdn.mozilla.net
services.addons.mozilla.org
gitlab.com
push.services.mozilla.com
ublockorigin.github.io
malware-filter.gitlab.io
raw.githubusercontent.com
pgl.yoyo.org
curbengh.github.io
malware-filter.pages.dev
cdn.statically.io
versioncheck-bg.addons.mozilla.org
cdn.jsdelivr.net
ublockorigin.pages.dev
publicsuffix.org
codeberg.org

top 3 comments

sorted by: hot top controversial new old

[–] qweertz@programming.dev 4 points 6 days ago

These all seem valid and functional, no?

[–] potatoguy@mbin.potato-guy.space 16 points 1 week ago

I believe these two:

firefox.settings.services.mozilla.com

content-signature-2.cdn.mozilla.net

involves certificate expiration, so they are really important. But I could be wrong.

[–] ken@discuss.tchncs.de 5 points 1 week ago* (last edited 6 days ago)

YSAK: If you care about stuff like this, Konform Browser is likely more suitable for you!

It makes these things easier to configure (e.g: There is UI for toggling RS server or setting a custom URL). It makes it easier to selectively enable only security-related stuff (cert revocation lists) while keeping requests for less important features disabled. It requires opt-in to enable the background fetching and has 0 self-initiated/background outgoing connections on first startup. When request to RemoteSettings is blocked by configuration, it reuses locally available data to a larger extent. It is more selective about what to sync and not. It loads ublock origin from local filesystem instead of downloading it from internet at runtime. Etc...

What is particularly annoying is that some of these domains, related to “remote settings”, are essentially hard-coded and cannot be disabled by changing configuration parameters.

This is not entirely true. Relevant prefs for about:config or librewolf.overrides.cfg that are recognized by either browser:

services.settings.server
librewolf.services.settings.allowedCollections
librewolf.services.settings.allowedCollectionsFromDump

For example