[ysnp]

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.

[strcat]

The approach used by /e/ doesn't actually work and enables fingerprinting VPN users. It only stops the least invasive tracking for client side analytics, etc. where there are single purpose domains which can be blocked. Multi-purpose domains used for both privacy invasive things and functionality don't get blocked. The app's own servers used for the most privacy invasive behaviors in practice of course don't get blocked. They can share whatever they want with arbitrary third parties through those. However, it won't get blocked client side by /e/ if it's needed for any functionality so third party services which are privacy invasive won't be blocked unless the app doesn't need them, doesn't do it server side and doesn't do basic evasion of filtering deployed in many apps by resolving DNS queries themselves or having IP fallbacks like Facebook.

Location Scopes is a planned replacement for the standard Android Mock Location feature which is rebranded in /e/ as their own feature. /e/ does not have features similar to Contact Scopes or Storage Scopes. It doesn't provide the current generation standard Android privacy protections or patches since it's always very far behind on updates. Most privacy patches aren't backported to older releases, but they lag far behind on backports and don't fully apply them despite claiming to provide a much newer patch level than they do.

[ForHackernews]

/e/OS has native support for feeding fake data to apps, too: https://doc.e.foundation/support-topics/advanced_privacy#fak...

[strcat]

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