I don't think they use this term anywhere.

It also now works on Motorola devices, it's on my HN feed literally right above this post.

But we have to keep in mind that /e/ has a lot of problems, the only one solved is sending data to Google. The security aspect of the OS is problematic and some key elements of a privacy seem questioning (AI integration, commercial collaborations, ...).

Fix: IA => AI typo and various English errors.

So if you're trying to be a silly purist, then /e/OS doesn't fit either. If you're not, getting a Pixel will significantly enhance your safety since they're better supported for security patches and better designed in hardware when it comes to security.

The goal is to give you the option to avoid needing to rely on Google's spying or services while not having to compromise on security.

None of these other solutions regularly get included in Celebrite's documentation as being an explicit benchmark of their software's ability to break into phones. And that's almost certainly due to the fact that unless you leverage hardware security features like what GrapheneOS (and stock Android on a Pixel, and iOS on an iPhone) utilises, you have no chance of going against any actual adversaries.

And I'm not just talking about state actors here, even drive-by opportunistic attacks are likelier on a random other phone running some other Android build.

So yeah, you are running Google hardware, that doesn't make you "googled". It's just a sad reflection on the reality of the hardware landscape. If you want the same security as what GrapheneOS offers, you will currently need to use a Pixel.

I'd be curious to see what comes out of their Motorola partnership though.

https://news.ycombinator.com/item?id=47214645

>insistence on not supporting MicroG leads to poor UX,

The problem they are trying to solve is apps not working without the presence of Google Mobile Services or Google Play. They don't want to compromise by having a component with high privileges integrated in their image that involves security issues like signature spoofing.

MicroG will send less data to Google partly because it is simply an incomplete implementation of the features offered by GMS (sanboxed-google-play appp compatibility is quite a bit higher), partly because the access is more granular or there are choices offered for services like location (GrapheneOS provides non-Google location services and community support on only installing and enabling the parts you need for specific app features to work). UX is not adversely affected, but if you want to use a privileged app bypassing security checks and sending data to Google anyway then you have the freedom to compile microG with it integrated if you would like.

>They also seem to be very opinionated about (not) using a firewall for privacy, like NetGuard, instead recommending some weird alternatives like DNS firewalls

GrapheneOS tries to implement or end encourage sustainable approaches to privacy and security, and this partially means approaches that don't break if the adversary knows what you are doing.

Egress/outbound traffic filtering is fundamentally unworkable. Apps do not have to connect to known privacy a invasive third party domains to violate your privacy or expose your data to extra parties, they can simply send anything they want to their own servers and do anything they like with the data. From my understanding this is why GrapheneOS do not want to encourage the approach of blocking apps from connecting to certain domains/addresses.

Instead they tackle the problem at its source by providing a direct AND indirect network access toggle which cuts off an apps access to the outernet without letting the app know (pretends the network is down). This makes it non trivial for apps to exfiltrate data and as a side effect can provide benefits like data conservation (for capped plans).

>instead recommending some weird alternatives like DNS firewalls.

DNS based solutions are offered (not promoted) if you want more control over your DNS query resolvers or you want to improve your quality of experience by blocking advertisements and malvertising domains.

>they (heavily) prioritize security over privacy.

Can you point out another OS project with real privacy features like a network permission, sensors data access permission, contact access scopes, storage access scopes, per connection MAC randomisation and so on? https://eylenburg.github.io/android_comparison.htm They have even more plans for privacy like location scopes, anti-fingerprinting for Vanadium browser and maybe AnonymisedDNSCrypt/Oblivious DNS and probably more they haven't mentioned. If you suggest some more on their issue tracker they may get back to it when they have the resources.

Doesn't seem a universal bug.

If you can use GrapheneOS, good for you but what /e/OS offers is:

- Usable Android with your usual Android app (banking, etc) - No data sent to Google by default - Easier interface with nearly no bloatware - Available easily on many smartphones, including older ones - Extending the life of some smartphones

The price to pay is:

- Some Murena cloud bloatware - Android security patches are sometimes delayed - Security is not on par with GrapheneOS

If your main concern is protecting your privacy from Google and extending the life of your smartphone without breaking a sweat, /e/OS is probably the best option.

If your main concern is protecting against state actors attacks or very specific threats, then GrapheneOS might be better.

/e/OS works really great for non-techie users. I’ve done it in my family.

But what I think a lot of people are missing is what you exactly just touched on. We have options! That's a good thing. Yeah, some options are not as good as others if you wanna optimize for X. Then don't use that option! Use the option that works for you.

To me, the fact that alternatives exist on varying spectra of "degoogle-fication" is a win in my book. The fact that we're able to talk about and recommend so many alternatives is a good thing.