As someone who switched from FP4 with /e/OS to GrapheneOS - absolutely not true.
My reason for switching was a bug where the phone calls didn't display the caller number. So I switched to GOS in hope it would be better... and it is, but not in all areas. For example their insistence on not supporting MicroG leads to poor UX, because let's face it, you can't trust Google services, even sandboxed, to not syphon tons of data into the cloud. MicroG was easybto use for privacy. They also seem to be very opinionated about (not) using a firewall for privacy, like NetGuard, instead recommending some weird alternatives like DNS firewalls. And don't get me started on their icons - I don't mind ugly-ish icons, but they are taking the ugliness to a whole new level.
GrapheneOS is not a bad OS, but it is very opinionated, and they (heavily) prioritize security over privacy. When I turn FP4 on, I still like it way better than GOS. Still, I like seeing who is calling, so I'm not going back... Ymmv.
It is not, it is related to both major phone service providers in my country. Abroad, everything worked just fine. And just in 4G/5G, however 3G is getting phased out, so if I forced it, I was often unreachable.
I was wondering if I could fix it myself, but I'm not even sure if this is firmware or OS issue. I assume the former, which afaik is not opensource? Not sure.
I am not a project member so I cannot speak for GrapheneOS, but maybe I can help clear up some misunderstandings.
>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.
To put my answer in context, I was replying to this:
> There's absolutely no reason to use /e/ when GrapheneOS exists.
There absolutely is. If I was choosing again today I would be tempted to switch back, for the reasons I listed. And I would probably miss many things you cited, like Storage and Contact Scopes.
As for MicroG, afaik I can't use it on GOS without considerable effort (recompiling OS) and probably also ongoing maintenance burden (updates). So this is not an option for me, FP5 with /e/OS is still better then.
NetGuard - very nice answer, shows exactly what you and GOS developers are missing! Yes, the actively hostile apps will exfiltrate data as soon as you let them contact anything on the outside. But most of the apps are by incompetent/lazy/pressured devs who just throw in some library and don't even care that it leaks data to Google. For example my banking app. Why the hell should Google be notified when I decide to open my banking app? If I cut its network, as you suggested, the app stops working. But if I just blacklist Google site for this app, the problem is solved. Of course, I don't want to cut it for all apps, because then some might not work. And that's just one of many similar examples.
That's why I said that the main focus of GOS is security, not privacy. If they cared about privacy primarily, they would actively support microG and NetGuard, or at least similar solutions.
That said, I am actually a fan of GrapheneOS, it is just so frustrating that we can't have it all in one package. Ah well.
>are by incompetent/lazy/pressured devs who just throw in some library and don't even care that it leaks data to Google
Even if I agreed with this statement, I don't understand why it is better to put limited/precious resources something the app developers can easily circumvent, praying they never stop being incompetent/lazy/pressured and tell device owners it is an important privacy feature? Instead of waiting for the apps to become actively hostile why not just feed them fake data in the first place? Like the scoped access permissions do?
If you really want to do this, you (and any GrapheneOS user) can do it today with mitmproxy and RethinkDNS but I think it is perfectly OK users choose their (privacy-invasive) apps and choose how to mitigate annoyances like that themselves. Otherwise they need to complain to the app developers and app stores.
>That's why I said that the main focus of GOS is security, not privacy. If they cared about privacy primarily, they would actively support microG and NetGuard, or at least similar solutions.
That feels more like you are framing your opinion as a fact. To me it is not so obvious.
When I think of privacy, I think of Privacy Enhancing Technologies (https://petsymposium.org/). I also think of things like:
My reason for switching was a bug where the phone calls didn't display the caller number. So I switched to GOS in hope it would be better... and it is, but not in all areas. For example their insistence on not supporting MicroG leads to poor UX, because let's face it, you can't trust Google services, even sandboxed, to not syphon tons of data into the cloud. MicroG was easybto use for privacy. They also seem to be very opinionated about (not) using a firewall for privacy, like NetGuard, instead recommending some weird alternatives like DNS firewalls. And don't get me started on their icons - I don't mind ugly-ish icons, but they are taking the ugliness to a whole new level.
GrapheneOS is not a bad OS, but it is very opinionated, and they (heavily) prioritize security over privacy. When I turn FP4 on, I still like it way better than GOS. Still, I like seeing who is calling, so I'm not going back... Ymmv.