>
are by incompetent/lazy/pressured devs who just throw in some library and don't even care that it leaks data to GoogleEven 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:
* separate network namespaces for profiles (https://github.com/GrapheneOS/os-issue-tracker/issues/5225#i...) and/or a GrapheneOS-Gateway equivalent to https://www.whonix.org/wiki/Whonix-Gateway,
* built-in OS support for chaining VPNs together or splitting different traffic over different privacy-enhanced networks like in RethinkDNS,
* adversarial pressure wave + ultrasonic noise to thwart smart listening devices https://youtu.be/xMYm2d9bmEA?t=1305,
* virtualisation as a sandboxing and anti-fingerprinting primitive (https://discuss.grapheneos.org/d/5775-device-fingerprinting-...),
* control over what apps can communicate with each other https://github.com/GrapheneOS/os-issue-tracker/issues/2197
* location scopes/phone state scopes etc that are already planned.
etc.