It's mind boggingly stupid that they lock down apps like this, when you can just open the thing in a website anyway. I can use my bank on some linux distro, crazy that they trust me since it is not Windows - the truly secure OS!
Knew about those things before I started, so all in all I'm pretty happy. I'd recommend NOT using different users for different things (I started with banking etc in one profile, that ended up being a huge PITA and according to their docs it is mostly security theater anyway). Happy tinkering!
I don't get it. If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?
I'm guessing it's because there are a lot of phones floating around that aren't updated (probably far more than are rooted), and they're willing to pretend to be secure when it impacts a small number of users but not willing to pretend to be secure when it impacts many users.
Google doesn't provide an API or data set to figure out what the current security patch level is for any particular device. Officially, OEMs can now be 4 months out-of-date, and user updates lag behind that.
Your guess is good, but misses the point. Banks are worried about a couple things with mobile clients: credential stealing and application spoofing. As a consequence, the banks want to ensure that the thing connecting to their client API is an unmodified first-party application. The only way to accomplish this with any sort of confidence is to use hardware attestation, which requires a secure chain-of-trust from the hardware TEE/TPM, to the bootloader, to the system OS, and finally to your application.
So you need a way for security people working for banks to feel confident that it's the bank's code which is operating on the user's behalf to do things like transfer money. They care less about exploits for unsupported devices, and it's inconvenient to users if they can't make payments from their five-year-old device.
And this is why Web Environment Integrity and friends should never be allowed to exist, because Android is the perfect cautionary tale of what banks will do with trusted-computing features: which is, the laziest possible thing that technically works, and keeps their support phone lines open.
I'm not an Android developer, but I was thinking they could use something like the android.os.Build.VERSION.SECURITY_PATCH call to get the security patch level. Maybe that's not sufficient for that purpose, though.
Even then, two things turn out to be true:
- Banks don't actually want to put in the effort and deal with angry customers with slightly-out-of-date devices.
- All the credential-stealing malware on Android works perfectly fine on stock, unmodified, non-rooted OS images anyway. They just need to socially-engineer the user to grant accessibility permissions to the malicious app.
My guess: They're afraid that the scammers are going to mirror the screen and remote control access to the app. (More orgs are moving to app/phone based assumptions because it saves the org money and pushes cost on the consumer) Instead of providing protections from account take over.. we're going to get devices we don't own and we have to to pay for, maintain and pay for services to get a terminal to your own bank account. Additionally, there are many dictatorships, like the UK, North Korea, etc, that are very adimate that you don't look at things without their permission. So they're trying to close the gap of avoiding age verification bypasses with VPNs.
auditors are clueless parasites as far as im concerned. the whole thing is always a charade where the compliance team, who barely knows any better tries to lie to yhe auditor, and the auditor pick random items they dont understand anyway. waste of time, money and humans.
Agreed on everything you said. Just wish there was a more efficient way to do things :/
Unfortunately, some banks do, for various functionality; there are many things you can do via bank apps and not typically via their website.
This is 1000x more useful than online petitions or other passive stuff. Politicians know that one person to have taken the effort to do this, means 1000 others are feeling the same thing but are quiet.
Unfortunately, the rot runs too deep.
Pick up the can!
They would not believe I was creating an account and using the device, because their own logging was so terrible.
I had to send them a screen recording from me using this abomination, and only then was I told "you're using the wrong special characters". They helpfully gave me some examples of allowed special characters, which then would pass the server validation.
I wish they would have gotten rid of the account requirement, as the device and client software seemed to work fine without them.
A properly-coded system wouldn't care, but the people who write the rules have read old OWASP documents and in there they saw these symbols were somehow involved in big scary hacks that they didn't understand. So it's easier to ban them.
With rainbow tables, even 11-character simple passwords like 'password123' can be trivially cracked, and as the number of password leaks show, not everyone is great at managing secrets and credentials.
I started using passphrases after I saw this xkcd https://xkcd.com/936/
When I'm trying to log into something on a device that has a terrible keyboard, like a TV or giant touchscreen, it's a lot easier to type words I know than gibberish.
The amount of times people have complained to me that this doesn't work because of low max-chars on passwords is insane.
Uh4zB4DP55WD!
Apparently I was a bit salty with the system when I set it.
The fact that she shouldn't have even been able to look up the password in the first place due to hashing was lost on her.
On password length, I once had an account on Aetna that let me put whatever I want for my password, so I used a three-word passphrase that bitwarden generated for me. It ended up being like 20 chars.
Then I tried to log in with that password. Whooosies, the password input only allowed max 16 chars!
Ended up using a much less secure password because of this.
"Hey idiot, I'm storing your password in plaintext, don't know anything about password security, and I'm also going to make you pick something you can't remember for 'security'."
Gotta admit, this triggered me. I don’t think those are the same thing. If no one had a good password we wouldn’t affect each other negatively. If no one picked up trash, we would.
Edit: Sorry folks, didn’t get the reference.
The GP is equating policies for strong passwords that aren't trivially cracked with authoritarianism.
If no one had a good password, we actually would affect each other negatively. If your personal banker can be easily compromised, that means that you could be easily parted with your money.
I do agree that they are not the same thing.
Incorrect - the requirements I mentioned make passwords less memorable and less secure (maximum length 12???). Obviously that's not as bad as authoritarianism, but I was trying to capture the arbitrary act being forced on us for no real justifiable reason.
GrapheneOS is not rooted, or is not required to be.
Not in Spain. I can access my bank's website but I can't do anything without their bank app. Even sometimes they require to confirm my identity using their app in order to access their website.
I have several linux phones but I can only do banking with their app downloaded from Aurora Store in my Vollaphone.
Here in central Europe I can still access the bank website fine without smartphone. I need a physical device to yield a TAN though, but I can access and do online transactions fine. So I think something is wrong with the spanish government. People need to protest.
> This should be illegal that the government forces people into apps controlled by private, commercial entities. I call such a government corrupt.
I’ve always believed governments and companies should be regarded with fairly low trust, and the behavior of big tech companies and some recent government actions are great examples why.
But what disappoints me a bit about this moment is (the perhaps inevitable?) response to nationalism with more nationalism.
Just as I didn’t seek to punish the EU over authoritarianism in Hungary and Poland, I feel the current moment has many responding to the symptoms instead of the sources of the problems. This is not a defense of policies I believe concern you, it’s a question of priorities.
I think the author of the article got it right. Because in addition to privacy, I believe one should be able to navigate the internet freely without a mandate to do business with monopolistic dominant companies, which includes rights like ownership of your data.
Big US tech companies are infamous for not following the EU's data protection rules, and they wouldn't even able to, because some US regulations (I think PRISM, FISA and others) are incompatible with the requirements of EU GDPR. This dates back at lest to Snowden leaks and the invalidation of EU-US data protection agreements by Schrems judgments.
https://en.wikipedia.org/wiki/Max_Schrems#Complaints_with_th...
Unfortunately it is now a question of sovereignty and basic risk management, not nationalism ([0] and multiple other sources).
[0]: https://mspoweruser.com/europe-calls-out-us-tech-after-micro...
And that is mandated by the EU.
I don't know about Spain specifically, but as far as I understand it no bank in the European Economic Area + UK should allow banking via just the website alone anymore, because of the "Revised Payment Services Directive" (PSD2) regulation.
Essentially, banks are required to implement "strong customer authentication", which in essence is just multi-factor authentication with a password + either biometrics or a security device of some sort.
And in practise that means a banking app, because most people do not want a separate token they have to buy and can lose. Though a lot of banks do offer those as well.
Phones and sim cards a lot more temporary than ID cards. I don't know of a lot of theves that target ID cards for their authorization uses. Phones... people will steal those.
You can change it in the app, yes.
> How to issue new key if needed?
I think you’ll have to reissue your ID.
There’s also digi-ID (similar e-signature certificate on a card, but without any ID features), Mobiil-ID (e-signature on a SIM-card, no idea how it works), Smart-ID (in app, tied to secure storage in Android/iOS, cross-signed by the server which is supposed to check the device somehow) and probably something else I don’t remember. All of these are independent options, so you can, for example, revoke your Mobiil-ID if you lose your phone, and still use the your main ID card to sign things.
Is the app tied to Google or Apple?
(Though Smart-ID is its own thing and is a fair bit more locked down, but I’ve managed to get it running on a phone without Google services IIRC.)
But, like the parent said, you have many other options other than the physical ID-card as well. Most people these days use Mobiil-ID or SmartID, which works on your phone and even smart watch. SmartID is completely free and Mobiil-ID is tied to your phones carrier, so the cost varies, but it's a one-time set-up fee of around 5€. Mobiil-ID certificate also lasts 5 years.
(When will people learn that biometrics are not another factor: they're entirely public and irrevocable. It's not just security theater, but Apple & Google know that this forces you into their ecosystem, which should be illegal. Of course, Brussels is full of rubes anyway.)
"a device could be used as evidence of possession, provided that there is a ‘reliable means to confirm possession through the generation or receipt of a dynamic validation element on the device’"
So in essence the TOTP has to be bound to the device in a way that prevents users from just extracting the secret and putting in in their password manager. Hypothetically that would still allow Yubikeys and other security keys that provide attestation from the factory, but in practise banks probably don't want to deal with the support headache and just provide their own, like the TAN generator mentioned by other commentors.
Two other highlights from the interpretation of the EBA:
"App installed on the device" -> not sufficient/compliant
"In the case of an SMS, and as highlighted in Q&A 4039, the possession element ‘would not be the SMS itself, but rather, typically, the SIM-card associated with the respective mobile number’."
"SIM-card associated with the mobile number" - is that even technically possible? Do mobile carriers provide a API for banks to verify that a number still corresponds to the same SIM card? If so I've never heard of it.
[0] https://web.archive.org/web/20191207213213/https://eba.europ...
When confirming a large transfer, you also need to enter the payment amount in the device, and I assume this gets hashed into the number as well.
More recently (last 3/4 years), you can also use their mobile app to do this instead / as well as.
It can be SMS. As said in another comment, the main banks in Spain offer this authentication method while being PSD2 compliant. Some also offer a card with coordinates. So it's not mandatory in any way to use a banking app.
But yes banking apps are not mandatory, and likely won't be in the near future either, though the alternatives are treated a bit like second class citizens.
Edit to add this anecdote. My bank told me I need to use their app because SMS is not secure, but you need to activate their app using an SMS code!
My bank used to have other options but it has made mandatory the use of their app.
Yes, none of them required me to use the app a single time. In fact, for all the banks I work with, I always identified myself at a local office when opening the account for the first time, the last one less than a year ago. And all of them allow me to operate in the website without the need of an app (actually I could never use any banking app as my telephone lacks Google Play).
https://triodos.es has 2FA via SMS, for what is worth.
If someone wants to try Graphene os maybe that option will work on their banks too.
I've seen this elsewhere, and it's absolutely ridiculous.
Why?
Because in almost all cases, the apps may only be installed with Google Play, and require the framework to work correctly. And that means?
If you are not in good standing with Google, you cannot bank!!
I cannot stress how inane it is, to have Google or Apple as the gatekeeping to identify verification. How not having an active, in good standing account with one of these two, means you cannot bank.
And it's happening more and more.
Meanwhile, banks -- which tend to make billions in profits quarterly, do this to save on infrastructure costs. They do it so they don't have to stand up their own push servers, or have an app which doesn't require firebase.
Well cry me a river, boo-hoo Mr Banker, I'm not even remotely interested in you saving on infra-structure costs at the loss of autonomy. And on top of this, many banks are reducing hours, closing branches, claiming that they don't need them.
Leaving absolutely no other choice.
This sort of thing should be illegal. Being in Spain, but requiring a US megacorp to tell your own bank, that you're you.
I don't agree with this dependency on being in good standing with Google either.
But there is a technical reason that isn't wanting to avoid using their push servers. It is about battery usage and radio bandwidth.
Keeping open an idle connection over WebSocket, long-poll HTTP or TCP/IP needs regular pings (typically 30 seconds are used), one ping per connection. Otherwise your app can't be sure to receive messages from the server in real time, as the connection can disappear into CGNAT or similar hole where it doesn't receive messages sent by the server. To an app not using pings to check, such a blackholed connection is indisinguishable from an idle connection with no pending messages.
Waking the radio every 30 seconds, times 2 (back and forth), times the number of registered applications, would be quite battery draining. It drains battery both for background CPU usage and radio processing. Those pings in aggregate can even amount to a significant amount of data usage for users on smaller plans.
So there is a battery and radio advantage in using a shared push service, which only need a single idle connection to be kept live with 30 second pings.
There's another level to this, not available to regular developers using TCP/IP, HTTP or WebSockets.
The mobile network itself has to maintain handset connection liveness to the nearest tower, at a lower level than IP pings, and this is obviously optimised for battery and radio performance, and always running.
With arrangements in place with the mobile networks (which Google and Apple have), the mobile OS can leverage that for more reliable, lower power push notifications, by either guaranteeing the network will send something technically similar to a low-level SMS when there's an outstanding message, or by guaranteeing their special push IP connection will stay live by itself (no CGNAT blackhole) or be notified if something happens to it.
This allows the mobile OS to offer a shared push service that's fairly reliable at real-time notifications, with zero continuous CPU and radio power overhead for the idle connection.
When I want to do banking I'll open the app, do my business, then close the app. A banking application does not need push notifications.
Clearly, real-time notifications are useful with many apps, notably real-time messaging, even if you don't think they have a place with bank apps.
For bank and credit card apps, I find their push notifications to be very useful. They are among the most useful notifications I get, because they tell me about things I find important, which I wouldn't notice otherwise.
They tell me things about transactions that have gone through, sometimes after a long delay, transactions that need confirmation right now or they will be blocked, balance being too low, or too high (credit cards), payments that are required today, refunds that came through after a product was returned, transfers that completed on the receiving said, payment received from a client, direct debits that are going out tomorrow so I will need to make sure there's enough in the account, customer service messages that require a response from me or they will eventually close the account, and so forth.
"Just open the app" doesn't work: All of those, except transaction confirmations, are things where I wouldn't know to open the app if I didn't get a message of some kind to tell me.
These days, in some juristictions it's also required to send real-time notification to confirm some purchases, because the phone's security is considered better than card details alone. Depending on how the purchase is made (e.g. in-person vs online, different payment terminals), you might not know the reason a transaction is blocked or held is because it's waiting for you to confirm in the app, so the notification is useful for this.
All these used to be done by SMS, and that was useful too. But SMSs are just push notificatons with a worse UI and worse visual cues.
> But SMSs are just push notificatons with a worse UI and worse visual cues.
I am too lazy to test, but did this change? Can't you just make a "fake" account and continue with your life? The phone company knows where you are, the bank knows what you purchase. Compared to that Google will know far less (ofc, if you don't activate everything)
I find it much more insane that it was possible for so long to do banking WITHOUT strong authentication (however implemented) by just providing those 3 numbers on the back of the card (strong security!)
> If you are not in good standing with Google, you cannot bank!!
> I cannot stress how inane it is, to have Google or Apple as the gatekeeping to identify verification. How not having an active, in good standing account with one of these two, means you cannot bank.
Having to register some phone number (does not need to be your main number, a sim card is quite cheap) to a "fake/unused" email address (even if as you say you are required yo) does not require you to "be in good standing with Google" and they are not gatekeepers of identity.
At this point in time I feel the banks and the mobile phone operators are much worse managers of identity, because, for example they even accept stolen identifiers to make an account in "your name" - for me that's more ridiculous, not that they require some multiple factor of authentication.
Absolute madness.
1. Revolut app stopped working so I emptied my account and opened a Wise account which is fully administer-able from their website. Revolut has subsequently started working again after a couple of app/OS updates.
Same, though I’ve never returned to Revolut.
Wise does have some quirks (e.g. they’ve blocked me from unfreezing or reissuing my cards recently for no apparent reason), but still they’re way way closer to zero-bullshit than any other neobanks I’ve tried.
- RBC 2FA is that if I try to login through my browser, the phone app will ask if I authorize the login. I think I can disable this and use sms/call, but that's even more insecure, so I don't.
- TD lets me login fine and do everything in the browser. But any online transaction that is moderately large or presumably fishy, will force me to authorize the transaction via the app.
These are among the largest banks in Canada.
But, yes, you can't tap to pay and it's unlikely you ever will. Banking apps will be hit and miss depending on their (generally hypocritical) paranoia levels.
I pay with a tap-to-pay card, and I have never needed to do banking related things immediately, I've always done it via the bank's website.
I also still have a not-very-old 'normal' android phone for some edge cases - which are few and far between (actually, I think it's usually to cast youtube to the TV since I only have the revanced youtube app on the GrapheneOS device).
P.S. On the use of profiles, I use them to separate work apps and notifications from personal, from sporting club, from X, Y, and Z. Yes, they're a pain in the arse to switch between, but I'd argue it's more of a pain in the arse to have them all jumbled together causing even more notifications, frustrations, and distractions from whatever one should actually be concentrating on in the present moment.
Biometric login was also confirmed to work around the same time. I can however confirm that it doesn't work on the latest app version. It complains that the webview isn't Google Chrome.
This is probably just an oversight. I will email them again; good chance they'll push a fix to recognise Vanadium webview.
Yes, I've been doing that since 2009 on Ubuntu and Debian but there are several caveats.
One of those banks has its own TOTP device and they won't replace it when the battery dies. It's almost 20 years old now. Then it's the fingerprint sensor on my phone.
The other banks authenticate accesses and many operations with either their app + fingerprint (all of them) or SMS (some of them). So basically I would still need a phone with a blessed OS. I could buy the cheapest one and store it in a drawer, but it's still a dependency on Google or Apple.
GrapheneOS requirement of Pixel devices is a dependency on Google too.
They are currently working with an OEM to release a non-Pixel GrapheneOS phone in the future.
In any case, replacement stylii are very cheap online. Less than a screen protector.
Unfortunately not.
I'm in the UK. Two of my personal banks, all four business banks that I need to use, and several credit cards, require authentication using their phone app to confirm login on their website.
None of those I've seen are using TOTP or SMS, for which I could use a general security service. All use their own phone or tablet app. One does something interesting where the website shows a unique QR code on each login, the phone app reads it with the phone camera, and then website login proceeds instantly without clicking anything.
Oh, and some of them also require phone app confirmation for card purchase transactions.
When my last phone's screen stopped working, I called one bank's "phone banking" line (using another phone of course) to make an urgent transaction, and they told me they can't do that, as only service they offer by phone is registering a new phone or tablet. They told me explicitly that it's not possible to login to their web-based banking service without using their app for authentication, and on a registered device.
It's the reason I have my current phone. I had to buy a cheap-ish Android in a hurry from a local shop, in order to proceed with my bank transaction.
Back to the main topic: I love the idea of a properly open source phone, I used to own not one but two Nokia N900s, and I once toyed with the idea of building my own Linux phone from scratch, big project though that is.
But the security ecosystem around logins has changed, and so have the services I depend on. These days I use many bank and other financial-service related apps, and I'm not, in practice, free to switch providers. So I couldn't use a Nokia N900 or modern equivalent any more as my only mobile device. I'd have to carry a second phone as well.
(Banking and other service authentications are also the only reason I have my current passport. I resented having to pay to renew my expired passport, given I had no plans to travel (small children) and the expired passport used to be accepted, but I found some banks, credit cards and even government services increasingly requiring to see a non-expired passport from time to time. When I asked one of them what do they do for the large number of people who don't have one, they simply told me they close those people's accounts and that's ok, they don't need to serve everyone. But that's another story.)
And banks often have their apps region locked, so if you live abroad or have accounts in more than one country, you’re fucked.
Want to use Vipps tæpp so much but I have Nordea for private and they don't allow it on their cards, for whatever godforsaken reason.
I wouldn't mind sending in a complaint to both BankID (allow biometric login) and of course DnB corpo edition.
Here is the github repo where banking app compatibilities are tracked: https://github.com/PrivSec-dev/banking-apps-compat-report
And it's rendered to a page here: https://privsec.dev/posts/android/banking-applications-compa...
Thanks anyway!
I don't know how to contact the engineering team. IIRC that is how the private app got fixed, someone got word to someone on the inside.
I agree that the locking down is truly stupid. For what it’s worth, the reasoning for locking down mobile apps is allegedly that mobile users are a less technologically competent demographic than desktop users. I do not think so myself, given the difficulty in trying Graphene vs. Desktop Linux.
I don't agree that it is stupid. Both banking on a Windows PC or on an unlocked + rooted phone is potentially catastrophic. Windows because of the prevalence of malware, unlocked phones with custom AOSP forks because people download 'ROMs' (as they call them) from the most shady sites.
Once 10,000s of Euros are siphoned from a bank account, it's usually the bank that has to deal with the mess. Especially if they cannot prove the transactions were done in on an insecure platform.
Phones are generally safer (though there is a huge variance between the safety of different Android phones) because they use verified boot and strong application sandboxing.
I think it is possible to believe the following two things a the same time:
- Banking apps should only run on locked phones with secure boot.
- Banking apps should not be limited to the Apple/Google duopoly.
The solution is that there is some validation of alternative OS vendors, e.g. in the form of an audit, and that banks are required to approve apps on their platforms after the audit. This would be fairly straightforward tech-wise, because e.g. GrapheneOS supports remote attestation, but banking apps need to add/allow the hashes of the official boot keys: https://grapheneos.org/articles/attestation-compatibility-gu...
We have secure hardware already, it's called a smartcard and is what you find in all bank cards, SIM cards, authenticator devices... my phone is my phone, not a second factor, or at least I (as a hacker/tinkerer) don't want it to be that way, just like with my desktop which is also not the bank's to mandate whatever from
Somehow they got the memo for devices where it is normal to have admin permissions, but for mobile devices the two big tech companies successfully scaremongered non-techies
It's not, because even though the authenticator is secure, you are entering the auth codes in a browser in general purpose desktop OS with (if you use Windows or desktop Linux) little to no sandboxing outside the browser. You are one malware app (or NodeJS package for tech users who claim they'll never download malware) for your session getting hijacked.
The sad reality is that phones (and some tablets) are the only relatively secure computing environments that we have. Thanks to Windows with it decades of piled up legacy and Linux with large sandbox and secure boot-hating parts of its community, we cannot have nice things.
(The part about the Linux community, which I'm also part of is a generalization, but the hostility against Flatpak, secure boot, etc. is pretty big.)
It doesn't matter what device relays the code I typed over or otherwise transmits the approval through untrusted networks to the server
> The sad reality is that phones (and some tablets) are the only relatively secure computing environments that we have
My bank('s authenticator hardware) begs to differ
That's not what I am saying. The authenticator is irrelavant to this attack. If your machine is compromised by malware, the malware could take over the browser session, regardless of how you log in.
Phones are better protected against persistent malware because every application is sandboxed (harder to escalate) and much more of the boot chain/OS is validated (harder to persist).
enjoy it while it lasts. hardware attestation requirement for (at least) banking apps is a question of 'when', not 'if'.
Wait till you find out that your prefered Linux bank won't have the same mortgage terms as you'd like and you'll be running to buy a Google/Apple phone to get those % down.
I have no problem with a device that they trust being used for transaction approval, but that device shouldn't also be the device I use for my daily life and do all sorts of private things on. We should want to be able to inspect that one
Still, I'm plenty okay with my phone as a second factor for my laptop and vice versa for nearly all services. The rest is about tying things to a government identity (bank cares only if it's me who's authorising the transaction; government cares only if it's me who's requesting a student loan) and can be done with the chip that's already in my identity document and a single 20€ nfc chip reader or by using a phone as nfc reader
I'm worried the day will come when some sites will require, even on a computer, a full-chain verification from the bootloader to the OS, all the way down to the browser. By requiring that each of these elements be digitally signed so that if you're not on a "secure" platform, from the bootloader to the browser, sites such as home banking could restrict access. Imagine not being able to login to your home banking because your linux box is rooted.
Btw, the good old days of modding are gone...
Some other apps are often willing to accept my current setup (Lineage for microG [0], plus Magisk, if you don’t need root – Magisk Hide does some magic I don’t really understand, but even without Play Integrity passing, apps just start working).
With more tweaks, you might be able to get Play Integrity to work to some extent, but it’s hit or miss. I’ve just stopped using apps that demand it.
Even un-modified you'll then be stuck with an old version of Android that doesn't support the latest versions of apps and the old versions of apps won't work properly.
It's really a shame because a lot of old phones work perfectly fine otherwise.
Can you record phone calls? Do third party voice recorders continue recording even when the screen is locked? Thank you!
Do you use any authenticator apps such as Okta? My org requires biometrics when using Okta on my phone.
The BankID thing is a SW quirk on their end, but generic fingerprint seems works great across the ecosystem.
This is inconvenient in some ways, but at least it is sort of privacy as good as it gets while still being able to run official apps when I need them at home.
To de-google the phone, I use F-Droid as primary App store, Aurora as fallback for non-f-droid Apps and as a last resort Obtainium to install Apps that are not in these stores.
The only google App I really "need" (kind of) is the Camera App, which is sandboxed via GrapheneOS Storage Spaces and without Network permission (why would a camera need internet?).
To backup my phone, I use the integrated GrapheneOS Solution (seedvault!?) for storage and apps, immich for Photos and MyPhoneExplorer for Contacts.
Sometimes it is a bit hard to find good apps for specific purposes, so for everyone interested, here is a list of Apps that I personally use or have used.
Newpipe - Youtube Client
Audiobookshelf - Audiobooks
Voice (PaulWoitaschek) - Local Audiobook Player
Substreamer - Music
DSub - Music (alternative)
VLC - Video-Player
Organic Maps - Google Maps alternative (not as good)
PDF Doc Scanner - Open Source Document Scanner
Wireguard - VPN
Immich - Photo Backup / Viewer
LocalSend - File Transfer
K9 Mail / FairMail - Email Client
KOReader - Ebooks
Binary Eye - QRCodes and Barcodes
Pure Todo - Self hosted PWA PHP Todo List
Signal - Messenger
Open Camera - Open Source Camera AppAegis - 2FA (https://github.com/beemdevelopment/Aegis)
Breezy Weather - A very good looking weather app (https://github.com/breezy-weather/breezy-weather)
OnlyOffice Documents - MS Office suite replacement (https://github.com/ONLYOFFICE/documents-app-android)
Fossify Calendar (https://github.com/FossifyOrg/Calendar)
Fossify Messages (https://github.com/FossifyOrg/Messages)
Aves - Local gallery with great organization (https://github.com/deckerst/aves)
Termux - Terminal emulator (https://github.com/termux/termux-app/)
Unexpected Keyboard - A unique keyboard that pairs nicely with Termux (https://github.com/Julow/Unexpected-Keyboard)
WG Tunnel - WireGuard client (https://github.com/wgtunnel/wgtunnel)
These are all easily installed through Obtainium: https://obtainium.imranr.dev/
* NextCloud -- client for personal NextCloud server; this app is used primarily for file sync, with other features accessed with other apps. (https://nextcloud.com/features/?filter=Clients#android-clien...)
* KeePassDX -- password manager, shares DB with KeePassXC on desktop, which is synced via NextCloud. Also functions as a TOTP authenticator. (https://www.keepassdx.com/)
* DAVx5 -- CalDAV and CardDAV client; keeps mobile calendar and contact list synced with private NextCloud server. (https://www.davx5.com/)
* AntennaPod -- excellent FOSS podcatcher. (https://antennapod.org/)
* KDE Connect -- desktop sync tool; allows file/clipboard/keyboard/audio/etc. sharing between phone and a Linux desktop. (https://kdeconnect.kde.org/)
* Kore -- remote control app for a Kodi instance running on your LAN. (https://kodi.wiki/view/Kore)
And I don't see F-Droid itself mentioned -- it's the most popular repository of FOSS software for Android, with an accompanying app: https://f-droid.org.
F-Droid itself is great, but I find that the NeoStore front end to F-Droid is superior because it has multi-repository capability, offering a long list of alternative apk sources that can readily be verified for quality.
Also, the desktop client on Linux is quite useful.
Alternatives for Windows etc. are Cruiser Maps, a Java application (and also available as an Android app).
However, I listed it because it is a "usable" alternative that works offline.
Where it’s lacking is POIs – there’s way more stuff on Google Maps, and if I’m looking for some place in particular, I usually go straight to Google, then copy the location over to CoMaps.¹ I then try to add it to OSM when I have the time. Still again, there’s no reviews or photos (in the app; OSM does support photo linking).
Public transit is another problem. It’s usually okay for metro (MRT/LRT/etc), but I wouldn’t trust it with buses just yet.
¹ – yes, there’s been another fork: https://en.wikipedia.org/wiki/CoMaps#History
Although I would like speed limits shown in MPH in the UK, OrganicMaps' KMH limits were useful on the Continent.
Does anybody know of a project that offers public transport routing? Ideally with real time information, but I can live with only using schedules or even just average passage interval.
The other general sticking point for me is the reviews, but I could invite more serendipity to my restaurant search.
It's pretty excellent! The improved integration with OpenStreetMaps to provide edits/additions is great. I made my first contribution to OSM via CoMaps.
I'd love to have something like this for Linux desktops as well. Maybe a website that has app-lists, where people can then potentially add info about their use cases and reasoning for their choices. Could be a great subreddit!
I tried Omarchy specifically because installed an opionated selection of apps to covered most bases, and it got me started in Arch fairly quickly. I've now completely swapped out all the components so I no longer use Omarchy at all, but it was a great way to get back into desktop Linux after being away for 20 years.
I also made a custom fork with some quality of life improvements, like series and part visible on screen, headset remote click patterns (tap for play/pause, double-tap for next, etc.).
Currently I'm working on a totally DIY build offline audio (book) player with the footprint a bit bigger than the iPod Nano 7g that maybe never will be finished, but ATM it is fun to work on... (see https://github.com/sandreas/rust-slint-riscv64-musl-demo for the testing repo and https://github.com/nanowave-player/nanowave-ui for the latest code I'm working on)
But unironically Pixels are currently some of the best actually open phones. They do not lock down or require shady practices for unlocking the bootloader (although they do require a network check once that happens automatically, but it will permanently allow unlocking the bootloader if successful once. Pixels are very easy to restore and almost un-brickable, allow bypassing the boot screen warning by pressing the power button twice, actually allow relocking the bootloader and don't void your warranty unlocking it, don't have a shady one-time fuse like Samsung phones do with Knox, etc.
https://www.androidauthority.com/graphene-os-major-android-o...
https://www.youtube.com/watch?v=ik0AiO0WtuU
If you don't like giving money to Google, plenty of companies offer refurbished Pixel phones.
When was in college and had Sprint this was a nightmare since then I wanted root for unlimited hotspot (Sprint made it easy that way), but most refurbished Pixels were Verizon variants.
And I couldn't just use OnePlus because they were only designed GSM networks or later Verizon CDMA-less. Then, new Pixels were unaffordable for me, but parents insisted on using Sprint.
I ended up getting a Pixel 3 off Mercari (which I still own) just to keep root.
Now, I can afford a Pixel 10 Pro new (which I am right now), alongside spare Pixel 9 and OnePlus 13R units. But even then (a) my income is lower than when I worked at Microsoft and (b) The OnePlus was from a trade-in deal.
This is separate from SIM locking, which forbids use with another carrier. US carriers still do that, but are required to remove the lock after a while if the customer doesn't owe them money.
It's not clear why Verizon insists on permanently locked bootloaders or why Google agrees to it for Verizon when they don't do it on Pixels sold anywhere else.
Anyway, I now need to get the battery replaced, because apparently they are dangerous and Google pays for the replacement. Unfortunately, the replacement process requires the stock android to be installed. Meaning, I would need to backup the whole phone, reinstall stock android, then restore everything - and hope the whole ordeal works out.
I run a Thinkpad with NixOS and KDE, a Pixel 9 with GrapheneOS, and an Amazfit watch paired with GadgetBridge on my phone.
It's a testament to the hard work of the FOSS maintainers of these projects, and the spirit of open source, that everything works flawlessly together without any cloud service sucking up my data. For example, I can control youtube and music playback on my laptop with my watch because KDE Connect syncs my laptop and my phone, and gadgetbridge syncs the phone and the watch. The breezy weather app on my phone can automatically push its data to gadgetbridge which in turn pushes the data to the watch. And so on. So many little things, developed independently, working like a single well oiled machine.
So I ended installing ActivityLog2[0] to do something with the files I had to have on desktop and GadgetBridge was of little use because relying on GadgetBridge without actually syncing the files might make me forget about doing the backup to a device I control (GrapheneOS or a computer).
As soon as GadgetBridge support syncing the files from the watch to the app (or any local folder on Android), I'll install it again and stop doing the manual backups over USB. Syncthing will do it automatically.
In background I also have Withings scale sync the measurements a couple of times a day to Garmin.
Then switch back to Google/Apple after half a year when you discover that you can’t run
- your banking app - any government app - the app required to access large sports events - the pandemic tracking app without which you can’t enter an airport - various other random apps
because they ALL detect that you’re running on a phone with an unlocked bootloader and will flat out refuse to start. And for many of those, there is no legal alternative.
(The extent of this varies depending on where you live, of course.)
Also, do not leave your bootloader unlocked. That is an incomplete GOS install and you will need to lock it to secure your device. Not locking it is both insecure and will make a much higher number of apps fail.
(I don't deny that there are apps that won't work. Best to check before switching full-time.)
Not sure if airports specifically used another mechanism, but the Android contact tracing APIs were actually reimplemented in microG, allowing these apps to work even on custom roms.
Your other examples don't hold universally either (banking apps are compatible with un-rooted custom ROMs more often than not, and not sure how many sports event apps use integrity checks), but your general point stands that it may come with trade-offs.
Thats not coming from some paranoid security person, just regular (software dev) joe.
1. The Pixel camera app works, including all modes and settings. A camera that takes good photos was absolutely a requirement for me, and the FOSS camera apps are not quite as good yet.
2. I don't have Google Photos and the pixel camera app tries to launch google photos when you want to review the picture you just took. But there is a FOSS app called GPhotosShim that uses the same namespace as google photos and thus fools the camera into launching that app instead. Once launched, it just launches whatever media management app you actually have configured, so it's seamless.
3. Android Auto works!
4. Android QuickShare works!
5. NFC tags / Yubikey integration works!
6. Screencasting works!
7. Sensor access and internet access can be disabled for apps by default (and I do).
I bought a second hand Pixel 7 to test this and an exFat SanDisk Extreme Portable 2TB works with reads/writes perfectly.
Does this require installing google play and other google services to work?
Does that require being logged into a Google account? How to ensure Google knows nothing about your shares?
I have Graphene w/ Google Play Services (required for my job) and would love a easy way to share files/info with various devices (incl. iOS/macOS which I remember should work with QuickShare in the future) but will avoid a service that shares data with Google.
Pixel are supposed to be very good in photography, part hardware and part software, and my concern would be degradation of that software part. With small kids, there is nothing more important on phone for me than photos/video quality these days (apart from never going into apple ecosystem, I am just incompatible with that company' philosophy).
Or its just about slapping some commercial photo app (like I heard from other photographers is often done on apple to get most out of it, but forgot the name of the app) and not caring about this?
On the other hand, if you switch to the latest Google camera app, you will not really be participating in making the open source version better.
https://play.google.com/store/apps/details?id=com.google.and...
What most people miss: the real value of GrapheneOS is not just escaping Google surveillance but the per-app network and sensor permission toggles. Being able to cut network access to apps that have no business phoning home changes how you think about every install. That alone is worth the switch.
Building fintech apps, we integrated Play Integrity as a fraud signal. Sandboxed Play Services on GrapheneOS actually passes most of these checks now, and false positive rates for legitimate users are negligible. The hardliners who refuse sandboxed Play can still use most banking apps that fall back to basic root detection rather than hardware attestation.
The real gap is NFC payments - Google Pay needs privileged hardware access that sandboxed apps cannot get. But that is one use case, not a reason to skip GrapheneOS entirely. Curve works fine in EU.
AFAICT, Garmin Pay works like Apple Pay, meaning (unlike Google Pay) no network connection is required.
The only things I'm missing (which don't exist in other OS'es either):
- Being able to configure contact scopes in such a way that the app in question only gets access to the phone numbers of the contacts belonging to the label I specified, e.g. "WhatsApp", nothing more. Yes, one can of course add contacts' phone numbers to the contact scopes "by hand" but 1) there is a limit on the number of contacts/phone numbers configured this way, and 2) AFAIK there is no way to back up that list.
- Being able to install browser extensions in Vanadium.
- Being able to configure multiple VPNs at once, e.g. for Tailscale, ad filtering, blocking HackerNews during times when I should be doing something more productive :) etc., especially since the Vanadium browser doesn't support extensions (see above). I was hoping that the Rethink app might implement something like this (https://github.com/celzero/rethink-app/issues/1047) but it doesn't look like it's coming and it'd probably be much better to do this at the OS level.
You can use IronFox - available in Accrescent store that comes with GrapheneOS, and install firefox extensions
This doesn't answer your question, but in case it helps for others out there: it's possible to use WhatsApp with no access whatsoever to your contacts and I used it that way for years. Connecting with people is slightly jankier but it still works.
> Unfortunately, I must recommend Windows 10/11 here, because then you don’t have to mess around with any drivers; it’s the simplest option.
When I worked at Microsoft but ran FreeBSD at home, I often used my work Windows laptop to install custom ROMs. This is because FreeBSD was finicky with adb.
Now I run Fedora and the Android drivers are pre-installed. I installed GrapheneOS on both a Pixel 10 Pro (main) and Pixel 9 (spare) that way.
On Windows, I've had more trouble with Android drivers than I did on non-Windows.
I wonder how secure GrapheneOS is in that regard, and what the other contenders are?
(it's not magic. All big vendors have these details, just choose to take their sweet time to patch them. GOS has partnered with a major OEM vendor who provides them with access)
Other than the specific patches above, there's a list of generic GOS features: https://grapheneos.org/features#exploit-protection
All in all you're probably much safer.
Android's attack surface seems pretty jagged. For example there is only one webrender engine on iOS, where you can run anything you like on Android/GrapheneOS.
A short list of the hardware security measures necessary to consider it "not a toy" ;) -- https://grapheneos.org/faq#future-devices
> If the hardware is an open book then no.
So you choose security through obscurity. I have no further questions.
GrapheneOS really wants the software in the phone to not pwn the phone. This is good. Its a different, and much more difficult problem to secure the connection to the telco, and the larger internet, because the transport is attacker controlled.
Think of it this way: Say you use Qubes because security is valued very highly for you. Even if you run Qubes, if your router is controlled by your attacker, what kind of a security guarantee could you really get for yourself?
In theory Pixel phones have IOMMU and GrapheneOS is using them, so even a compromised baseband doesn't result unrestricted access to the system.
I do run Qubes, and a compromised router, e.g., will not get access to any passwords that I store in an offline VM as text, even with any previously known vulnerability since 2006.
This does make a material difference, e.g.: https://x.com/MetroplexGOS/status/1982163802188575178
That said, if a state-level actor is up against you, then it's hard to defend yourself against that.
However, there was one case that lead me to thinking about ditching grapheneos to this day. I installed Uber on my phone and I was able to successfully create an account and use it. When it came to booking a ride, the app crashed and I had to log in again. Once I did that, I was told that my account has been suspended for violating the terms of services. All I did to that point was creating an account and booking a ride. I was able to resolve the issue luckily after a few days and going back and fourth a couple of times with the Uber support, however, the risk of getting banned on any such platform is still risky, and thus I'm not sure if grapheneos is usable if you need to use such services.
I've run into my share of scammy taxi drivers.
Taxi across the town is £20, Uber usually 5-10. There are no other providers.
Taxi from my airport (some 15 miles away) is £60-80, Uber usually £30-ish. Public transportation (2 trains + 2 buses) over £50.
I wish I had an option.
Your aim is misplaced: ditch Uber, not GrapheneOS.
Every app on my phone has at least one other app, usually already installed, that can replace it. This wasn't intentional, it just happened naturally. Unless all two or three apps in a category get blocked for me at the same time, this already unlikely situation is barely an inconvenience.
If using GrapheneOS significantly increases the risk a person won't be able to use a service they rely on, that may be unacceptable.
I'm not doing this on purpose, I just now scrolled through my app list looking for one app that would actually fuck me up if I lost it in an instant. There are none. And I'm not currently even running graphene or anything else, just a stock Samsung.
The good news is that they are actively working on developing their own hardware. The bad news is that it’s been delayed. But I’m watching closely.
https://www.galaxus.at/en/page/grapheneos-postpones-pixel-al...
Google would not allow this and they're way too entangled with Samsung.
That limitation might be doing you a favor, as these things go...
Even if Pixels hadn't PWM a larger screen (or, dare I say, a book) will be an improvement for longer reading sessions.
In the meantime, I use a Motorola G Power 2024 which has IPS. I'm very much a non-expert but made a minor hobby out of trying to de-google it as much as possible.
Never signed into Google with it. Using NetGuard with a whitelist to prevent most of the phoning home. Uninstalled or disabled most built-in apps. The apps I use are installed via either Obtanium or Fdroid. Have Dropbox from Aurora. Use Motorola's private space for keeping some data and apps in a separate, supposedly secure locker.
I'm sure this doesn't come close to GrapheneOS's security level but it's the best I can do within the limitations of this device. It was a fun mini-project. NetGuard is invaluable for this purpose. Almost feels like the phone is truly mine.
The problem with nearly every other phone, except maybe Samsung flagships, is that they don't fulfill the security requirements. And Samsung is hostile against unlocking (even when it was still possible, it would burn a Knox eFuse).
I also with they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS.
My understanding is that there are close to half a million GrapheneOS users. And many potential users don't want to buy a Google phone. So it feels like it is starting to become worth considering for manufacturers...
I don't get why Fairphone doesn't look into that. Is it because they are not aware, or is it too hard for them to make hardware that is compliant with what GrapheneOS requires? Hundreds of thousands of devices may not count so much for Samsung, but they must definitely count for Fairphone.
What is "its alternative"?
> I also wish they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS.
The manufacturers aren't blocking the installing of GrapheneOS...
I meant alternativeS, sorry. Well, anything AOSP-based that is not Android.
> The manufacturers aren't blocking the installing of GrapheneOS...
Of course they are not. But they produce hardware that is not secure enough for GrapheneOS to consider. I wish they saw value in GrapheneOS and produced hardware that met their requirements.
It's actually weird, because I'm convinced that it's completely worth it: just add those requirements to the design of one new model, and a potential of hundreds of thousands of people may buy it just for GrapheneOS.
The OS makers don't have to go out of their way to support a device they don't want to (that's the beauty of open source passion projects), but it's also not like any manufacturer (that allows bootloader unlocking or ships an unlocked bootloader) is blocking GrapheneOS or anyone else from doing it, which the quote implies in my reading (maybe other people read it differently)
I agree, but you are the one who talked about "blocking". I did not :-).
I don't get your logic. Requirements are a choice. It's very easy to create requirements that exclude every device but one.
Example: "It has to be the Samsung Galaxy S23". Done.
Now you can disagree with those requirements, but that's completely different from saying that the requirements are wrong.
Again, requirements are not laws of physics. As the author of a project, I am free to make up my own requirements, and when something doesn't meet them, then I am free to reject it because it does not meet my requirements...
If you go to a bank and they refuse to lend you money because you don't meet their requirement, you will have a hard time convincing them that their requirement are wrong and that they should instead replace it with yours :-).
Why are GrapheneOS releases dependant on Google releases?
I'm not even really sure what you mean by "manufacturer updates".
The more I hear about this project, the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
If you have an EOL Pixel and a new major version of Android is released, Google will not port this new version of Android (and therefore AOSP) to it. So GrapheneOS would have to do it. GrapheneOS just say they don't have the resources to do that, so they follow the Google releases. Could you keep an EOL Pixel without receiving updates? Sure. But then it's not supported anymore, it's just outdated, insecure software.
> I'm not even really sure what you mean by "manufacturer updates".
There are the AOSP updates (which bring new features, but importantly in our case bring security fixes) that come from Google, but your phone is more than that. There is a bunch of hardware running in your phone and a bunch of firmwares exposing it. Say your camera, or your wifi module, etc. If there is a security issue in the firmware of the camera, then it won't be fixed in the AOSP codebase. You need the camera manufacturer to fix it and release a firmware, pass it to the phone manufacturer who will then deploy it on your phone.
Google split both of those concepts years ago in order to deploy Android updates faster and make everybody more secure, because manufacturers had a tendency to lag a lot. Some still do but the situation generally improved, I think. Anyway, you need to receive those security updates from your manufacturer because they are independent from Google.
> the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
If you think that AOSP is shit, then sure. I mean, if you think that the Linux kernel is shit, maybe you don't want to run a Linux distribution.
I personally think that AOSP is pretty great, and vastly superior to Linux on mobile (among other because it has a much better security model). I am not a big fan of Google being root on my phone (with Android and system apps like Play Services), which is something that GrapheneOS fixes (by making Play Services run like any other, unprivileged app). GrapheneOS is also adding privacy features, be it by proxying your location requests (so that they go through the GrapheneOS servers instead of directly to Google) or by adding features like "scopes", where you can choose exactly which contact you share with an app, for instance, or refuse Internet access to an app without breaking it (GrapheneOS will just make the app believe that it has the permission to access the internet but there is just no connection right now). And of course GrapheneOS hardens the system in terms of security (e.g. with a hardened malloc or memory tagging stuff that Apple recently introduced as well).
So yeah, it is relatively thin, because AOSP is a huge codebase. But it doesn't mean that it's worthless: this skin makes it more secure, more private, and for me more enjoyable than Android.
I think breaking away from open source Google code is not really meaningful. It's kinda like saying "I don't want to run Linux because it contains code from IBM/Google/Meta". AOSP is a great and useful project. If the day that Google stops releasing AOSP ever comes, a consortium of interested organizations can fork it. But it does not make a whole lot of sense to start a new mobile ecosystem completely from scratch, if one that is great and open source already exists and buys you compatibility with millions of apps.
It’s cool it’s possible, but it’s not practical for most people.
I'm not a mobile phone security expert but my feeling is that in the case of GrapheneOS - which target is probably high-profile people at risk of state actors et similia attacks - a zero-day in the closed source firmware from Qualcomm will probably screw you anyway.
I understand that you are anyway reducing the attack surface (now they need to target the modem firmware specifically), I understand the concept of security in depth and I also understand that by using GrapheneOS you are already placing mitigations for many other known and unknown attack vectors. But still...
All the devices that GrapheneOS supports implement a clear separation of the baseband and the CPU in the form of SMMU, ARMs version of IOMMU. So a zero-day in the baseband does not immediately screw you - unless the code on the CPU side also contains vulnerabilities or there is a major flaw in the SMMU implementation that somehow breaks isolation.
I probably explained myself in a shitty manner, I didn't try to downplay GrapheneOS efforts, and I should have kept my initial statement about "next best thing can create a false sense of completeness" as a generic remark and not specific to GrapheneOS, for which I don't have enough knowledge to know if it applies or not.
What that means is they can push malicious settings and configurations (Definitely) and probably malicious firmware to the handset at will. They don't need to code this, they buy the software packages from the usual suspects. Adversary simply needs to put a drt box or a hailstorm or what-not close enough to the handset to do the work.
The baseband can do a lot, it has dma (if I recall correctly) and can almost certainly screen look, and extract information from some but not all base bands. This varies.
GrapheneOS cannot really influence this, but hardened_malloc could conceivably help. What would be great is a bench firmware re-flash, but I don't want to do this every single day.
There's an IOMMU:
> Is the baseband isolated? > Yes, the baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. [...]
https://grapheneos.org/faq#baseband-isolation
> GrapheneOS cannot really influence this, but hardened_malloc could conceivably help.
They can and do, see above. But I don't see how hardened_malloc is related to the baseband doing DMA.
To answer your question, I thought it might just be slightly harder to extract secrets or exploit a running process directly. Thats all I was saying.
I do this on iOS I’m sure it’s do-able on GrapheneOS and hopefully on Android too.
Essentially, 5G is sort of a lie. Phones spend a lot of time exchanging information via 4g/lte, and just like 2g/3g and 3g/4g, there are simply downgrades that can be performed in the field, without getting too far into the weeds.
5G matters not for this.
And it's not only security - simple stuff like USB data off unless the phone is unlocked, native call recording, much enhanced user profiles (to separate data mining apps like Uber or Instagram from your financial affairs), etc.
And yes, it's about reducing the attack vector. On most other handsets you'll get most of the fixes 6 months or a year later. At best.
I do understand your point that people at risk of state level attacks might get a false surface level appearance of defence from this. But then anyone who's a target of state level attacks and is making OS decisions based on a surface level understanding of the tech is not going to have a good time anyway.
How about Pinephone with its partially freed baseband OS [0] or Librem 5 with its removable modem [1]?
Many people here might recoil at this: to go through the trouble of de-Googling your phone and then just install Google Play services and the Play Store, but the important part is that it is a choice they could make.
Pixels are arguably the best option for software choice among mainstream phones (and iPhones are the worst), but both are a huge regression of choice compared to traditional personal computing platforms.
You could also buy a used Pixel.
That said, I do not like how much the project depends on Google.
- GrapheneOS is based on Android, which is solely developed by Google.
- GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
- They recommend using the Google Play Store (requires a Google account) to get apps and recommend against using F-Droid.
- Their Vanadium web browser is based on Chromium, which is controlled by Google. It also does not have an ad blocker or support extensions. They recommend against using Firefox. Firefox, and Safari to a more limited extent, are the only web browsers keeping Google from having complete control over web standards and the way we can access the internet.
This is not a criticism of the GrapheneOS project or developers. I understand that security is the biggest priority of GrapheneOS and I understand that Google is often good at security. They are following the goals of the project. It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered. Most users do not need security at all costs. Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
It does have a network-level ad blocker. What it doesn't have is a blocker which modifies/injects Javascript into pages, which iiuc is the main reason that the blocker doesn't help with ads on YouTube much, or pages which employ similar techniques.
> They recommend against using Firefox.
To clarify: they recommend against Firefox Mobile because it didn't support site isolation until last month's v147 updates. I don't know if the goalpost has moved since, but in any case: there's nothing on Graphene that would prevent you from using Firefox.
The complete lack of content and site sandboxing on Firefox for Android is only one of the reasons we recommend against it. It has major security deficiencies beyond this and cannot benefit from many of the hardware and OS protections due to it. Vanadium is much more secure than standard Chromium while Firefox is much less secure than it, so there's quite a stark difference between them.
Recommending against using Firefox and F-Droid due to major security deficiencies doesn't in any way reduce user choice as the post above portrays it. Having a lot of accurate information provided by GrapheneOS enables our users to make more well informed decisions. We also do not specifically recommend the Play Store as the post says above but rather we provide nuanced information about the available choices. Specifically for obtaining apps from the Play Store which aren't available directly from the developers, we recommend using the sandboxed Play Store for users who using sandboxed Google Play in a profile for app compatibility already. Play Store itself has signature verification while Aurora Store only has TLS with a smaller set of trusted CAs by default similar to many Google apps. Aurora Store is sometimes needed to work around app's filtering who can install it so we do recommend it for that specific purpose. Aurora Store still logs into a Play Store account and making a throwaway account to use the Play Store app doesn't reduce privacy compared to using sandboxed Google Play without one.
GrapheneOS is based on the Android Open Source Project. It's incorrect to say it's solely developed by Google and it's open source software which we're free to change as we see fit.
> GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
No, we already have a partnership with a major Android OEM. It's not something we're working on obtaining and we've provided a fair bit of details including that it will be publicly announced by the OEM in March, that the devices will launch in 2027 and that they'll use a high end Snapdragon SoC which is either the flagship (most likely) or one step below it.
> They recommend using the Google Play Store
No, that's not our recommendation.
> recommend against using F-Droid
We recommend against F-Droid due to it being an unnecessary middleman between users and app developers which does not truly reduce trust the app developers. F-Droid apps are consistently out-of-date and often lag months being on important privacy and security fixes. F-Droid consistently makes problematic undocumented changes to apps including rolling back dependency updates. F-Droid is known to use highly outdated build infrastructure which is very poorly secured. They have a bunch of bad security practices throughout their approach and have made it clear it isn't a priority for them. They've repeatedly said they don't believe app sandboxing is useful and much more than that. Many open source apps including Signal and WireGuard have asked to have their apps omitted from F-Droid due to the security and trustworthiness issues with the project. That's not at all something specific to GrapheneOS.
> Their Vanadium web browser is based on Chromium, which is controlled by Google.
Chromium is an open source project which is collaboratively worked on by multiple projects using it as the basis for their browsers. That includes Microsoft who implemented the WebAssembly interpreter available in the upstream Chromium codebase which is used by Vanadium but is dead code in Chrome and regular Chromium builds since it was added for Edge.
> It also does not have an ad blocker
No, that's not true. Vanadium has a default enabled ad blocker which uses EasyList, EasyPrivacy, EasyList's Adblock Warning Removal List and also selectively activates a whole bunch of EasyList affiliated language/regional lists based on the currently active languages. This approach avoids adblocking being used for fingerprinting, avoids greatly weakening site isolation sandboxing as extensions do and is much higher performance which is important on mobile. It very clearly has ad blocking and a per-site toggle for it.
> or support extensions
Extensions greatly weaken site isolation and give third party code without verified boot extensive access to website content similar to dangerous Android accessibility service apps. Very few extensions are focused on privacy and security in a similar way to GrapheneOS and would compromise what we're trying to build. It's not the approach we want to use in Vanadium. If you want to use extensions then you can use a browser with them but it doesn't fit into what we're building with Vanadium where we want to implement features ourselves in a very private, secure and robust way which cannot be done with extensions. Extensions fundamentally reduce security including because they used a shared process across all isolated websites which inherently reduces isolation. Few extensions take this seriously, even the ones focused on privacy. They commonly add leaks between sites. There are plenty of other browsers available but ours is aiming for a standard of privacy and security which cannot be achieved with extensions.
> They recommend against using Firefox.
Firefox's Android app has atrocious privacy and security. A browser without even basic content sandboxing let alone sandboxing with full site isolation. That's combined with major other major security deficiencies and it isn't something we could recommend using. Recommending against it doesn't mean people can't use it...
You'll still be using Vanadium as the web content engine within apps using the WebView such as email clients rendering HTML email and many more. Many people have a misunderstanding of what the WebView is and confuse it with custom tabs which are provided by the user's selected default browser rather than the WebView used within other apps.
> This is not a criticism of the GrapheneOS project or developers.
How isn't it criticism of GrapheneOS? Regardless, Vanadium does have an adblocker and we don't specifically recommend the Play Store as you said. The biggest issue is that what you're saying about what we prioritize, advise or provide isn't accurate.
> I understand that security is the biggest priority of GrapheneOS
Privacy is the biggest priority of GrapheneOS and privacy depends on security. GrapheneOS is a privacy project.
> It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered.
Our project and community regularly recommends iOS as an alternative which provides far better privacy and security than non-GrapheneOS options. Most other options have very poor privacy/security including lacking even basic privacy/security patches and protections. Similarly, our project and community regularly recommends using macOS for better privacy and security than either Windows or desktop Linux. What you're saying are blind recommendations are anything but that but rather very well informed information provided by the GrapheneOS project.
> Most users do not need security at all costs.
GrapheneOS is not about security at all costs and this misconception which regularly comes up that it's about security rather than privacy is completely wrong. Many projects failing to provide decent privacy treat it as if privacy is solely about which apps/services are bundled rather than needing to provide privacy patches, privacy protections and solid security to protect that from being bypassed. Much of what GrapheneOS provides are privacy features such as Contact Scopes, Storage Scopes and the Sensors/Network toggles along with much more. The security protections it provides exist to protect privacy. Why else would the security protections be there other than to protect privacy? It's not a separate thing from privacy but rather is a huge part of providing it. There's no other reason for us to work on security than protecting privacy. It doesn't make sense to say we work on security instead of privacy.
Most users do need basic privacy/security updates and protections. Failing to keep up with basic updates and misleading users about it is a severe issue. There isn't any major non-GrapheneOS AOSP-based OS that's doing the bare minimum of keeping up with updates.
> Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
You aren't accurately representing what GrapheneOS provides, our approach or our priorities. People can see for themselves from the detailed article that it provides a highly usable and compatible system with a huge amount of user choice. People can choose from a wide range of approaches based on their privacy and security goals. It doesn't impose choices on people. You treat it as if people are forced to use Vanadium when it's another choice of browser which people have on GrapheneOS but not elsewhere. GrapheneOS users have more choice among browsers and the one we have DOES provide ad blocking contrary to what you said. GrapheneOS users can use F-Droid despite us recommending against it due to the major security deficiencies. Providing well informed recommendations with detailed explanations does not in any way hinder user choice but rather informs people so they can make better choices. Our recommendations not aligning with your personal beliefs or preferences doesn't mean we're somehow reducing user choice.
Luckily I have hardware 2FA keys from my bank so I can authenticate using that. It also slightly decreases the suck-factor from whenever the phone decides to fly off down a drain. This may not be the case for you, so do your research on what you need for daily living.
Still missing Android Pay but that's due to Android Pay being closed. I wish banks would do something and support NFC payment systems that don't require the device to be controlled by Google (how can we be okay with this?!)
There are countries where it's possible to pay everywhere with the banking app scanning a QR code. No need for NFC :-).
You need the Google/Apple app though, don't you? Or can you write your own personal app that will handle that?
NFC is by far more convenient and reliable.
QR codes are reliable.
NFC (EMV) works offline.
It's pretty common here that people will be told they need to turn off an otherwise working Wifi connection when facing problems because bank apps will often just not work properly on wifi.
But as I said, even without that, the convenience level is ridiculously different. It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes, before we even talk about the convenience of watch/phone payments using NFC.
Got it, that's a fair point!
> But as I said, even without that, the convenience level is ridiculously different. It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes
This part sounds like those people who use a different unit system than I do and explain to me how my unit system is objectively more inconvenient than theirs. To which I answer: "I think I know better than you what is more convenient for me, given that I use it everyday" :-).
I use QR codes instead of opening my wallet, which kind of hints towards the former being more convenient than the latter for me. And for the millions of people who also do that.
I'm not saying "yours" is less convenient. I'm saying the one you and I both use regularly is less convenient than anything NFC based, which I also use semi-regularly.
> It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes
So I assume that even though QR codes are available where you live, you use your debit card with an NFC chip because it is quicker than using QR codes...
Anyway, the important part is that NFC doesn't require an internet connection, and I had missed that. Now I wonder why a QR code couldn't work without an internet connection just the same. I'll have to look into that!
Yes, I generally use my card rather than than QR unless the shop doesn't take cards, doesn't have a paywave/etc-enabled card reader, the card reader is broken, the sales person doesn't know how to use it, or the sales person insists I give them my card and PIN to pay (none of those are hypotheticals, I've experienced all of those first hand, some of them quite repeatedly).
> Now I wonder why a QR code couldn't work without an internet connection just the same.
Because a QR code is just a short piece of information to tell your banking app who to send funds to - it's like putting a mailto: link on a website rather than asking people to re-type your email address to contact you.
The problem is not GrapheneOS, but rather that phone manufacturers other than Google don't care. Now if there were millions of GrapheneOS users, it would start becoming interesting for other phone manufacturers to care.
My point being that I buy Pixel in order to give more weight to GrapheneOS, in the hope that other manufacturers will eventually realise that.
E.g. a new Pixel 9a is currently 369 Euro in The Netherlands and 367 Euro in Germany. The Pixel 10a will be released soon, but the 9a will run GrapheneOS just fine (same SoC except modem as the vanilla 9).
In any case, for me this also sort of defeats the purpose: I'd rather break free from Google and Apple, not just (stock) Android and iOS.
https://privsec.dev/posts/android/banking-applications-compa...
Not really. On GrapheneOS, the Play Services/Play Store run as sandboxed apps, i.e. they are not system apps like on Android. They just run like a normal, unprivileged app. That's a lot better than on Android.
> I'd rather break free from Google and Apple, not just (stock) Android and iOS
If you want to break free, you don't have to install the Play Services / Play Store on GrapheneOS, just like you don't have to install microG on LineageOS. There is a misconception that microG is better than sandboxed Play, but I disagree. With microG, your apps still connect to the Google servers, so you're not "breaking free".
Moreover, some OSes (e.g. /e/OS) give certain Google apps higher privileges than other apps even with microG, install Android Auto and it's still game over. GrapheneOS does not have this issue because as you say, Google apps/services get sandboxed.
Obligatory link: https://eylenburg.github.io/android_comparison.htm
Edit: ignore this - there's a list elsewhere in this thread!
If you are using a rather popular banking app, chances are high that it has been discussed in the GrapheneOS forum.
Anyway, with google play services installed, mine have worked out of the box.
It's just so damned convenient. And the recording of transactions on the phone saves me having to collect paper receipts.
If anyone wants this without GrapheneOS: https://f-droid.org/packages/dev.ukanth.ufirewall
If anyone wants this without GrapheneOS and without root: https://f-droid.org/packages/net.kollnig.missioncontrol.fdro...
Why start from scratch?
I've been on ubports for 3 years and while it also has some weird caveats like read only rootfs, no working package manager (due to read-only fs. however ubports has pretty cool support for lxc containers where you can use apt). Due to chronic lack of time I haven't been able to sit down on my phone to play with it a bit (for example id like to install waydroid), but it seems a lot easier than android. For example, while there isn't an app for call recording, some guy worked around it by writing a systemd user service as a workaround[1]. This is exactly the type of thing I'm thinking about when talking "linux phone".
For me as a linux user, the difference if ubports was a human, I'd think that perhaps they were sick, whereas if android was a human, i'd shoot them in the face :)
Remember that GrapheneOS is not Android: it's an AOSP-based OS.
I actually had hopes that Huawei would start that with HarmonyOS.
It is finnish, anyone knows how are they going?
i used that for 2 years, it's linux+kde bottom to top, a terminal + shell is a builtin, though only supporting 5+ years old Sony phones got tiresome.
Still.. it seems the only one that's usable enough apart of the duopoly. May have to switch to it again.
You can run desktop apps on GrapheneOS including on a desktop monitor via the desktop mode with free form windows. There's support for non-native apps via hardware-based virtualization. These features are experimental but already work pretty well.
The situation with Sony Xperia devices is not great, the best experience is still on the X10III (from 2021 I think) and there are significant issues with the support of 10 IV and V generation devices (a free beta release is available for those as well).
It seems that recently there has been quite a lot of buzz in the Sailfish community compared to the past few years. In the public repos there are some interesting contributions like xdg-shell support for Lipstick, which looks set to enable compiling many previously unavailable Linux apps natively if that will actually be integrated in an upcoming OS version.
I wish Europe would have forced that 10 years ago since the US is beyond saving.
Decompiling apps only works if you can get the app. I don't understand GP's problem with the apk format either, but you do need to break terms of service to get the files if you don't have a phone with Google services installed. Whether that's ethical or legal is up for debate
In regular use, main difference will be that /e/OS comes with access to the alternative cloud service that project provides. It uses the default FOSS solution microG for google api compatibility, unlike GrapheneOS with their sandbox approach. /e/OS sets on AppLounge to install and upgrade both play store or F-Droid apps. Graphene has a small curated app repo instead.
I'd never use GrapheneOS since I don't trust the project. /e/OS is also not my favorite since it feels like it is developing slowly, having had issues with outdated software versions - though it does work well in practice. Have a look at iode for an alternative.
Fair enough, you choose what you trust.
But personally, I have never seen a technical claim from GrapheneOS that was wrong or misleading. But I have seen many claims from /e/OS that were technically wrong or misleading. So I trust GrapheneOS more.
Then there is the drama, and all sides annoy me when they behave like this. But I have seen drama coming from all sides.
Sorry, I won't spend 30 minutes digging to find that :-). I follow /e/OS, GrapheneOS and (followed) Calyx. I have seen messages from all of those either on forums, Mastodon, etc.
Also, whenever GrapheneOS makes a technical point (which is often a blunt "GrapheneOS is superior because [...] does it wrong"), many users of those projects answer aggressively (and of course many GrapheneOS participate as well).
And on top of that, a lot of messages criticising some GOS people or the entire project and calling them "toxic" whenever GrapheneOS is mentioned.
I have no skin in this game, so it doesn't touch me. But I could understand that the GOS people feel "harassed" by this. If everywhere I went people said "have you seen this guy? I hear he's toxic", I would consider it harassment, I think?
You or other readers can check https://github.com/mozilla/ichnaea/issues/2065 for a public display on how GOS attacks work when they are mixed into technical debates, how they destroy any chance of cooperation.
Sure, you're free to do what you want. Just sharing my opinion given that I follow those projects from the outside.
> You or other readers can check
I guess what I am trying to say is that it takes multiple sides to argue.
For what it's worth, your link shows the founder of /e/OS engaging there. I have seen both technically wrong and misleading claims from the founder of /e/OS on Mastodon, then GrapheneOS explaining why they thought it was wrong on their forum, and then the founder of /e/OS calling them toxic and complaining about those attacks. And then /e/OS users would join the party and start attacking GrapheneOS, fully trusting those claims from the /e/OS founder. I can't really say that he didn't have any responsibility in the drama under those conditions...
Again, GrapheneOS tend to be blunt, but it doesn't make it technically wrong. And when the message is "it is unacceptable to us in terms of security", then it will be blunt anyway. I realised after years of using a phone I bought to Murena that my system (that they installed and sold to me) was entirely breaking the AOSP security model: it was signed with the Google testing keys and the bootloader was unlocked (and just couldn't be relocked, and anyway it wouldn't matter because of those keys that are not meant for production).
In other words, I bought a product to Murena that was unacceptable to me in terms of security, but genuinely thought it was better than Stock Android because of Murena / /e/OS marketing. I genuinely feel either they tricked me, or they didn't know it themselves. I have personally seen multiple /e/OS phones in a state where they were objectively less secure than Stock Android. I get that they don't like it when GrapheneOS says it, but that is not wrong.
For the security thing: It is wrong to claim that an unlocked bootloader completely breaks the android security model. If anything, it breaks one specific aspect, one that doesn't matter for many attacker models. Besides, on some phones the bootloader just can't be relocked, that's on the phone vendor though. Signing keys for bootloaders might just not matter if change detection was working or the bootloader was not relockable, but maybe I'm missing some specifics there.
So imho what you describe as catastrophic scenario likely wasn't one.
You seem knowledgeable about this, so I'll take the opportunity to ask: if I install a malicious app and it manages to escape the sandbox and alter the system, my understanding is that it will be detected next time I boot it (because the image hash won't match). Isn't that true?
> Signing keys for bootloaders might just not matter
Again a question, I haven't found it in the official documentation: aren't those keys the "system keys"? As in, if my system is signed with some keys and an app is signed with those same keys, doesn't it allow this app to get privileged permissions?
If a malicious app tries to alter the system in a bootloader relevant way, it would most likely fail. On those roms, apps don't have root rights, and users are even unable to activate a root account (part of why we need unlocked bootloaders in the first place to achieve user control over bought devices). But yes, as part of AVB system parts are hashed and a mismatch would be detected, see https://emteria.com/blog/android-verified-boot for a writeup.
For system apps, again two aspects. It's not that easy for an app to become a system app, it has to be moved to a specific place. Think about how the Gapps package is usually installed when you install a ROM, externally by the recovery system and not inside Android itself, that would be the reason. But yes, there are platform keys that the docs at https://source.android.com/docs/core/ota/sign_builds claim should be secret release keys.
About those release keys being also used for the system app verification, I think so. There are different keys on Android, like the release keys and the verity_key, but I think it follows from the docs that the release key is the one used to verify system apps (on modern Android versions).
It is debatable whether users not being able to exchange system apps then is a valid requirement for a FOSS Android distribution like /e/. But that position does exist, claiming users should build their ROM variants on their own with custom keys if they want to modify the system, to close this attack vector.
They're misrepresenting what has been said by GrapheneOS and also lack a good understanding of it themselves. They're definitely not a good source of information about this.
1. Is it correct that the secure boot protects again a malicious app escaping the sandbox and persisting into the system?
2. Is it correct that if the system is signed with the Google testing keys, then someone could sign an app with those keys and the app would get more permissions than it should (I believe it's called the "signature" permissions)?
That's not just a claim, this is an objective fact. GrapheneOS has a excellent track record when it comes to security, they have made several patches that got upstreamed to Android, etc.
GrapheneOS has been heavily analyzed by privacy and security experts who say it provides far better privacy and security. There's a large amount of real world evidence showing GrapheneOS very successfully defends against commercial exploits tools. /e/ has been heavily criticized for having poor privacy and atrocious security by many experts. /e/ doesn't keep up with basic privacy/security patches and misses many important standard protections.
> keep in mind that it is not an independent comparison
That's not true. It's an independent comparison and the site compares a lot of other software. Contributors to many of the projects compared by it submit issues to it which doesn't many it not an independent comparison.
> In regular use, main difference will be that /e/OS comes with access to the alternative cloud service that project provides.
GrapheneOS users have many cloud services available including suites from Proton and others. Murena services have poor privacy and security overall due to neglecting server security, updates and more. Their speech-to-text service being a thin wrapper around OpenAI sending this sensitive user data to them rather than doing it locally as our SpeechServices app does similarly to Apple (even Google has that as an option):
https://community.e.foundation/t/voice-to-text-feature-using...
> It uses the default FOSS solution microG for google api compatibility
Their approach with microG gives highly privileged access to Google apps/services by default. GrapheneOS doesn't include sandboxed Google Play by default and they're installed as regular apps. microG doesn't change the fact that the apps are using closed source Google libraries, which are still present with microG and have strictly more access to user data on /e/ than GrapheneOS with sandboxed Google Play. Sandboxed Google Play is an entirely opt-in feature people need to install. /e/ has microG set up where it downloads closed source Google Play components it runs with privileged access as the default.
> /e/OS sets on AppLounge to install and upgrade both play store or F-Droid apps
This is a strange merger of Aurora Store, F-Droid and more. It's very misleading and confusing for users.
> /e/OS is also not my favorite since it feels like it is developing slowly, having had issues with outdated software versions - though it does work well in practice. Have a look at iode for an alternative.
Neither /e/ or iodéOS keeps up with updates to Android, Chromium, firmware, drivers or the Linux kernel. Both mislead users with an inaccurate Android security patch level. iodéOS lags far less behind /e/ and doesn't have nearly as many privacy violating services and added privacy/security flaws but neither is a privacy or security hardened OS. Neither keeps the privacy or security of standard AOSP intact.
- If your phone is supported by GOS, you should go for GOS.
- If your phone is not supported by GOS, you should look carefully and compare between /e/OS and Stock Android.
I had a Fairphone 3, and after 5 years, /e/OS was outdated by 4 years w.r.t. the manufacturer updates. In other words, Stock Android coming from Fairphone was more secure than /e/OS on that Fairphone.
In my experience, /e/OS has a tendency to claim that they support everything, but they just can't, there is too much. And then they complain when GrapheneOS criticises the fact that some /e/OS users believe their phone is well supported but actually isn't. And GrapheneOS is not wrong: I realised I was in that case after 4 years with /e/OS.
Mine is running /e/ and reporting Android 13, which appears to be the last one Fairphone support. /e/ said it was too difficult to support 14 with the kernel involved. It's had continual security updates apart from the Android version.
Edit: Murena make it clear which phones are officially supported and which have "community" support.
This is not the manufacturer updates. I was talking about the manufacturer updates. I just checked and someone complained a few months ago and they updated them. Before that, they had not been updated in years on /e/OS, but they were up-to-date on Stock Android.
> Edit: Murena make it clear which phones are officially supported and which have "community" support.
I bought a phone to Murena, advertised by Murena, through Murena. It really felt like it would be officially supported, otherwise they should have made it clear that they advertise and sell something that they won't support, wouldn't you say? My feeling is that they just stopped supporting it after a while.
Also I would assume that "supported" means that it receives both the LineageOS updates and the manufacturer updates. Apparently they have a different definition of "supported" (which is fine, maybe it's just "we will continue sending you our own updates"). It's just that in my book, if I get more security updates with the Stock Android than with /e/OS, then Stock Android is more secure.
Nope, it doesn't receive most privacy and security patches. Users are being heavily misled about what's provided. First of all, the kernel is nearly entirely not being updated which is a massive portion of the privacy and security patches. Murena's devices have poor privacy and atrocious security including due to the failure to properly provide basic privacy/security patches. Their claims about what they provide need to be distinguished from what is actually provided. /e/ updates the patch level regularly to claim they provide the security patch backports but that doesn't mean they actually provided all of them. It's an arbitrary value and they don't set it accurately.
Fairphone 3 uses the end-of-life Linux 4.9 branch, Fairphone 4 use the end-of-life Linux 4.19 branch and Fairphone 5 uses the end-of-life 5.4 branch. Each was largely not receiving the upstream LTS updates while they were still provided but now they're not provided. An OS that's not receiving basic kernel updates is definitely not receiving security patches anymore, but they were largely never providing these updates in the first place long before the kernel branch or devices were considered end-of-life.
Similar to iOS and other operating systems, Android only backports a subset of privacy and security patches to older Android branches. Only Android 16 QPR2 has the full set of Android privacy and security patches. You aren't receiving all of the standard Android privacy and security patches if you're not on Android 16 QPR2. Many of the patches are also treated as optional and deferred as being mandatory far into the future. It's also worth noting the dates are misleading. Android's March 2026 security backported have been finalized for a while and up to August 2026 are available to ship by OEMs already but a lot more will be added to June 2026. February 2026 Android security patches are the latest with a public bulletin but not the latest available to ship.
Fairphone and especially /e/ also have very incomplete patches for firmware and drivers. /e/ also has major issues patching other components including the browser engine used by the OS for the WebView.
If you have an iPhone that's still supported, you have strong privacy and security. If you have a phone that's not an iPhone and not supported by GrapheneOS then you likely have a phone with atrocious privacy and security regardless of OS choice. If people can afford to get a secure device with years of proper support remaining then they should do that rather than using an insecure device with a sidegrade for privacy and security using a problematic AOSP fork. LineageOS is far less problematic than /e/. If people want to switch the OS to something else due to the OEM abandoning it or to avoid Google Mobile Services they should use at least use LineageOS which is less of a privacy and security downgrade from OS. LineageOS does not fully maintain the privacy and security of AOSP or fully keep up with updates but it's a lot less bad than /e/. Most alternate OSes are forks of LineageOS to reuse their work on hardware support and nearly entirely make privacy and security worse, not better, so why not use the upstream project instead?
> I had a Fairphone 3, and after 5 years, /e/OS was outdated by 4 years w.r.t. the manufacturer updates. In other words, Stock Android coming from Fairphone was more secure than /e/OS on that Fairphone.
It's important to note that an alternate OS depends on the OEM for firmware and in practice much more than that including kernel and driver updates. It's theoretically possible to replace the kernel and drivers with much different ones but it's not done in practice by alternate AOSP-based operating systems. If the device is abandoned by the OEM then you aren't going to have a secure device.
/e/ lags far behind on standard privacy and security updates everywhere but misleads users with an inaccurate Android security patch level along with many inaccurate privacy and security claims. LineageOS is much better than the fork of it by /e/ and does much less to mislead users, although it still has the inaccurate Android security patch level and many people still wrongly believe they're getting patches they aren't after the OEM dropped support.
I can confirm that I did, and was not very happy when I realised it.
/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.
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.
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.
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.
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 "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.
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.
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 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.
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'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?!
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.
Reminds me of https://xkcd.com/1200/
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?
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.
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.
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
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.
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?
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.
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).
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.
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.
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.
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.
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.
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.
/e/OS (and similar "non-LineageOS" ROMs really) instead focus more on de-Googling. They're still generally security focused, but the priority is less "someone's after you" and more "corporate surveillance is kinda scary innit". The aim is less to avoid someone actively trying to drain your phone of data and more to prevent your phone from passively sending everything it can possibly find to the Big G's ad machine (as well as whatever other trackers get snuck into apps.) Because of this, they usually have better depreciation timelines and support a lot more devices compared to GOS who only support the Pixel line (which is an increasingly awful set of phones truth be told); their scope is much smaller.
Finally, it's worth noting that the GOS community is absurdly toxic to anyone doing anything privacy-related that isn't under the banner of GOS. It's extremely maximalist, tends to get very upset at other projects whenever they get attention (see sibling reply to this, where they pretty much melted down because an outlet dared to recommend a Fair phone+/e/OS) and the projects official channels have generally encouraged this sort of behavior. It doesn't really damage the software itself, but it's worth considering.
> it's worth noting that the GOS community is absurdly toxic to anyone doing anything privacy-related that isn't under the banner of GOS
What I have seen (and I am not involved in any of those projects) is that GOS does care a lot about security, has a higher quality in that regard than anything else, and tends to be blunt about "inferior" projects communicating about security.
Not that they couldn't improve their communication style, but usually when they call out technical limitations of other projects (e.g. /e/OS), they are right. And I mean the technical arguments. Then I have seen a bunch of drama, but to be fair I have seen those other communities show toxic behaviour towards GOS just as much as the opposite.
It feels like it is GOS vs "the others", because the others don't criticise each other, and GOS bluntly criticises when they see claims they find are wrong (I have seen claims by /e/OS going from misleading to downright wrong).
On my particular phone, after 5 years with /e/OS, the Fairphone updates were outdated by 4 years. In terms of security I would have been better with the Stock Android. It depends on the phone of course, because /e/OS tends to claim that they support everything and they just can't. Even on a phone that /e/OS supports well, GrapheneOS is superior, period.
But I agree, I could do without all the drama. I guess my point is that it goes both ways.
> GOS does care a lot about security, has a higher quality in that regard than anything else, and tends to be blunt about "inferior" projects communicating about security.
Two remarks:
- There's a difference between "blunt" and hostile or misleading. GOS (owners) are often the latter two from what I read, where by misleading I mean distorting reality about whom you should be protecting from and recommending you should never use anything else to reach your goals (as opposed to GOS' goals)
- They also reply when privacy comes up in other projects, not just security, but they treat it as though it's essential for privacy. Not everyone is running from an intelligence agency or cellebrite border checkpoints, some people just want a phone with as many open components as possible or want to lie to Facebook about which contacts are on their device. You don't need a locked bootloader and be prevented from accessing your own data for that (can't access /data on your own device on any official GrapheneOS build; which is fine if that's what you want, but not everyone's goals are the same)
OK, but would it be such a bad thing if most people's personal devices were pretty damn resilient to mercenary spyware by default? I really don't think the standards GrapheneOS are aspiring to are the problem with this picture.
In my case, it was a few months ago, so end of 2025.
I think it's just that they can't possibly support thousands of Android devices. I just don't like that they are not being very clear about it. You would think that buying a phone through Murena would guarantee some kind of support, but it actually doesn't.
https://archive.is/SWXPJ https://archive.is/n4yTO
The communities of several projects including /e/ have heavily engaged in spreading misinformation about GrapheneOS including fabricated stories about our team. They've even taken it to the point of repeated swatting attacks aimed at killing our team members. There are relentless raids on the GrapheneOS community platforms including our chat rooms where Child Sex Abuse Material, gore and endless harassment towards our team members including fabricated stories and harassment content from Kiwi Farms and elsewhere is posted.
I would suggest having a look at CoMaps, a recent fork of OrganicMaps :-).
> Securitywise it's hard to argue against them, although GOS tends to sacrifice usability in favor of security, which leads to odd decisions.
GrapheneOS doesn't make any major usability sacrifices for security. Privacy or security features with usability compromises are either opt-in or opt-out.
> Worth noting however is that usage of GOS is also seen as a signal in and of itself for the authorities that you may have something unsavory to hide
GrapheneOS is far more widely used than most alternate mobile operating systems and there's a lack of basis to claim that it's widely seen in the way you're describing in a way that other operating systems are not. In fact, they're largely conflating other operating systems with GrapheneOS because it's the most widely talked about and known about. They're calling devices GrapheneOS devices which aren't running it. In many cases it's not even a fork of it.
> have said that the OS is popular with organized crime
This is completely unsubstantiated and not evidence has ever been provided. On the other hand, it's known that law enforcement in Europe has widely sold devices to organized crime which they marketed by claiming they were based on GrapheneOS:
https://darknetdiaries.com/episode/146/
Using portions of our code doesn't make something GrapheneOS and marketing is also a different thing than reality. Most of what's claimed to be GrapheneOS in this context is not GrapheneOS but rather trademark infringement by forks or even non-forks.
> /e/OS (and similar "non-LineageOS" ROMs really) instead focus more on de-Googling.
Nope, /e/ always connects to multiple Google services regardless of configuration and gives highly privileged access to them. GrapheneOS doesn't connect to Google servers by default and avoids giving privileged access to installed Google apps via our sandboxed Google Play compatibility layer.
> They're still generally security focused.
No, that's definitely not the case. /e/ has absolutely atrocious security and fails to provide even basic security patches and protections. This is also part of why it provides poor privacy due to lagging far behind on privacy patches in addition to security patches along with being missing important standard Android privacy and security protections due to being far behind and not having it all set up. /e/ doesn't provide comparable privacy features to GrapheneOS Storage Scopes, Contact Scopes, Sensors toggle and far more not only the security features. /e/ isn't just not a security hardened OS, it's also not a privacy hardened OS. LineageOS has better privacy and security than /e/. AOSP has better privacy and security than LineageOS.
> Because of this, they usually have better depreciation timelines
/e/ doesn't provide proper updates for any devices. Many of the devices they support aren't getting driver and firmware updates from them even when they're available. They lag far behind on kernel, Android, Chromium (including WebView) and other updates too. They support many devices without kernel, driver and firmware updates available but they're usually way behind even when they are. /e/ simply doesn't care about providing basic privacy and security so they continue having people buy and use highly non-private and insecure devices lacking basic patches.
> Finally, it's worth noting that the GOS community is absurdly toxic to anyone doing anything privacy-related that isn't under the banner of GOS. It's extremely maximalist, tends to get very upset at other projects whenever they get attention (see sibling reply to this, where they pretty much melted down because an outlet dared to recommend a Fair phone+/e/OS) and the projects official channels have generally encouraged this sort of behavior. It doesn't really damage the software itself, but it's worth considering.
No, completely backwards. The massive amount of false marketing, misinformation and harassment engaged in by the /e/ project and community is what's toxic. The founder and CEO of /e/ and Murena openly spreads content from Kiwi Farms and neo-nazi sites. He directly engages in harassment towards the GrapheneOS team. Here's him supporting authoritarians smearing GrapheneOS by replying to threads about it linking to harassment content based on fabrications on a neo-nazi conspiracy site:
https://archive.is/SWXPJ https://archive.is/n4yTO
The communities of several projects including /e/ have heavily engaged in spreading misinformation about GrapheneOS including fabricated stories about our team. They've even taken it to the point of repeated swatting attacks aimed at killing our team members. There are relentless raids on the GrapheneOS community platforms including our chat rooms where Child Sex Abuse Material, gore and endless harassment towards our team members including fabricated stories and harassment content from Kiwi Farms and elsewhere is posted.
People should review https://eylenburg.github.io/android_comparison.htm which is a third party maintained comparison between AOSP-based operating systems which addresses many of the misconceptions you have about how GrapheneOS compares to AOSP, /e/ and other operating systems. You're not at all correct about what's provided by /e/ which fails to keep up with basic updates or provide the standard protections.
We can provide large amounts of further examples of the founder and CEO of /e/ and Murena participating in this harassment.
The attacks towards us including your libelous claims about us here are what's absurdly toxic.
> It's extremely maximalist
It isn't but rather is very pragmatic and focused on usability, robustness and compatibility alongside the major focus on privacy. The focus on security is to protect privacy because it depends on it.
A common misconception is that people believe GrapheneOS is less usable than much less private and far less secure options but it's the other way around. GrapheneOS provides nearly perfect app compatibility when taking into account the per-app exploit protection compatibility toggle and sandboxed Google Play. Nearly the only apps not working on GrapheneOS are ones banning any alternate OS and a larger number of those work on GrapheneOS than elsewhere due to a subset specifically permitting GrapheneOS due to far higher rather than weaker security. Apps have legitimate reasons for being concerned about the poor security of many alternate operating systems but they're wrongly grouping it all together as if GrapheneOS.
/e/ lags weeks, months and even years behind on providing updates for drivers, firmware, the Linux kernel and more. They miss a large portion of the monthly Android security bulletins which are a limited subset of the patches in the first place but then claim to provide the latest patch level despite many of the required patches being missing.
/e/ has a supposedly private speech-to-text sends data to OpenAI and their own servers without obtaining explicit user consent to share sensitive data with a third party.
https://community.e.foundation/t/voice-to-text-feature-using...
They say the data is anonymized based on passing it through their own servers before OpenAI but OpenAI is receiving all of the user speech data under their usual terms of service enabling them to store and leverage it.
Fairphone lags significantly behind on OS updates and patches with only a small subset of what should be provided being shipped. Their hardware omits important security protections required by GrapheneOS which it uses to protect users against widespread commercial exploit tools. Fairphone doesn't provide upstream Linux kernel updates in practice which is a massive omission for their updates. Fairphone 4 has an end-of-life 4.19 kernel branch and the Fairphone 5 despite not being very old already has an end-of-life 5.4 kernel branch. Neither was providing the LTS revisions prior to end-of-life so from their perspective nothing really changed but it means it's a huge task for an alternative OS to provide basic updates since they'd need to port everything to a newer kernel branch.
/e/ does not provide similar privacy features to GrapheneOS such as Contact Scopes, Storage Scopes, Sensors toggle and much more. It focuses on bundling things which can be provided with apps such as RethinkDNS on GrapheneOS with a higher quality implementation. GrapheneOS delegates as much as it can to apps while focused on the core OS. If a feature can be done better with an open source app, we'd rather leave it up to that app and many provide privacy and security protections which apps cannot. For the most part, apps can't improve OS privacy and security. Enumerating badness via blocklists which cannot block anything that's dual purpose functionality is also a very weak approach to privacy which is increasingly less useful. The most privacy invasive behavior of apps is nearly all done through their own services which also provide their functionality. Among other things, /e/ uses this system for labeling app tracking and permissions which is incorrect and misleading as shown by this example:
https://reports.exodus-privacy.eu.org/en/reports/com.faceboo...
Facebook clearly doesn't have no tracking but rather this system only detects a small number of specific third party libraries they've decided are trackers. Those choices are often very questionable such as portraying even opt-in crash reporting as tracking because it used a third party library on their list. Meanwhile, Facebook's lite app supposedly has no trackers. The permissions list is thoroughly inaccurate and not how Android permissions work. The core permissions are opt-in with apps having to request them so listing those as if they're granted on install and mandatory due to being possible to grant is incorrect. Most of the rest have special access toggles which are opt-in for the sensitive ones or other toggles such as the battery optimization mode where Restricted stops apps starting themselves and delays those things until it's run by another app or the user.
Privacy requires providing privacy patches and strong privacy protections. It also depends on security which means providing security patches and strong security protections. GrapheneOS is heavily focused on all of that rather than simply treating not having bundled Google apps and services as meaning a private OS. There are also worse things for privacy than Google apps and services. /e/ sending speech data to OpenAI vs. Apple doing the processing locally as we've it implemented for GrapheneOS is a good example. Google at least has partial local speech-to-text support and a better privacy policy than OpenAI for the cloud portion. Avoiding Google apps/services is not the same thing as providing strong privacy.
To put it concretely, GrapheneOS recommends running all the proprietary Google apps in a locked "sandbox" so they can't read data on the phone outside the sandbox -- but obviously Google still gets to see everything you do in their apps. /e/OS tries to provide [largely but not entirely FLOSS] alternatives (e.g. their own Maps app, their own email, their own calendar) that make your phone usable out of the box without Google software.
Well, the actually scary part of google services is that they have this quasi-elevated access in your phone where it can do a lot of stuff ordinary android services just can't do. E.g. google maps' location sharing works this way (but don't quote me on that).
GrapheneOS managed to "put it back into the bottle", and it runs as a regular android service anyone could write, with the same rules applying. So you have much more control on what you allow it, and this will also limit what data apps relying on google services can leak about you.
Right. Something that GrapheneOS boosters often fail to mention. It's not like those guys at Google are just idiots and don't know how to make a hardened allocator. Android uses a different hardened allocator that is much, much faster and uses less space. GrapheneOS is slower and uses more memory.
Another tradeoff GrapheneOS makes is because of the way they configure the USB port makes it more possible that you will irreversibly brick your phone by accident. You could say that the USB management is the only really material difference between Android and GrapheneOS when it comes to a law enforcement search threat model, but that also comes with a tradeoff.
Good point about the USB thing btw. It's obvious to me and the reason why I go one step further and leave USB debugging always enabled now that there's this private key authorisation method anyway (it asks for computers whose key it doesn't yet trust), but indeed a lot of users might follow GrapheneOS' advice without realising
https://eylenburg.github.io/android_comparison.htm
In short, GrapheneOS is vastly superior.
My running watch is from a chinese company that I do not trust, so I lock down the permissions quite far. I like that Graphene lets me control the network permission and have offline maps that cannot report anything external.
Overall the most annoying thing is not being able to iMessage... I moved who I could over to signal.
Also the battery life is amazing because I keept restricting apps from background usage and the defaults already do a good job of that
Is it really "breaking free" from a company if the method of "breaking free" requires continued cooperation from the company
This is not to suggest using a modified version of Android isn't useful. This comment is not about GrapheneOS. (But there will be HN replies that will try to redirect focus to it anyway.) This comment is about claiming it's possible to "break free" from something while still remaining inextricably tied to it
In addition to using a custom ROM, there are methods of stopping the Pixel's attempts to "phone home" to the company that work even with the version of Android pre-installed by the company intact. However if a method requires software, e.g., drivers, or is "based on" software controlled by the company, then ultimately the company holds the cards. IMHO, this is not what it means to "break free"
Perhaps the most reliable method of stopping these connections to the company is one that does not rely on cooperation by the company. This is because if the company decides to stop cooperating, the method still works
So it would follow that a valid privacy-respecting third option would potentially help Apple customers as well as Google customers.
Well, "Android" generally means either variant. I run GrapheneOS and I call it Android. If someone asks, I say I run Android, not GrapheneOS. Actually in terms of experience, it is Android to me.
But in a context where we oppose GrapheneOS to Android, then I think it's important to be clear. GrapheneOS belongs to the family of OSes that are based on AOSP (like Android, LineageOS, IodeOS, /e/OS, CalyxOS), while Android is itself a "subfamily" of that, including the Google Android, the Samsung Android, the Xiaomi Android, etc.
In a way, I personally feel like GrapheneOS is closer to Google Android than the Samsung Android is from the Google Android, if that makes sense. Moving from GrapheneOS to Google Android, I really don't see significant differences. Now Moving to a Samsung Android, I need to adapt a little.
All that to say, I really only make a difference when we are talking about AOSP-based systems as a distinct group, by opposition to "Android certified" systems. Just like it sometimes make sense to talk about GNU/Linux in specific conversations, but generally, we refer to a Linux distribution as "Linux".
I am probably going to switch back to a used old iPhone for "phone appliance" tasks, but keep around the Pixel for other things.
My main takeaway from the experience is that iMessage is an even bigger weapon than I thought.
The best thing would be to switch to Signal (Molly) for texting.
As an aside, from the latest release notes: Sandboxed Google Play compatibility layer: add toggle for granting Play services access to ICC auth in order to support RCS with carriers requiring it for RCS in Google Messages including T-Mobile (see RCS usage guide)
If anything, iOS seems buggier and less reliable, but I know (and am related to) a lot of people who insist on using iMessage/RCS, and I can't be missing messages.
Are there valid reasons to only support pixels?
https://grapheneos.org/faq#future-devices
GrapheneOS is partnered with a major Android OEM working on improving their future devices to meet our requirements. The first devices with official GrapheneOS support from them are planned for 2027. It takes time and resources to make reasonably secure devices. Future generations can improve further including adding hardware-based privacy/security protections unavailable on Pixels.
https://www.androidauthority.com/graphene-os-major-android-o...
For me the biggest concern is that while you may be able to use and run your own device, you will be locked out of most propietary services. Much like how more and more websites simply don't work with Firefox anymore.
Although this is not the case, moving away from proprietary services (and self-hosting your own) is an important goal in itself. See for instance the recent controversy regarding Discord's age verification.
https://privsec.dev/posts/android/banking-applications-compa...
This is linked to from the Banking Apps section on GrapheneOS docs: https://grapheneos.org/usage#banking-apps
Sample size of 1: my UK banking apps all work fine.
I've had less issues than with CalyxOS for example, where more apps broke.
https://grapheneos.org/articles/attestation-compatibility-gu...
https://privsec.dev/posts/android/banking-applications-compa...
Also, people looking at GrapheneOS want technical excellence, so better not rush it :-).
Oh the irony.
I prefer to use intermediaries like Kagi Assistant, thanks to the strict privacy conditions of the API and the mixing of queries from thousands of users.
> It’s thanks to them that we even have the option of at least partially freeing ourselves from Google (Android) and Apple (iOS)
partially. And I do think they successfully did this. Asking Gemini questions when you really have something to ask is very different from integrating your whole digital life with Google.
But of course that's entirely up to how their algorithm happens to feel about you.
(Also it is possible to do these things if you root your phone, but caries its own risks and I wouldn't recommend. Ending your dependency on third party processors is probably the best outcome)
For the end user, breaking free from Google means exiting from Google’s services surveillance system wherever possible. It doesn’t mean complete elimination of the use of source code written by Google employees.
GrapheneOS is really the most private option of all viable daily drivable smartphone operating systems available, because your only other options generally involve Apple and Google services dependency.
You can use GrapheneOS and never send any user information to Google, that’s how you “break free.”
Do you know if it's the same for Fairphone or Shiftphone? Or is there another manufacturer that doesn't require this?
I've recently bought a new phone so it's not relevant for me anymore but when I next go looking, it can factor into it. As it was, I had Google marked in my spreadsheet as the most accessible unlock method together with brands like Oneplus and Fairphone
I could not get a replacement as I bought the phone in a foreign country (Google doesn’t sell Pixels here in Brazil).
So as much as I love the idea of running a more private phone, I found the hardware extremely fragile and poorly designed, so I will not buy from them again anytime soon.
This sounds like your phone may have been one of the Pixel 6a models with a defective battery[1]. It was a major problem for which Google pushed out an update that nerfed the battery life. There is a tool online where you can check if your particular 6a was one with a battery from the bad production batch[2].
But that unfortunately doesn't help if you are in Brazil where, as you say, Pixels aren't officially sold and import/export controls tend to make tech warranties useless in practice.
[1] https://www.lifewire.com/pixel-6a-battery-overheating-warnin...
[2] https://support.google.com/pixelphone/answer/16340779?hl=en
The flag ship should not be more than $500
Which is (almost) the case during sales. The P10 was on sale for $599 not long ago, and you could buy a 9a for little more than $300. That is extremely good value compared to any iThing repoted your every move to Apple.
My initial assumption was "this is gonna look like a typical OSS product, and not as polished as iOS or Android". A single screenshot would have dispelled that notion.
You don't need a Google account to use YouTube and can use it via the browser, NewPipe or several other alternatives rather than their app.
The linked article covers someone's first experience with it with a lot of detail. They're using it as their daily driver with mainly open source apps and separate profiles with mainstream apps they still need. They're using those with much better privacy protections including having sandboxed Google Play in those profiles for using mainstream apps rather than regular highly privileged Google Play heavily integrated into the OS and not running with the standard app sandbox or privileges.
Privacy is more a dream than a real thing.
https://grapheneos.org/faq#future-devices
8th, 9th and 10th gen Pixels provide our full set of requirements with 7 years of support from launch. 6th and 7th gen Pixels are missing the ARMv9 security features including the extremely important hardware memory tagging (MTE) feature we heavily use to protect against exploitation. Even the first devices we supported back in 2014 including the Nexus 5 had isolation for the cellular radio but similar isolation for Wi-Fi/Bluetooth started with the Nexus 5X.
Sounds like we can't actually breaking free from Android and iOS. Maybe with Linux like the Fedora Atomic for mobile devices? https://github.com/pocketblue/pocketblue Or PostmarketOS? https://postmarketos.org/
Even then banking would probably only work through the browser... Sad state of the world really.
And no tap to pay.
Hopefully the new EU banking system will work on Graphene and Ill switch back
I must also be getting old, because I don't get the big fuss about NFC payments. Firstly, I'd never use them if they go through Google/Apple. But even when/if they don't, it's not a big deal to use a card, isn't it (if you hate cash)?
> But even when/if they don't, it's not a big deal to use a card, isn't it (if you hate cash)?
Card is usually linked to the US. Some people would like to not depend on that. But the rational solution IMO is for the banking system to use QR codes instead of NFC. Some countries do that and it just works.
You have a point, and even though it looks like it will be a very corporate-driven system, and possibly dependent on Google or Apple, there seems to be an EU payment system on the making (if it ends up depending on Google or Apple, that will be the irony of leaving VISA/Mastercard to fall in the fangs of Google / Apple, but... oh well, one step at a time).
I think the name is Wero, it was on HN a few days ago.
Where do you get that number from? All the banking apps I've tried work on GrapheneOS.
> And no tap to pay.
There are countries where the payment terminals show QR codes, and banking apps work by scanning it. No need for NFC :-).
> I'm not sure it's really breaking free when the first task to do is intall Google Play Services so your banking app works.
sandboxed Google Play Services. It's an important difference.
If you want to be a certified Android system (like all Android manufacturers do), you have to port AOSP to your hardware, install the Play Services as a system app (giving Google root access), install the system apps you want (e.g. Samsung have their own UI, maybe their own camera, their own store that they want to be installed as system apps), pass some conformity tests by Google (Google wants to ensure that it's good enough to be called "Android") and pay a ton of money to Google for the licence.
But as an individual, you can just download the AOSP sources, build them and install them on your phone. It's AOSP, but not Android.
GrapheneOS is based on AOSP. /e/OS is based on LineageOS which is based on AOSP. Those are not Android systems, they are AOSP-based systems. In a way like Linux Mint is based on Ubuntu which is based on Debian. Those are different layers. If you hate Canonical, it doesn't mean that you have to hate Debian, even though Canonical does contribute to software that runs in Debian (like the Linux kernel). The comparison is worth what it's worth, but I hope you get my point :-).
To quote Google's documentation:
> To build an Android-compatible mobile device, follow this three-step process: > 1. Using AOSP, implement Android on your device. > 2. Ensure your device complies with the Android Compatibility Definition Document. The CDD enumerates the software and hardware requirements for an Android-compatible device. > 3. Pass the Compatibility Test Suite (CTS). Use the CTS as an ongoing aid to evaluate compatibility during the development process.
AOSP is how Android is being distributed. Being "Android-compatible" (implementing Android and passing CTS) does not automatically give you access to Google Play, it just unlocks the possibility of licensing it:
> After achieving compatibility, your device is considered Android compatible and you can consider Licensing Google Mobile Services (GMS) and prepare to use the Android trademark.
Google restricts the use of "Android" trademark on hardware, packaging or marketing materials of devices and requires prior approval of any use, but that doesn't make AOSP "not Android". If you insist otherwise, you're going against common use of these terms.
In fact, not just "common use", but even Google's use - AOSP's homepage has this as its headline:
> Android is an open source software stack created for a wide array of devices with different form factors.
It also tells you how to "get the Android source" or "build the Android OS".
Sure, many apps that are being called "Android apps" are in fact apps for the Google Play platform (perhaps that's where you got your confusion from), but that doesn't make Android-based systems non-Android.
Now when someone says "Break free from Android... by installing Android?", either they are having fun by using the two different meanings in the same sentence, or they are confused and genuinely believe that using GrapheneOS does not allow you to break free from the system running on a device that can legally be advertised using the Android trademark.
To that, I answer that GrapheneOS is not a system that can legally be advertised using the Android trademark, but rather a system that is based on what is commonly (and can legally be) called AOSP, which is made of the open source codebase that builds the system that can legally be advertised as Android.
Similarly, in a discussion about kernels, Android is a Linux system, but in a discussion about OSes, Android is not a Linux system. If I write an article about "breaking free from Linux by using Android", where the context makes it exceedingly clear that I'm talking about Linux as an OS and not Linux as a kernel, and you say "it makes no sense, you're talking about breaking free from Linux by installing... Linux", then I think you're confused. As in: you did not understand what the article was talking about.
I'm not a photographer or anything, I just want to quickly point and shoot and get on with whatever I'm doing without thinking too hard.
https://inteltechniques.com/blog/2026/01/05/grapheneos-2026-...
Recall using one years ago on my Samsung device with happy results. That was long before banking apps etc. Wondering what's the difference with this? Extra security?
Step 1: Buy a Google phone
Currently have an iPhone 16 pro, and probably my next phone will be something like this.
I need to be able to share photos easily with my wife, typically I’ve been using airdrop.
GrapheneOS supports Android's Quick Share, which (on the Pixel 10 family) is compatible with AirDrop [2].
[1] https://grapheneos.org/faq#supported-devices
[2] https://blog.google/products-and-platforms/platforms/android...
[1] https://grapheneos.social/@GrapheneOS/115987006592879172
But yeah, same binary blob issues for firmwares, but Linux on Mobile has the same issues.
Which ones? I'm pretty sure that being "Android" means that you are certified by Google. You cannot sell an Android device if it's not certified by Google.
> It's become sort of a GNU/Linux kind of distinction where the "certified" Android is AOSP + Google
It depends on the context. If someone asks you "are you using Windows or Linux?", answering "I'm using GNU/Linux" is a way to show that you are that kind of people. But if someone asks you what userland you are using, then suddenly it makes sense to make a distinction between GNU and, say, busybox.
When someone asks me if I have and iPhone or Android, I say Android (even though I am running GrapheneOS). But when we're talking specifically about an alternative to Android that builds upon AOSP, then I think it makes sense to make a distinction. There is a whole (niche) market of AOSP-based alternatives to Android, that users choose specifically because they are not Android. When we talk about that, it makes sense to use the right words.
I feel the frustration should be targeted at OEMs that don't meet very reasonable requirements like minimum 5 years of monthly (timely) security updates.
It's not frustration, just disapproval.
> but it wouldn't be right to say they 'restrict themselves to Pixels'.
It's absolutely right to say that. You justify why in your next sentence.
> They believe strongly in a standard for privacy/security of people's personal devices, and unfortunately only Pixels are close to meeting those standards.
That doesn't prohibit them from releasing a version that runs on other phones, even if it's missing a few (and it would only be very few) features. Most of the graphene users are not using it because of those features.
> I feel the frustration should be targeted at OEMs that don't meet very reasonable requirements like minimum 5 years of monthly (timely) security updates.
Again, though, no frustration; I wouldn't run graphene even if I could as I have my own setup I'm quite happy with. Just disapproval at an arbitrarily high standard that isn't doing the good they think it is, and ultimately, actually does more harm in not making their product accessible to the hundreds of thousands of people it would benefit.
Whether or not that defeats the purpose is an exercise left to the reader.
For now I consider smartphones as disposable toys that can't be trusted with anything sensitive and use a computer for privacy.
I also don't like the idea of running Android, I still hope for a real linux phone at some point.
Also, they are working with a partner to get their own phone hardware, hopefully by next year.
That statement might not have aged so well, especially consindering googles attempt to lock out apps from their devices, If the developers do not comply with being oficially registered.
The fact that the play store is not exactly known for exceptionally high standards w.r.t. malware, or that there are lots of valid concerns that come along with a company controlling who is allowed to supply apps for the device is a different topic.
However I haven't seen anybody try
In this case, reader mode fixes it (your browser probably has a button built in)
If you're based on AOSP, the project is still 100% reliant on Google!
It seems extremely cynical to me to depend on the work of a thousand-man team to build your OS, then patch out a couple of lines and claim you've broken free from them. Without Google, none of this project could exist.
All supported devices are exclusively Pixels.
And I couldn't easily find a link to a page that summarised GrapheneOS with some images so I could see how polished it looked.
This is one of the reasons why OSS fails to gain mainstream appeal (as much as I want it to)
There are many useful videos about GrapheneOS here:
https://www.youtube.com/@sideofburritos/videos
Any of the videos older than December 2025 will be prior to Android 16 QPR2 so the overall UI will be outdated. That's part of why we don't focus on screenshots or videos because many would need to get updated every 4 months. We'd mainly be using them for our own features which often improve more frequently than that.
First things, first, kudos to the GrapheneOS team for making it this easy to install and the surprisingly rapid support for new devices. Sure, there are features which I otherwise liked in the stock android that came with Pixel phones(swipe typing is something I very much enjoyed) but all in all, I can't say I miss much from it otherwise. I've slimmed down my list of apps to basic functionalities backed by self-hosted services (nextcloud, immich, jellifin, etc. along with a VPN I maintain myself) and I honestly don't miss much from the stock Android.
I want to point out that for a very long time I worked for a company that developed games for mobile devices and while the data we collected was mostly anonymous(*unless you logged in with facebook and by implications we had your facebook id) and it was never even utilized all that much beyond bad attempts at maximizing sales(not effectively anyway cause the people in charge were as incompetent as they could get), I can say that we collected ungodly amounts of data: most of the cloud bills were storage for that specific reason. While we did not have bad intentions and had to operate under strict GDPR regulations, this was a large company that was constantly monitored. Small companies can fly under the radar and get away with not abiding by the rules and laws and commonly they are not even aware what the repercussions could be. Similarly, the US and Asia-based giants can simply shrug it off and toss a few billions in fines. Make no mistake, no company is looking for your best interest and with that in mind, I couldn't recommend GrapheneOS (and self-hosting everything) enough, assuming you know what you are doing.
GrapheneOS team, I'm begging you... Hire or recruit one person with advertising or copy-for-public-consumption experience. Just one.
Saving a click, it looks like any bare Android without vendor customisations. You just get extra settings like turning off network per app
I don't disagree that some screenshots might be good marketing
Look, it's better than stock android overall, UI much more simplified even though it gives you a lot more security control, battery feels slightly longer, but there are drawbacks, i.e. twitter/x wouldn't install, neither would my bank's app. However from time to time I go to use iOS on the iphone and it just feels like better software, with better ergonomics overall, the combination of the xnu kernel plus the design and feel of the..buttons.. on iOS is still years ahead in my opinion. So keep that in mind if you're switching away from apple to it, as android still feels like decade plus old software.
Now for the upsides.. there's a built in terminal and debian vm you can install and run your agentic AI tools (claude code,opencode etc) in a portable sandboxed environment which you just don't get onios. You can even fire up a graphical xfce session albeit that takes quite a bit of work to get it to go.
As for the tablet form factor of the phone itself when unfolded, i found it amazing the first few weeks and then later found myself rarely using it.
Overall I'm going to stick with itand will never go back to stock android, but am quite annoyed at how much better it could actually be.
GrapheneOS has a partnership with one of the largest Android OEMs. They're going to be announcing it in March 2026. Devices meeting all of the update and security requirements from them with official GrapheneOS support are planned for 2027. We don't expect future Pixels to prevent installing GrapheneOS but we'll be fine if they do. We'd still like to keep supporting new Pixels but they'll become a secondary option in the future since there will be devices with official support.
the OS is great, but too risky in certain situations.
I'm not aware of any that bans you when not using an allowlisted OS, so maybe it was something else that caused this shadowban, or (more likely) that's just my bubble
“It’s perfect. I love it. It works great. No complaints” and then go on to list 100 rough edges that mainstream phone OS users never have any issues with. It’s funny.
The biggest problem with security culture is its obsessive hyperfocus on security. Any change that could possibly be less secure (even in extremely exclusive circumstances) must be wrong. Even if it improves accessibility, it must be rejected out of hand.
GrapheneOS promises to liberate us from the enshittification of Google's anticompetitive moat; but it focuses that effort exclusively on security. Everything else that was enshittified gets carefully preserved as-is in the name of "security".
All I want is a mobile computer that does what I tell it to. Why is that constantly treated as an unreasonable fantasy?
Full control over app permissions
GrapheneOS allows for full control over what permissions each application can have.
For example, in conventional Android forks, every application by default has granted
Network (internet access) and Sensors [...] permissions.
Has anyone ever wondered if all apps on a phone need Internet access?
They subsidize Pixel hardware (to incentivize users to adopt their spyware OS), you (buying used obviously) take their subsidized hardware and do not repay them by using their spyware, replacing it with Graphene. Only google loses. Their hardware is technically very good otherwise (in fact no other hardware fits the strict graphene security requirements).