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