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!
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.
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.
Unfortunately, the rot runs too deep.
Pick up the can!
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.
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.
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.
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.
(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.
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.
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.
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.)
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.
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.
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.
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.
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
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
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.
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.
Can you record phone calls? Do third party voice recorders continue recording even when the screen is locked? Thank you!
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 AppI'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.
Aegis - 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.
Although I would like speed limits shown in MPH in the UK, OrganicMaps' KMH limits were useful on the Continent.
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
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.
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.)
(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.
My Librem 5 running PureOS also supports external storage just fine.
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.
Does this require installing google play and other google services to work?
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...
> 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.
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
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.
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?
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.
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).
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.
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.
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...
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.
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.
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]?
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
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.
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.
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).
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.
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.
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
Privacy is more a dream than a real thing.
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.
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.
So it would follow that a valid privacy-respecting third option would potentially help Apple customers as well as Google customers.
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.
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.
- 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.
/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)
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.
I would suggest having a look at CoMaps, a recent fork of OrganicMaps :-).
/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.
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?!
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
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.
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.
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.
https://eylenburg.github.io/android_comparison.htm
In short, GrapheneOS is vastly superior.
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.
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.
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...
Are there valid reasons to only support 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.
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...
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.
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.
The flag ship should not be more than $500
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.”
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.
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)
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.
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?
https://inteltechniques.com/blog/2026/01/05/grapheneos-2026-...
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.
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
Step 1: Buy a Google phone
All supported devices are exclusively Pixels.
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.
Whether or not that defeats the purpose is an exercise left to the reader.
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
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)
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.
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.
GrapheneOS team, I'm begging you... Hire or recruit one person with advertising or copy-for-public-consumption experience. Just one.
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.
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.
the OS is great, but too risky in certain situations.
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).