3 ms·

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.

user2722 1y ago
It uses microG which has its own set of issues, though.
- cookiengineer 1y ago
  And it's a 1:1 copy of LineageOS, so there's that.
- strcat 1y ago
  It has very poor privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private 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.
ysnp 1y ago
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 https://eylenburg.github.io/android_comparison.htm.
- ForHackernews 1y ago
  /e/OS blocks trackers in apps out of the box. AFAIK Graphene doesn't do anything similar.
  - ysnp 1y ago
    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.
    - ForHackernews 1y ago
      /e/OS has native support for feeding fake data to apps, too: https://doc.e.foundation/support-topics/advanced_privacy#fake-my-location https://doc.e.foundation/support-topics/advanced_privacy#fak...
      - strcat 1y ago
        Global Mock Location is a standard Android feature not specific to /e/. GrapheneOS also supports it, and is building a better replacement for it similar to our Contact Scopes and Storage Scopes features providing otherwise missing functionality in Android that's partly available in iOS. /e/ doesn't have either of those things or other privacy features such as the Sensors toggle. /e/ can't prevent tracking by apps and doesn't do it. It has built-in DNS filtering, which doesn't stop the most privacy invasive behavior by apps but rather only single purpose domains for the least invasive tracking making no attempt to evade filtering as explained in https://news.ycombinator.com/item?id=45598100 https://news.ycombinator.com/item?id=45598100. Any app or SDK wanting to evade DNS filtering only has to use a dual purpose domain, perform their own DNS requests via DoH or fall back to an IP address so many apps and SDKs do those things. However, the most privacy invasive behavior almost always happens through the servers used for app functionality with server side data sharing with third parties. It's not considered good practice to put API keys into the client and do things client side in the first place. There are some exceptions such as crash reporting, analytics and telemetry where that's common which are far from the most privacy invasive behaviors. If they want to evade DNS filtering for those, that's easy.
strcat 1y ago
/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-standard-privacysecurity-patches-and-protections-arent-private 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.
pcdoodle 1y ago
I can't trust someone that names their product /e/OS.

user2722 1y ago

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

cookiengineer 1y ago
And it's a 1:1 copy of LineageOS, so there's that.
strcat 1y ago
It has very poor privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private 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.

ysnp 1y ago

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 https://eylenburg.github.io/android_comparison.htm.

ForHackernews 1y ago
/e/OS blocks trackers in apps out of the box. AFAIK Graphene doesn't do anything similar.
- ysnp 1y ago
  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.
  - ForHackernews 1y ago
    /e/OS has native support for feeding fake data to apps, too: https://doc.e.foundation/support-topics/advanced_privacy#fake-my-location https://doc.e.foundation/support-topics/advanced_privacy#fak...
    - strcat 1y ago
      Global Mock Location is a standard Android feature not specific to /e/. GrapheneOS also supports it, and is building a better replacement for it similar to our Contact Scopes and Storage Scopes features providing otherwise missing functionality in Android that's partly available in iOS. /e/ doesn't have either of those things or other privacy features such as the Sensors toggle. /e/ can't prevent tracking by apps and doesn't do it. It has built-in DNS filtering, which doesn't stop the most privacy invasive behavior by apps but rather only single purpose domains for the least invasive tracking making no attempt to evade filtering as explained in https://news.ycombinator.com/item?id=45598100 https://news.ycombinator.com/item?id=45598100. Any app or SDK wanting to evade DNS filtering only has to use a dual purpose domain, perform their own DNS requests via DoH or fall back to an IP address so many apps and SDKs do those things. However, the most privacy invasive behavior almost always happens through the servers used for app functionality with server side data sharing with third parties. It's not considered good practice to put API keys into the client and do things client side in the first place. There are some exceptions such as crash reporting, analytics and telemetry where that's common which are far from the most privacy invasive behaviors. If they want to evade DNS filtering for those, that's easy.

strcat 1y ago

/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-standard-privacysecurity-patches-and-protections-arent-private 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.

pcdoodle 1y ago

I can't trust someone that names their product /e/OS.