Comment by strcat
8 days ago
GrapheneOS is primarily privacy project. It keeps up with important Android updates with major privacy enhancements and very important privacy patches. It builds crucial privacy protections such as Storage Scopes, Contact Scopes, Sensors toggle and much more into the OS. Privacy depends on security so security protections and security patches are part of providing strong privacy too.
It's a misconception that GrapheneOS is focused on security over privacy. It heavily works on privacy features and the work on security features is entirely to protect privacy. There's widespread use of commercial exploit tools and GrapheneOS is proven to provide far better real world protection against those. Most alternate operating systems reduce privacy from AOSP and massively reduce security while GrapheneOS is preserving the baseline and heavily improving both side by side.
GrapheneOS is also very focused on usability and app compatibility, making sure to preserve those with the major privacy and security enhancements.
The #1 security problem your average Android user face isn't an attack by some Israeli firm but data leaks by advertisers and unless I missed something (it's possible), GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.
Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.
I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.
>GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
Content filtering is built into the browser. GrapheneOS have always maintained that you cannot prevent an app from exfiltrating data, especially if it has internet access. Enumerating badness is an unsustainable approach they don't want to encourage. Instead they attack the heart of the issue with Storage Scopes/Contact Scopes/Network Permission/Sensors Permission etc. They allow aps to think they have full access when they do not, so you can control exactly what data they get in the first place. Maybe all of the other AOSP projects could contribute App Communication Scopes/Enhanced Clipboard Privacy and other things because this approach makes a lot of sense to me. Like preventing an illness instead of wasting energy treating symptoms.
>The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
Something similar was addressed some years ago as a feature request for GrapheneOS https://github.com/GrapheneOS/os-issue-tracker/issues/284. To summarise there was no way to do this without an unacceptable security cost to the OS, but this is sort of doable if you run your own userdebug build which you have the power to do.
> Something similar was addressed some years ago as a feature request for GrapheneOS https://github.com/GrapheneOS/os-issue-tracker/issues/284. To summarise there was no way to do this without an unacceptable security cost to the OS, but this is sort of doable if you run your own userdebug build which you have the power to do.
It's badness enumeration which is an unworkable approach to providing strong privacy. It fundamentally can't provide it, only weak case-by-case improvements which are very fragile and trivially bypassed. It can also be done by modifying APKs instead of having a hooking framework within the OS heavily compromising security. You don't need the OS providing anything to use arbitrarily modified APKs. We also don't want to give apps a legitimate reason to ban GrapheneOS as opposed to being able to convince the tiny number of apps enforcing Google certification to allow it.
2 replies →
GrapheneOS provides greatly improved privacy including through features like Contact Scopes and Storage Scopes.
> GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
Enumerating badness by trying to list domains which are solely used for advertising, telemetry, etc. doesn't address any of the main privacy invasive behavior by apps which is done through their own services and server side contact with third parties.
uBlock Origin has the same problems in the browser but the rules within a browser are a lot more flexible than the extreme limitations of domain-based blocking whether any useful purpose of the domain results in blocklists not being able to include it or apps would break. Domain-based filtering is also far less usable in practice and is typically not per-app either.
RethinkDNS on GrapheneOS works far better than the domain blocklist in /e/ but it's not a strong approach to privacy and does not address much.
Apps can easily work around it and prevent the filtering, as can the SDKs. One way is doing server-side connections and another is using DNS-over-HTTPS for DNS resolution. Facebook has fallback IPs and DNS resolution in a growing number of their apps and can do it in their SDKs too.
Using a fundamentally unworkable approach that's increasingly becoming less useful is not how GrapheneOS approaches privacy.
> The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
This is another fundamentally unworkable enumerating badness approach which is not how GrapheneOS approaches privacy. GrapheneOS avoids apps getting access to sensitive data rather than trying to stop them sending it to specific places.
> I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.
GrapheneOS is a Linux distribution. Desktop Linux distributions have far worse privacy and security than GrapheneOS. The ports of desktop Linux distributions to mobile are largely losing even more security. That's a huge setback for privacy and security, not progress. They don't have similar privacy protections, don't have a similarly strict approach to privacy for default services and lack security to keep privacy intact. Using mostly or only open source software doesn't mean you don't need privacy and security protections. Aside from that, the open source mobile app ecosystem for Android and GrapheneOS is far better than it is for those operating systems.
> Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.
GrapheneOS provides drastically better privacy and security than the desktop operating you think are better. It has a great open source app ecosystem available with lots of high quality apps. You're portraying it as if people must use privacy invasive apps but that's not at all the case. Plenty of desktop users are using apps like Discord where they can access the entirety of their data as opposed to GrapheneOS where it's a heavily sandboxed app with lots of user control along with prevention of coercion to get access via the scopes features we add for pretending to grant permissions while actually granting access to no files/media/contacts by default where it simply appears there are none until users explicitly opt-in to adding them.
> I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.
Waydroid has far worse privacy and security from Android apps than running them on AOSP or especially GrapheneOS. It loses the Android app sandbox and permission model. It uses a very outdated fork of AOSP and breaks the privacy/security model through how it's implemented. It runs on top of a far less secure host OS with worse isolation for the apps inside it from the rest of the OS than exists on Android itself. Moving to a drastically less private/secure host OS while running Android apps in a much less private/secure way is hardly progress.
> Using a fundamentally unworkable approach that's increasingly becoming less useful is not how GrapheneOS approaches privacy.
I feel like we agree on the premises but not the conclusion then.
If there's no way to make a Revanced on steroids system work on Android, it means that Android's security model is fundamentally broken for me and beyond repair.
Fundamentally, Android is built with untrusted as its core value. Google doesn't trust Qualcomm, which doesn't trust the manufacturer, which doesn't trust app makers, which doesn't trust the user. It's a chain of untrusted parties all the way to the user. With one single exception, in your average phone, the user has to trust all the the above. So the user is the one trusting everybody blindly and nobody else has to do it.
The only way to make this untrusted chain model work is to go one step further, make the user not trust all of the above with a heavily modified system, including dynamic patching and that's almost impossible.
The reason why it works differently on a Linux distribution is it's built on the opposite values. The maintainers trust contributors which trust app makers ... all the way to the user. If one of them breaks that trust, they are out for good, they know they have one chance and this makes the stack fundamentally less hostile.
You can't easily fix a broken social contract like in Android with just tech.
Since you seem to be one of the developers, one thing that I wish Graphene focused on more is browser fingerprinting. This is is probably the number one threat against privacy nowadays. Vanadium is very usable, but it seems to be quite easily fingerprintable.
GrapheneOS does focus on browser fingerprinting with a long term approach that's being implemented. That's why adblocking is implemented the way that it is with a specific list of filters and then regional/language filters activated based on which languages are enabled. Vanadium does provide good protection against instances of Vanadium being distinguished from each other in ways other than the IP addresses, language, time zone, etc. Adding support for using a universal UTC time zone in Vanadium is one of many planned features for countering fingerprinting. Expanding the Vanadium userbase beyond GrapheneOS would be the main way to reduce fingerprinting since it heavily depends on the number of people using the browser so we eventually plan to launch it for use outside of GrapheneOS once it has more features.
Brave has the best anti-fingerprinting on Android right now but it's not all implemented in a good way and they have a lot of features with privacy and security downsides too. Vanadium is gradually working towards having stronger anti-fingerprinting than it. It will take time. In general, our approach is focusing on doing things properly with the long term in mind. It takes longer but the end results will be better as can be seen for what we ship in many areas. Our network-based location implementation is a nice example among many others.
The founder, afaik, not just a developer.
Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans.
Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a little frustrating that they couldn't collaborate some base like this to the open source community.
> Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans.
We're in the process of hiring a bunch of full time developers and will have more people working on Vanadium soon. The bottleneck isn't money but rather building out the organization and hiring people. We get a lot of donations and are going to be greatly expanding the project, particularly with the funding being offered by Vitalik Buterin for hiring 5 more full time developers.
> Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a little frustrating that they couldn't collaborate some base like this to the open source community.
Many aren't using permissive licensing and a lot of it is a mess that's not possible to include in Vanadium rather than making our own implementation that's more focused on correctness and maintainability. GrapheneOS is going to have an increasingly large amount of resources so we wouldn't get much from working with tiny projects. We could hire people to work on Vanadium instead. Working with Brave would be compelling but not much else. Brave has a lot of stuff we want but usually it's quite messy and complex compared to what we want to have. We're using work from Microsoft on Chromium hardening that's not used in Chrome / Chromium such as the WebAssembly interpreter.
1 reply →
> 'privacy' browser projects based on Chromium for Android
As far as I know none of these projects have tackled the JS fingerprinting problem. The most earnest attempts seem to be Brave and Firefox with the Arkenfox user.js, but they have their own problems. The basic issue is that JS gives websites far too much control over the user's device. The JS spec should have never allowed websites control over the clipboard (e.g. to disable paste), to know if the user is active, when the mouse is being moved, etc. Since it is too late now, short of disabling JS entirely, there will be usability tradeoffs, but I think these are necessary (at least optionally) in an OS like Graphene.
Unfortunately, browsers have often done too little, too late when it comes to privacy. For example, until recently, most browsers allowed third party cookies by default.
2 replies →