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:
> 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.