Wie /e/OS von @murena mein Smartphone vor Tracking-Versuchen schützt. https://e.foundation/wp-content/uploads/2025/01/White_Paper_-_Privacy_-_DE.pdf (PDF)

Spitzenreiter ist #sofascore mit durchschnittlich einem Trackingversuch pro Stunde. Allesamt blockiert.

@docjosiahboone @murena Ich kann /e/os leider nicht empfehlen. Deren FW Images sind of veraltet und enthalten damit bekannte Sicherheitslücken, der verwende App-Store ist inherent unsicher (F-Droid), der Zugriff auf den Google-Appstore über Aurora kann von Google jederzeit abgedreht werden. Ein Betriebssystem das bekannte Sicherheitslücken enthält kann auch die Privatsphäre nicht schützen.
Ich persönlich verwende @GrapheneOS.
@innerand
Graphene klingt interessant und wollte ich schon ausprobieren, unterstützt aber leider viele Smartphones so wie auch meines nicht.
@docjosiahboone /e/OS does not protect your privacy and security but rather massively reduces it. It lacks the most basic privacy/security protections. It does not keep up with privacy/security patches and misleads users about it. It doesn't keep crucial parts of the privacy/security model intact. It's an unsafe OS choice and extraordinarily insecure and non-private. Doing DNS-based filtering of non-required connections does not stop invasive apps/services getting/sharing your data.
@docjosiahboone NS-based filtering can be trivially bypassed through apps hard-wiring IPs or doing their own DNS resolution. Facebook already takes this approach. It's also inherently only capable of blocking things with standalone DNS names which are nicely split out from functionality required for apps to work. As long as the same names are used for services needed for wanted and unwanted functionality, it can't deal with it. This means it's worse than a typical enumerating badness approach.

@docjosiahboone Developers can and do make third party connections from their own services instead of doing it within the app. This is increasingly how things are implemented due to filtering and also because otherwise sensitive API keys are generally leaked through the client.

There are better implementations of DNS-based filtering implemented as apps which can still be used with an actual VPN including RethinkDNS. However, the approach itself is increasingly limited in what it can do.