← Back to context

Comment by ForHackernews

6 months ago

You might like /e/OS. It's less secure/hardened than Graphene, but offers a de-Googled Android with a focus on privacy and usability.

/e/ has extraordinarily poor privacy and security. It's largely the opposite of GrapheneOS. It's hardly focused on privacy and security. See the information available at https://discuss.grapheneos.org/d/24134-devices-lacking-stand... including the information that's linked from third party privacy and security researchers.

/e/ always uses multiple Google services and builds in privileged support for Google apps and services so the branding as a degoogled OS doesn't really make sense. GrapheneOS doesn't brand itself that way but doesn't make connections to Google servers by default and doesn't provide privileged access to Google apps and services.

It uses microG which has its own set of issues, though.

  • It has very poor privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand.... It lags extremely far behind on kernel, driver and firmware patches even when they're available. It lags far behind on AOSP and browser patches too. As an example, /e/ on the Pixel 7 is still on Android 13 with multiple years of missing High and Critical severity kernel, firmware and driver patches since they didn't backport it to Android 13 while the Pixel 7 is on Android 16.

The base operating system is quite far behind on app compatibility, privacy and "deGoogling" in comparison to GrapheneOS https://eylenburg.github.io/android_comparison.htm.

  • /e/OS blocks trackers in apps out of the box. AFAIK Graphene doesn't do anything similar.

    • No, it doesn't block tracking or privacy invasive behavior by apps and it has much weaker privacy protections from apps than GrapheneOS.

      /e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.

      DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.

      /e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....

      2 replies →

    • Rethink DNS app provides the ability to do that. Also can use it to connect to any Wireguard VPN and also monitor connections.

      There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections

      1 reply →

    • Because the technicalities of accomplishing something like that are quite complicated from what I understand. If an app has the necessary permissions and network access, almost anything you try to stop it from transmitting data about the platform and data about its usage is futile.

      You're firing a starting pistol for a race to the bottom where app developers just end up sending all that information to their own first-party servers instead to be shared with whoever they wanted to anyway.

      GrapheneOS absolutely tries to deal with the root of the issue, by giving the user control over sensors and network permissions that return fake/simulated data to keep the app running while denying access to data in the first place. Or contact scopes and storage scopes which restrict access to contact information or storage locations in the first place. As you can imagine, more are planned like location scopes, app communication scopes etc.

      3 replies →