No, it doesn't block tracking or privacy invasive behavior by apps and it has much weaker privacy protections from apps than GrapheneOS.
/e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.
DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.
/e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....
You're responding to verifiable technical information by linking to harassment content based on fabricated stories.
The company you've linked was scamming people who wanted GrapheneOS phones by selling them end-of-life devices no longer supported by it and devices near end-of-life while pretending they were perfectly fine and would last years. They were misleading people about what they were getting and violating our trademark. Despite profiting from selling devices with GrapheneOS, they were also actively misleading people about it with many inaccurate claims. Their response to us politely bringing it up was blocking our project account and attacking us. When we warned our community, they responded by joining in with spreading fabricated stories about our team aimed at directing harassment towards us. The videos linked in the article are harassment content filled with fabrications and misrepresentations. The initial video is from someone responsible for encouraging repeated swatting attacks towards our team and the 2nd is from someone who openly uses Kiwi Farms which they directly personally involved to target us.
/e/ leadership spent years trying to mislead people about GrapheneOS including highly inaccurate claims about privacy and usability. We began debunking this and posting accurate technical criticisms of /e/. Despite spending years attacking us with little to no response from us, /e/ has responded to us informing people about it by joining the harassment you've tried to promote. Their CEO / founder has directly participated in it. It's a very typical pattern from /e/ and their community for the response to accurate technical information to be fabricated stories aimed at targeting us with harassment.
Rethink DNS app provides the ability to do that. Also can use it to connect to any Wireguard VPN and also monitor connections.
There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections
Apps mainly avoid it because their most privacy invasive features are tied to their functionality and their own servers. They can share with third party server side and mainly do that. Client side stuff is mainly far less important analytics, telemetry, crash reporting, etc. If the app or SDK wants to evade filtering client side, they just need to do their own DNS resolution via DoH using a hard-wired IP whether it's 1.1.1.1 or their own server. Facebook has IP fallbacks in several of their apps.
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.
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.
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.
No, it doesn't block tracking or privacy invasive behavior by apps and it has much weaker privacy protections from apps than GrapheneOS.
/e/ has built-in DNS filtering, which blocks a small minority of third party tracking and not the most privacy invasive behavior by apps. It blocks single purpose domains not needed for functionality which were added to their list. It doesn't block any of this when it's on multi-purpose domains with the third party sharing either done server side or required for functionality. Apps can also trivially bypass DNS filtering by doing their own DNS resolution or having IP fallbacks, which many do. However, most simply do the most invasive sharing with third parties server side. App and SDK developers are well aware many people are filtering DNS and work around it.
DNS filtering has downsides including making a VPN not provide the same level of anonymity from websites unless the VPN provides it as a standard feature, since the specific list of blocked domains can be detected.
/e/ doesn't provide current generation Android privacy protections and doesn't keep up with the privacy patches, which would requiring following along with the stable releases of the OS. It doesn't provide privacy features like the GrapheneOS Contact Scopes, Storage Scopes, Sensors toggle and many others. /e/ doesn't improve the app sandbox or permission model like GrapheneOS but rather destroys them. Lagging behind so far on basic privacy and security patches means lack of basic privacy and security. See https://discuss.grapheneos.org/d/24134-devices-lacking-stand....
You really come across like you have a personal vendetta here.
Is this you? https://privatephoneshop.com/why-we-no-longer-sell-phones-wi...
You're responding to verifiable technical information by linking to harassment content based on fabricated stories.
The company you've linked was scamming people who wanted GrapheneOS phones by selling them end-of-life devices no longer supported by it and devices near end-of-life while pretending they were perfectly fine and would last years. They were misleading people about what they were getting and violating our trademark. Despite profiting from selling devices with GrapheneOS, they were also actively misleading people about it with many inaccurate claims. Their response to us politely bringing it up was blocking our project account and attacking us. When we warned our community, they responded by joining in with spreading fabricated stories about our team aimed at directing harassment towards us. The videos linked in the article are harassment content filled with fabrications and misrepresentations. The initial video is from someone responsible for encouraging repeated swatting attacks towards our team and the 2nd is from someone who openly uses Kiwi Farms which they directly personally involved to target us.
/e/ leadership spent years trying to mislead people about GrapheneOS including highly inaccurate claims about privacy and usability. We began debunking this and posting accurate technical criticisms of /e/. Despite spending years attacking us with little to no response from us, /e/ has responded to us informing people about it by joining the harassment you've tried to promote. Their CEO / founder has directly participated in it. It's a very typical pattern from /e/ and their community for the response to accurate technical information to be fabricated stories aimed at targeting us with harassment.
Rethink DNS app provides the ability to do that. Also can use it to connect to any Wireguard VPN and also monitor connections.
There are various apps that either connect directly to an IP address or do DNS resolution themselves to sidestep this kind of blocking. Rethink lets you stop apps making these kind of connections bypassing DNS and whatever DNS filtering you have set up to control their connections
Apps mainly avoid it because their most privacy invasive features are tied to their functionality and their own servers. They can share with third party server side and mainly do that. Client side stuff is mainly far less important analytics, telemetry, crash reporting, etc. If the app or SDK wants to evade filtering client side, they just need to do their own DNS resolution via DoH using a hard-wired IP whether it's 1.1.1.1 or their own server. Facebook has IP fallbacks in several of their apps.
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.
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.
/e/OS has native support for feeding fake data to apps, too: https://doc.e.foundation/support-topics/advanced_privacy#fak...
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.