Consider this (by Graphene OS): https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
/e/OS community talking about it: https://community.e.foundation/t/article-from-grapheneos-abo...
And then maybe this: https://eylenburg.github.io/android_comparison.htm
Hope that helps.
I like GrapheneOS but they fail to understand in this post that the #1 security concern an android user face is the lack of privacy.
Sure they have hardened everything but realistically, that's not the main threat for your average user.
Their top contribution to android is the sandboxed Google Play, by far.
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.
I think it's more of a marketing claim from less secure systems that "privacy is not security, and GrapheneOS focuses on security while we focus on privacy".
GrapheneOS does care about both, quite obviously. And GrapheneOS tends to say that if your security is bad, then it is affecting your privacy too. Whereas others say "sure, we break the Android security model by unlocking the bootloader and signing our system with the Google test keys, but your apps will contact Google through microG instead of the Play Services, so it's more private". Which is worth what it is worth...
> I think it's more of a marketing claim from less secure systems that "privacy is not security
I'm not sure Cyanogenmod had a marketing team that convinced me of anything when I first installed their rom in 2013 and explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS, you can only use the Android APIs, same as on stock
Am I brainwashed by marketing?!
I am not sure what you are trying to say.
My point is that
1. If you care about privacy, you should care about security. If your email server is compromised and your emails leak in the public internet, then they are not private anymore.
2. GrapheneOS does care about both security and privacy.
> explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS
I think you're talking about something like "freedom", here. GrapheneOS doesn't claim to give you the freedom to do whatever you want. In fact, part of the Android security model is to limit your freedom.
Which is not to say that you should not want the freedom to have root access on your phone. But if that's what you want, GrapheneOS is probably not it.
This is only my opinion, but GrapheneOS's approach to privacy seems obtuse to me. They will claim that an unlocked bootloader is a risk, but then turn around and recommend you install proprietary apps GApps in their sandbox. The sandbox doesn't matter if all the private data is in the same sandbox!
Reminds me of https://xkcd.com/1200/
Feels like you don't know what "the sandbox" is. It's not "their" sandbox, it's from AOSP.
When you run an app on Android, it runs in a sandbox. Meaning that your social media app cannot access the files of your banking app by default. They are "sandboxed".
On a normal Android, the Play Services are installed as a system app. It is privileged app that has "system" access. A system app is not sandboxed.
GrapheneOS allows you to install the Play Services and the Play Store as "sandboxed" apps in that they run unprivileged, just like WhatsApp or TikTok or your banking app.
So running the proprietary Google apps in the sandbox is obviously more private than running them as system apps, wouldn't you say?
If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
I agree there's some marginal benefit that sandboxed GApps need to prompt the user for permissions (rather than having privileged system level access) but at the end of the day, Google Maps will get GPS perms and Google will know everywhere your phone goes.
> If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
Sure, but that's the same if you run TikTok with microG (which will relay your data to the Google servers just like the Play Services) or in waydroid on a Mobile Linux. But you can't blame the system for what the apps are allowed to do by the user.
Take your Google Maps example: if the user wants to run Google Maps, obviously they will be sharing data with Google. It's very weird to blame the system for that.
What the sandbox brings is that for users who want to run the Play Services (because they want to run TikTok, knowing that it will share data with some servers, including but not limited to the Google servers through the Play Services), then at least the Play Services are not root on their OS. So then instead of running microG, you can run the Play Services and have the same kind of benefits.
Now if you don't want your apps to contact Google, then by all means, don't install the Play Services! But don't install microG either! And don't install Google Maps!
It's all about trade-offs, it's not an all or nothing situation. Sandboxed Play Services is better than privileged Play Services.
I agree it's about trade-offs. I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
You're of course correct that we can't blame the system for choices made by users, but I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play
>GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play
Sandboxed-Google-Play is not encouraged or promoted. It is suggested if you need apps only accessible via Google Play or needing Google services purely because it provides the maximum compatibility. GrapheneOS have always said that Android's strnegth is a large wealth of open source apps (many of which do not need Google). If more everyday apps (media streaming, taxi, food delivery & rewards, banking, government, social media) did not depend on Google, GrapheneOS would not spend the time, resources and effort that they have on sandboxed-google-play.
> I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
microG still forwards the requests to the Google servers. Not sure what you mean by "tracking APIs"? microG is a reverse-engineered, open source implementation of a subset of Play Services, right? It's not obviously a better option: for instance, some things that are supported in Play Services are not supported in microG, and microG sometimes breaks (because of changes in the API).
> allows you to select alternative Location Providers
GOS does that, too.
> I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps
I don't get that. It does not encourage them to install Play Services, it makes it available. Because for many (most?) users, it is important to have it.
I am not sure what you are trying to say: is your opinion that there is no point in using an alternative OS (like GOS, /e/OS, LineageOS, IodeOS, ...) or are you trying to say that GOS is not the most secure/private alternative OS?
I'm trying to say the same thing I said up at the top: GOS's approach to privacy is obtuse. They deliberately conflate security with privacy (you even write "secure/private" as though they're the same thing) in a way that does a disservice to users.
My opinion is that GOS is very successful at its own stated goal of having an extremely secure mobile OS that rolls out patch updates quickly. I think it's far less successful at protecting user privacy because — as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play and help them securely upload their personal data to the world's biggest adtech firm.
I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
> as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play
I installed the Play Services right away, just like I installed microG right away on a LineageOS system (I don't know about iodeOS, but /e/OS comes with microG by default). In terms of privacy, I don't think it is very different: microG is an open source implementation of the Play Services, that also contacts the Google servers. Many will use something like the Aurora store, which is a client for the Play Store. Etc.
GrapheneOS has proxies, e.g. for the location service. They are doing a lot for privacy, that's very clear.
> I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
And that's your right. I think that GrapheneOS is more secure, and not less private than those. Actually in my experience with /e/OS, it was less secure than Stock Android (though more private, admittedly).
They recommend you install google play services if you need it. Privacy is in no small part a user-decision - no matter how secure your device is if you just scroll Facebook all day.
privacy != security.
And sandboxed Google Play services serve both goals -- it runs the service as a regular android service, not an exceptional one that has a bunch of extra permissions. So you can allow/restrict it as you seem fit, while not "getting behind" on features/apps that mandate it.
GrapheneOS provides major privacy enhancements including Contact Scopes, Storage Scopes, Sensors toggle, per-connection Wi-Fi privacy via per-connection DHCP state + MAC randomization and far more. It's a privacy project and privacy depends on security so it heavily focuses on protecting against exploitation of privacy and security vulnerabilities too. Privacy and security are not separate things from each other but rather closely tied together and our work is on both for the sake of improving privacy. Our only reason to work on security features is protecting privacy.
I disagree, privacy is an essential part of security, if there's no privacy, then there's no security.
That's also why I don't keep anything important on my phone as I don't trust what's going on there despite having all the secure features that you would want.
Other way around, actually. It's possible to make concessions to privacy, like providing crash reports, or running applications in sandboxes which limits what they can harvest, while keeping the platform secure.
Any privacy you have on a system is reliant on no one tampering with that system and on software behaving itself. Without security, you can't trust the system to implement any privacy.
I also disagree with that, I trust my Linux distribution to behave well much more than I trust any Android platform and it doesn't even have much app sandboxing at all.
You can't fix a lack of trust like you have in Android with technical solutions. The flaw in Android is fundamentally a social problem.
There's a massive open source app ecosystem for Android which is far larger than the subset available in F-Droid. Open source does not imply private or trustworthy. Completely trusting applications with access to all your data with no insight in to what they're accessing or sending to services means you wouldn't know if your privacy is being violating anyway.
The (desktop) Linux security model is different. You trust the distro maintainers in the same way you trust the GOS devs, and instead of "app sandboxing" you use user accounts, containers or VMs to protect personal information. The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.
That reads more as sports team flag wavey thoughts and feelings trust than anything actually backed by objective data.
That's the difference between trusted computing (Linux distribution) and untrusted computing (Android).
If you want something backed by objective data, my phone has an advertising ID built in the OS and my laptop doesn't. My phone had 100s of privacy scandals and my laptop doesn't have one.
I do applaud GrapheneOS don't get me wrong but I have a feeling that they are fighting a losing battle.
There's a huge open source app ecosystem available for Android. The distinction you're trying to draw is inaccurate. Open source apps also very open do privacy invasive things. On Android, people can see that many open source privacy even including Signal include dark patterns such as repeatedly asking for access to contacts when it works without it. On a desktop OS, the apps and services will simply have access to nearly everything by default so you aren't aware of it happening for the most part.
GrapheneOS provides far better privacy and security than a desktop OS. There's no such thing as an advertising ID built into GrapheneOS so it's a strange thing to bring up. There are plenty of privacy invasive things built into desktop operating systems and applications, including open source ones. They nearly entirely lack the ability to protect against apps and services being privacy invasive in the first place. They also have far weaker protection against exploitation.
What advertising ID is built into the OS?
See https://support.google.com/googleplay/android-developer/answ... for Android and https://developer.apple.com/documentation/adsupport/asidenti... for iOS
[dead]