Been using this for about a year on a p9 pro. It works very well. I hear the google tap to pay does not work, but I've never tried it. However Vipps with their tap to pay works fine. BankID works but not with biometric login, which some things require IIRC. And for some reason DnB private works fine, but you are not allowed in on the corp app.
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!
A collegue of mine was tech lead at a large online bank. For the mobile app, the first and foremost threat that security auditors would find was "The app runs on a rooted phone!!!". Security theater at its finest, checkboxes gotta be checked. The irony is that the devs were using rooted phones for QA and debugging.
Meanwhile, it's probably A-OK for the app to run on a phone that hasn't received security updates for 5 years.
I don't get it. If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?
I'm guessing it's because there are a lot of phones floating around that aren't updated (probably far more than are rooted), and they're willing to pretend to be secure when it impacts a small number of users but not willing to pretend to be secure when it impacts many users.
Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years. For example, a malicious OS maker could add their own certificate to the root store, essentially allowing them to MitM all the traffic you send to the bank.
Liability works on the principle that "if it's good enough for Google, it's good enough for me." A bank cannot realistically vet every vendor, so they rely on the OS maker to do the heavy lifting.
Even if they wanted to trust a third-party OS, they would need to review them on a case-by-case basis. A hobbyist OS compiled by a random volunteer would almost certainly be rejected.
I can add certificates on my unrooted android. That how HTTPToolkit [0] works, it only requires adb, which (thankfully) doesn't trip banking apps. Banking apps can (and do iirc) pin certificates, so a rooted phone adds no risk whatsoever.
Also in my experience a rooted phone experience is by far more secure than the OEM androids. Security is supposed to assess risk objectively, yet "running on a Xiaomi phone with 3rd party apps that cannot be uninstalled and have system access" is somehow more secure than "running on a signed LineageOS where user can edit hosts file".
>Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years.
That's just straight-up false ; the phone without security updates has known exploits its user knows nothing about (and certainly not how to avoid them). The phone with an unknown OS has a user capable of installing said OS, at the very least.
> Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years.
I'm not convinced this is generally true, at least as can be detected by an app. Back when I had my phone rooted, it was configured so that it would pass all the Google checks and look like the stock OS. That configuration was probably dangerous, but apps were happy with it. Now that I run an OS that doesn't lie about what it is, I'm flagged as untrustworthy. What's the point in being honest?
Overall, I don't think they really have any idea what's a threat based on the checks they're doing, so I don't think they can say at all what's more or less trustworthy. But I think that a phone that reports being years out of date should reasonably not be expected to be secure, but yet they mark it as secure anyway. Many of those devices can be rooted in a way that can still pass their checks. I would think, if nothing else, that would be reason to block them, since they're interested in blocking rooted devices.
> If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?
Google doesn't provide an API or data set to figure out what the current security patch level is for any particular device. Officially, OEMs can now be 4 months out-of-date, and user updates lag behind that.
Your guess is good, but misses the point. Banks are worried about a couple things with mobile clients: credential stealing and application spoofing. As a consequence, the banks want to ensure that the thing connecting to their client API is an unmodified first-party application. The only way to accomplish this with any sort of confidence is to use hardware attestation, which requires a secure chain-of-trust from the hardware TEE/TPM, to the bootloader, to the system OS, and finally to your application.
So you need a way for security people working for banks to feel confident that it's the bank's code which is operating on the user's behalf to do things like transfer money. They care less about exploits for unsupported devices, and it's inconvenient to users if they can't make payments from their five-year-old device.
And this is why Web Environment Integrity and friends should never be allowed to exist, because Android is the perfect cautionary tale of what banks will do with trusted-computing features: which is, the laziest possible thing that technically works, and keeps their support phone lines open.
I'm not an Android developer, but I was thinking they could use something like the android.os.Build.VERSION.SECURITY_PATCH call to get the security patch level. Maybe that's not sufficient for that purpose, though.
Sure, there is enough information available to the app to determine what OS version and patch level it is running under. The issue is, the app would need to communicate this to the bank via an API, and the bank wants to trust the app in the first place in order to rely on this information.
Even then, two things turn out to be true:
- Banks don't actually want to put in the effort and deal with angry customers with slightly-out-of-date devices.
- All the credential-stealing malware on Android works perfectly fine on stock, unmodified, non-rooted OS images anyway. They just need to socially-engineer the user to grant accessibility permissions to the malicious app.
It's more frustrating because my partner's pixel 4A cannot use google pay or the bank apps because it is an invalid os - I am guessing due to lack of updates? So, perfectly fine hardware, but crippled in functionality due to the lack of software updates.
ive seen:
-"but ios can be jailbroken and it doesnt have an AV!" while the MDM does not allow jailbroken devices, and they also allowed sudo on linux.
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.
Yep, some stakeholder wants a pen-test or an audit so you do it and address the findings to keep them happy. Going through it now at work - bunch of silly findings because the pen testers know they don't get paid to send back an empty report and tell you everything is fine.
As long as copying some numbers, printed on a piece of plastic, into an online order form is all the authentication that is needed for a transaction, anything more than that is inherently security theater.
That’s why for most transactions I do with a credit card in my country, you need an extra validation with the mobile app. It is mostly American websites that do not enable this functionality.
Yes, because we don't want these stupid locked down apps. Credit cards give buyers many protections, it's very easy to dispute an illegitimate transaction.
The consumer does not typically pay this directly. It may be passed onto the consumer indirectly through higher prices, but those apply to anyone regardless of payment method. On the contrary, I get cash back on purchases and other rewards.
Because we have anti-fraud consumer potection rules and CCs operate on a make money first type of bais. The debit networks on the otherhand are a different story.
Yeah that's the first thing a pentest will complain about, had the same problem too. I pushed back enough so that it's trivial to bypass but the bank and pentesters also agreed with me that it's security theater or else I would never had the chance.
I always ask them if they have root/admin on their computer. Then follow up playing dumb with "shouldn't we lock out PCs too?". Watching them stammer is worth the 30 second aside.
Who do we lobby to get this removed from the auditors checklists? This is a solvable problem but it’s political. And if we don’t solve it personal computing is at risk.
Start by calling (or visiting the area office of) your senator and congressman. If you are reasonably articulate, they engage and listen. Doesn't matter if the listener is not a techie; they will ask questions around policy and why it affects constituents.
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.
From my experience with the fed level senator.. they're already lobbied to shit. For example, explaining to Duckworth that fed level id tying to your internet travel and encryption backdoors aren't safe.. they'll send you copy that she really wants you to know she's thinking about the children while rolling around in her wheelchair.
A lot of that is security theater at its best. However given the forced attack surface I would imagine that there is a hard push from authoritarians and the finance world to make a "secure chain" from service to screen.
My guess: They're afraid that the scammers are going to mirror the screen and remote control access to the app. (More orgs are moving to app/phone based assumptions because it saves the org money and pushes cost on the consumer) Instead of providing protections from account take over.. we're going to get devices we don't own and we have to to pay for, maintain and pay for services to get a terminal to your own bank account. Additionally, there are many dictatorships, like the UK, North Korea, etc, that are very adimate that you don't look at things without their permission. So they're trying to close the gap of avoiding age verification bypasses with VPNs.
Moreso, the project advises against rooting your phone and tells you that if you install GrapheneOS and root it that you aren't running GrapheneOS anymore.
Yep that's my experience as well, if you don't get the play protect™ absolution your device is seen as rooted. Latest app to display this BS behavior was PagerDuty, I guess they have to protect their secret sauce of calling an API and showing notifications
I know some people have issues with Duo, I don't, with pager duty i _just_ installed th last version from Play store, logged in with sso to my org and I'm in, can do or see everything.
Maybe it's play services in your case, not play integrity? I'm on the last release from the stable channel.
My favorite is when it must have punctuation, but certain punctuation is silently banned, so I have to keep refreshing my password generator until it gives me an acceptable combination.
I came across a "special character" requirement while creating an account. The client validation was not the same as the server validation. The client proceeded as if my account was created, but it never was. The client functioned without an account until it was closed. I asked the creator what their app's problem was, why did I need to keep resetting my password, then be told that I don't have an account, and have to create it anew.
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.
Sometimes when that happens, and any of `:({ |&;` are on the no-no list, I try bypassing the client validations and setting my password to a shell fork bomb. So far as I'm aware it hasn't broken anything yet, but I'm determined to keep trying.
Somewhat unrelated, is there any technical reason certain punctuation might be banned? I can understand maybe not allowing letters with diacritics or other NON-ASCII chars but why would a system reject an @ sign or bracket > for example?
Depending on the protocol they can be url encoded or even helpfully html encoded; the same password can be used over different protocols. It's the best to not use punctuation by default (length supplies more entropy than charset), I add -0 at the end to make dumb password policies happy.
Sorry I'm a bit lost here. Are you saying requiring a special character and a number are dumb password policies? Wouldn't charset AND length make for exponentially higher entropy? 52 (or 62 for digits) to the length power vs (62+20 special chars) to the length power? Or am I missing something?
I guess what they're saying is that, for example, a password of length 12 has about 71 bits of entropy if using an alphabet of 62 characters, and 76 bits with an alphabet of 82 characters. But if you only increase the length by 1 you already get 77 bits with 62 characters only. So length beats adding special chars in that sense.
Gotcha, I guess my question is, why not both? Is it the requirement of special chars over a min-length password that is in question here? Like the system is like "minimum 8 char password but also three special chars, ancient heiroglyphs, and the blood of your firstborn child" when you can omit the special chars and just have min 16 char password for the same security benefit?
This is true, but I think the argument is that for maintainers of the system, it's more work to allow more char options when it (should be) more trivial to change MAX_PASS_LENGTH from 12 to 32. Like, if you're gonna add more restrictions, make it the ones that encourage, not block, more secure passwords.
A lot of the restricted stuff is cargo-cult fear of symbols that could be used in SQL-injection or XSS attacks.
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.
Having more than just alphanumeric characters widens the domain of the password hash function, and this directly increases the difficulty of brute-force cracking. But having a such a small maximum password length is... puzzling, to say the least. I would accept passwords of up to 1 KiB in length.
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.
It's easier for me to remember really long passphrases than even short alphanumeric strings - small maximum password lengths set my teeth on edge. The passwords should be getting hashed anyway right?
The problem is that you never really know what a website operator does with your credentials. Ideally, you have both a unique email and a unique password for each site, because sadly credential stuffing [1] is a thing.
I recommend all my friends and family to use a password manager like Bitwarden, and if they can't do that for some reason, at least use a 3-word passphrase separated by a hyphen.
The amount of times people have complained to me that this doesn't work because of low max-chars on passwords is insane.
I regularly conduct transactions at the branch of my local bank wherein they ask me for no credentials whatsoever. I also once forgot to bring my account number with me and the teller said "no worries, I'll look it up for you." Kind of horrifying.
That's scary. I wonder if incompetence like that could lead to a lawsuit in the case of a breach.
At this point I wouldn't be surprised if there exists a system that just asks for username with a checkbox "check here if you are the owner of this account"
Until the late 2010s, the AD account password at my financial institution employer was capped at 12 characters because, for a subset of workers, AD creds were sync'ed to a mainframe application that could only support that many characters.
Sounds about right. One of Australia's big four banks had the online banking password requirement of exactly six characters for a long time - for similar reasons I assume.
I think we (whoever we is) should start normalizing the concept of passphrases; on sign-up screens they should show the benefits of a passphrase. I'm surprised that Googles PW generator does not use passphrases, and I don't know about ios because I haven't tried theirs yet.
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.
Haha having such a low range of max chars just makes it that much easier to brute force doesn't it?
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.
Maximum lengths like this are like a big neon sign that says:
"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.
I'm pretty sure it's referencing Half-Life 2, where an agent of an oppressive regime tells you to pick up a can that they just dropped on the floor as a sadistic display of authority (and to provide world-building and teach the grab mechanics to the player).
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.
> The GP is equating policies for strong passwords that aren't trivially cracked with authoritarianism.
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.
> 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...
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.
This should be illegal that the government forces people into apps controlled by private, commercial entities. I call such a government corrupt.
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.
Or how about schools requiring parents to use WhatsApp to receive updates and information? Luckily my ex forwards to me the important stuff, but not everyone is as lucky to have an ex like mine ))
If the government (or school) is going to require us to have a smartphone in order to access critical government information, then we should demand that the government provide us with a compatible smartphone.
If your employer required the use of a smartphone for essential components of your job and provided you with a smartphone and cellular data plan, would you not use that smartphone for those components of your job?
I'd not use employer- or government-furnished equipment for tasks that the equipment wasn't provided to complete, but I'd definitely use it for those tasks.
Exactly. Bank needs me to have an official FruitPhone to access my account? Fine, send me the phone, I'll turn it on when I need to bank, and at all other times it sits powered-off in a drawer. Same for the government-supplied DroidPhone I need to access my Social Security statements (or whatever). Turn on, do my business, turn off.
Would this apply to giving you a phone plan, internet plan, computer, paper, pen, electricity, etc., because all of those are necessary to do online banking or access school chats as well?
Forget exes—-how about current partners! I predict with high confidence that my wife’s response to such a request would be “grow up and install WhatsApp already.”
Even the EU initiative Wero requires Google or Apple. You can't even use it on a desktop pc and you're not even allowed to have developer options on. Ridiculous. I've never seen any app that is so strict.
That's not exactly right, Wero the app is not Wero the payment system. Banks and payment processors are expected to integrate Wero the same way they do with iDeal and similar systems. So ultimately if your bank's app doesn't require attestation you will be able to use Wero through it.
Weird, because Wero is an internationalization of the dutch iDeal and that worked fine without any apps. You clicked ‘continue to bank’, select your bank, and then login on the bank web portal.
American here who values individual liberties greatly. I know things are politically tense at the moment, but I’m not sure I understand this popular contemporary sentiment.
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.
I don't think this is about the current situation in the US.
Big US tech companies are infamous for not following the EU's data protection rules, and they wouldn't even able to, because some US regulations (I think PRISM, FISA and others) are incompatible with the requirements of EU GDPR.
This dates back at lest to Snowden leaks and the invalidation of EU-US data protection agreements by Schrems judgments.
I switched bank in the UK due to enforced app use, from Starling to Nationwide. They use a card reader to issue codes, so I can still use the web. I see this as a much of a must-have as physical bank branches with real cashier services.
Might be able to file a complaint with the financial services that they're charging you hidden fees to access and manage your money.. (the requirement of having a working mobile, phone, service, etc)
My bank still supports TAN codes with a device too. Unfortunately, once it breaks or the battery goes dead you cannot get a new one and have to use their app. Fortunately, their app works on GrapheneOS without issues.
Where is the government forcing you here? Does Spain have regulation that obliges the use of apps for banking for certain functionality and disallows websites? Or what are you talking about?
> Not in Spain. I can access my bank's website but I can't do anything without their bank app.
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.
In Estonia you can easily do banking via the website on all the banks (LHV, Swedbank, SEB). That said, we do have it all integrated with our digital-ID (which every ID card has private keys encoded into with a PIN you know) so it's not like you can access it with a simple password (our online voting works the same way).
Voting, much like all other things in Estonia such as getting married/divorced, doing taxes, signing documents, starting/closing companies, notary dealings, bank dealings, selling/buying vehicles, and many more things I can't even think of right now are entirely done via the digital ID that every citizen has. This means that you authorize/sign actions with it, including voting, because only you have your private keys (either in your personal ID card, in your phone's sim card, etc) that you yourself know the PIN for, which then authenticates you as being you. I think we're now at a point where there isn't a single government or business dealing you can not do entirely online (https://e-estonia.com/solutions/).
Phones and sim cards a lot more temporary than ID cards. I don't know of a lot of theves that target ID cards for their authorization uses. Phones... people will steal those.
You can close your Mobile-ID when your phone gets stolen so the security keys on it will be useless, and even if you don't close it, nobody can use your security keys without your PIN, which is in your head.
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.
Wow, that is definitely more sophisticated than we have in the states. It seems like you can use it for things that one would otherwise need a notary for, that is such a timesaver.
It costs as much as your ID card costs by the government, and lasts as long as well. They are one and the same. Applying for a new ID card / national ID document in Estonia costs 35€ and the document is valid for 5 years. If you forget your PIN code, you can reset it with your PUK codes, but if you also lose your PUK codes you need to apply for a new ID card. The process for getting a new ID card from the moment you applied for it takes no more than 30 days. You can also have it fast tracked for 250€ and get it in 2 days.
But, like the parent said, you have many other options other than the physical ID-card as well. Most people these days use Mobiil-ID or SmartID, which works on your phone and even smart watch. SmartID is completely free and Mobiil-ID is tied to your phones carrier, so the cost varies, but it's a one-time set-up fee of around 5€. Mobiil-ID certificate also lasts 5 years.
(When will people learn that biometrics are not another factor: they're entirely public and irrevocable. It's not just security theater, but Apple & Google know that this forces you into their ecosystem, which should be illegal. Of course, Brussels is full of rubes anyway.)
The question is what generated that TOTP code. The banks must ensure that they "are independent, in that the breach of one does not compromise the reliability of the others," as article 4(30) states. That text is vague as hell, but published opinion of the European Banking Authority on the matter[0] is:
"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.
Some UK banks (Nationwide and Barclays I know for certain) have had mini card-reader PIN devices since around 2010 that they've given customers, that basically generate on an LCD screen an 8-digit code for authentication.
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.
Moved from the UK to Germany. My German card reader is even better, no manually entering the transaction details, I just scan a QR code from my laptop, and the card reader display shows the IBAN and amounts, before I confirm to get the code.
> And in practise that means a banking app, because most people do not want a separate token they have to buy and can lose.
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.
Probably not for much longer though. Several countries, including mine, have already banned SMS 2FA for banking, and it's likely that that will be implemented for all of Europe in the near future, possibly with PSD3. Not that SMS 2FA was ever a good idea in the first place.
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.
I don't know which banks you are using but in my case I work with five Spanish banks and I can do everything from their websites, no app required. Yes, they try to push you to use their app, some tried to activate mobile 2fa for me when this psd2 thing became mandatory but I always told them their app doesn't work on my phone (which is true) and they offered me alternate methods like sms.
In my country we have a large religious population who eschew the smartphone. This means that no government, banking, or other services require a smartphone.
> Can you access their websites without the need to confirm 'who you are' with their app?
Yes, none of them required me to use the app a single time. In fact, for all the banks I work with, I always identified myself at a local office when opening the account for the first time, the last one less than a year ago. And all of them allow me to operate in the website without the need of an app (actually I could never use any banking app as my telephone lacks Google Play).
> 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 been using GrapheneOS for a few months in Spain with and out of three banking apps only one gave me trouble, I had to enable "Exploit Protection Compatibility Mode" on "app information". Personally I refuse to pay with the phone so I am okay not having that option.
If someone wants to try Graphene os maybe that option will work on their banks too.
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'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.
> They do it so they don't have to stand up their own push servers
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.
My comment was about push service sharing generally, not banks, from a technical point of view that many people aren't aware of but may find interesting.
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.
I'm on Android, and SMS notifications look exactly like every other notification (with one caveat I'll mention below), so I don't know what this guy is on about.
> ...SMSs are just push notificatons with a worse UI...
By this, does OP mean that shit where programs can put buttons and bigass images into their notifications? If yes, I don't want that shit. That's just more opportunity to accidentally trigger unwanted behavior with one's fat fingers, and more screen space gobbled up by overly-self-important software.
The thing that's shitty about SMS is that it's "worst^Wbest effort" delivery... which means that messages can (and will) get delivered late, out of order, or never. Don't use SMS; use email. Email is also best-effort, but -based on my personal experience- far more email server operators give a shit about delivering your messages than SMS relay operators.
That is clearly not the opinon of the product owners and business people. They believe that they own your device, data, and location of when you use it and how you use it. If they want to tell you about their new terrible financial product they will try to force it on you.
I thought this was what Larry meant when he said surveillance will keep citizens on their best behavior. If one’s reputation score is low, sorry no money. Also, if anyone in one’s network has bad behavior, no money and no friends. Maybe the kids will learn to accept it, but being of the last analog generation, to me it seems like a painful future.
As far as I remember, last time I needed to use Google play on a shared phone I could just create a random Google address (I mean, completely invented name, etc.) and it allowed me to do anything, just as my normal Android.
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!)
You can create a Google account without adding a phone number, that's still possible currently.
To do this you need to make it within an app, for example Google Play Store or YouTube, not on the websites. You also need to use a trusted IP, so you shouldn't use a VPN. To avoid handing out your home WiFi IP, you can use a public WiFi point or use cellular which cycles IPs more quickly.
> 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.
At my "traditional" bank I even need the TAN generator for my phone. While at my "neo" bank I even need the phone app to access the website. :-) (That is how the neo bank tricked me. I read "website access" in their ad and thought I could still access the bank account if I lose my phone. But no, you can't login without the app.)
Especially with how things are currently, I whole heartedly agree - you cannot operate as a human being in Europe without having a good standing with either Alphabet or Apple.
Absolute madness or complete nonsense - I have neither an Apple account or device, nor a Google account or mandated device (e/os on Fairphone 3+) and operate perfectly successfully in the UK with (almost [1.]) zero friction.
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.
> Revolut app stopped working so I emptied my account and opened a Wise account
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.
I'd also recommend to slowly migrate to GrapheneOS, getting to know where the boundaries are for specific apps. Once you've got your 'dailies' all up and running predictably, then you're good to go, but it could take a few days depending on how much spare time you have to find said boundaries. Having said that, I turn on most of the higher level security protections, which quite a few apps need exceptions from.
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, the way I explained it was misleading, mainly because the different persona's tend to use different sets of apps. The personas, in general, are:
- Personal
- Work
- Sporting Club Committee
- Testing (kinda persona, for things I'm not sure of yet and don't want jumbled together with one of the other personas)
This is where it may become a pain, but for some people it may be worth it: sub-personas or topic-specific like streaming or finance or torrenting or porn or any other category you can think of if you want to keep certain things behind a boundary in case you need to share your phone (main profile) with friends or family members for whatever reason.
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.
It's not really a requirement of a Pixel device. It just happens to be the case that Pixel devices currently are the only devices meeting the hardware requirements listed in the FAQ: https://grapheneos.org/faq#future-devices. The hardware requirements don't contain exoctic things but non-Google and non-Apple companies until now just fail to deliver on the security front. It's also not that GrapheneOS catered these requirements to fit to Google and Google only. They are actively working with an OEM partner since June 2025 to help them meet the hardeware requirements for a subset of their future devices. So they are even willing to assist companies to meet the requirements if they have the ambition to do so. The OEM is not yet disclosed, the launch of the device will be somewhere in 2027.
I hope and pray that is a Samsung S Ultra device. The built-in stylus transforms the whole user experience, I would not go back to a device that I must swipe my dirty fingers across.
I saw one last week. I can't comment about the stylus (but I'm swiping with my thumb to write this message). I held it in my hands and it's a brick but most phones of the last years are bricks so I expect that they will deliver another nearly 7" 200 grams brick. We used to call them phablets. This is one of the models that defined the category in the early 2010s https://m.gsmarena.com/samsung_galaxy_note_n7000-4135.php
It's almost lightweight nowadays and it's definitely small. I remember that we thought that it was insanely huge when pressed to a ear to talk.
I’ve never seen anyone in real life using the stylus on a Samsung phone so I always figured it was a somewhat unused feature of a very specific niche model in the lineup.
The ultra series MSRP is over $1400, I imagine at that price Samsung sells less than 5% of their volume with an integrated S Pen.
It won't be Fairphone. Fairphone is very far removed from the hardware requirements listed here https://grapheneos.org/faq#future-devices
They don't seme to take security seriously at the moment, so the chance is low they are going to make the huge leap needed to meet the requirements.
Fairphone heavily markets their sustainability but it's very relative. Fairphone doesn't give proper software support. They don't properly keep up with Android updates and also stop giving updates much more quickly than Google (8 years since Pixel 8) and iPhone. Giving proper software support is also part of what makes a device usable for a longer period of time and hence reduces the need to purchases a new device which has an environmental and climate impact. With regards to the hardware longetivity, Google has good repair programs for their Pixels. It's more difficult and less supported to do repairs yourself but it's certainly possible to repair your device.
> when you can just open the thing in a website anyway. I can use my bank on some linux distro
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.)
I was the one that submitted the DNB Bedrift app report to the sec dev repo! I contacted DNB but they never responded to my email. I wonder if we can find a dev? I believe that's how the private app got fixed.
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.
Hah - both were in my browser history, yes I know them :) I misunderstood and thought you had sent direct emails to relevant parties arguing for why they should be allowed on grapheneos.
Oh I also misunderstood! I did send an email to DNB Bedrift customer service about Graphene support, citing the private app fix. They technically gave me a response that it would be looked into, but it felt very handwavy, and that was 3 months ago. It was via the bedrift portal, there is a "Send E-Post" button.
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.
About BankID: There was a regression in the app back in june that broke the app entirely. Back then I emailed the developers complaining about it, and their response indicated that there was no deliberate attempt at breaking BankID on GrapheneOS, and the specific developer who replied to me said he was a fan of the OS.
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.
Fwiw, biometric login works fine for me. You need to install something like DuckDuckGo or Brave and set as default browser during setup. And only Google Password manager works for storing the passkey.
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.
“Installing alternate OSs” is juicy bait for “tech enthusiasts” who know just enough to be effectively worse off than someone with a browser, yes, and at its core is this holier than thou attitude.
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...
Needing to use a verified boot chain with keys that the bank trusts is essentially the same as using the authenticator device from said bank, except this one costs 100€ or more, has a microphone and camera built in, and you use it for private messages as well. That's not a future I want to live in
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
Needing to use a verified boot chain with keys that the bank trusts is essentially the same as using the authenticator device from said bank,
It's not, because even though the authenticator is secure, you are entering the auth codes in a browser in general purpose desktop OS with (if you use Windows or desktop Linux) little to no sandboxing outside the browser. You are one malware app (or NodeJS package for tech users who claim they'll never download malware) for your session getting hijacked.
The sad reality is that phones (and some tablets) are the only relatively secure computing environments that we have. Thanks to Windows with it decades of piled up legacy and Linux with large sandbox and secure boot-hating parts of its community, we cannot have nice things.
(The part about the Linux community, which I'm also part of is a generalization, but the hostility against Flatpak, secure boot, etc. is pretty big.)
That seems wrong. If malware can fake what the authenticator shows me, the authenticator is broken!
That's not what I am saying. The authenticator is irrelavant to this attack. If your machine is compromised by malware, the malware could take over the browser session, regardless of how you log in.
Phones are better protected against persistent malware because every application is sandboxed (harder to escalate) and much more of the boot chain/OS is validated (harder to persist).
The authenticator preserves account integrity with the compromised host attack you describe. The device I have shows something like "you are authorising a transaction of 1337€ to RU07BANK012345678, y/n?". What an attacker can do is read along while I log in, but not modify data
The server generates the challenge that's sent to the authenticator. The attacker can modify and replace it by being in your browser and show any text on your computer screen, but the authenticator will either show the truth, or the approval code it generates doesn't match the server's challenge
> That's not what I am saying. The authenticator is irrelavant to this attack.
If you need to change the security measures (take out the authenticator) in order to be able to mount an attack, maybe that means the security measure is working? xD
Trying to understand your point here. If you're merely saying that phones have better process isolation then I can only agree, but I wasn't saying that it doesn't. You can use online banking on your phone OS if you like, or use Android on your laptop. The comment you replied to upthread said that I'd like to have ownership of and freedom within my own hardware, in order to have privacy. When banks require that my phone is DRM'd with some keys from Google, Samsung, or Apple, then suddenly that has a lot of consequences for what I can and cannot do with, or inspect about, the device. Using an external authenticator, which they can attest to their heart's content, is the solution that I'm using and aligns with all parties' goals. Banks don't need to require that everyone's phone is locked down in order to use the banking software, just like it isn't in the browser, while still meeting their security goals
> 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!
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.
I hope this isn't going to be the case universally. If my bank cuts off my access from my browser-on-linux setup, then I'm finding an alternative bank (hopefully some will always exist), which I don't say lightly since I've been with my current bank since I was old enough to have a bank account.
You'll quickly find out - as people are finding out in EU nowadays - that *no* bank will go through the trouble of fighting checklist security auditors to keep your linuxes working.
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.
Keep complaining to the regulators that you're being locked out of your account. Sue them and keep escalating. Forcing you into a system where you have to pay, maintain, etc for access is often not legal.
My bank has always had hardware attestation, but it was their hardware that was being attested. Customers get it loaned when signing up
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
Yeah, I should have pursued the idea ten years ago of making a usable 2fa hardware device (that confirms what you're authenticating and an attacker can't simply pull auth codes for whatever they want)
Still, I'm plenty okay with my phone as a second factor for my laptop and vice versa for nearly all services. The rest is about tying things to a government identity (bank cares only if it's me who's authorising the transaction; government cares only if it's me who's requesting a student loan) and can be done with the chip that's already in my identity document and a single 20€ nfc chip reader or by using a phone as nfc reader
You're doomed to this issue with old phones in general.
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.
Generally Lineage is the latest. Unfortunately, there are other issues (such as the blobs that Lineage needs drifting out of date, and it's usually suggested that you'll should backup and then wipe to upgrade to the next major release, etc.)
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.
Well, I’ve jinxed it. My current “neobank” of choice, TNG eWallet, is onto me now :(
(Not because of my comment, probably – I’ve upgraded LineageOS and had to reinstall everything. But just in case you guys read this – please, just let me bypass it, I’m aware of the risks :)
I use microsoft authenticator, in its own work profile for work. I also use fingerprint login for Nordea, the Proton Suite, my personal 2fa program. Biometric works great on the Pixel 9A, at least, and it was fine on the 8 Pro when I had it.
The BankID thing is a SW quirk on their end, but generic fingerprint seems works great across the ecosystem.
I personally tend to own two Phones. One all-day carry GrapheneOS device (Pixel 8) and an older WiFi and at home only iPhone for all payment and ensurance stuff.
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 App
* 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/)
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.
Neo Store looks interesting, but the readme in the GitHub repo includes emojis in the feature list, which is a bit of a red flag for me, especially since the project appears to have started only two years ago.
Thanks for the links. I am concerned about supply chain attacks and such with FOSS tools these days. It seems like the easiest attack surface. In my dev opinion it’s not if it’s when. Kinda sucks and I think the adversary is moving faster than the provider. (I have created and maintained public domain software but not currently. Now I’m crapping on the thread sorry. But no one else is sorry for crapping on threads…I need to stop over thinking or maybe just close this tab)
I like Organic Maps because it isn't full of the social things. Every time I open Google Maps it shows that card at the bottom with "what's popular in your area", full of pictures of people's breakfasts and other nonsense. Organic Maps is free of this noise.
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).
All map apps I tested so far were kind of usable but nowhere near Apple or Google maps. Especially for longer trips I often got lost and had to re-navigate by different reasons (voice announcement too late, no lane instructions, etc.).
However, I listed it because it is a "usable" alternative that works offline.
Idk, pedestrian navigation has been pretty decent for me so far. (There’s been one case of it showing a path in Tbilisi that would require me to jump from a 3 m wall, but it was exactly once.) I suppose it depends on which city you’re in and how well mapped it is on the OSM.
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.
I used OrganicMaps for navigation from the UK through France, Germany, Switzerland, back into France and then Spain last year on a 2 week enjoyable camper van trip. It can take a while for routing changes if you ignore it and decide to drive elsewhere, and I don't really use the voice alerts (I just have it on my phone on the dashboard via a magnet), but all in all it worked really well.
Although I would like speed limits shown in MPH in the UK, OrganicMaps' KMH limits were useful on the Continent.
Does anybody know of a project that offers public transport routing? Ideally with real time information, but I can live with only using schedules or even just average passage interval.
The other general sticking point for me is the reviews, but I could invite more serendipity to my restaurant search.
Thanks for the tip, I'll check it out for when I am back in central Europe, but I am currently based in south Europe and sadly my country/city are not covered.
FWIW Organic Maps are aware of this issue. In the poll on their mastodon account, lack of public transit information was voted as number one missing feature. As far as I’m aware, they are looking into integrating the public APIs for it wherever possible.
It's pretty excellent! The improved integration with OpenStreetMaps to provide edits/additions is great. I made my first contribution to OSM via CoMaps.
I like your recommendations mostly, just wanted to point out that Organic Maps has had a falling out with the Open Source community that built it, so I wouldn't use that anymore. The community fork is called 'CoMaps' now.
Great... I consider this for my next App listing. Unfortunately there is no edit option at the moment. Since I don't use Organic Maps any more, I just remembered it being the most usable alternative.
Thanks for this, it's so helpful for people trying out a new platform.
I'd love to have something like this for Linux desktops as well. Maybe a website that has app-lists, where people can then potentially add info about their use cases and reasoning for their choices. Could be a great subreddit!
I tried Omarchy specifically because installed an opionated selection of apps to covered most bases, and it got me started in Arch fairly quickly. I've now completely swapped out all the components so I no longer use Omarchy at all, but it was a great way to get back into desktop Linux after being away for 20 years.
Maybe you might want to try out my zarch[1] repo, which is a Linux on ZFSBootMenu installer script for ArchLinux with configurable profiles - basically a folder with some package listings.
The t480s profile is my personal Notebook config, which is not fully up to date but probably a pretty good start. You can also only take a look at the archpkg.txt and the aurpkg.txt to see the packages that I'm using.
What would sandboxing an app like Google Maps look like? There are definitely situations where a sub-par map app would be detrimental. Obviously it's going to send data to Google, but do I have to sign into an account or will it have some other way of identifying my phone if I used a one-off account just for it?
Google Maps is sandboxed even on the stock Pixel OS. Sandboxing is part of the AOSP. GrapheneOS hardens the sandbox a bit, but it's not the most significant feature of the project. What isn't sandboxed on Android OSes that license Google Mobile Services (GMS) is Google Play (Play Store, Play Services and for older installs also Play Services Framework). On GrapheneOS Google Play is sandboxed as well, so it's treated as any other regular app, it's doesn't get priviliged exceptions.
Sandboxing isn't what would prevent an app from sending data. Sandboxing restricts what an app can access on your device because access is gated behind permissions and apps also can't peek into other apps. So it won't just be able to grab and send out data you don't give it access to, which is the most important of course.
You can install Google Maps and use a dedicated Google account for it with limited personal info. You can avoid giving your real name and also giving a phone number if you make your Google account from within the app and on a trusted network (not a VPN adress but public WiFi or cellular). It won't be able to identify your phone using hardware identifiers because non-system apps don't have access to those, the only regular app that might be able to acces such hardware identifiers is an app which is set as the default SMS app. See: https://grapheneos.org/faq#hardware-identifiers
It doesn't need to be logged on to a Google account, and it supports locally storing map data and generating routes, so you could turn on network access, download local maps, block network access, then use it for navigation without it calling home.
I recently PR'ed some improvements within the search (series and part are now searchable).
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.).
"Break free from Google" and buy a Pixel phone from them to do so.
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.
Graphene is supposedly working with a major OEM manufacturer to have future device support independent of google, on a flagship device. It's been in the works for awhile but it's very exciting.
It won't be Fairphone. Fairphone is very far removed from the hardware requirements listed here https://grapheneos.org/faq#future-devices They don't seme to take security seriously at the moment, so the chance is low they are going to make the huge leap needed to meet the requirements.
Pixels are really great despite being from Google. I hope they will continue to make them unlockable/relockable. As you say they are also surprisingly hard to brick. Here is someone trying to break it intentionally during the GrapheneOS install:
In the US, many refurbished Pixel phones are Verizon variants which disallow OEM unlocking.
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.
Oh man, sorry to hear that! On the other side of the pond, carrier-specific/locked phones haven't been a thing for ages. Haven't seen a carrier-specific phone since 2013 or 2014.
It is possible, but many people still buy them from their provider with financing or subsidies. That means people shopping for used Pixels who want to unlock the bootloader need to avoid the special Verizon variant which forbids unlocking the bootloader.
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.
Yep. I lost a restocking fee when I bought a used "unlocked" Pixel. Turned out it was not SIM locked, but it was impossible to unlock the bootloader. It was pretty easy to find a bootloader-unlockable Pixel once I knew what to look out for, but the first time I had no idea this was something you had to look out for.
I have a Pixel 6a with GrapheneOS. Runs great for years, except for one or two apps that require an "official" Android.
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.
That makes no sense. If there is a recall program for safety, surely they have to accept whatever software is on there? It's not relevant to the hardware repair
> "Break free from Google" and buy a Pixel phone from them to do so.
Pretty much yeah.
Also, the surveillance tech is getting ahead of the people now, this article might make sense back in 2015, it’s not the case anymore, even if you use a full linux distribution, hardened too, but connected to the cellular network through a modem, the operator can pinpoint your location accurately, because all new cell modems are equipped with gnss and send the NMEA message either in demand or periodically to the towers.. not to mention if your software is open source and secure, your hardware isn’t, and until we reach that point, I would prefer to have a gray man model and blend in within the crowd rather than standing out like a sore thumb.
I've wanted to try this on my old Pixel 5, but it has the dreaded screen/motherboard failure. It appears there is no solution for that short of replacing the screen/mobo, which i've already done once after cracking it.
And once you are on GrapheneOS, break free from your proprietary watch ecosystem and switch to GadgetBridge (https://gadgetbridge.org/)
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.
I tried GadgetBridge because it cannot sync the activity files (.fit and/or .gpx) so I still had to plug the watch into a computer to keep the actual data.
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.
Under settings->automations->auto export, you have "Auto export zip" where you can specify export interval. The zip file includes all the data (personally, I only see .fit files) from your app. For sync, you might have to use something like syncthing.
Setting up GadgetBridge is very easy since it's just an android app. No flashing firmware etc. However, not all gadgets are equally supported, and you should check the support status of your device - https://gadgetbridge.org/gadgets/ (I bought my watch only after checking that page for compatibility).
> And once you are on GrapheneOS, break free from your proprietary watch ecosystem and switch to GadgetBridge
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.)
You won't pass Google Play hardware attestation that way, and you won't find a bank in Europe or the UK that doesn't require that to log on to their website within five years.
My bank works fine after relocking (in NL, Europe). And last time I checked all Dutch banks work. My VISA credit card app (from ICS) also works. Same for the government identification app, the government message app, our insurance app. In fact, I haven't encountered anything outside of Google Pay that didn't work.
(I don't deny that there are apps that won't work. Best to check before switching full-time.)
That's a prediction I would disagree with. Firstly, there are application developers which specifically add support for GrapheneOS if they are asked nicely. Secondly, there is a chance that Play Integrity will have to change due to anti-trust regulation.
You pass basic, but not device or strong integrity. This is purely googles fault and is an artificial limitation that requires regulatory restrictions.
> - the pandemic tracking app without which you can’t enter an airport
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.
No banking app on phone because why; no government app because oh fuck why, whats wrong with your government (at least in primary phone and I never needed secondary); app for sport events - thats just me but I prefer doing sports rather than passively watch them, so 0 loss; pandemic what? its 2026 and I never saw such requirement in Europe, Africa nor Asia; no other app requires that.
Thats not coming from some paranoid security person, just regular (software dev) joe.
Most banking apps work perfectly, most government apps work perfectly, etc. It is only an exceptionally small subset of apps using anticompetitive measures such as play integrity.
Also, do not leave your bootloader unlocked. That is an incomplete GOS install and you will need to lock it to secure your device. Not locking it is both insecure and will make a much higher number of apps fail.
YMMV. I run sandboxed Google Play Services on GrapheneOS so almost every app works. My digital payments app works, and the same with most government apps I have tried. My private bank's app doesn't work, but I just use their website for the handful of times a year I need to access it.
Been running GrapheneOS for a while on a Pixel 9, and extremely happy with it! Apart from the usual perks of the FOSS ecosystem, there are a few things specific to GrapheneOS that are not immediately apparent but have turned out to work very well -
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).
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.
> 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.
I originally wanted to get the Pixel camera app working when I got started with GOS a few years ago, but then I found Open Camera and haven't looked back. Does it do something cool that Open Camera doesn't?
I hadn't seen that button, but at least for me it's not enough: I want to be able to select the camera directly. And in Open Camera I can only select two out of the three cameras.
A quick question from potential buyer of next generation of pixel phones, since samsung keeps disappointing hard with their top line - is there any difference in quality between default photo app and what graphene os bundles with?
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?
Yes, it's a huge difference. However, you can install the very latest Google Camera app through the Aurora app (or Play Market), and it works perfectly except you don't get photo preview within that app; to fix that minor issue, you can install the Gphotoshim which someone else mentioned in the comments.
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.
I've used GrapheneOS on a Pixel 3a, 5, 8 and 10 Pro so far and it's worked really well. I couldn't imagine going back.
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.
> 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
AdAway (in F-Droid) can block with /etc/hosts (no VPN involved) if you have root. The hosts blocking still works even when connected to a VPN. Aside from loading ad domain lists into /etc/hosts, it also allows you to specify custom domains to block - I personally have Reddit and HN in there :)
> AdAway (in F-Droid) can block with /etc/hosts (no VPN involved)
lifts head
> if you have root
Sigh. :)
Sure, on LineageOS back in the day I used to edit /etc/hosts by hand. On GrapheneOS I no longer have root, though (unless I compile it myself), which generally I think is a good idea, weren't it for Linux's absolutely abysmal access control system that requires you to be root for almost everything.
Yes, I already do that but:
- Vanadium is said to be safer.
- The reality is that websites often don't work in Firefox anymore.
- I want to be able to block social media at certain times. (Today I often circumvent such blocking in FF by just opening Vanadium…)
You might want to read my comment again. :) If you use labels, the app will have full access to the associated contacts, not just to their names & phone numbers.
So it's not about labels, but you want the ability to restrict the fields an app has access to rather than an all or nothing – full access to a contact or none at all?
I'm annoyed at everyone who shares my name, phone number and any other details with Meta. I never consented to it. The behavior of their app slurping up your contacts database is despicable.
This doesn't answer your question, but in case it helps for others out there: it's possible to use WhatsApp with no access whatsoever to your contacts and I used it that way for years. Connecting with people is slightly jankier but it still works.
This is especially interesting in regard to the recent HN dicussion on spyware by for-profit intel firms having access to Whatsapp, Telegram, Signal, etc. (https://news.ycombinator.com/item?id=47033976) through OS-level no-click hijacks.
I wonder how secure GrapheneOS is in that regard, and what the other contenders are?
Hard to say how it fares against those specific attacks but some of the vulnerabilities that will go out in the mid-2026 on the mainstream handsets are already patched: https://grapheneos.org/releases#2026021200
(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)
GrapheneOS themselves dont pretend that their secure from that level of attack, but its about evaluating your own threat level. State sponsered actors aren't burning zero days on the vast majority of people, and you only need to look at how badly several european governments want to ban graphene and similar to see that such exploits aren't even being burned on organised crime. Realistically unless you're a journalist or considered a political target you're gonna be fine with graphene.
Its definitely a scary world, safe to assume all your online activity could be hacked if so wanted. Just gotta hope its not wanted and that it doesnt become possible to do it on a mass scale (UK is currently pushing to ban E2E lol, and I know the EU has contemplated similar. If you do fall into the wanted category, face 2 face is really the only option. I know a lot of politcal/investigative journalists also constantly cycle and maintain burner devices but even thats a risk of just how long is a safe time before a device is considered burned.
GrapheneOS have hardened_malloc which is a huge advantage, I think. It makes the weird machines problem much harder. I would say be very careful, because you can still get previews of images, or old and weird media formats that could be exploitable, and android/GrapheneOS doesn't have the same sorts of policy as say Apple with the iMessage blast door. They control safari, etc.
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.
Chromium is the only web engine present on a fresh install. If a user doesn't install a browser with another engine, the attack surface doesn't get increased. Chromium/Blink is more secure than Safari/Webkit overall so I don't really think this is an argument in favour of iOS. iOS for sure does some good things though and is better than Android in some areas.
It's quite secure against casual attacks, but a proprietary mobile platform has inherent issues wrt. withstanding even mildly sophisticated attackers, including mercenary spyware services. You still have a huge attack surface from all sorts of proprietary firmware blobs and hardware IP blocks that are running directly on the SoC. It's not clear that it's really worth even trying to secure it as opposed to just treating it like an untrusted toy.
In my understanding, it's not the OS that makes it a toy but the hardware. I guess something with open schematics (Librem 5, Pinephone) should be better, or an open-hardware device like Precursor.
I'm not convinced that all of these is required for security. My Qubes OS desktop is probably more secure than any GrapheneOS phone, and it only requires good hardware virtualization for that.
> If the hardware is an open book then no.
So you choose security through obscurity. I have no further questions.
- dedicated, certified security coprocessor (Titan M2) - on pixel it's fused with verified boot, offers key storage, firmware isolation and anti rollback.
- verified boot: mandatory and backed by Titan, immutable boot from. Almost all laptops lack as much as anti rollback.
- strong hardware-backed key protection and actually isolated TEE. Yes, I know about Intel (SGX/TDX) and AMD (SEV/SME). Broken into many times over. How many commodity hardware devices offer comprehensive protections like Titan-backed TEE?
- secure hardware-backed disk encryption key derivation (with throttling of course)
- on-device attestation: complete verification of the entire chain. Dreaded Play Integrity or open AOSP / GrapheneOS hardware attestation. Which PC vendors can offer that? Perhaps Apple but that's not a pc and you won't run qubes on that?
- physical anti-tamper: which laptops wipe encryption keys stored in the secure hardware when you're trying to unlock the bootloader?
- physical memory tagging (see ARM MTE). Apple offers some but again, that's not for qubes. Intel promises MKTME in the future.
- does your laptop disable all the unconnected ports whilst the laptop is broken? Does your pin/password verification happen inside TEE/TPM, not in the OS?
- modes similar to PXN/SMEP, SMAP/PAN (to stop these pesky wifi/gpu firmware from reading userpace memory). There's some support for SMEP and SMAP on intel/amd
- microcode and firmware upgrades velocity
There are reasons GOS doesn't support any hardware other than pixels. Regrettably and thankfully that is about to change soon <3
Don't read me wrong, qubes is brilliant and on SOME hardware (business grade laptops with TPM 2.0, verified firmware upgrade process with some protections and proved track progress with rapid hardware drivers and firmware upgrades -- sure, brilliant choice. For pcs.
But is not even remotely close security-wise..
Best available would be probably Purism Libre (lacking TPM if I read it correctly, weak hardware but, oh well, pixel is not super fast either lol), or something with coreboot perhaps?
Whats the safest and still useful laptop hardware you cna think of?
Let's compare with with pixel.
QubesOS certainly has some good things going for it with isolation but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS
Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.
With regards to security through obscurity, the Pixel firmware isn't obfuscated at all. It's closed source but it's easy to decompile the code and inspect it. They don't try to obfuscate it to make that difficult.
You cannot just say this without any links. Last escape from VT-d virtualization, which Qubes uses, was found in 2006 by the Qubes founder ("Blue Pill").
> Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.
You can run Qubes OS on something even better: Coreboot with Heads and with a hardware key. All based on FLOSS. Works for me.
> but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS
First of all, you can in principle run any OS in Qubes VMs, including hardened ones. You can even disable the root account. Second, with such statement, you misinterpret the Qubes' approach to security. You isolate trusted workflows from untrusted ones, which gives you the strong security. You never open anything untrusted in trusted VMs, so their internal security plays no big role.
well, a concerted attack could easily subvert the baseband if you have a few million dollars and the correct letterhead or private contacts.
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?
> 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.
The firmware being proprietary is compeltely unrelated to how much attack surface it has compared to open source firmware. The only thing that matters is how secure the firmware is.
That's too simple. First of all, Pixel (which GrapheneOS requires) is one of the few Android phones with a separate secure enclave. GrapheneOS also applies a lot of hardening that other vendors do not: https://grapheneos.org/features#exploit-protection
I've been using GrapheneOS for about 3 years now. For the most part, it works very well. I don't have any issues with banking apps, nor any other closed source apps. I'm using two profiles both with sandboxed Google play installed. I'm logged in into my private Google account on the work profile.
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.
Yeah, it's more expensive - in this case because of the changes and separate operators on every part of the journey.
I could potentially swap one train for a bus and then take different train and skip one of the buses saving some £5 but extending trip by about a hour at least.
Maybe not being able to use Uber isn't the downside you think it is though. UK centric view but call a cab and pay in cash, you haven't comprimised your security and you're not engaging with an unethical business.
Right but at least then you are the one being scammed, and can decline to be scammed if you wish. As opposed to willingly partaking in a shitty system.
And the amount of lock-in. If they ever decide to kick out your favorite OS or hardware vendor, well, good luck doing that if you can use the services on a website. They'd have to port all the web users over to mobile and know they'll lose at least some of those customers
What exactly is the risk of getting temporarily banned on Uber? You have to use a different taxi app? As if such a thing even exists?!? Unacceptable!!
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.
The key phrase there is "such services". It's not just about one problem once with Uber, it's the risk of problems like this with any service of that kind, or really any service you rely on.
If using GrapheneOS significantly increases the risk a person won't be able to use a service they rely on, that may be unacceptable.
But that's my point, what one irreplacable app/service do people rely on? The only thing that comes to my mind is messaging apps, but even there, almost everyone I need to talk to is reachable on at least one other app. I have multiple taxi apps because I compare prices and availability, like any reasonable consumer should. I have two banks, but even if I didn't, I can pay by cash or card, not just phone. If I need to make a bank transfer, I can go to a branch or do it online. I have two map and navigation apps because they have different strengths and weaknesses. My email is accessible by browser if the app breaks.
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.
And what is preventing Lyft/Uber whatever's algorithm to have a bug and just falsely flag your account after registration? Like there is no guarantee it works on a stock android/apple device either and I'm fairly sure they have a long list of false flaggings that support has to unlock day-to-day.
> 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.
This has been my experience with Windows too. Airpods connect out of the box on Linux, but on Windows they would stop pairing every couple minutes until I fixed some drivers
It's a shame only Pixel phones are supported. I have PWM sensitivity and Pixel phones are notoriously bad for this, my eyes hurt when I look at one for more than 30mn. Due to the lack of good, secure alternative, I have had to give up on privacy in exchange for manufacturer updates.
That article speculates the OEM is Samsung but I find that very hard to believe. Samsung is totally beholden to Google. The discontinued their own DeX and Tizen smartwatch OS for Google alternatives and as for their "AI" features most of them actually come from Google.
Google would not allow this and they're way too entangled with Samsung.
Interesting article. Let's now hope for a reasonable price, even though it will be challenging for their team. It would be a shame if the target audience is limited to overpaid nerds like most of HN.
I'm in the same boat. Bought a 9 Pro XL and had to return it. Hope their OEM will use DC dimming for the screens or have an IPS option.
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.
So, buy it refurbished? Google doesn't directly profit from it, you create less pollution, and once you have GrapheneOS on it you can leave Google out the door.
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).
GrapheneOS' approach is to focus more on security than privacy, because they believe increased security leads to increased privacy. Unfortunately, that means their hardware requirements pretty much limit the hardware that you can run it on (currently only the Pixel phone range). Worse, it also means they stop supporting a device when it reaches End-Of-Life as software security updates stop for it (see How long can GrapheneOS support my device for? - https://grapheneos.org/faq#device-lifetime ). Sad though - GrapheneOS on Sony Open Devices ( https://developer.sony.com/open-source/aosp-on-xperia-open-d... ) would have been nice.
The whole reason why GrapheneOS is superior to its alternative is because they do all that.
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.
I meant alternativeS, sorry. Well, anything AOSP-based that is not Android.
> The manufacturers aren't blocking the installing of GrapheneOS...
Of course they are not. But they produce hardware that is not secure enough for GrapheneOS to consider. I wish they saw value in GrapheneOS and produced hardware that met their requirements.
It's actually weird, because I'm convinced that it's completely worth it: just add those requirements to the design of one new model, and a potential of hundreds of thousands of people may buy it just for GrapheneOS.
This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
> Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
The requirements are indeed minimal. I have no problem with your valuing independence from Google, but please don't misrepresent GrapheneOS' requirements as the highest degree of security because not even they have said that. They have actually mentioned wanting to be more involved in the hardware/firmware side to implement more pro-user changes.
They are mostly basic requirements that Android OEMs should be embarrassed not to meet in 2026.
I disagree that such requirements are minimal. Nothing prevents running GrapheneOS on a device with lower requirements. It's a questionable choice by the developers restricting the choice for users.
(I agree with you in spirit, namely that GrapheneOS' standards are clearly beyond what most vendors are willing or able to do and a compromise or support of users who want to port the OS might be fitting for the current situation, but notice that the person you replied to never said "minimal", they said "minimum". I'm not a native english speaker but I believe your reading is a value judgement along the lines of "not much work" (in this context) whereas they probably intended it like a statement of fact regarding what the requirements are.)
Aren't requirements defined as the set of minimal constraints that are needed for something to be deemed acceptable by those who define that set?
Again, requirements are not laws of physics. As the author of a project, I am free to make up my own requirements, and when something doesn't meet them, then I am free to reject it because it does not meet my requirements...
If you go to a bank and they refuse to lend you money because you don't meet their requirement, you will have a hard time convincing them that their requirement are wrong and that they should instead replace it with yours :-).
It is not the job of GrapheneOS to lower their standards and deplete their resources supporting every phone under the sun. We already have LineageOS for that. I would rather not be snarky but I don't understand why people keep blaming GrapheneOS instead of the OEMs. Almost every single time.
GrapheneOS has requirements that result in only the Pixels being supported. LineageOS has other requirements that result in most phones being supported.
I may wish that more devices met the requirements of GrapheneOS, because I like GrapheneOS and their requirements, but I find it very weird to with GrapheneOS changed their core vision. What makes GrapheneOS is those requirements.
You are not independent from Google if you purchase an android device from another manufacturer. You're then having your data sent to both Google and that manufacturer, resulting in far worse privacy overall than with just Google, not to mention worse security at hardware level. If you don't want to "support" Google, just buy any used Pixel 6 to 10 series.
That's like saying Tulip blocked the installation of Vista because they didn't install enough RAM to run it
The OS makers don't have to go out of their way to support a device they don't want to (that's the beauty of open source passion projects), but it's also not like any manufacturer (that allows bootloader unlocking or ships an unlocked bootloader) is blocking GrapheneOS or anyone else from doing it, which the quote implies in my reading (maybe other people read it differently)
You called it a problem coming from the manufacturers. That implies they actively thwart it (woa, another new word! It's crazy how language works). But they don't actually have a problem with it; some of them are actively publishing the info needed for alternative OSes to work on their hardware and GrapheneOS needs only take it if they want to, but they don't. Who has a problem with whom here?
Again, not saying GrapheneOS is doing something wrong. Nobody's under an obligation. Just that, if someone wants to argue that one party is making a problem out of the situation, I don't find it fair to assign that label to every manufacturer on the planet besides google
They are dependent on the AOSP releases (which Google develops) and on the manufacturer updates (and because GrapheneOS runs on Pixels, then it goes back to Google again).
I can understand relying on an OEM to provide hardware support for a given model - but I'm finding it hard to understand why they're unable to continue supporting a release just because the upstream removes support for something.
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.
Debian surely doesn't depend on Lenovo or Asus to release OS updates for my laptop. Apparently it's not "everyone else" that needs this but it's some sort of dependency for mobile (qualcomm?) devices
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
Debian does not write the whole software stack running everywhere on your system. So if you want your system to be "supported", as in, "if a security flaw is discovered in a firmware, I want it patched and I want my firmware to be updated", then you need whoever writes that firmware to do 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.
Interesting, so any security patches to kernel level and above (AOSP code, browsers, other apps) can still be fully up-to-date when the manufacturer says a device is out of support. Not sure I understand the fuss then that Fairphone had about selecting a SoC with long support. Really thought it was some sort of problem updating the kernel or other AOSP components when using manufacturer blobs
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
> why they're unable to continue supporting a release just because the upstream removes support for something.
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 they mean breaking free from Google Analytics, Google Play Services, Google Play, Google Location Services, etc. Play Services and Play are not installed on GrapheneOS by default, so it is possible to run your phone with just GrapheneOS with your choice of open/closed source apps on top.
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.
One of the only big downsides I've noticed with GrapheneOS is that several banking apps don't work with it at all thanks to being tied to Google's verification ecosystem.
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.
I contacted my bank, insisting that GrapheneOS is one of the most secure OS on the market and therefore should be supported if they actually care about users' security (it's actually far more secure than all the old, far less secure but Google-approved devices out there). They acknowledged an fixed their app, one of the most popular in France.
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?!)
The point of NFC-on-a-phone is that you don't need the damn banking apps and internet and retailer support for all that to validate a simple transaction. My credit card has NFC, no internet and no app, and it's universal.
There are several banks, especially over here in Europe, that have their own implementations of contactless payments, if that's what you mean. Here's a German article outlining this and mentioning a few examples: https://www.kuketz-blog.de/nfc-datenschutzfreundlich-bezahle...
I can't say about "convenient" because I don't use it, but I have been using QR codes for years and I haven't had a single issue. I don't know anyone who has.
It's regularly unreliable here, because it's reliant on a bank app which in turn is reliant on an internet connection, and banks here are kind of shit.
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.
> It's regularly unreliable here, because it's reliant on a bank app which in turn is reliant on an internet connection
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!
> 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...
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.
Most anti-google move: buy a second hand pixel, they receive no revenue on the device which is (assumed) already highly subsidized by google so that they can profit off users' data, then you use their subsidized hardware without running their spyware OS. Google only loses money in this scenario, it is a great protest.
Have you seen those prices? I don't think the devices need subsidising at all. How else could competitors, who aren't selling off your data, offer it for cheaper?
That depends on (1) which one you pick and (2) whether you keep the stock OS
Given that there exist vendors like Fairphone/Murena that sell lower-performant hardware at much lower price points, it seems to me that the expensive but decent hardware (like Google's flagship) might be priced appropriately as well
Other competitors (that do track you, like Samsung) have similar price points for their high-end hardware and are again much cheaper for slower hardware. If selling data is so essential, they wouldn't allow removing the tracking. (Samsung may be a bad example because they removed it last summer, but root popularity has been diminishing since early android days anyway so I can't imagine it's a big factor for them)
I see it as a necessity, because the Google phone is the only one worth it if you care about security.
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.
Besides the already mentioned point of getting one refurbished, Pixels tend to get really cheap towards the end of the yearly cycle. At that point, they were mostly going to make money from you using their ecosystem and then you are sticking it to them by installing GrapheneOS :p (probably they don't care).
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).
Yup, also Google Pay doesn't work, though there are other providers which work fine (Curve Pay I think works in all of EU), but it just made me carry my wallet everywhere and I understood I don't mind that at all.
Since all of comments are about NFC payments, this should be higher.
Can confirm Curve Pay works (pixel 9a) at least with one Greek bank and Revilut.
Not affiliated in any way with them and don't know this service is actually works just Yeah I'm amazed too.
No, because most banking apps call upon the Google Play Integrity API, which GrapheneOS doesn't (or can't?) use. There's a decent list kicking around of which ones work (Monzo, for instance).
It's more common in banking apps than in other apps to implement Play Integrity but it's cetainly not "most banks" that do it. It's still only a small subset. Sucks of course if it's your bank.
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".
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.
While I admire GrapheneOS and its goals, I feel that until we free the proprietary baseband processors and their RTOS from the grips of Qualcomm and friends it's a pyrrhic victory, at best.
Unless the next best thing makes you think you are already achieving the "perfect solution" for what you think you care about, but in truth does not.
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...
> a zero-day in the closed source firmware from Qualcomm will probably screw you anyway.
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.
Thanks for the clarification (and to the others that answered as well).
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.
fyi a Cell Site Simulator can masquerade as the legitimate telco operator and push type 0 messages to the handset.
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.
> 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. [...]
I don’t have the source (I’ll have to try find it), but I read that the cell site simulators can work on 4G and earlier but don’t work on 5G. So one thing folks can do is set ur phone to use 5G networks only (unless ur stuck and then u can make it looser but be aware your less protected at that time).
I do this on iOS I’m sure it’s do-able on GrapheneOS and hopefully on Android too.
5G CSS is harder yes, but keep in mind that most 5G is the 5G_NSA variety, and is really just riding on the same cell bands, no mmwave here. You probably notice that your phone often slips out of 5g, or you inhabit different modes here.
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.
So no, their target is people who marginally care about privacy and security but don't want to use iOS. I don't think they target any particular demographic but I see security engineers and activists among users.
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 think the appeal and use case for Graphene and similar OS for most users is the Google/privacy/ownership type argument.
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.
iirc Graphene is in talks with an unnamed HW vendor to make a grapheneos specific phone. They refer to the vendor as someone who makes phones and you've likely heard of, but haven't given any more info otherwise.
We need Linux OSes and phones to catch up to really break free from this duopoly. Only when there is enough traction, essential infrastructure like banks will start supporting Oses like that. It's a chicken and egg kind of problem.
I think that the main problem is that android has a lot of weird modifications that are not consistent with the rest of linux distros. The user data is suddenly in /data instead of /home, theres no package manager, no systemd (for better or worse), and there's hella lotta security gotchas, for example call recording is impossible without root as far as I know. I'm not saying that Android is not hackable, but it's a different type of hackability than desktop linux, you have to learn it all over again and in my opinion it's much harder to master than desktop linux.
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 :)
If your criterium for choosing an OS is tinkering and hackability freedom to do modify almost anything to your liking (even if it will compeltely break your system or poke extra security holes in), then desktop Linux OSes ported to mobile might indeed be a good option.
If your goal is security and privacy (which go hand in hand), mobile OSes are clearly the best solution.
Anyway Android is still a Linux OS. The only requirement to be a Linux OS technically is to ship a Linux kernel. Adhering to freedesktop specifications like the FHS, using systemd, using GNU userspace software, etc. isn't necessary.
On Android you can install software by installing directly from APK files or you can use application stores which are package manager, they help you install software and if there are dependencies they can also install the dependencies if they support that.
Call recording is possible on multiple Android OSes, it's possible on stock PixelOS and GrapheneOS, I'm not sure about others but normally it's just part of the Dialer app. You don't need root at all for that.
Yeah, just need to decide where to start the fork. The larger problem is radio firmware. FCC regs were the initial excuse, for wifi and Bluetooth too, but we need to open up the source for all of these and allocate money for enforcement if we are truly worried people are going to start adding wifi channels etc. Open firmware phone radios would let you do things like truly turning off the radio when wifi was present, no gps ping even.
You’re not wrong. The thing that bothers me is that AOSP is being developed behind close doors and controlled by a single company which wields way too much power and control over our daily lives, and which has a track record of abusing that power.
They for sure control the direction of the development but it's not really that problematic given that things downstream projects take issue with can just be removed from the source and things they want can be added.
The portions of SailfishOS specific to it including the user interface and application layer are nearly entirely closed source, unlike the open source Android Open Source Project (AOSP). SailfishOS has far worse privacy, security, functionality and usability than the Android Open Source Project. It isn't possible to make a fork improving it due to it not being open source like AOSP.
You can run desktop apps on GrapheneOS including on a desktop monitor via the desktop mode with free form windows. There's support for non-native apps via hardware-based virtualization. These features are experimental but already work pretty well.
There's a new Jolla Phone in pre-marketing phase right now (almost 9000 phones have been pre-ordered so far). First device deliveries are scheduled for this summer and this should easily be the new benchmark for officially supported SailfishOS devices.
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.
Jolla mishandled the funds they got for the tablets, it went bankrupt and bought up by a company connected to the Russian state. Jolla lied a lot during these events and tried to hide what happened, and I don't think that's an acceptable thing to do when the main selling point of your product is privacy and trust. AFAIK they recently got bankrupted again and bought by the original owners, but it's hard to rebuild trust.
> For me, it works like this: on the Owner user, because that’s the name of the main account created automatically with the system, I installed the Google Play Store along with Google Play services and GmsCompatConfig
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.
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.
> I'd never use GrapheneOS since I don't trust the project
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.
I have never seen drama from /e/ or any other project GrapheneOS attacks, like Calyx. Please link me to it - I asked this several times, people never can follow up. So far?
> Please link me to it - I asked this several times, people never can follow up. So far?
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?
Sorry, but then I take this as the usual - GOS is attacking other projects, that I can easily see in all their socials, and the other projects have done nothing wrong. GOS always claims that the other projects attack them since years, and never shows any proof. And indeed, I still never have seen any attack against GOS. Seems like this won't change today.
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.
I still haven't seen what you describe, the behaviour of other projects. And I dont believe it without proof (since it was claimed so often by GOS without proof being shown, or in some cases with it obviously not existing).
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.
> It is wrong to claim that an unlocked bootloader completely breaks the android security model.
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?
Take what I say with a grain of salt. There are many people that know more than me. But I'll try to answer to the best of my knowledge.
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.
> 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?
They're misrepresenting what has been said by GrapheneOS and also lack a good understanding of it themselves. They're definitely not a good source of information about this.
Could you provide some insights there? That would be appreciated.
1. Is it correct that the secure boot protects again a malicious app escaping the sandbox and persisting into the system?
2. Is it correct that if the system is signed with the Google testing keys, then someone could sign an app with those keys and the app would get more permissions than it should (I believe it's called the "signature" permissions)?
The nitter thread shows the exact behaviour the article is complaining about, proving it right (at least the toned-down version). Highlighting the abusive behaviour of one person in the GOS project that actually does happen isn't an attack against GOS, and certainly not wrong.
It's exactly the problem: You have one bully here that claims everything criticizing his abhorent behaviour is a libelous attack, thus he attacks other people and projects that attack him, spinning substantiated criticism against him as "projects driving a campaign against GOS". And the Graphene followers believe him. It's absurd.
That's not just a claim, this is an objective fact. GrapheneOS has a excellent track record when it comes to security, they have made several patches that got upstreamed to Android, etc.
> GrapheneOS claims to be a lot more secure, having additional hardening.
GrapheneOS has been heavily analyzed by privacy and security experts who say it provides far better privacy and security. There's a large amount of real world evidence showing GrapheneOS very successfully defends against commercial exploits tools. /e/ has been heavily criticized for having poor privacy and atrocious security by many experts. /e/ doesn't keep up with basic privacy/security patches and misses many important standard protections.
> keep in mind that it is not an independent comparison
That's not true. It's an independent comparison and the site compares a lot of other software. Contributors to many of the projects compared by it submit issues to it which doesn't many it not an independent comparison.
> In regular use, main difference will be that /e/OS comes with access to the alternative cloud service that project provides.
GrapheneOS users have many cloud services available including suites from Proton and others. Murena services have poor privacy and security overall due to neglecting server security, updates and more. Their speech-to-text service being a thin wrapper around OpenAI sending this sensitive user data to them rather than doing it locally as our SpeechServices app does similarly to Apple (even Google has that as an option):
> It uses the default FOSS solution microG for google api compatibility
Their approach with microG gives highly privileged access to Google apps/services by default. GrapheneOS doesn't include sandboxed Google Play by default and they're installed as regular apps. microG doesn't change the fact that the apps are using closed source Google libraries, which are still present with microG and have strictly more access to user data on /e/ than GrapheneOS with sandboxed Google Play. Sandboxed Google Play is an entirely opt-in feature people need to install. /e/ has microG set up where it downloads closed source Google Play components it runs with privileged access as the default.
> /e/OS sets on AppLounge to install and upgrade both play store or F-Droid apps
This is a strange merger of Aurora Store, F-Droid and more. It's very misleading and confusing for users.
> /e/OS is also not my favorite since it feels like it is developing slowly, having had issues with outdated software versions - though it does work well in practice. Have a look at iode for an alternative.
Neither /e/ or iodéOS keeps up with updates to Android, Chromium, firmware, drivers or the Linux kernel. Both mislead users with an inaccurate Android security patch level. iodéOS lags far less behind /e/ and doesn't have nearly as many privacy violating services and added privacy/security flaws but neither is a privacy or security hardened OS. Neither keeps the privacy or security of standard AOSP intact.
I have been using /e/OS for 5 years, and also GOS. My take is:
- 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.
> I had a Fairphone 3, and after 5 years, /e/OS was outdated by 4 years w.r.t. the manufacturer updates
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.
> Mine is running /e/ and reporting Android 13, which appears to be the last one Fairphone 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.
> It's had continual security updates apart from the Android version.
Nope, it doesn't receive most privacy and security patches. Users are being heavily misled about what's provided. First of all, the kernel is nearly entirely not being updated which is a massive portion of the privacy and security patches. Murena's devices have poor privacy and atrocious security including due to the failure to properly provide basic privacy/security patches. Their claims about what they provide need to be distinguished from what is actually provided. /e/ updates the patch level regularly to claim they provide the security patch backports but that doesn't mean they actually provided all of them. It's an arbitrary value and they don't set it accurately.
Fairphone 3 uses the end-of-life Linux 4.9 branch, Fairphone 4 use the end-of-life Linux 4.19 branch and Fairphone 5 uses the end-of-life 5.4 branch. Each was largely not receiving the upstream LTS updates while they were still provided but now they're not provided. An OS that's not receiving basic kernel updates is definitely not receiving security patches anymore, but they were largely never providing these updates in the first place long before the kernel branch or devices were considered end-of-life.
Similar to iOS and other operating systems, Android only backports a subset of privacy and security patches to older Android branches. Only Android 16 QPR2 has the full set of Android privacy and security patches. You aren't receiving all of the standard Android privacy and security patches if you're not on Android 16 QPR2. Many of the patches are also treated as optional and deferred as being mandatory far into the future. It's also worth noting the dates are misleading. Android's March 2026 security backported have been finalized for a while and up to August 2026 are available to ship by OEMs already but a lot more will be added to June 2026. February 2026 Android security patches are the latest with a public bulletin but not the latest available to ship.
Fairphone and especially /e/ also have very incomplete patches for firmware and drivers. /e/ also has major issues patching other components including the browser engine used by the OS for the WebView.
> If your phone is not supported by GOS, you should look carefully and compare between /e/OS and Stock Android.
If you have an iPhone that's still supported, you have strong privacy and security. If you have a phone that's not an iPhone and not supported by GrapheneOS then you likely have a phone with atrocious privacy and security regardless of OS choice. If people can afford to get a secure device with years of proper support remaining then they should do that rather than using an insecure device with a sidegrade for privacy and security using a problematic AOSP fork. LineageOS is far less problematic than /e/. If people want to switch the OS to something else due to the OEM abandoning it or to avoid Google Mobile Services they should use at least use LineageOS which is less of a privacy and security downgrade from OS. LineageOS does not fully maintain the privacy and security of AOSP or fully keep up with updates but it's a lot less bad than /e/. Most alternate OSes are forks of LineageOS to reuse their work on hardware support and nearly entirely make privacy and security worse, not better, so why not use the upstream project instead?
> I had a Fairphone 3, and after 5 years, /e/OS was outdated by 4 years w.r.t. the manufacturer updates. In other words, Stock Android coming from Fairphone was more secure than /e/OS on that Fairphone.
It's important to note that an alternate OS depends on the OEM for firmware and in practice much more than that including kernel and driver updates. It's theoretically possible to replace the kernel and drivers with much different ones but it's not done in practice by alternate AOSP-based operating systems. If the device is abandoned by the OEM then you aren't going to have a secure device.
/e/ lags far behind on standard privacy and security updates everywhere but misleads users with an inaccurate Android security patch level along with many inaccurate privacy and security claims. LineageOS is much better than the fork of it by /e/ and does much less to mislead users, although it still has the inaccurate Android security patch level and many people still wrongly believe they're getting patches they aren't after the OEM dropped support.
In what ways does LineageOS trail behind AOSP in terms of security? I looked at the comparison chart you linked elsewhere and the privacy/security sections only seem to list advantages over OEM Android (not AOSP), with the exception of secure boot [1], but AOSP (not OEM Android) doesn't have that out-of-the-box either. Unless you are comparing Lineage with OEM Android?
The main difference is that GrapheneOS prioritizes security hardening first and foremost (above usability or compatibility). /e/OS focuses on privacy (i.e. reducing data leakage to adtech) and usability over security.
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.
> /e/OS focuses on privacy (i.e. reducing data leakage to adtech)
/e/OS literally sends STT data straight to OpenAI...
/e/OS uses priviliged MicroG, which connects to Google for some of its functionality
/e/OS doesn't keep up with updates properly, making its security suffer, making yoru phone easier to compromise, increasing the likelihood of amongs other things sandbox escabes which open up possibilities to data leakage.
> GrapheneOS recommends running all the proprietary Google apps in a locked "sandbox"
They don't recommend this. The user can choose to do so.
> but obviously Google still gets to see everything you do in their apps
Indeed, obviously. So, obviously, also the case on any other OS.
> 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.
You can install apps you need on GrapheneOS providing those alternatives yourself. Android has a large FOSS app eecosystem.
Much of the things /e/OS bundles for services are just using Nextcloud and their services have been very unreliable in the past, making people unable to access their data for months. Also, Nextcloud isn't end to end encrypted.
GrapheneOS also makes their own apps, like Vanadium, PDF viewer and Secure Camera.
> but obviously Google still gets to see everything you do in their apps
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.
> security hardening first and foremost (above usability or compatibility).
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.
I assume this is all technically correct, but in practice I've not noticed any speed difference between stock Pixel and GrapheneOS. Maybe their Vanadium browser when tab switching, that feels slow, but I wasn't planning on being part of the Chromium monoculture anyway so this doesn't matter to me
That's great and, of course, only your experience matters to the choice of which OS you use. I just don't want people to get the impression there are no tradeoffs.
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.
It doesn't make it more possible to irreversibly brick your phone. Even if you set it to the most strict setting the port still works when you are in the bootloader and recovery modes. See https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...
Also, it isn't the only materials difference in that threat model. To just give on example, the autoreboot feature is also useful for that.
Not sure if I'm understanding you right, but I wasn't saying that my experience is the only one that matters. Just that it's not a thing one notices in practice, at least not under conditions I've experienced (I figure a reader can fill in that last bit for a comment written in the first person). Saying AOSP's is "much, much faster" suggests it would be noticeable and afaik it's not (at human timescales), so I wanted to add that info to the thread
Good point about the USB thing btw. It's obvious to me and the reason why I go one step further and leave USB debugging always enabled now that there's this private key authorisation method anyway (it asks for computers whose key it doesn't yet trust), but indeed a lot of users might follow GrapheneOS' advice without realising
Leaving USB dubbing enabled just exposes a lot of attack surface. And if you use USB debugging you are placing a lot of trust in the computer you are connecting to. You don't need USB debugging to reflash GrapheneOS or to sideload updates from the recovery mode. So, it's not relevant to prevent a device brick.
I just want to note that I believe the default setting is that data is disabled for the USB port when the phone is locked except after a reboot (before unlocking the phone for the first time), so if you break your screen you have the option to use the keyboard if you reboot the phone.
GOS creates a complete bunker of a phone that can provide defense against pretty much all but the most dedicated state level actors. If you're worried that someone would steal your phone specifically to target you, Graphene will protect against that. Securitywise it's hard to argue against them, although GOS tends to sacrifice usability in favor of security, which leads to odd decisions. Their device depreciation timeline is also pretty aggressive and really just matches that of the Pixel. (You're also buying the Google phone... to not want Google in your life; this bizarre paradox will always be strange). It's not exactly a recommendation for long-term support. Worth noting however is that usage of GOS is also seen as a signal in and of itself for the authorities that you may have something unsavory to hide, so using it stands out in that regard; some law enforcement officers (I think it was in Spain?) have said that the OS is popular with organized crime. GOS obviously denies the connection and they're probably honest in that the OS isn't deliberately designed for criminals, but it's worth noting at the very least. (Basically GOS is the paradox where someone trying their hardest to be anonymous ends up standing out way too much from the crowd and drawing attention to themselves.)
/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.
I have been a user of /e/OS for 5 years, and also of GOS and would like to share my opinion on this:
> 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.
I'm also not involved with any mobile privacy/security project, unless OpenStreetMap data and self-hosting can be said to be such
> 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)
>Not everyone is running from an intelligence agency or cellebrite border checkpoints
OK, but would it be such a bad thing if most people's personal devices were pretty damn resilient to mercenary spyware by default? I really don't think the standards GrapheneOS are aspiring to are the problem with this picture.
Certainly not, but there's more goals than singular security from government agents at all cost
With the current mobile OS landscape, getting away from ubiquitous overseas dependencies, constant tracking, and closed-source mandatory apps is, to me, much more direct-impact than protecting against this extremely remote chance of having an exploit, customised to my software stack, finding its way onto my device somehow. I'd much rather have the freedom to do with my hardware what I wish
Some people will prefer one thing, and other people another. Neither is a bad choice if it fits your goals and you know the risks of each one. So what I'm saying (and seem to be repeating over and over and over in any graphene fanboy thread) is that it's a choice, not a one-size-fits-all, and not a foregone conclusion (as GOS authors pretend it is, which this subthread started with)
> /e/OS/ was bad with updates for a long time (I had to switch 2022).
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.
iodéOS lags far behind on Android, Linux kernel, browser engine and other updates too. It's much less behind than /e/ and misleads users less but they still do. They set an inaccurate Android security patch level which misleads users just as /e/ does.
I didn't know. Do you have a link to one specific announcement where they mislead people about the patch level? It would help to start a conversation to change that.
I guess on /e/OS you can just run Google Maps in a browser if you really want Google Maps features (like searching for a restaurant).
Organicmaps works fine if you just need to get from A to B. It does lack live traffic, but you'll have to live with fewer features if you really want to not use Google for most stuff.
The founder and CEO of /e/ and Murena openly spreads content from Kiwi Farms and neo-nazi sites. He directly engages in harassment towards the GrapheneOS team. Here's him supporting authoritarians smearing GrapheneOS by replying to threads about it linking to harassment content based on fabrications on a neo-nazi conspiracy site:
The communities of several projects including /e/ have heavily engaged in spreading misinformation about GrapheneOS including fabricated stories about our team. They've even taken it to the point of repeated swatting attacks aimed at killing our team members. There are relentless raids on the GrapheneOS community platforms including our chat rooms where Child Sex Abuse Material, gore and endless harassment towards our team members including fabricated stories and harassment content from Kiwi Farms and elsewhere is posted.
I find it very hard to reconcile claims like "repeated swatting attacks aimed at killing our team members...Child Sex Abuse Material..." with the proof offered being a blog post that makes the fairly anodyne (especially read in light of this comment) case that you are an extremely paranoid person whose paranoia leads you to extreme judgements that may harm users. If you are the target of extreme attacks, it seems far more plausible to me that those originate from state actors and security adversaries, rather than from erstwhile allies also trying to build better mobile OSes.
Rather than reading this as "harassment", I would suggest you should try to take it as constructive feedback: You do not play well with others and your prickly interpersonal demeanor hampers the adoption of what is (by all accounts) technically strong software.
It's your claims which are extraordinarily and have been thoroughly debunked. You're directly engaging in bullying with baseless personal attacks. You make false accusations about us while you're actively engaging in those things.
> I find it very hard to reconcile claims like "repeated swatting attacks aimed at killing our team members...Child Sex Abuse Material..." with the proof offered being a blog post that makes the fairly anodyne (especially read in light of this comment) case that you are an extremely paranoid person whose paranoia leads you to extreme judgements that may harm users. If you are the target of extreme attacks, it seems far more plausible to me that those originate from state actors and security adversaries, rather than from erstwhile allies also trying to build better mobile OSes.
It's very easy to see that the site which was linked is a neo-nazi conspiracy site. Gaël Duval knew that when linking to it. Gaël Duval has repeatedly spread harassment and libel content from Kiwi Farms and elsewhere. He has linked to the same harassment content linked in the post. Both of those videos are from Kiwi Farmers and one of them participates on the site with an account in their real name which received identity verification. They openly use the site as their personal army and were the one to involve them.
Duval very clearly knows that he's directing his community to target our team with harassment by spreading fabricated stories about us. Anyone can take a look around the site which was linked and see a whole lot of the paranoia and delusion you falsely attribute to me with no basis. Duval is opportunistically spreading harassment content to benefit his for-profit business for the same reason he has heavily invested in spreading misinformation about GrapheneOS.
Duval is not an ally. He's a grifter selling phony privacy products with dramatically worse privacy and security than an iPhone. They're scamming people with false marketing for their products. The supposedly private speech-to-text service from Murena actually just sends user data to an OpenAI service vs. iOS and GrapheneOS doing it locally which is very representative of their overall approach to the apps, services and OS.
GrapheneOS is the only open source privacy and security hardened mobile OS based on AOSP in practice. Products using privacywashing for marketing aren't in the same space. They're not allies but rather the misinformation they propagate and the attacks they make on our team are extremely harmful to us. They're the main adversaries. Companies like Microsoft tend to be very friendly to us and open to collaboration vs. these small companies building a business around false marketing who feel very threatened by us so they engage in spreading misinformation and personal attacks on us. Claiming that it's state sponsored is ridiculous. It has been ongoing since long before GrapheneOS had significant adoption and has always been primarily caused by companies who feel threatened by GrapheneOS trying to harm it. Multiple companies have engaged in it because it's very convenient for them to hop onto the existing bandwagon of fabrications/harassment started in 2018. The privacy and security industries are filled with charlatans and scams. We have good relationships with a bunch of legitimate privacy and security projects including QubesOS, secureblue, Molly, Accrescent and MANY others. It's these companies selling supposedly private/secure phones which are in reality not very private and extraordinarily insecure where nearly all the attacks originate from.
> Rather than reading this as "harassment", I would suggest you should try to take it as constructive feedback: You do not play well with others and your prickly interpersonal demeanor hampers the adoption of what is (by all accounts) technically strong software.
It's libelous harassment content based on fabricated stories. You're claiming it's not happening while directly engaging in it. You're making the ridiculous claim that it's from state actors while the actual perpetrators are plainly visible and include yourself. It's the community around /e/ and several other projects which are extraordinarily toxic and engaging in harassment. Our community and project doesn't do it. You folks cross-reference your libel, bullying and harassment content entirely based on making up stories, personal insults, etc. while claiming a bunch of fabrications referencing each other is evidence. Calling me paranoid, delusional, etc. with no basis is nothing more than sociopathic bullying. Hacker News moderators shouldn't be allowing it.
Please print out this comment and the one that preceded it and show it to a friend you trust to be honest. You should seek therapy, and it will make you a more effective technical leader.
I'm surprised Graphene foundation haven't banned or heavily restricted Daniel Micay from publicly representing GOS. He's fine when he's providing product updates and technical information but he absolutely needs to see a therapist. I know he's been told this a million times and I'm not sure if he takes it serious enough. If he doesn't do something about this behaviour, his spiraling will be the downfall of GOS.
It's a misconception that GrapheneOS is focused on security over everything else. It's a privacy project and privacy depends on security so it heavily focuses on both. It also provides major privacy improvements on a technical level rather than only avoiding privacy invasive apps and services. Privacy involves a lot more than which apps and services are bundled with the OS, contrary to how most supposedly private phone options are marketed.
> Securitywise it's hard to argue against them, although GOS tends to sacrifice usability in favor of security, which leads to odd decisions.
GrapheneOS doesn't make any major usability sacrifices for security. Privacy or security features with usability compromises are either opt-in or opt-out.
> Worth noting however is that usage of GOS is also seen as a signal in and of itself for the authorities that you may have something unsavory to hide
GrapheneOS is far more widely used than most alternate mobile operating systems and there's a lack of basis to claim that it's widely seen in the way you're describing in a way that other operating systems are not. In fact, they're largely conflating other operating systems with GrapheneOS because it's the most widely talked about and known about. They're calling devices GrapheneOS devices which aren't running it. In many cases it's not even a fork of it.
> have said that the OS is popular with organized crime
This is completely unsubstantiated and not evidence has ever been provided. On the other hand, it's known that law enforcement in Europe has widely sold devices to organized crime which they marketed by claiming they were based on GrapheneOS:
Using portions of our code doesn't make something GrapheneOS and marketing is also a different thing than reality. Most of what's claimed to be GrapheneOS in this context is not GrapheneOS but rather trademark infringement by forks or even non-forks.
> /e/OS (and similar "non-LineageOS" ROMs really) instead focus more on de-Googling.
Nope, /e/ always connects to multiple Google services regardless of configuration and gives highly privileged access to them. GrapheneOS doesn't connect to Google servers by default and avoids giving privileged access to installed Google apps via our sandboxed Google Play compatibility layer.
> They're still generally security focused.
No, that's definitely not the case. /e/ has absolutely atrocious security and fails to provide even basic security patches and protections. This is also part of why it provides poor privacy due to lagging far behind on privacy patches in addition to security patches along with being missing important standard Android privacy and security protections due to being far behind and not having it all set up. /e/ doesn't provide comparable privacy features to GrapheneOS Storage Scopes, Contact Scopes, Sensors toggle and far more not only the security features. /e/ isn't just not a security hardened OS, it's also not a privacy hardened OS. LineageOS has better privacy and security than /e/. AOSP has better privacy and security than LineageOS.
> Because of this, they usually have better depreciation timelines
/e/ doesn't provide proper updates for any devices. Many of the devices they support aren't getting driver and firmware updates from them even when they're available. They lag far behind on kernel, Android, Chromium (including WebView) and other updates too. They support many devices without kernel, driver and firmware updates available but they're usually way behind even when they are. /e/ simply doesn't care about providing basic privacy and security so they continue having people buy and use highly non-private and insecure devices lacking basic patches.
> Finally, it's worth noting that the GOS community is absurdly toxic to anyone doing anything privacy-related that isn't under the banner of GOS. It's extremely maximalist, tends to get very upset at other projects whenever they get attention (see sibling reply to this, where they pretty much melted down because an outlet dared to recommend a Fair phone+/e/OS) and the projects official channels have generally encouraged this sort of behavior. It doesn't really damage the software itself, but it's worth considering.
No, completely backwards. The massive amount of false marketing, misinformation and harassment engaged in by the /e/ project and community is what's toxic. The founder and CEO of /e/ and Murena openly spreads content from Kiwi Farms and neo-nazi sites. He directly engages in harassment towards the GrapheneOS team. Here's him supporting authoritarians smearing GrapheneOS by replying to threads about it linking to harassment content based on fabrications on a neo-nazi conspiracy site:
The communities of several projects including /e/ have heavily engaged in spreading misinformation about GrapheneOS including fabricated stories about our team. They've even taken it to the point of repeated swatting attacks aimed at killing our team members. There are relentless raids on the GrapheneOS community platforms including our chat rooms where Child Sex Abuse Material, gore and endless harassment towards our team members including fabricated stories and harassment content from Kiwi Farms and elsewhere is posted.
People should review https://eylenburg.github.io/android_comparison.htm which is a third party maintained comparison between AOSP-based operating systems which addresses many of the misconceptions you have about how GrapheneOS compares to AOSP, /e/ and other operating systems. You're not at all correct about what's provided by /e/ which fails to keep up with basic updates or provide the standard protections.
We can provide large amounts of further examples of the founder and CEO of /e/ and Murena participating in this harassment.
The attacks towards us including your libelous claims about us here are what's absurdly toxic.
> It's extremely maximalist
It isn't but rather is very pragmatic and focused on usability, robustness and compatibility alongside the major focus on privacy. The focus on security is to protect privacy because it depends on it.
Given I don't disagree with you about GOS being the best on security, I think there's only one thing really worth mentioning:
> The attacks towards us including your libelous claims about us here are what's absurdly toxic.
I want to make this clear upfront: I have no connection to /e/, Calyx, DivestOS or whatever other projects you've had issues with over the years. If you've had trouble with them I find that very unfortunate for you, but they are entirely unrelated to this conclusion. I do not consider these claims to be libelous when they're fairly easy to check:
The reason I consider GOS' community to be extremely toxic and find official channels enabling this is for a few very simple reasons:
1. I've seen several incidents of GOS users coming into adjacent Android communities to start beef with those communities while giving off the attitude of zealots. For a concrete example, the F-Droid forums have a thread about Googles impending changes to letting users install their own software ( https://web.archive.org/web/20250903081432/https://forum.f-d... ). The original OP for this thread has a pointless attack on the F-Droid project, declaring GOS to be superior. Moderators eventually changed this to be more mild (but it's why the first replies are snarking on low-hanging fruit about GOS), but I've seen similar behavior in other places - there's a reason that a lot of Android communities generally respond with trepidation and annoyance whenever the project is brought up and it's because of this behavior from the userbase.
2. I can read the GrapheneOS forums; they're public. Nearly every issue I've seen people have with GOS on the forums is effectively met by a "you're holding it wrong". This sets a tone for the community that makes it come across as extremely hostile to potentially interested users.
3. In the same sense, it's trivial to notice that the official GrapheneOS account on this forum is a frequent participant in these discussions, generally backing up the hostility on the virtue of technical accuracy. This to me suggests endorsement of this attitude. (See a sibling to my initial comment where the official account makes a post on the GOS forums about an unrelated blog for daring to recommend a different ROM/phone combo. This to me is not indicative of healthy communications, but rather of an obsession to promote GrapheneOS at every corner.)
4. I remember, as a Bromite user, the futzing with the Vanadium license in order to prevent other Android Chromium forks from making use of it's patches for the crime of... considering a contribution from someone the GOS project has beef with. That to me is the most telling thing really. The goal with that license futzing was never to actually help advance privacy/security or anything like that. It was to try and force a different project to conform to GrapheneOS' demands over something extremely minor and GOS went ballistic and threatened license changes (which they eventually did) the moment the maintainer asked for a bit more information because "GOS doesn't like this person" isn't enough to immediately warrant kicking someone off a project. Cromite (the fork of Bromite, as Bromite's maintainer went AWOL) still doesn't include Vanadiums hardening patches because of this. It's fucking absurd.
4 is the big one for me. It is absolutely unacceptable, unbecoming and to put it plainly: toxic behavior from an official voice in the project. It's fucking rich and borderline hypocritical to talk about GOS' consistent upstreaming of Android hardening patches while making it impossible through a license change for other projects to share it's contributions.
I think it's more of a marketing claim from less secure systems that "privacy is not security, and GrapheneOS focuses on security while we focus on privacy".
GrapheneOS does care about both, quite obviously. And GrapheneOS tends to say that if your security is bad, then it is affecting your privacy too. Whereas others say "sure, we break the Android security model by unlocking the bootloader and signing our system with the Google test keys, but your apps will contact Google through microG instead of the Play Services, so it's more private". Which is worth what it is worth...
> I think it's more of a marketing claim from less secure systems that "privacy is not security
I'm not sure Cyanogenmod had a marketing team that convinced me of anything when I first installed their rom in 2013 and explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS, you can only use the Android APIs, same as on stock
1. If you care about privacy, you should care about security. If your email server is compromised and your emails leak in the public internet, then they are not private anymore.
2. GrapheneOS does care about both security and privacy.
> explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS
I think you're talking about something like "freedom", here. GrapheneOS doesn't claim to give you the freedom to do whatever you want. In fact, part of the Android security model is to limit your freedom.
Which is not to say that you should not want the freedom to have root access on your phone. But if that's what you want, GrapheneOS is probably not it.
My phone isn't my email server though? It's not exposed to the public internet. It connects outwards but you can't simply connect inwards to the IMAP client
You can invert your logic as well: Why care about security without privacy? If your apps are leaking everything to the internet, what's there to keep secure. One could argue this is the essential dependency, not the other way around, since security depends on the threat model but, without privacy, there's no more secrets
> I think you're talking about something like "freedom", here
In part, as well as a means to an end, yes. (GrapheneOS uses this as well, since without the freedom to bring your own OS, they couldn't run on Google's devices. I would think we all enjoy having the freedom to do what we want with our own hardware.) Note also the part where it says "provide fake data to tracking apps": that's privacy which GOS doesn't offer but a user root device / any desktop OS would
> You can invert your logic as well: Why care about security without privacy?
That's EXACTLY my point here. GrapheneOS cares about both, because GrapheneOS considers that they go together.
People come and say "GrapheneOS doesn't understand that people care about privacy and not security, therefore people are happier with less secure systems like /e/OS because /e/OS doesn't care much about security but cares about privacy".
My point is that I care about both, and I am therefore happier with GrapheneOS because GrapheneOS cares about both.
> Note also the part where it says "provide fake data to tracking apps": that's privacy which GOS
GrapheneOS offers such privacy features (like giving a permission to the app but telling the system to feed it dummy data). But yeah, maybe it's not exactly doing what you want (actually it sounds more like you just don't know what
GrapheneOS can do, but it's not stopping you), therefore you can probably go around and claim that "GrapheneOS doesn't provide privacy", because why not?
This is only my opinion, but GrapheneOS's approach to privacy seems obtuse to me. They will claim that an unlocked bootloader is a risk, but then turn around and recommend you install proprietary apps GApps in their sandbox. The sandbox doesn't matter if all the private data is in the same sandbox!
> recommend you install proprietary apps GApps in their sandbox
They don't recommend you to do that.
They tell people that if people want to install apps, Google Play Store is a secure and easy way to get apps.
They inform people about this because some have the misconception that using the Play Store defeats the whole purpose of GOS (which it doesn't) or that the Play Store is highly problematic (it's better than most alternatives).
But, the user itself is free to decide what they do. If you look at project members of GrapheneOS, some say they use Play, some say they don't.
> The sandbox doesn't matter if all the private data is in the same sandbox!
That's not how sandboxing works. The sandbox is around the app. Each app is in the sandbox. On GrapheneOS even the componenents of Google Play (Play Store, Play Services and on older installs Play Services Framework) are sandboxed. On Android OSes that bundle Google Mobile Services (GMS), Play gets an exception and is a priviliged app. On GrapheneOS they are regular apps. They are each put in their own sandbox. The access of each is controlled by their own set of fine-grained run-time permissions.
With all due respect, you fundamentally misunderstand how sandboxing works, even on Android in general. I recommend reading this to understand sandboxing in the AOSP: https://source.android.com/docs/security/app-sandbox . On GrapheneOS the sandbox is hardened a bit, but that's not the most significant feature of the OS at all, and Play is forced to run sandboxed if users choose to install it.
Feels like you don't know what "the sandbox" is. It's not "their" sandbox, it's from AOSP.
When you run an app on Android, it runs in a sandbox. Meaning that your social media app cannot access the files of your banking app by default. They are "sandboxed".
On a normal Android, the Play Services are installed as a system app. It is privileged app that has "system" access. A system app is not sandboxed.
GrapheneOS allows you to install the Play Services and the Play Store as "sandboxed" apps in that they run unprivileged, just like WhatsApp or TikTok or your banking app.
So running the proprietary Google apps in the sandbox is obviously more private than running them as system apps, wouldn't you say?
If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
I agree there's some marginal benefit that sandboxed GApps need to prompt the user for permissions (rather than having privileged system level access) but at the end of the day, Google Maps will get GPS perms and Google will know everywhere your phone goes.
> If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
Sure, but that's the same if you run TikTok with microG (which will relay your data to the Google servers just like the Play Services) or in waydroid on a Mobile Linux. But you can't blame the system for what the apps are allowed to do by the user.
Take your Google Maps example: if the user wants to run Google Maps, obviously they will be sharing data with Google. It's very weird to blame the system for that.
What the sandbox brings is that for users who want to run the Play Services (because they want to run TikTok, knowing that it will share data with some servers, including but not limited to the Google servers through the Play Services), then at least the Play Services are not root on their OS. So then instead of running microG, you can run the Play Services and have the same kind of benefits.
Now if you don't want your apps to contact Google, then by all means, don't install the Play Services! But don't install microG either! And don't install Google Maps!
It's all about trade-offs, it's not an all or nothing situation. Sandboxed Play Services is better than privileged Play Services.
I agree it's about trade-offs. I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
You're of course correct that we can't blame the system for choices made by users, but I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play
Regarding location, please see my comment higher in the thread about the location rerouting through GrapheneOS.
Also, it's not a better option to use MicroG. MicroG is in most OSes where it's bundled running priviliged and still connects to Google. Moreover, their reimpementation isn't complete and also not as well odne as Google's.
> encouraging users to install sandboxed GApps
What you link isn't an encouragement at all. It's offered as an option, because there is a demand for it in order to keep compatability with apps high. It's a usability feature (compatability) that's implemented much more securely and privately than on other OSes because it runs in the sandbox. Users are not forced at all to use it nor are they pushed to it.
Not all GrapheneOS project members (devs and moderators) even use Google Play, so how would they be "lulling us into complacency".
> focusing on the security angle only
The app sandbox isn't only a security feature, it's a privacy feature. Access to your data is gated behind permissions due to the sandbox. This is privacy.
> I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
microG still forwards the requests to the Google servers. Not sure what you mean by "tracking APIs"? microG is a reverse-engineered, open source implementation of a subset of Play Services, right? It's not obviously a better option: for instance, some things that are supported in Play Services are not supported in microG, and microG sometimes breaks (because of changes in the API).
> allows you to select alternative Location Providers
GOS does that, too.
> I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps
I don't get that. It does not encourage them to install Play Services, it makes it available. Because for many (most?) users, it is important to have it.
I am not sure what you are trying to say: is your opinion that there is no point in using an alternative OS (like GOS, /e/OS, LineageOS, IodeOS, ...) or are you trying to say that GOS is not the most secure/private alternative OS?
I'm trying to say the same thing I said up at the top: GOS's approach to privacy is obtuse. They deliberately conflate security with privacy (you even write "secure/private" as though they're the same thing) in a way that does a disservice to users.
My opinion is that GOS is very successful at its own stated goal of having an extremely secure mobile OS that rolls out patch updates quickly. I think it's far less successful at protecting user privacy because — as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play and help them securely upload their personal data to the world's biggest adtech firm.
I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
> as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play
I installed the Play Services right away, just like I installed microG right away on a LineageOS system (I don't know about iodeOS, but /e/OS comes with microG by default). In terms of privacy, I don't think it is very different: microG is an open source implementation of the Play Services, that also contacts the Google servers. Many will use something like the Aurora store, which is a client for the Play Store. Etc.
GrapheneOS has proxies, e.g. for the location service. They are doing a lot for privacy, that's very clear.
> I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
And that's your right. I think that GrapheneOS is more secure, and not less private than those. Actually in my experience with /e/OS, it was less secure than Stock Android (though more private, admittedly).
> They deliberately conflate security with privacy (you even write "secure/private" as though they're the same thing) in a way that does a disservice to users.
That's not really true. In fact, the way you are presenting it, as if they were seperate is doing a disservice to the reality and therefore to the users.
You can't have privacy without security. Security is what enforces the privacy. If your system is insecure, privacy controls can be bypassed.
> 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.
GOS' "own stated goal" is privacy, security and usability. The main reason the project is made is to give people privacy, and the reality is that in order to give privacy you need strong security. Usability is also striven for by trying to match other mobile OSes in app compatability and accessibility features (the latter being a current work in progress with TTS and STT coming soon).
> 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.
Many people are able to use their phone fine without installing Google Play. It depends on choices people make. If you use a different set of apps not relying on Play, it's perfectly possible to use it. If you care so much, just change the apps you use. Also installing Google Play doesn't equate to "securely uploaidng their personal data to the world's biggest adtech firm". Again totally misunderstanding how the app sandbox works.
> I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
Unclear what you want. If you want something aligning to your vibes and ideology, probably. If you want privacy, not really.
Sandboxed-Google-Play is not encouraged or promoted. It is suggested if you need apps only accessible via Google Play or needing Google services purely because it provides the maximum compatibility. GrapheneOS have always said that Android's strnegth is a large wealth of open source apps (many of which do not need Google). If more everyday apps (media streaming, taxi, food delivery & rewards, banking, government, social media) did not depend on Google, GrapheneOS would not spend the time, resources and effort that they have on sandboxed-google-play.
Communication between apps using IPC happens on mutual consent and is explicit. You can't just throw data to Play Services and expect it to accept it and process it well, that's not how it works. Communication via IPC is always very intentional and specific, so it will be very structured data for specific purposes, not just a dump of all your data. Firebase Cloud Messaging (FCM) is a push messaging service, it doesn't need to be used to send the actual notification. It's perfectly possible to just use FCM to wake the device and then handle notifications by yourself as app. The way FCM can be used is much different from Apple's system. Apple forces you to use their services for notifications while Google allows you to use FCM just for waking your device. It's also possible for apps to not use FCM at all and to just use WebSockets or UnifiedPush.
If you just grant Google Maps location permission and don't give it to Play Services and keep your sandboxed google play settings to the default, the location requests are rerouted through the GrapheneOS servers. If you want to use network location to get quicker location locks and location indoors, you can also use GrapheneOS network location, so you don't need to use the Google implementation for that.
And, even if you would decide to use Google directly for the location, you can perfectly avoid giving permanent location access. You can hand it over only once or only when the app is in use. So Google doesn't know everywhere your phone goes, at all.
They recommend you install google play services if you need it. Privacy is in no small part a user-decision - no matter how secure your device is if you just scroll Facebook all day.
GrapheneOS is primarily privacy project. It keeps up with important Android updates with major privacy enhancements and very important privacy patches. It builds crucial privacy protections such as Storage Scopes, Contact Scopes, Sensors toggle and much more into the OS. Privacy depends on security so security protections and security patches are part of providing strong privacy too.
It's a misconception that GrapheneOS is focused on security over privacy. It heavily works on privacy features and the work on security features is entirely to protect privacy. There's widespread use of commercial exploit tools and GrapheneOS is proven to provide far better real world protection against those. Most alternate operating systems reduce privacy from AOSP and massively reduce security while GrapheneOS is preserving the baseline and heavily improving both side by side.
GrapheneOS is also very focused on usability and app compatibility, making sure to preserve those with the major privacy and security enhancements.
The #1 security problem your average Android user face isn't an attack by some Israeli firm but data leaks by advertisers and unless I missed something (it's possible), GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.
Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.
I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.
>GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
Content filtering is built into the browser. GrapheneOS have always maintained that you cannot prevent an app from exfiltrating data, especially if it has internet access. Enumerating badness is an unsustainable approach they don't want to encourage. Instead they attack the heart of the issue with Storage Scopes/Contact Scopes/Network Permission/Sensors Permission etc. They allow aps to think they have full access when they do not, so you can control exactly what data they get in the first place. Maybe all of the other AOSP projects could contribute App Communication Scopes/Enhanced Clipboard Privacy and other things because this approach makes a lot of sense to me. Like preventing an illness instead of wasting energy treating symptoms.
>The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
Something similar was addressed some years ago as a feature request for GrapheneOS https://github.com/GrapheneOS/os-issue-tracker/issues/284. To summarise there was no way to do this without an unacceptable security cost to the OS, but this is sort of doable if you run your own userdebug build which you have the power to do.
> Something similar was addressed some years ago as a feature request for GrapheneOS https://github.com/GrapheneOS/os-issue-tracker/issues/284. To summarise there was no way to do this without an unacceptable security cost to the OS, but this is sort of doable if you run your own userdebug build which you have the power to do.
It's badness enumeration which is an unworkable approach to providing strong privacy. It fundamentally can't provide it, only weak case-by-case improvements which are very fragile and trivially bypassed. It can also be done by modifying APKs instead of having a hooking framework within the OS heavily compromising security. You don't need the OS providing anything to use arbitrarily modified APKs. We also don't want to give apps a legitimate reason to ban GrapheneOS as opposed to being able to convince the tiny number of apps enforcing Google certification to allow it.
> You don't need the OS providing anything to use arbitrarily modified APKs. We also don't want to give apps a legitimate reason to ban GrapheneOS as opposed to being able to convince the tiny number of apps enforcing Google certification to allow it.
I think you said the truth out loud, a rom which tries too much to fight for your privacy would just be banned. (And I do agree with that)
Protecting strong privacy conflicts with the kind of hooking features unable to actually protect privacy without being easily bypassed. The reason apps would ban doing that is due to compromising the privacy and security model for applications, not protecting user privacy.
Nearly the only thing which would potentially result in the OS being banned which is a legitimate privacy feature would be hiding that the Mock Location feature is enabled which is pretty much pointless since apps can ban the OS as a whole instead of only banning using them when Mock Location being enabled. Our planned per-app Location Scopes feature doesn't necessarily need to say that Mock Location is enabled but it should be possible for apps to detect so they don't have an excuse to ban GrapheneOS as a whole. It's far better that they ban using Location Scopes than banning using GrapheneOS at all. We could make our own API for detecting it's enabled so that apps detecting Mock Location work but apps aware of GrapheneOS can choose to ban Location Scopes rather than banning GrapheneOS. We aren't going to do something which simply hurts users should reducing the apps they can use for no actual benefit.
GrapheneOS provides greatly improved privacy including through features like Contact Scopes and Storage Scopes.
> GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
Enumerating badness by trying to list domains which are solely used for advertising, telemetry, etc. doesn't address any of the main privacy invasive behavior by apps which is done through their own services and server side contact with third parties.
uBlock Origin has the same problems in the browser but the rules within a browser are a lot more flexible than the extreme limitations of domain-based blocking whether any useful purpose of the domain results in blocklists not being able to include it or apps would break. Domain-based filtering is also far less usable in practice and is typically not per-app either.
RethinkDNS on GrapheneOS works far better than the domain blocklist in /e/ but it's not a strong approach to privacy and does not address much.
Apps can easily work around it and prevent the filtering, as can the SDKs. One way is doing server-side connections and another is using DNS-over-HTTPS for DNS resolution. Facebook has fallback IPs and DNS resolution in a growing number of their apps and can do it in their SDKs too.
Using a fundamentally unworkable approach that's increasingly becoming less useful is not how GrapheneOS approaches privacy.
> The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
This is another fundamentally unworkable enumerating badness approach which is not how GrapheneOS approaches privacy. GrapheneOS avoids apps getting access to sensitive data rather than trying to stop them sending it to specific places.
> I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.
GrapheneOS is a Linux distribution. Desktop Linux distributions have far worse privacy and security than GrapheneOS. The ports of desktop Linux distributions to mobile are largely losing even more security. That's a huge setback for privacy and security, not progress. They don't have similar privacy protections, don't have a similarly strict approach to privacy for default services and lack security to keep privacy intact. Using mostly or only open source software doesn't mean you don't need privacy and security protections. Aside from that, the open source mobile app ecosystem for Android and GrapheneOS is far better than it is for those operating systems.
> Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.
GrapheneOS provides drastically better privacy and security than the desktop operating you think are better. It has a great open source app ecosystem available with lots of high quality apps. You're portraying it as if people must use privacy invasive apps but that's not at all the case. Plenty of desktop users are using apps like Discord where they can access the entirety of their data as opposed to GrapheneOS where it's a heavily sandboxed app with lots of user control along with prevention of coercion to get access via the scopes features we add for pretending to grant permissions while actually granting access to no files/media/contacts by default where it simply appears there are none until users explicitly opt-in to adding them.
> I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.
Waydroid has far worse privacy and security from Android apps than running them on AOSP or especially GrapheneOS. It loses the Android app sandbox and permission model. It uses a very outdated fork of AOSP and breaks the privacy/security model through how it's implemented. It runs on top of a far less secure host OS with worse isolation for the apps inside it from the rest of the OS than exists on Android itself. Moving to a drastically less private/secure host OS while running Android apps in a much less private/secure way is hardly progress.
> Using a fundamentally unworkable approach that's increasingly becoming less useful is not how GrapheneOS approaches privacy.
I feel like we agree on the premises but not the conclusion then.
If there's no way to make a Revanced on steroids system work on Android, it means that Android's security model is fundamentally broken for me and beyond repair.
Fundamentally, Android is built with untrusted as its core value. Google doesn't trust Qualcomm, which doesn't trust the manufacturer, which doesn't trust app makers, which doesn't trust the user. It's a chain of untrusted parties all the way to the user. With one single exception, in your average phone, the user has to trust all the the above. So the user is the one trusting everybody blindly and nobody else has to do it.
The only way to make this untrusted chain model work is to go one step further, make the user not trust all of the above with a heavily modified system, including dynamic patching and that's almost impossible.
The reason why it works differently on a Linux distribution is it's built on the opposite values. The maintainers trust contributors which trust app makers ... all the way to the user. If one of them breaks that trust, they are out for good, they know they have one chance and this makes the stack fundamentally less hostile.
You can't easily fix a broken social contract like in Android with just tech.
Since you seem to be one of the developers, one thing that I wish Graphene focused on more is browser fingerprinting. This is is probably the number one threat against privacy nowadays. Vanadium is very usable, but it seems to be quite easily fingerprintable.
GrapheneOS does focus on browser fingerprinting with a long term approach that's being implemented. That's why adblocking is implemented the way that it is with a specific list of filters and then regional/language filters activated based on which languages are enabled. Vanadium does provide good protection against instances of Vanadium being distinguished from each other in ways other than the IP addresses, language, time zone, etc. Adding support for using a universal UTC time zone in Vanadium is one of many planned features for countering fingerprinting. Expanding the Vanadium userbase beyond GrapheneOS would be the main way to reduce fingerprinting since it heavily depends on the number of people using the browser so we eventually plan to launch it for use outside of GrapheneOS once it has more features.
Brave has the best anti-fingerprinting on Android right now but it's not all implemented in a good way and they have a lot of features with privacy and security downsides too. Vanadium is gradually working towards having stronger anti-fingerprinting than it. It will take time. In general, our approach is focusing on doing things properly with the long term in mind. It takes longer but the end results will be better as can be seen for what we ship in many areas. Our network-based location implementation is a nice example among many others.
Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans.
Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a little frustrating that they couldn't collaborate some base like this to the open source community.
> Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans.
We're in the process of hiring a bunch of full time developers and will have more people working on Vanadium soon. The bottleneck isn't money but rather building out the organization and hiring people. We get a lot of donations and are going to be greatly expanding the project, particularly with the funding being offered by Vitalik Buterin for hiring 5 more full time developers.
> Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a little frustrating that they couldn't collaborate some base like this to the open source community.
Many aren't using permissive licensing and a lot of it is a mess that's not possible to include in Vanadium rather than making our own implementation that's more focused on correctness and maintainability. GrapheneOS is going to have an increasingly large amount of resources so we wouldn't get much from working with tiny projects. We could hire people to work on Vanadium instead. Working with Brave would be compelling but not much else. Brave has a lot of stuff we want but usually it's quite messy and complex compared to what we want to have. We're using work from Microsoft on Chromium hardening that's not used in Chrome / Chromium such as the WebAssembly interpreter.
I missed this in the bustle of this thread but that's fantastic news. Hugely appreciative of the work yourself and your team at GrapheneOS are doing and it is great to hear it will be expanding/growing too.
> 'privacy' browser projects based on Chromium for Android
As far as I know none of these projects have tackled the JS fingerprinting problem. The most earnest attempts seem to be Brave and Firefox with the Arkenfox user.js, but they have their own problems. The basic issue is that JS gives websites far too much control over the user's device. The JS spec should have never allowed websites control over the clipboard (e.g. to disable paste), to know if the user is active, when the mouse is being moved, etc. Since it is too late now, short of disabling JS entirely, there will be usability tradeoffs, but I think these are necessary (at least optionally) in an OS like Graphene.
Unfortunately, browsers have often done too little, too late when it comes to privacy. For example, until recently, most browsers allowed third party cookies by default.
GrapheneOS has a lot planned for Vanadium. It could become a project almost as large as the core OS project. We're going to be greatly expanding our team and that needs to happen before Vanadium can have substantially more changes than it currently does. Full state partitioning including for cookies is a much better approach than disabling third party cookies. Vanadium does disable third party cookies but that doesn't really do as much as you'd think because the way third party cookies are defined and what disabling them means is not intuitive. Third party cookies would not be a significant issue if cookies were fully partitioned by the top level site. Chromium has implemented state partitioning for the vast majority of the state but specifically not cookies by default where it's opt-in, so we need to handle that ourselves. They do support partitioned cookies but it's opt-in. Strictly partitioning cookies breaks a lot of cross-site functionality so no mainstream browser is doing it but rather they use heuristics to support cases like cross-site login and their partitioning is easy to bypass through that.
Fundamentally, almost all "innovation" in browser and JS development for the last 20 years has been about giving new powers to website authors, not to the people actually using the browser. The idea of telling website authors "no, you can't do that" seems to be anathema to browser authors and standards groups. The result is that they make it easy for website authors to wrap their content in shinier and shinier wrapping paper and then tell users how great it is that they can now see all that shininess. Probably 50% of what a website can do today is stuff we would be better off not having available.
And sandboxed Google Play services serve both goals -- it runs the service as a regular android service, not an exceptional one that has a bunch of extra permissions. So you can allow/restrict it as you seem fit, while not "getting behind" on features/apps that mandate it.
GrapheneOS provides major privacy enhancements including Contact Scopes, Storage Scopes, Sensors toggle, per-connection Wi-Fi privacy via per-connection DHCP state + MAC randomization and far more. It's a privacy project and privacy depends on security so it heavily focuses on protecting against exploitation of privacy and security vulnerabilities too. Privacy and security are not separate things from each other but rather closely tied together and our work is on both for the sake of improving privacy. Our only reason to work on security features is protecting privacy.
I won't argue with you on the project-related part of it, you obviously know best there :) Thank you for all the work!
But how would you "rate" for example desktop "GNU/Linux" with this in mind? Quite clearly privacy is important here and none of the major components leak/store unnecessary personal data. But the security story is quite sad, everything runs as the same user so a random `npm install` can just do whatever it wants with my browser caches, ssh keys, etc. I would say that GNU/Linux is privacy-friendly, but has terrible security. Would you not agree here? How does this fit with the "privacy and security are not separate things" part? Genuinely curious about your opinion here, not arguing for the sake of it, they are just not as closely connected in my mind. For example Google has a good track record of having safe practices regarding data storage -- but privacy is not their strong suit/hard to define what it means for a company to begin with.
I disagree, privacy is an essential part of security, if there's no privacy, then there's no security.
That's also why I don't keep anything important on my phone as I don't trust what's going on there despite having all the secure features that you would want.
Other way around, actually. It's possible to make concessions to privacy, like providing crash reports, or running applications in sandboxes which limits what they can harvest, while keeping the platform secure.
Any privacy you have on a system is reliant on no one tampering with that system and on software behaving itself. Without security, you can't trust the system to implement any privacy.
I also disagree with that, I trust my Linux distribution to behave well much more than I trust any Android platform and it doesn't even have much app sandboxing at all.
You can't fix a lack of trust like you have in Android with technical solutions. The flaw in Android is fundamentally a social problem.
There's a massive open source app ecosystem for Android which is far larger than the subset available in F-Droid. Open source does not imply private or trustworthy. Completely trusting applications with access to all your data with no insight in to what they're accessing or sending to services means you wouldn't know if your privacy is being violating anyway.
The (desktop) Linux security model is different. You trust the distro maintainers in the same way you trust the GOS devs, and instead of "app sandboxing" you use user accounts, containers or VMs to protect personal information. The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.
> The (desktop) Linux security model is different.
Desktop Linux distributions lack a viable privacy and security model for applications and far more. They don't have comparable protections against exploitation or comparable privacy protection as a systemic part of the OS either. The approaches are very incomplete and apps generally aren't contained unless they're run in another OS in a virtual machine such as the approach in QubesOS which is not really a Linux distribution but rather a Xen distribution acting as a meta-Linux-distribution. It can use Windows too.
> user accounts
This isn't an application sandbox and doesn't provide similar isolation for desktops.
> containers
Containers do not directly work for sandboxing desktop applications. It still requires that the UI and application layer of the OS provides sandboxing. Containers can be used to isolate things at the filesystem level, etc. as part of a sandbox but are not a sandbox for desktop applications on their own.
> VMs to protect personal information
GrapheneOS has hardware accelerated virtualization on all supported devices. Running a separate OS in a VM is a much different thing from providing a working privacy and security model within the OS. Using virtualization as part of an app sandbox that's integrated into the OS itself with a separate VM for each app is a far different thing than just running another OS in a VM.
> The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.
Android has a far larger open source app ecosystem for mobile than those operating systems. Open source applications still need to be sandboxed to provide reasonable privacy and security. Otherwise, you're not only trusting those applications and their supply chains to not do anything privacy invasive which does happen extremely frequently but also to avoid having vulnerabilities. The vast majority of applications do not take privacy and security very seriously so an OS not containing them and protecting them against exploits with modern exploit protections won't provide good privacy and security itself. Application vulnerabilities are the main attack vector for remote attacks. Open source software as an overall ecosystem is also not nearly as privacy respecting as you make it out to be. Most is not focused on privacy or security, which means they regularly do things which are privacy invasive to provide functionality and also aren't providing strong privacy or security protections at all.
In that it doesn't really exist. Sure, linux has all the capabilities to do it properly, but defaults matter in security so the way it currently works, basically every program has access to everything actually important (personal files, photos, ssh keys, etc). It just can't upgrade your GPU driver.
I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user.
You can't fix the lack of trust you have on Android with just sandboxing.
I do trust the Linux distro maintainers that they don't have nefarious purposes. But they can't and won't verify third party projects' code, nor the huge number of contributors that come and go on any of these projects, or their transitive dependencies.
As has been shown, it's almost trivial to get malicious code merged into open source projects, so not really sure where your "trust" comes from. It's not trust, it's naiveness.
The proof is in the pudding at the end of the day, how many privacy scandals Debian had vs how many privacy scandals Android had? One model seems to clearly work better than the other. Talk is cheap, I like to see the results.
And to answer your question, of course they can't check everything, that's why it's a model based on trust and not a model based on verify.
What would happen if let's say VLC would upload your user documents in the background? They would get nuked out of the repository and never be seen again. That's why apps do not tend to do that.
I'm not against sandboxing and a strong technical model myself, it's just that if I have to pick between a trust model and technical features, well the trust model wins hands down 10 times out of 10 as it has a better proven track record.
> The proof is in the pudding at the end of the day, how many privacy scandals Debian had vs how many privacy scandals Android had? One model seems to clearly work better than the other. Talk is cheap, I like to see the results.
You're drawing completely false equivalences between a specific OS and an entire ecosystem with tens of thousands of operating systems. For some reason you're including apps like Discord as part of your evaluation for the OS for Android but not desktop Linux. On desktop Linux, Discord gets access to everything. On Android, it's a sandboxed app. On GrapheneOS, it's a much stronger app sandbox with far better user control including features to avoid apps coercing giving access to files/media and contacts, etc.
> And to answer your question, of course they can't check everything, that's why it's a model based on trust and not a model based on verify.
Distributions aren't doing any significant review of what they package in practice. Debian ended up with backdoored sshd not because their review missed something in xz but because they don't review it in the first place.
Open source software very regularly has privacy invasive services and practices. It's very common and not at all rare. Actual backdoors and malware is rare but the same goes for proprietary software from reputable companies. Privacy invasive behavior is more common for proprietary apps. You're portraying it as if Android doesn't have a large open source app ecosystem when it absolutely does and as if proprietary software doesn't exist for desktop Linux when it absolutely does. The basis of all your arguments about this are these false premises.
> What would happen if let's say VLC would upload your user documents in the background? They would get nuked out of the repository and never be seen again. That's why apps do not tend to do that.
VLC is available as an Android app. VLC is not a privacy or security focused app. It doesn't provide strong protection against exploitation from maliciously crafted media files or malicious services. Running it on an OS with strong exploit protections for apps and a sandbox around it not giving it access to everything is very valuable. VLC on GrapheneOS has far stronger exploit protections including hardware memory tagging along with being in a very good sandbox. Users don't need to grant it access to most of their files and generally won't since they can use it without granting access to any files, grant access to specific indexed files types, specific directories or do it on a case-by-case basis.
> I'm not against sandboxing and a strong technical model myself, it's just that if I have to pick between a trust model and technical features, well the trust model wins hands down 10 times out of 10 as it has a better proven track record.
GrapheneOS has a large open source app ecosystem far bigger than what's available for non-AOSP Linux distributions on mobile. It has a strong app sandbox with a permission model that's getting increasing good both from upstream AOSP improvements and our growing privacy protections. Our Contact Scopes and Storage Scopes features are an approach we're taking for other permissions too to gradually phase out permissions where an app either works or doesn't work based on granting a specific permission even though it doesn't need to be that way. We took care of the main ones already but there's a lot more to do. This is very useful even for open source apps which rarely focus on privacy and usually doesn't care much about security. It's extremely valuable to avoid giving open source apps access to more than they need. You brought up VLC as an example which has atrocious security and is a great example of an app heavily benefit from sandboxing even if you fully trust not only the VLC developers but also the developers of the large dependency graph.
> I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user.
Nope, that's not actually how it works. In reality, there's little to no review of what's being packaged. The distribution packagers are additional trusted parties. You're also trusting the upstream developers and their dependencies which are largely not very interested in privacy and especially security. There's extremely little systemic work on privacy and security in desktop Linux operating systems which is why they still haven't fully deployed basic exploit protections from the early 2000s, let alone providing a strong privacy and security model with strong defenses throughout the OS.
> You can't fix the lack of trust you have on Android with just sandboxing.
Contrary to what you keep saying, Android has a large open source app ecosystem. Those open source apps run in a sandbox avoiding them being a single point of failure for the entirety of privacy and security of the OS. The vast majority of open source developers are not writing privacy and security focused software. Security is extremely neglected in the vast majority of open source projects and many do privacy invasive things. Open source does not provide privacy and security itself. Publishing sources under an open source license doesn't make software more private or secure itself. Most open source projects aren't getting significant privacy and security benefits from doing so since little of it gets deeply reviewed. Most projects do not get a lot of external contributions to the code. Open source code doesn't mean the developers aren't heavily trusted and only theoretically provides the ability to check everything extremely thoroughly which simply doesn't happen. If it worked the way you believe, there wouldn't be an endless stream of vulnerabilities being fixed which have often been present for a long time including years or decades. See https://lore.kernel.org/linux-cve-announce/ for a major example.
That's the difference between trusted computing (Linux distribution) and untrusted computing (Android).
If you want something backed by objective data, my phone has an advertising ID built in the OS and my laptop doesn't. My phone had 100s of privacy scandals and my laptop doesn't have one.
I do applaud GrapheneOS don't get me wrong but I have a feeling that they are fighting a losing battle.
There's a huge open source app ecosystem available for Android. The distinction you're trying to draw is inaccurate. Open source apps also very open do privacy invasive things. On Android, people can see that many open source privacy even including Signal include dark patterns such as repeatedly asking for access to contacts when it works without it. On a desktop OS, the apps and services will simply have access to nearly everything by default so you aren't aware of it happening for the most part.
GrapheneOS provides far better privacy and security than a desktop OS. There's no such thing as an advertising ID built into GrapheneOS so it's a strange thing to bring up. There are plenty of privacy invasive things built into desktop operating systems and applications, including open source ones. They nearly entirely lack the ability to protect against apps and services being privacy invasive in the first place. They also have far weaker protection against exploitation.
You're linking to Google Play's documentation, not Android code itself that GrapheneOS etc. are built upon
You can find hardware identifiers exposed by Linux distributions more than by Android itself. That Google adds a nice sauce on top... yeah that's a sorry state of affairs, but an optional layer if you don't use the stock OS if it ships with Google Play
edit: but I appreciate looking it up nonetheless! I wasn't completely sure that I hadn't missed that Android (AOSP) includes this now as well
You can't really use Android without the Google Play anyways so that's a moot point, none of the popular apps will work. Google Play is very much a core part of the Android OS.
You can perfectly fine use it without, many people do.
If you can tell us what issues you exactly bump into when trying to use the phone without Play, feel free to share, we might be able to suggest you some apps or workflows to work around the issues you are having.
GrapheneOS is a privacy and security hardened OS. It preserves the standard privacy and security of the Android Open Source Project (AOSP) along with keeping up with the updates. It builds major privacy and security improvements on top of that. /e/ is the direct opposite and reduces privacy and especially security compared to AOSP. /e/ doesn't keep up with updates, has huge delays for important privacy and security patches along with reducing privacy and especially security in many other ways. GrapheneOS is a much more widely used OS with much more testing and provides much broader app compatibility. Unlike /e/, GrapheneOS only connects to GrapheneOS services by default and provides a high level of control over it. /e/ still uses a bunch of Google services by default and gives extensive privilege access to Google apps/services. Our approach is that Google apps/services are an optional thing people can install which do not receive any special access and can't do more than other regular apps since they're installed as regular sandboxed apps on GrapheneOS via our Sandboxed Google Play compatibility layer.
A common misconception is that people believe GrapheneOS is less usable than much less private and far less secure options but it's the other way around. GrapheneOS provides nearly perfect app compatibility when taking into account the per-app exploit protection compatibility toggle and sandboxed Google Play. Nearly the only apps not working on GrapheneOS are ones banning any alternate OS and a larger number of those work on GrapheneOS than elsewhere due to a subset specifically permitting GrapheneOS due to far higher rather than weaker security. Apps have legitimate reasons for being concerned about the poor security of many alternate operating systems but they're wrongly grouping it all together as if GrapheneOS.
/e/ lags weeks, months and even years behind on providing updates for drivers, firmware, the Linux kernel and more. They miss a large portion of the monthly Android security bulletins which are a limited subset of the patches in the first place but then claim to provide the latest patch level despite many of the required patches being missing.
/e/ has a supposedly private speech-to-text sends data to OpenAI and their own servers without obtaining explicit user consent to share sensitive data with a third party.
They say the data is anonymized based on passing it through their own servers before OpenAI but OpenAI is receiving all of the user speech data under their usual terms of service enabling them to store and leverage it.
Fairphone lags significantly behind on OS updates and patches with only a small subset of what should be provided being shipped. Their hardware omits important security protections required by GrapheneOS which it uses to protect users against widespread commercial exploit tools. Fairphone doesn't provide upstream Linux kernel updates in practice which is a massive omission for their updates. Fairphone 4 has an end-of-life 4.19 kernel branch and the Fairphone 5 despite not being very old already has an end-of-life 5.4 kernel branch. Neither was providing the LTS revisions prior to end-of-life so from their perspective nothing really changed but it means it's a huge task for an alternative OS to provide basic updates since they'd need to port everything to a newer kernel branch.
/e/ does not provide similar privacy features to GrapheneOS such as Contact Scopes, Storage Scopes, Sensors toggle and much more. It focuses on bundling things which can be provided with apps such as RethinkDNS on GrapheneOS with a higher quality implementation. GrapheneOS delegates as much as it can to apps while focused on the core OS. If a feature can be done better with an open source app, we'd rather leave it up to that app and many provide privacy and security protections which apps cannot. For the most part, apps can't improve OS privacy and security. Enumerating badness via blocklists which cannot block anything that's dual purpose functionality is also a very weak approach to privacy which is increasingly less useful. The most privacy invasive behavior of apps is nearly all done through their own services which also provide their functionality. Among other things, /e/ uses this system for labeling app tracking and permissions which is incorrect and misleading as shown by this example:
Facebook clearly doesn't have no tracking but rather this system only detects a small number of specific third party libraries they've decided are trackers. Those choices are often very questionable such as portraying even opt-in crash reporting as tracking because it used a third party library on their list. Meanwhile, Facebook's lite app supposedly has no trackers. The permissions list is thoroughly inaccurate and not how Android permissions work. The core permissions are opt-in with apps having to request them so listing those as if they're granted on install and mandatory due to being possible to grant is incorrect. Most of the rest have special access toggles which are opt-in for the sensitive ones or other toggles such as the battery optimization mode where Restricted stops apps starting themselves and delays those things until it's run by another app or the user.
Privacy requires providing privacy patches and strong privacy protections. It also depends on security which means providing security patches and strong security protections. GrapheneOS is heavily focused on all of that rather than simply treating not having bundled Google apps and services as meaning a private OS. There are also worse things for privacy than Google apps and services. /e/ sending speech data to OpenAI vs. Apple doing the processing locally as we've it implemented for GrapheneOS is a good example. Google at least has partial local speech-to-text support and a better privacy policy than OpenAI for the cloud portion. Avoiding Google apps/services is not the same thing as providing strong privacy.
I use and appreciate GrapheneOS due to it being one of, if not the best, option we currently have.
That said, I do not like how much the project depends on Google.
- GrapheneOS is based on Android, which is solely developed by Google.
- GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
- They recommend using the Google Play Store (requires a Google account) to get apps and recommend against using F-Droid.
- Their Vanadium web browser is based on Chromium, which is controlled by Google. It also does not have an ad blocker or support extensions. They recommend against using Firefox. Firefox, and Safari to a more limited extent, are the only web browsers keeping Google from having complete control over web standards and the way we can access the internet.
This is not a criticism of the GrapheneOS project or developers. I understand that security is the biggest priority of GrapheneOS and I understand that Google is often good at security. They are following the goals of the project. It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered. Most users do not need security at all costs. Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
It does have a network-level ad blocker. What it doesn't have is a blocker which modifies/injects Javascript into pages, which iiuc is the main reason that the blocker doesn't help with ads on YouTube much, or pages which employ similar techniques.
> They recommend against using Firefox.
To clarify: they recommend against Firefox Mobile because it didn't support site isolation until last month's v147 updates. I don't know if the goalpost has moved since, but in any case: there's nothing on Graphene that would prevent you from using Firefox.
Firefox 147 doesn't provide site sandboxing or even basic content sandboxing on Android. They enabled multi-process support by default but still don't provide any form of sandbox for the separate processes. They enabled the separation part of site isolation which is partially implemented for Firefox desktop and now mobile but do not have content sandboxing and partial site sandboxing as they do for the desktop browser. See https://bugzilla.mozilla.org/show_bug.cgi?id=1565196 for their still open issue with many other issues as dependencies for sandboxing.
The complete lack of content and site sandboxing on Firefox for Android is only one of the reasons we recommend against it. It has major security deficiencies beyond this and cannot benefit from many of the hardware and OS protections due to it. Vanadium is much more secure than standard Chromium while Firefox is much less secure than it, so there's quite a stark difference between them.
Recommending against using Firefox and F-Droid due to major security deficiencies doesn't in any way reduce user choice as the post above portrays it. Having a lot of accurate information provided by GrapheneOS enables our users to make more well informed decisions. We also do not specifically recommend the Play Store as the post says above but rather we provide nuanced information about the available choices. Specifically for obtaining apps from the Play Store which aren't available directly from the developers, we recommend using the sandboxed Play Store for users who using sandboxed Google Play in a profile for app compatibility already. Play Store itself has signature verification while Aurora Store only has TLS with a smaller set of trusted CAs by default similar to many Google apps. Aurora Store is sometimes needed to work around app's filtering who can install it so we do recommend it for that specific purpose. Aurora Store still logs into a Play Store account and making a throwaway account to use the Play Store app doesn't reduce privacy compared to using sandboxed Google Play without one.
> GrapheneOS is based on Android, which is solely developed by Google.
GrapheneOS is based on the Android Open Source Project. It's incorrect to say it's solely developed by Google and it's open source software which we're free to change as we see fit.
> GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
No, we already have a partnership with a major Android OEM. It's not something we're working on obtaining and we've provided a fair bit of details including that it will be publicly announced by the OEM in March, that the devices will launch in 2027 and that they'll use a high end Snapdragon SoC which is either the flagship (most likely) or one step below it.
> They recommend using the Google Play Store
No, that's not our recommendation.
> recommend against using F-Droid
We recommend against F-Droid due to it being an unnecessary middleman between users and app developers which does not truly reduce trust the app developers. F-Droid apps are consistently out-of-date and often lag months being on important privacy and security fixes. F-Droid consistently makes problematic undocumented changes to apps including rolling back dependency updates. F-Droid is known to use highly outdated build infrastructure which is very poorly secured. They have a bunch of bad security practices throughout their approach and have made it clear it isn't a priority for them. They've repeatedly said they don't believe app sandboxing is useful and much more than that. Many open source apps including Signal and WireGuard have asked to have their apps omitted from F-Droid due to the security and trustworthiness issues with the project. That's not at all something specific to GrapheneOS.
> Their Vanadium web browser is based on Chromium, which is controlled by Google.
Chromium is an open source project which is collaboratively worked on by multiple projects using it as the basis for their browsers. That includes Microsoft who implemented the WebAssembly interpreter available in the upstream Chromium codebase which is used by Vanadium but is dead code in Chrome and regular Chromium builds since it was added for Edge.
> It also does not have an ad blocker
No, that's not true. Vanadium has a default enabled ad blocker which uses EasyList, EasyPrivacy, EasyList's Adblock Warning Removal List and also selectively activates a whole bunch of EasyList affiliated language/regional lists based on the currently active languages. This approach avoids adblocking being used for fingerprinting, avoids greatly weakening site isolation sandboxing as extensions do and is much higher performance which is important on mobile. It very clearly has ad blocking and a per-site toggle for it.
> or support extensions
Extensions greatly weaken site isolation and give third party code without verified boot extensive access to website content similar to dangerous Android accessibility service apps. Very few extensions are focused on privacy and security in a similar way to GrapheneOS and would compromise what we're trying to build. It's not the approach we want to use in Vanadium. If you want to use extensions then you can use a browser with them but it doesn't fit into what we're building with Vanadium where we want to implement features ourselves in a very private, secure and robust way which cannot be done with extensions. Extensions fundamentally reduce security including because they used a shared process across all isolated websites which inherently reduces isolation. Few extensions take this seriously, even the ones focused on privacy. They commonly add leaks between sites. There are plenty of other browsers available but ours is aiming for a standard of privacy and security which cannot be achieved with extensions.
> They recommend against using Firefox.
Firefox's Android app has atrocious privacy and security. A browser without even basic content sandboxing let alone sandboxing with full site isolation. That's combined with major other major security deficiencies and it isn't something we could recommend using. Recommending against it doesn't mean people can't use it...
You'll still be using Vanadium as the web content engine within apps using the WebView such as email clients rendering HTML email and many more. Many people have a misunderstanding of what the WebView is and confuse it with custom tabs which are provided by the user's selected default browser rather than the WebView used within other apps.
> This is not a criticism of the GrapheneOS project or developers.
How isn't it criticism of GrapheneOS? Regardless, Vanadium does have an adblocker and we don't specifically recommend the Play Store as you said. The biggest issue is that what you're saying about what we prioritize, advise or provide isn't accurate.
> I understand that security is the biggest priority of GrapheneOS
Privacy is the biggest priority of GrapheneOS and privacy depends on security. GrapheneOS is a privacy project.
> It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered.
Our project and community regularly recommends iOS as an alternative which provides far better privacy and security than non-GrapheneOS options. Most other options have very poor privacy/security including lacking even basic privacy/security patches and protections. Similarly, our project and community regularly recommends using macOS for better privacy and security than either Windows or desktop Linux. What you're saying are blind recommendations are anything but that but rather very well informed information provided by the GrapheneOS project.
> Most users do not need security at all costs.
GrapheneOS is not about security at all costs and this misconception which regularly comes up that it's about security rather than privacy is completely wrong. Many projects failing to provide decent privacy treat it as if privacy is solely about which apps/services are bundled rather than needing to provide privacy patches, privacy protections and solid security to protect that from being bypassed. Much of what GrapheneOS provides are privacy features such as Contact Scopes, Storage Scopes and the Sensors/Network toggles along with much more. The security protections it provides exist to protect privacy. Why else would the security protections be there other than to protect privacy? It's not a separate thing from privacy but rather is a huge part of providing it. There's no other reason for us to work on security than protecting privacy. It doesn't make sense to say we work on security instead of privacy.
Most users do need basic privacy/security updates and protections. Failing to keep up with basic updates and misleading users about it is a severe issue. There isn't any major non-GrapheneOS AOSP-based OS that's doing the bare minimum of keeping up with updates.
> Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
You aren't accurately representing what GrapheneOS provides, our approach or our priorities. People can see for themselves from the detailed article that it provides a highly usable and compatible system with a huge amount of user choice. People can choose from a wide range of approaches based on their privacy and security goals. It doesn't impose choices on people. You treat it as if people are forced to use Vanadium when it's another choice of browser which people have on GrapheneOS but not elsewhere. GrapheneOS users have more choice among browsers and the one we have DOES provide ad blocking contrary to what you said. GrapheneOS users can use F-Droid despite us recommending against it due to the major security deficiencies. Providing well informed recommendations with detailed explanations does not in any way hinder user choice but rather informs people so they can make better choices. Our recommendations not aligning with your personal beliefs or preferences doesn't mean we're somehow reducing user choice.
The main problem with the Pixel phones, along with most Android phones these days, is the lack of a μSD card slot and a 3.5mm headphone jack. When I recently had to purchase a new phone, I had to go with a Motorolo G, as it had both of those features.
There are some problems with this, often if a microSD card is used the storage on that SD card isn't encrypted because of the portability goal of it. It would be a bad fit for the project. As per the headphone jack, the headphone jack is much less durable than a USB-C port and has less use cases. Two USB-C ports on a phone would be nice however. For audio with audio devices not accepting digital audio in you would need to add an adaptor with a DAC in between but this is mostly good for audio quality given that those DACs often have better quality than the ones built into the phones. This is my opinion though, you may have different needs.
GrapheneOS is partnered with a major Android OEM working on improving their future devices to meet our requirements. The first devices with official GrapheneOS support from them are planned for 2027. It takes time and resources to make reasonably secure devices. Future generations can improve further including adding hardware-based privacy/security protections unavailable on Pixels.
One thing that is a game changer on GrapheneOS is the network toggle for apps. Turn off network access for your keyboard, camera app, calculator, files, etc.
That's not at all a similar approach so it doesn't quality as "if anyone wants *this*). The GrapheneOS feature pretends the network is down and local host is also inaccessible. This is good for compatability (apps generally take into account that a network can be down) and too avoid apps knowing you are using the feature.
As long as it is based on AOSP, it is at the mercy of Google to release source code and updates. Given recent trends, I wouldn't be surprised if Google stops shipping Android source completely.
I would love if there were a different OS name to designate "Android phones with Google Services snooping in the background" but with the Android Open Source Project being called what it is, I fear "Android" will continue to be understood as a word for either variant
> I fear "Android" will continue to be understood as a word for either variant
Well, "Android" generally means either variant. I run GrapheneOS and I call it Android. If someone asks, I say I run Android, not GrapheneOS. Actually in terms of experience, it is Android to me.
But in a context where we oppose GrapheneOS to Android, then I think it's important to be clear. GrapheneOS belongs to the family of OSes that are based on AOSP (like Android, LineageOS, IodeOS, /e/OS, CalyxOS), while Android is itself a "subfamily" of that, including the Google Android, the Samsung Android, the Xiaomi Android, etc.
In a way, I personally feel like GrapheneOS is closer to Google Android than the Samsung Android is from the Google Android, if that makes sense. Moving from GrapheneOS to Google Android, I really don't see significant differences. Now Moving to a Samsung Android, I need to adapt a little.
All that to say, I really only make a difference when we are talking about AOSP-based systems as a distinct group, by opposition to "Android certified" systems. Just like it sometimes make sense to talk about GNU/Linux in specific conversations, but generally, we refer to a Linux distribution as "Linux".
I take that point, that's a useful thing to do. Not sure that many people even in threads like these will get it unless explained (at which point you might as well word around it) but on a close forum or chat this is definitely a useful approach
I am honestly getting tired of people complaining about the fact that there is a less ambiguous way to name things. Those projects are more and more converging into saying "AOSP-based" (but that's evolving, interesting how language works!). GrapheneOS always says AOSP-based. The English wikipedia page of LineageOS says AOSP-based. In the past we used to call them custom ROMs, but the naming has evolved.
Of course, it is only relevant when it is relevant.
You can join a discussion about cars, where people talk about their Honda or Opel or Fiat, and when they ask you what you drive, you say "a car". And when they say "no but... which brand", you can go on and explain to them that they don't know how to use language, that "a car" is the common way to talk about those vehicles and that nobody in the world cares about a brand, even though you just witnessed a discussion where those people did care about the brand. Sure, you can do that.
But don't expect to have an enjoyable social interaction this way. And don't tell me "but you started it!": I answered to a comment that was making the article sound ridiculous by proudly conflating the two concepts.
> It's ridiculous to say it's incorrect that GOS is not Android based.
I totally agree, but that's not what I'm saying, is it?
Someone said:
> "Break Free from Android and iOS" looks inside - Android
I answered that there is actually a nuance that is relevant in the context of this article. Ignoring that nuance to make the article sound stupid is simply unfair.
It's not necessary to spam the comments with your personal reinterpretations of widely known project names that don't match how these names are actually being used. If you really feel the need to be wrong on the Internet at least try to not repeat yourself.
Until these OS also start putting forward something like WebOS that tried to get phones back to on open web, there is no breaking the binary format and Appstore monopoly.
I wish Europe would have forced that 10 years ago since the US is beyond saving.
There's a huge open source app ecosystem for Android and it has the best support of any major platform for well integrated web applications. There are a bunch of alternatives for getting apps including getting them directly from the developers which has been automated without needing an app store. The linked post talks about using Obtainium for getting apps more directly from developers when possible.
So long as browsers allow you to open the developer tools and inspect memory etc., they're more open than remote attestation of a stock android or ios device
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
You have to understand that this is yo replace your os on your phone. No phone is designed for that to happen. If you find it difficult, try to do it on an iphone.
Phones, to just give one example, at least have fine-grained run-time permission controls while on Linux apps can just access anything the user can, except if you use something like Flatpak which gives you sandboxing but the quality of that sandboxing is still worse than Android 4.4 KitKat. How can you protect your sensitive info without such permission controls that gate access to your personal data?
Note that this is just one example, there are also other problems with traditional desktop OSes and a large portion of desktop hardware.
What about device attestation? Will you be able to run banking apps and Netflix et. al.?
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.
I only use Firefox. It has been years since I ran into a chrome only website. Though recently I ran into an edge only websit on my corporate network, not even sure how that happens.
Nearly all non-banking apps work with very few exceptions. A large majority of banking apps work. A growing number of banking apps were adding checks for Google certification but now a growing number of those are explicitly allowing GrapheneOS via the Android hardware-based attestation system it supports which can be used to verify the hardware, OS and app with an alternate OS or non-Google-certified hardware if it adds the hardware support for it.
> 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.
Although this is not the case, moving away from proprietary services (and self-hosting your own) is an important goal in itself. See for instance the recent controversy regarding Discord's age verification.
GrapheneOS was contacted by one of the largest Android OEMs in June 2025 and we're actively working with them. They're going to be announcing our partnership in March 2026 and the phones meeting our requirements with official GrapheneOS support are scheduled for 2027.
Yes, March 2026 is when the first announcement from the OEM will be which is when people will find out which OEM it is. A fair bit into 2027 is when the devices supporting GrapheneOS will be launched. It was theoretically possible for it to happen for 2026 but not very realistic and the hardware wasn't quite there yet.
In my opinion (which is worth what it is worth), 2027 is perfectly fine (my Pixel should live a lot longer than that anyway). What I find huge is that it is concretely happening! It will show recognition for GrapheneOS, and it will be great to have an alternative to the Google Pixels.
Also, people looking at GrapheneOS want technical excellence, so better not rush it :-).
I've found that your experience with GrapheneOS greatly depends on which country you're in and which mobile provider you use. I'm on Freedom Mobile in Canada and I had enough issues that I went back to stock. RCS didn't work at all, and my phone would regularly lose the cellular connection to the point I had to reboot the phone and reset the cellular network settings. I didn't feel like I could trust it in an emergency situation so I reverted. There are also times I'm out of cell coverage and having satellite SOS would be invaluable.
Some of these issues are known and some are just features the project won't support. Last I heard they aren't going to support satellite messaging at all.
It's not breaking free from Google, but pretending it does not affect you. You are still at mercy of app developers and Google which may introduce some changes that will affect you. Additionally you never know what will work or stop working.
Huh, and here I thought Google was one of the few manufacturers left that simply support it on their hardware. So it depends on some cloud service being alive.
Do you know if it's the same for Fairphone or Shiftphone? Or is there another manufacturer that doesn't require this?
I've recently bought a new phone so it's not relevant for me anymore but when I next go looking, it can factor into it. As it was, I had Google marked in my spreadsheet as the most accessible unlock method together with brands like Oneplus and Fairphone
It's probably worth pointing out that the online process is one time and it installs a token that permanently lets the setting be toggled offline afterwards. This persists across factory resets and flashing any OS.
As a long time iOS user, I now mainly run Graphene + GadgetBridge with a helio strap. Pretty nice and private setup.
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
Switched to this from Apple a year and a half ago. Works for most things. Unexpectedly, replacement apps lack polish. Also, RCS works very inconsistently (been without it for months), seems to be Google's fault. There may be workarounds, but I haven't had the energy to try the more complicated suggestions.
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.
Are you in the US? I get the impression that iMessage and RCS are only big there. Almost nobody uses them here in Europe. (It's mostly WhatsApp where I live and Signal is slowly getting more popular.)
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)
The RCS issue is why I switched back to iPhone, reluctantly.
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.
The list of open source apps in this article was very informative and something you can benefit from even if you don't use GrapheneOS. Many of the apps listed I hadn't heard of.
I switch from iPhone to a pixel 9 fold, and installed graphene after 2 weeks on stock android.
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.
You can bypass Play Store restrictions on app installs by using Aurora Store. There's a high chance your banking app can be used but it may require toggling the per-app exploit protection compatibility mode. Most banking apps work on GrapheneOS. X is one of extremely few apps disallowing using a non-Google-certified OS but it only partially disallows it in their store listing which can be worked around and for regular password login. Login is still possible to X via a passkey or Google login. X should stop doing that but they're quite understaffed and did this as a misguided anti-spam measure.
Aurora store is a horrible placeabo. Not only is it using other folks anonymized accounts, which violates several privacy laws internationally it also still has the Google libraries in their apks like everything else. You are not gaining any privacy or security using Aurora Store or F Droid for that matter but are indeed opening up more attack surface in the supply chain that ends at your device.
GrapheneOS strongly recommends against F-Droid because it has major security deficiencies and adds an unnecessary middleman. Our recommendation is using developer builds of apps. F-Droid doesn't review the code for app updates but rather automatically fetches and builds it. They make questionable downstream changes introducing security vulnerabilities. The Accrescent app store provides developer builds of apps signed by the developers for everything included which can be verified. Play Store provides developer builds but only a subset of older apps are still signed by developers since they phased it out and heavily recommend switching to Play Signing.
Aurora Store is not recommended by GrapheneOS in general. Our recommendation is to use the sandboxed Play Store for installing apps when using sandboxed Google Play in a profile. We recommend only using Aurora Store for bypassing restrictions set by app developers on where their apps can be installed. That's what was said above. It would be better if the Play Store didn't do this.
Contrary to what you're saying, Android apps do not include Google Play libraries by default. They're only included if developers explicitly go out of the way to include them in order to use Google service APIs. Android SDK, etc. is open source as part of AOSP and both the OS and AndroidX libraries are open source too. The proprietary Play libraries are clearly marked as such via being in the GMS namespace.
> So keep that in mind if you're switching away from apple to it, as android still feels like decade plus old software.
I think this might just be what you're used to. Android doesn't feel old to me at all, conversely iOS always felt aged even when it was new with the lack of basic features it had for a long time.
ios ui is sleek but in terms of security and privacy, it doesn't hold up to grapheneos. i used ios for 10 years before switching over and quite honestly, grapheneos on my p8 runs really smoothly.
for apps that demand invasive permissions i don't wish to grant, i use web pwas, like for banking. they work like a charm.
being able to grant or revoke permissions that are of paramount importance for security like MTE, JIT, DCL etc on a granular level for each and every user-installed app, and to grant/revoke network permission alone is such a huge W using GOS.
u will not find this in any iphone, now or in the future (i would bet).
I mean you're not degoogling yourself if you put all your transactions through a google server. Cash if possible, card if not.
(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)
If they switch mostly for privacy reason, then starting using Gemini might be counter productive as Google might learn far more about the end-user than if they just did some basic search on any other Android devices. To enable Gemini, one was to accept some crazy T&C and accept that Google collects an incredible amount of personal data.
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.
I mean... yes? But I really don't think there is any 'irony' here. The author clearly stated:
> 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.
I've been using /e/OS for years. Since 2025 I'm on Pixel 9A and GOS. It's excellent. Everything I need works great. Updates are so frequent. Attention to details regarded to security is amazing. My favorite mobile OS.
We need an Euroepean vendor or organ or consortium taking up Android or Graphene or whatever and stamping a cert on phones allowed to run bank apps, after which banks (etc) have to support those phones. And/Or having to offer all functionality in the app(s) also in mobile web, but having users who want to use that requiring an OTP (or so) hardware token. I would be in favour of having the latter no matter what; no I can do this with my bank, but it doesn't offer the same as the mobile app and the site is not mobile optimised either.
Break free from Android... by installing Android? 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.
I would put the focus on having capable web-banking. I never install the banking app on my phone.
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.
> Card is usually linked to the US. Some people would like to not depend on that.
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.
The new payment networks are not an independent app. They are a protocol your banking app has to implement, so unless your bank supports non-Google phones you are out of luck (not my case, thankfully).
AOSP is Android without the Google proprietary stuff (and without the manufacturer proprietary stuff, e.g. Samsung's). If you install bare AOSP, it will look like the Android on a Pixel phone, but the biggest difference you will see is that it won't have the Play Services or some Google apps.
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 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.
Just like Linux can mean "the Linux kernel" or "a Linux distribution" in "common use of the terms", Android can mean "a device that can legally be advertised using the Android trademark" or "whatever looks like Android to people".
Now when someone says "Break free from Android... by installing Android?", either they are having fun by using the two different meanings in the same sentence, or they are confused and genuinely believe that using GrapheneOS does not allow you to break free from the system running on a device that can legally be advertised using the Android trademark.
To that, I answer that GrapheneOS is not a system that can legally be advertised using the Android trademark, but rather a system that is based on what is commonly (and can legally be) called AOSP, which is made of the open source codebase that builds the system that can legally be advertised as Android.
Similarly, in a discussion about kernels, Android is a Linux system, but in a discussion about OSes, Android is not a Linux system. If I write an article about "breaking free from Linux by using Android", where the context makes it exceedingly clear that I'm talking about Linux as an OS and not Linux as a kernel, and you say "it makes no sense, you're talking about breaking free from Linux by installing... Linux", then I think you're confused. As in: you did not understand what the article was talking about.
You're vigorously defending a poorly thought out title by inventing irrelevant contexts and falsely accusing multiple people of being wrong because they claimed such uncontroversial things like "AOSP is Android". Sure, if we want to be strictly correct then AOSP is not Android, but rather the name of a Google project that distributes the source code of Android - but that's not how the term is commonly used in these discussions nor how you used it either.
What people objected to is the concept of "breaking free from Android" by using a distribution of Google-developed Android. Interpreting the title as "break free from flavors of Android that can use the Google's trademark in their marketing; here's one that can't" is just ridiculous and not what anyone will think about when reading it. The current one ("break free from Google") is still objectionable, but slightly less since one could perhaps make a somewhat correct point that relying on Google-developed codebase that's soft-forked by someone else actually is significant enough step away from using something that comes straight from Google and tightly integrates with their proprietary services. It's still quite obviously hyperbolic, especially when actual non-Android alternatives also exist.
> Sure, if we want to be strictly correct then AOSP is not Android, but rather the name of a Google project that distributes the source code of Android
Thank you.
I do find it ironic that you could not understand what I mean given that you're the kind of people who say "GNU/Linux".
This means GOS is not AOSP either, because it's not that particular project. It takes the Android source produced by AOSP and builds on it. But what you agreed to is just pointless pedantry that leads directly to this outcome, as everyone uses "AOSP" to refer to what AOSP produces (which is a particular flavor of Android that serves as a base to build other flavors on).
It stops being ironic when you take some time to understand that the two cases only appear related superficially, but are actually quite different. You could even say opposite.
Many are complaining about banking app compatability, but I've never felt compelled to use anything other than my browser for banking. What's the big deal with the banking apps?
Am missing out on some huge advantage here?
FYI: Google Fi + GrapheneOS doesn't work. My son recently tried setting up GrapheneOS and got everything working but couldn't get connected to Google Fi to work, even with a SIM card.
How does this break free from Google? Isn't the Android that Google themselves writes and maintains the upstream of Graphene? Are they going to disconnect completely from upstream Android or something?
The article directly answers your questions, specifically in the “what is GrapheneOS?” section.
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.”
I've been using it for more than 2 years, and I can't think of ever going back to a stock OS. I had to send my phone for a screen repair, in the meantime I picked up my old Samsung, and the sheer amount of apps I didn't want, notifications and dark patterns to tricking me into handing over my data made me anxious. I couldn't finish setting the phone up and drove to my parent's home to pick up their old, remotely nerfed by Google, Pixel 4a so I could install GrapheneOS into it and use it while I waited for my repaired Pixel 8.
Same. Not only has using it been no trouble, but having a barebones core app selection, a few picks from F-Droid, and using the browser for the rest makes my phone feel refreshingly under my control. It lasts for 3-4 days of low usage to boot, when nothing is phoning home constantly.
~6 months here. In my case, it became almost a full daily driver ( putting corporate spyware on it would kinda defeat the purpose ). It is by no means perfect, but I can recommend it ( and I could not do the same with other phones that should have been better on paper -- linux phones like pinephone or purism ).
If they'd put a screenshot, that would then have been immediately clear to casual visitors.
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.
It's weird that here on HN some people are trying to break free from Google and Apple and on the other side some people are married to Gemini, and both look like to be the majority at times.
I had a Pixel 6a with Graphene OS for a year before the phone started to glitch and eventually die. It ran pretty hot; sometimes it was hard to even hold the phone in my hands without burning myself.
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.
> I had a Pixel 6a with Graphene OS for a year before the phone started to glitch and eventually die. It ran pretty hot; sometimes it was hard to even hold the phone in my hands without burning myself.
This sounds like your phone may have been one of the Pixel 6a models with a defective battery[1]. It was a major problem for which Google pushed out an update that nerfed the battery life. There is a tool online where you can check if your particular 6a was one with a battery from the bad production batch[2].
But that unfortunately doesn't help if you are in Brazil where, as you say, Pixels aren't officially sold and import/export controls tend to make tech warranties useless in practice.
Which is (almost) the case during sales. The P10 was on sale for $599 not long ago, and you could buy a 9a for little more than $300. That is extremely good value compared to any iThing repoted your every move to Apple.
Switched a couple of weeks ago and works perfectly. I also found so many better apps that dont steal your data for basic stuff like weather, notes, messaging,...
Break free from Google by paying money to Google for a Pixel phone? Even with a used Pixel, you're helping prop up their used market value which helps Google
How are the cameras on the latest devices running GrapheneOS? My last Android experience was the Oneplus One and the experience left me with the feeling that cameras are just too proprietary to work well once you go tinkering with custom ROMs and camera apps.
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.
GrapheneOS has the same camera features and quality as the stock Pixel OS within the same apps. You can use Pixel Camera on GrapheneOS even without sandboxed Google Play in the same profile if you want the full feature set. If you want extremely good cameras, the Pixel 10 Pro and Pixel 10 Pro XL are the best choices. Those provide the highest quality image sensors among the available supported devices and the Pro mode in Pixel Camera. See https://www.dxomark.com/smartphones/ for how those compare to other devices. Our own Camera app will be heavily overhauled to narrow the gap more with the Pixel Camera app but you can already use that especially if you care a lot about this.
The biggest hold-back for me is that, here in Australia, Google Wallet (aka Google Pay) is the only way you can do tap credit card payments that I know of. Can't with Paypal. Not with any banking apps that I know of.
It's just so damned convenient. And the recording of transactions on the phone saves me having to collect paper receipts.
"Break free from Google ..." by purchasing Google hardware and using [software "based on"] Google software
Is it really "breaking free" from a company if the method of "breaking free" requires continued cooperation from the company
This is not to suggest using a modified version of Android isn't useful. This comment is not about GrapheneOS. (But there will be HN replies that will try to redirect focus to it anyway.) This comment is about claiming it's possible to "break free" from something while still remaining inextricably tied to it
In addition to using a custom ROM, there are methods of stopping the Pixel's attempts to "phone home" to the company that work even with the version of Android pre-installed by the company intact. However if a method requires software, e.g., drivers, or is "based on" software controlled by the company, then ultimately the company holds the cards. IMHO, this is not what it means to "break free"
Perhaps the most reliable method of stopping these connections to the company is one that does not rely on cooperation by the company. This is because if the company decides to stop cooperating, the method still works
Maybe an old Pixel with an old version of GrapheneOS, but at that point you're losing most of the security benefits and, depending on your goals, you may be better served with a small phone running a different OS
After reading this blog post, going to grapheneos's site, and browsing a half-dozen or so pages that I thought might show me what it looked like... I cannot find a single image of it.
GrapheneOS team, I'm begging you... Hire or recruit one person with advertising or copy-for-public-consumption experience. Just one.
It's not very important but what are you referring to with "it is not" ? AOSP is Android (it's in the name) so I don't get it. Are you talking about blobs re Pixel devices?
Well. I do get your point and I am aware of the situation and how Google pivoted away from a truly open source OS by systematically moving components like the keyboard to separate closed source apps. The fact remains though that it's Android Open Source Project where all Android systems are based on. It's become sort of a GNU/Linux kind of distinction where the "certified" Android is AOSP + Google. Though the situation is not that clear because there are other Android based phones that do not contain the Google layer but are still Android.
> Though the situation is not that clear because there are other Android based phones that do not contain the Google layer but are still Android.
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.
Google is so much engrained in our lives that we can't really break free. You can't just don't use youtube and for that you need a google account.These projects are nice and good for tinkering, but can't use this as a dialy driver.
GrapheneOS is very usable as a daily driver. Nearly every Android app can be used on it and there's a huge ecosystem of open source Android apps. You should read the whole linked article which explains in depth how someone new to using it set up their device. They chose a certain way of doing it to balance their priorities. Only a tiny portion of apps can't be used on GrapheneOS which are mostly a subset of around 15% of banking apps which ban using a non-Google-certified OS in a way we can't easily work around. Most banking apps do work and extremely very other apps are unavailable. Google apps and services aren't used by GrapheneOS by default but can be installed as regular sandboxed apps.
You don't need a Google account to use YouTube and can use it via the browser, NewPipe or several other alternatives rather than their app.
The linked article covers someone's first experience with it with a lot of detail. They're using it as their daily driver with mainly open source apps and separate profiles with mainstream apps they still need. They're using those with much better privacy protections including having sandboxed Google Play in those profiles for using mainstream apps rather than regular highly privileged Google Play heavily integrated into the OS and not running with the standard app sandbox or privileges.
Why do I need a Google account for Youtube? It seems I can watch nearly any video I want without logging in. Moreover there are anonymity proxies like Invidious.
Like others have said, you can use Youtube without Google account. Moreover, you can give Google the middle finger by using uBlock Origin or viewing though a third party client like VacuumTube. Also don't forget the shorts filter recently featured on HN to remove those annoying portrait format videos.
GrapheneOS is based on the latest release of the Android Open Source Project (AOSP) which is Android 16 QPR2. It looks nearly the same as the stock Pixel OS also based on the same AOSP release. The main UI differences are user-facing portions of the many privacy and security features added by GrapheneOS. There are minor differences such as the stock Pixel OS having a few different fonts than AOSP. The main thing to show would be the UI for features such as Contact Scopes, Storage Scopes, per-app exploit protection controls, etc. It looks like the stock Pixel OS without the Google app/service integration not present in AOSP with added privacy and security controls.
There are many useful videos about GrapheneOS here:
Any of the videos older than December 2025 will be prior to Android 16 QPR2 so the overall UI will be outdated. That's part of why we don't focus on screenshots or videos because many would need to get updated every 4 months. We'd mainly be using them for our own features which often improve more frequently than that.
There's several AOSP based ROMs in forums like xda. Mostly developed by enthusiasts.
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?
This is a production grade OS, it's made by professionals, it's not hobbyist. It keeps up with updates of upstream Android and Linux kernel. It has a ton of good security and privacy features.
This is the phone version of saying “the power utility is an evil awful monopoly that treats me like shit, so I’m gonna get solar and batteries and go off grid.”
It’s cool it’s possible, but it’s not practical for most people.
What do you think the major practical downsides are? Maybe you are not aware of how many things perfectly work or how easy some workaround are, so I am wondering.
GrapheneOS needs at least the modem blob provided by the OEM.
It runs as root, it has full network control.
Same could go for other "drivers" like wifi+bluetooth.
No, that's a misconception. GrapheneOS has only ever supported devices where the cellular radio is isolated from the OS and unprivileged. It does not have access to memory it hasn't been permitted to access by GrapheneOS. Wi-Fi, Bluetooth, NFC, UWB, etc. are isolated components too. Our hardware requirements are listed in our FAQ and require proper isolation for radios:
8th, 9th and 10th gen Pixels provide our full set of requirements with 7 years of support from launch. 6th and 7th gen Pixels are missing the ARMv9 security features including the extremely important hardware memory tagging (MTE) feature we heavily use to protect against exploitation. Even the first devices we supported back in 2014 including the Nexus 5 had isolation for the cellular radio but similar isolation for Wi-Fi/Bluetooth started with the Nexus 5X.
I've been using GOS for 3years give or take on a Pixel 7 PRO. Yes, GOS also stops you from buying new phone every year and personally, I am hopping Pixel 10 PRO is worth the upgrade, doubt it.
In Australia, everything works, from banking to gov services, they do not block or have limited function. CommBank App supports NFC payment via its app for example.
Dual profiles is silly and utterly unnecessary.
List of my open-source applications:
- Aurora Store: Should be avoided, it like F-Droid have broken security in place. You have a high risk of installing crappy on your phone via those stores. That is why I still use Google Play and download apk once here in there from GitHub project.
- Organic Maps: Dead project, a lot of things have happened and that is why CoMaps was created/forked.
It is a beautiful and mega lightweight offline GPS map with tons of features.
CoMaps replaced Earth Magic that got completely destroyed to greedy, and Sygic which I have an old lifetime premium license which now is somewhat limited unless you pay for premium plus :)
OP didn't mentioned but GOS + Android Auto works like a dream wirelessly, GOS provided is Google-free dependency version and it just works.
Does anyone have an answer to the problem of an OS for a laptop? I'm thinking about strong security here, less so about privacy (which is doable, for example via a Linux distribution).
Graphene is very attractive, the two things that prevent me from going are a) using your phone as a credit card, I'm too attached to that now. b) work profile does not work with rooted phones
Then GrapheneOS is currently not an option, however they are working with another OEM to have non-Google phones available with GrapheneOS by next year [1].
I had to replace my old phone a few months back and I went with a used Pixel 8 pro from Backmarket specifically so I could try GrapheneOS. I'll never go back if I can help it. I love this OS.
People seem to fondly remember the Microsoft phones. If they made them now though, I can't really imagine what sort of Copilot-filled abomination they would be.
I use this and lineage, but in a few years time this could be moot if Google decides to completely lock down devices. That leaves commercial options like Fairphone
Fairphone is far from meeting the update and security requirements for GrapheneOS. It isn't a viable platform for a hardened OS to use and isn't likely to ever become one due to security being very far from a priority for them.
GrapheneOS has a partnership with one of the largest Android OEMs. They're going to be announcing it in March 2026. Devices meeting all of the update and security requirements from them with official GrapheneOS support are planned for 2027. We don't expect future Pixels to prevent installing GrapheneOS but we'll be fine if they do. We'd still like to keep supporting new Pixels but they'll become a secondary option in the future since there will be devices with official support.
i use social media and have never gotten a shadowban. to the contrary grapheneos actually is very effective against apps like reddit shadowbanning you - if you get banned outright on reddit, for example, you can create a new profile in private space and reddit will not be able to detect that you're ban evading.
if you get banned from the profile u use in the app in private space, again, if you just delete private space and recreate it, download the reddit app again, it will be unable to detect that you're evading the ban. i previously tried doing this on other os's and reddit detected the ban evasion.
don't ask me how i know.
(just correcting this misinfo)
you're correcting nothing, my business revolves around evading these kind of checks especially on mobile apps. TikTok, for example, it is very aggressive. If you have something different than stock ROM, your reach will be greatly diminished.
Try a social media that is not antisocial. HN, Mastodon, Tildes, various forums... lots of communities and tech content are available in browsers or via open source apps
I'm not aware of any that bans you when not using an allowlisted OS, so maybe it was something else that caused this shadowban, or (more likely) that's just my bubble
They should get the same level of financing (donations) as Tor project at least. Some big organization like Open Technology Fund or NLnet should give them yearly grants.
GrapheneOS is like using Firefox. Works on most sites, but those few things just don’t. Maybe it’s a dealbreaker for some. And they’re dependent on Google.
As great as GrapheneOS has been, I'm still tempted to switch to LineageOS. Sure, it would be objectively less secure, but at least then I might be able to disable the obnoxious "automatically disabled 3 unused background apps" notifications.
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?
> Even if it improves accessibility, it must be rejected out of hand
GrapheneOS has many exploit mitigations and those that would break compatability with too much apps are opt-in instead of opt-out. They also have per app toggles so you can decide to use them per app. So they certainly don't sacrifice accessibility for the highest level of security.
> GrapheneOS promises to liberate us from the enshittification of Google's anticompetitive moat
This isn't something GrapheneOS promises anywhere on their website. They aim to offer a secure and private OS with good compatability with Android apps.
> but it focuses that effort exclusively on security.
They focus on privacy and usability as well. Security is actually only focused on because the privacy features aren't enforceable without security.
> Why is that constantly treated as an unreasonable fantasy?
Because tinkering, hackability and unrestricted freedom aren't the purposes for which GrapheneOS was made.
It's good enough for you, and therefore it can't get any better. Interrupting the user with pointless notifications is not security. Removing the ability to disable those notifications is only a security feature if the user wants then in the first place!
The problem here is more than the lack of interest in making a system that is both secure and usable. It's the outright rejection of usability as a goal.
It's very annoying that they restrict themselves to Pixels. I get they can't guarantee all the security features they want on other phones, but even a subset of those security features and the other advantages like the lack of cruft would make it very attractive to be able to run on other phones.
I can understand the frustration, but it wouldn't be right to say they 'restrict themselves to Pixels'. They believe strongly in a standard for privacy/security of people's personal devices, and unfortunately only Pixels are close to meeting those standards. It's not even like Pixels are their ideal device.
I feel the frustration should be targeted at OEMs that don't meet very reasonable requirements like minimum 5 years of monthly (timely) security updates.
> but it wouldn't be right to say they 'restrict themselves to Pixels'.
It's absolutely right to say that. You justify why in your next sentence.
> They believe strongly in a standard for privacy/security of people's personal devices, and unfortunately only Pixels are close to meeting those standards.
That doesn't prohibit them from releasing a version that runs on other phones, even if it's missing a few (and it would only be very few) features. Most of the graphene users are not using it because of those features.
> I feel the frustration should be targeted at OEMs that don't meet very reasonable requirements like minimum 5 years of monthly (timely) security updates.
Again, though, no frustration; I wouldn't run graphene even if I could as I have my own setup I'm quite happy with. Just disapproval at an arbitrarily high standard that isn't doing the good they think it is, and ultimately, actually does more harm in not making their product accessible to the hundreds of thousands of people it would benefit.
I love the ability to block apps from accessing the network. There is no reason apps like the keyboard, camera, or other offline apps and games need access to the internet.
Because phones have device-specific code. Effectively, each single model is running its own fork of Android. Naturally, Google has no incentive to change this - it makes it difficult to update (planned obsolescence) and install other software (like GrapheneOS).
>Because google actually cares about hardware and software security.
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.
There is a difference between security and privacy or freedom of use. Locking down the device to only allow a subset of apps that Google has some control over (by requiring developers to register) is a measure that can increase security, even though it obviously takes some control away from the end-user.
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.
I believe (as it's open source) there is nothing impeding anybody else to compile grapheneOS in a samsung S10, which would not be as secure, but should still work as any lineage
is it worth to buy google pixel just for installing grapheneos? in my country, it is kinda pricey and of course it cannot install bank apps because almost all of them are must non root phone.
Break free from Google by buying their hardware and be dependant on them to actively support the device. Things are absurd at this stage. I guess there is different motivations behind mobile OSes.
So you were happy in your orchard/garden but then plenti arrived offering the forbidden fruit; android. This is the slippery slope that led us here, open rebellion against the tech patriarchy
I can't take this seriously when their mission statement is to "break free from Google and Apple" and their entire output is a fork of a Google repo.
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.
i don't understand your issue - using grapheneos does allow you to break free from google in the sense that you have an android OS that works well, is secure and private, and gives you the choice to use google or not. if you choose to use play store/services, they run as sandboxed, unprivileged applications like every other app. on samsung/stock pixels etc, play services is a privileged component of the os and you can't avoid this. grapheneos gives you the freedom to break free from it in this sense.
soon enough grapheneos will be available on non-pixel devices, but if you really have, say, a philosophical problem with using google devices, get a used 2nd hand pixel. or wait til the oem partnership announcement.
For some (and other not-so) obvious reasons I switched to Graphene a few weeks ago. For years I've been pushing towards de-cloudifying my digital life and there were several reasons for it: On one hand it was the constant content subscription which gave me 0 guarantees that what I am interested in will still be available the next morning, even though I've paid for it, and the other was, you guessed it, the idiotic LLMs everywhere and subsequently the complete annihilation of security practices by giving a probabilistic model unrestricted access to all of your data.
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.
You can use a different keyboard than the default AOSP keyboard with more modern features including but not limited to swipe typing. We plan to replace AOSP keyboard with a fork of a more modern app but there isn't yet one meeting the functionality requirements which is under a license we can use. FlorisBoard is what we have plans to eventually use, although it might not be what we end up using.
A lot like Linux zealots people say a lot of things along these lines:
“It’s perfect. I love it. It works great. No complaints” and then go on to list 100 rough edges that mainstream phone OS users never have any issues with. It’s funny.
If you're willing to invest in a smartwatch principally as a secure payment appliance, tap-to-pay with Garmin Pay works when configured on Graphene OS, and most Garmin Smartwatches will happily stay in airplane mode for months once configured.
AFAICT, Garmin Pay works like Apple Pay, meaning (unlike Google Pay) no network connection is required.
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?
Well, Apple made privacy a major selling point, so I'm sure you can do this on iOS, too. /s
I commented elsewhere but GrapheneOS on Pixels actively siphon resources from Google and is arguably a good protest against google.
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).
There are currently no other devices meeting the update and security requirements. GrapheneOS is partnered with a major Android OEM working on making devices meeting all of those requirements along with providing official GrapheneOS support. The devices are planned for 2027 but is being announced by the OEM in March 2026 so people will know which OEM it is soon.
Good news they are making their own devices. But until then pixels are technically the most secure android devices and graphene would not be as robust on other devices.
Small correction, GrapheneOS are not making them. They are partnering with an existing large OEM to ensure one or a number of future flagship devices meets their security, privacy and support requirements.
It has been officially stated that GrapheneOS is partnered with a major Android OEM working on making devices meeting all of those requirements along with providing official GrapheneOS support. The devices are planned for 2027 but is being announced by the OEM in March 2026 so people will know which OEM it is soon.
Been using this for about a year on a p9 pro. It works very well. I hear the google tap to pay does not work, but I've never tried it. However Vipps with their tap to pay works fine. BankID works but not with biometric login, which some things require IIRC. And for some reason DnB private works fine, but you are not allowed in on the corp app.
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!
A collegue of mine was tech lead at a large online bank. For the mobile app, the first and foremost threat that security auditors would find was "The app runs on a rooted phone!!!". Security theater at its finest, checkboxes gotta be checked. The irony is that the devs were using rooted phones for QA and debugging.
Meanwhile, it's probably A-OK for the app to run on a phone that hasn't received security updates for 5 years.
I don't get it. If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?
I'm guessing it's because there are a lot of phones floating around that aren't updated (probably far more than are rooted), and they're willing to pretend to be secure when it impacts a small number of users but not willing to pretend to be secure when it impacts many users.
Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years. For example, a malicious OS maker could add their own certificate to the root store, essentially allowing them to MitM all the traffic you send to the bank.
Liability works on the principle that "if it's good enough for Google, it's good enough for me." A bank cannot realistically vet every vendor, so they rely on the OS maker to do the heavy lifting.
Even if they wanted to trust a third-party OS, they would need to review them on a case-by-case basis. A hobbyist OS compiled by a random volunteer would almost certainly be rejected.
I can add certificates on my unrooted android. That how HTTPToolkit [0] works, it only requires adb, which (thankfully) doesn't trip banking apps. Banking apps can (and do iirc) pin certificates, so a rooted phone adds no risk whatsoever.
Also in my experience a rooted phone experience is by far more secure than the OEM androids. Security is supposed to assess risk objectively, yet "running on a Xiaomi phone with 3rd party apps that cannot be uninstalled and have system access" is somehow more secure than "running on a signed LineageOS where user can edit hosts file".
[0] https://httptoolkit.com/
>Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years.
That's just straight-up false ; the phone without security updates has known exploits its user knows nothing about (and certainly not how to avoid them). The phone with an unknown OS has a user capable of installing said OS, at the very least.
> Because a phone running an unknown OS is significantly more dangerous than a phone that hasn't received security updates for years.
I'm not convinced this is generally true, at least as can be detected by an app. Back when I had my phone rooted, it was configured so that it would pass all the Google checks and look like the stock OS. That configuration was probably dangerous, but apps were happy with it. Now that I run an OS that doesn't lie about what it is, I'm flagged as untrustworthy. What's the point in being honest?
Overall, I don't think they really have any idea what's a threat based on the checks they're doing, so I don't think they can say at all what's more or less trustworthy. But I think that a phone that reports being years out of date should reasonably not be expected to be secure, but yet they mark it as secure anyway. Many of those devices can be rooted in a way that can still pass their checks. I would think, if nothing else, that would be reason to block them, since they're interested in blocking rooted devices.
> If they're worried about liability, why not check the security patch level and refuse to run on phones that aren't up to date?
Google doesn't provide an API or data set to figure out what the current security patch level is for any particular device. Officially, OEMs can now be 4 months out-of-date, and user updates lag behind that.
Your guess is good, but misses the point. Banks are worried about a couple things with mobile clients: credential stealing and application spoofing. As a consequence, the banks want to ensure that the thing connecting to their client API is an unmodified first-party application. The only way to accomplish this with any sort of confidence is to use hardware attestation, which requires a secure chain-of-trust from the hardware TEE/TPM, to the bootloader, to the system OS, and finally to your application.
So you need a way for security people working for banks to feel confident that it's the bank's code which is operating on the user's behalf to do things like transfer money. They care less about exploits for unsupported devices, and it's inconvenient to users if they can't make payments from their five-year-old device.
And this is why Web Environment Integrity and friends should never be allowed to exist, because Android is the perfect cautionary tale of what banks will do with trusted-computing features: which is, the laziest possible thing that technically works, and keeps their support phone lines open.
All good points. Thanks for that!
I'm not an Android developer, but I was thinking they could use something like the android.os.Build.VERSION.SECURITY_PATCH call to get the security patch level. Maybe that's not sufficient for that purpose, though.
Sure, there is enough information available to the app to determine what OS version and patch level it is running under. The issue is, the app would need to communicate this to the bank via an API, and the bank wants to trust the app in the first place in order to rely on this information.
Even then, two things turn out to be true:
- Banks don't actually want to put in the effort and deal with angry customers with slightly-out-of-date devices.
- All the credential-stealing malware on Android works perfectly fine on stock, unmodified, non-rooted OS images anyway. They just need to socially-engineer the user to grant accessibility permissions to the malicious app.
There's definitely some way of telling, Enterprises can block sign in with no recent updates in Microsoft authenticator or whatever app they use.
[dead]
It's more frustrating because my partner's pixel 4A cannot use google pay or the bank apps because it is an invalid os - I am guessing due to lack of updates? So, perfectly fine hardware, but crippled in functionality due to the lack of software updates.
My partner has a 4a and no such issues. Are you talking about stock Android or something else,
ive seen: -"but ios can be jailbroken and it doesnt have an AV!" while the MDM does not allow jailbroken devices, and they also allowed sudo on linux.
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.
at best it's "cover your ass security" so when you do get pwned you can say you went through an "accrediting auditor" - blah blah blah.
Agreed on everything you said. Just wish there was a more efficient way to do things :/
Yep, some stakeholder wants a pen-test or an audit so you do it and address the findings to keep them happy. Going through it now at work - bunch of silly findings because the pen testers know they don't get paid to send back an empty report and tell you everything is fine.
[dead]
As long as copying some numbers, printed on a piece of plastic, into an online order form is all the authentication that is needed for a transaction, anything more than that is inherently security theater.
That’s why for most transactions I do with a credit card in my country, you need an extra validation with the mobile app. It is mostly American websites that do not enable this functionality.
Yes, because we don't want these stupid locked down apps. Credit cards give buyers many protections, it's very easy to dispute an illegitimate transaction.
However, you pay 2.7% for that convenience
The consumer does not typically pay this directly. It may be passed onto the consumer indirectly through higher prices, but those apply to anyone regardless of payment method. On the contrary, I get cash back on purchases and other rewards.
Pretty cool that you have a system where poor people pay for your fraud protection, cash back and rewards!
Europe mostly uses debit cards but also have most of those protections.
Because we have anti-fraud consumer potection rules and CCs operate on a make money first type of bais. The debit networks on the otherhand are a different story.
Yeah that's the first thing a pentest will complain about, had the same problem too. I pushed back enough so that it's trivial to bypass but the bank and pentesters also agreed with me that it's security theater or else I would never had the chance.
I always ask them if they have root/admin on their computer. Then follow up playing dumb with "shouldn't we lock out PCs too?". Watching them stammer is worth the 30 second aside.
> Then follow up playing dumb with "shouldn't we lock out PCs too?".
Unfortunately, some banks do, for various functionality; there are many things you can do via bank apps and not typically via their website.
Locking down PCs is easy: just set a random password.
Just blow the right hardware fuses and secure boot will be forced with a key that doesn't (or can't) exist.
[dead]
Who do we lobby to get this removed from the auditors checklists? This is a solvable problem but it’s political. And if we don’t solve it personal computing is at risk.
Start by calling (or visiting the area office of) your senator and congressman. If you are reasonably articulate, they engage and listen. Doesn't matter if the listener is not a techie; they will ask questions around policy and why it affects constituents.
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.
From my experience with the fed level senator.. they're already lobbied to shit. For example, explaining to Duckworth that fed level id tying to your internet travel and encryption backdoors aren't safe.. they'll send you copy that she really wants you to know she's thinking about the children while rolling around in her wheelchair.
This is nothing to do with politicians.
A lot of that is security theater at its best. However given the forced attack surface I would imagine that there is a hard push from authoritarians and the finance world to make a "secure chain" from service to screen.
My guess: They're afraid that the scammers are going to mirror the screen and remote control access to the app. (More orgs are moving to app/phone based assumptions because it saves the org money and pushes cost on the consumer) Instead of providing protections from account take over.. we're going to get devices we don't own and we have to to pay for, maintain and pay for services to get a terminal to your own bank account. Additionally, there are many dictatorships, like the UK, North Korea, etc, that are very adimate that you don't look at things without their permission. So they're trying to close the gap of avoiding age verification bypasses with VPNs.
> the first and foremost threat that security auditors would find was "The app runs on a rooted phone!!!".
GrapheneOS is not rooted, or is not required to be.
Moreso, the project advises against rooting your phone and tells you that if you install GrapheneOS and root it that you aren't running GrapheneOS anymore.
No it's not, but it's bundled in the same basket. "Didn't pass DEVICE_INTEGRITY -> rooted"
Yep that's my experience as well, if you don't get the play protect™ absolution your device is seen as rooted. Latest app to display this BS behavior was PagerDuty, I guess they have to protect their secret sauce of calling an API and showing notifications
Huh, that would be absurd if PD did that.
I know some people have issues with Duo, I don't, with pager duty i _just_ installed th last version from Play store, logged in with sso to my org and I'm in, can do or see everything.
Maybe it's play services in your case, not play integrity? I'm on the last release from the stable channel.
But grapheneos doesn't need to be rooted!
Unfortunately, root detection is greatly flawed, most of the time.
Oh how I fucking wish "security" wasn't a stupid cargo cult checkbox list 3/4 of the times.
Unfortunately, the rot runs too deep.
Your password must be between 8 and 12 characters, and must have lowercase, uppercase, numbers, and punctuation.
Pick up the can!
My favorite is when it must have punctuation, but certain punctuation is silently banned, so I have to keep refreshing my password generator until it gives me an acceptable combination.
I came across a "special character" requirement while creating an account. The client validation was not the same as the server validation. The client proceeded as if my account was created, but it never was. The client functioned without an account until it was closed. I asked the creator what their app's problem was, why did I need to keep resetting my password, then be told that I don't have an account, and have to create it anew.
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.
Sometimes when that happens, and any of `:({ |&;` are on the no-no list, I try bypassing the client validations and setting my password to a shell fork bomb. So far as I'm aware it hasn't broken anything yet, but I'm determined to keep trying.
Somewhat unrelated, is there any technical reason certain punctuation might be banned? I can understand maybe not allowing letters with diacritics or other NON-ASCII chars but why would a system reject an @ sign or bracket > for example?
Depending on the protocol they can be url encoded or even helpfully html encoded; the same password can be used over different protocols. It's the best to not use punctuation by default (length supplies more entropy than charset), I add -0 at the end to make dumb password policies happy.
Sorry I'm a bit lost here. Are you saying requiring a special character and a number are dumb password policies? Wouldn't charset AND length make for exponentially higher entropy? 52 (or 62 for digits) to the length power vs (62+20 special chars) to the length power? Or am I missing something?
I guess what they're saying is that, for example, a password of length 12 has about 71 bits of entropy if using an alphabet of 62 characters, and 76 bits with an alphabet of 82 characters. But if you only increase the length by 1 you already get 77 bits with 62 characters only. So length beats adding special chars in that sense.
Gotcha, I guess my question is, why not both? Is it the requirement of special chars over a min-length password that is in question here? Like the system is like "minimum 8 char password but also three special chars, ancient heiroglyphs, and the blood of your firstborn child" when you can omit the special chars and just have min 16 char password for the same security benefit?
Not very meaningful to create yourself a problem to heroically overcome it later. You can already create enough problems unintentionally.
I don't quite follow your reasoning. All bugs are (usually) unintentional and created by the programmer.
By not using special chars in the first place, you can be sure you will not be able to run into any (unintentional) bugs later.
And not using special chars is cheap, as by requiring a min-length of 13 instead of 12, you can get an even greater level of security.
Got it, thanks! That makes sense.
Often, the same ones with limited punctuation also have length limits, so maximizing the character options is the only way to maximize entropy.
This is true, but I think the argument is that for maintainers of the system, it's more work to allow more char options when it (should be) more trivial to change MAX_PASS_LENGTH from 12 to 32. Like, if you're gonna add more restrictions, make it the ones that encourage, not block, more secure passwords.
A lot of the restricted stuff is cargo-cult fear of symbols that could be used in SQL-injection or XSS attacks.
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.
Having more than just alphanumeric characters widens the domain of the password hash function, and this directly increases the difficulty of brute-force cracking. But having a such a small maximum password length is... puzzling, to say the least. I would accept passwords of up to 1 KiB in length.
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.
It's easier for me to remember really long passphrases than even short alphanumeric strings - small maximum password lengths set my teeth on edge. The passwords should be getting hashed anyway right?
The problem is that you never really know what a website operator does with your credentials. Ideally, you have both a unique email and a unique password for each site, because sadly credential stuffing [1] is a thing.
[1] https://en.wikipedia.org/wiki/Credential_stuffing
Should being the operative word...
I recommend all my friends and family to use a password manager like Bitwarden, and if they can't do that for some reason, at least use a 3-word passphrase separated by a hyphen.
The amount of times people have complained to me that this doesn't work because of low max-chars on passwords is insane.
One time I had to reset my password with the power company - they had such a system, and the lady had to read me something like:
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.
That's pretty funny on a few levels, not in the least that they required a "secure" password like that but stored them in plain text.
I regularly conduct transactions at the branch of my local bank wherein they ask me for no credentials whatsoever. I also once forgot to bring my account number with me and the teller said "no worries, I'll look it up for you." Kind of horrifying.
Oh! But that’s safe! Secret question time: What’s your mother’s maiden name.
It helps that it’s a jailable offense to make fraudulent transactions
Isn’t unauthorized access to a computer system also a jailable offence in most places?
Would using the password you gain through this social engineering be doubly illegal?
Well... sure. But people be crimeing, and some of these attacks can be done internationally.
My bank’s password field is case insensitive. Of course they could have lowercased it before hashing but I doubt it.
That's scary. I wonder if incompetence like that could lead to a lawsuit in the case of a breach.
At this point I wouldn't be surprised if there exists a system that just asks for username with a checkbox "check here if you are the owner of this account"
Yeah I was a bit shocked... like... you're not supposed to know that!
I bet the rationale would be "anything over 12 characters will be too hard to remember and people will just write down the password."
But it's a maximum. It prevents people that want to use passphrases from doing so.
Until the late 2010s, the AD account password at my financial institution employer was capped at 12 characters because, for a subset of workers, AD creds were sync'ed to a mainframe application that could only support that many characters.
Sounds about right. One of Australia's big four banks had the online banking password requirement of exactly six characters for a long time - for similar reasons I assume.
I think we (whoever we is) should start normalizing the concept of passphrases; on sign-up screens they should show the benefits of a passphrase. I'm surprised that Googles PW generator does not use passphrases, and I don't know about ios because I haven't tried theirs yet.
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.
correct horse battery staple; knew it before I clicked the link.
Whoops, I've been pwnd!
https://haveibeenpwned.com/Passwords
Haha having such a low range of max chars just makes it that much easier to brute force doesn't it?
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.
Maximum lengths like this are like a big neon sign that says:
"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'."
> Pick up the can!
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.
I'm pretty sure it's referencing Half-Life 2, where an agent of an oppressive regime tells you to pick up a can that they just dropped on the floor as a sadistic display of authority (and to provide world-building and teach the grab mechanics to the player).
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.
> The GP is equating policies for strong passwords that aren't trivially cracked with authoritarianism.
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.
It's a Half-Life 2 reference: https://www.youtube.com/watch?v=nJshjMyg6no
> 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...
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.
This should be illegal that the government forces people into apps controlled by private, commercial entities. I call such a government corrupt.
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.
If the government (or school) is going to require us to have a smartphone in order to access critical government information, then we should demand that the government provide us with a compatible smartphone.
Would you use that phone?
If your employer required the use of a smartphone for essential components of your job and provided you with a smartphone and cellular data plan, would you not use that smartphone for those components of your job?
I'd not use employer- or government-furnished equipment for tasks that the equipment wasn't provided to complete, but I'd definitely use it for those tasks.
Exactly. Bank needs me to have an official FruitPhone to access my account? Fine, send me the phone, I'll turn it on when I need to bank, and at all other times it sits powered-off in a drawer. Same for the government-supplied DroidPhone I need to access my Social Security statements (or whatever). Turn on, do my business, turn off.
Would this apply to giving you a phone plan, internet plan, computer, paper, pen, electricity, etc., because all of those are necessary to do online banking or access school chats as well?
Forget exes—-how about current partners! I predict with high confidence that my wife’s response to such a request would be “grow up and install WhatsApp already.”
Mine would be the exact opposite. She'd walk into the school district office and read them the riot act for being so stupid.
To which one might reply "I can not unread those terms of service to which I do not consent".
Oh, wait, I think I've just figured out why I'm divorced.
Especially in Europe! They shouldn't be forcing you to run an OS from an American company.
Even the EU initiative Wero requires Google or Apple. You can't even use it on a desktop pc and you're not even allowed to have developer options on. Ridiculous. I've never seen any app that is so strict.
That's not exactly right, Wero the app is not Wero the payment system. Banks and payment processors are expected to integrate Wero the same way they do with iDeal and similar systems. So ultimately if your bank's app doesn't require attestation you will be able to use Wero through it.
Weird, because Wero is an internationalization of the dutch iDeal and that worked fine without any apps. You clicked ‘continue to bank’, select your bank, and then login on the bank web portal.
American here who values individual liberties greatly. I know things are politically tense at the moment, but I’m not sure I understand this popular contemporary sentiment.
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.
I don't think this is about the current situation in the US.
Big US tech companies are infamous for not following the EU's data protection rules, and they wouldn't even able to, because some US regulations (I think PRISM, FISA and others) are incompatible with the requirements of EU GDPR. This dates back at lest to Snowden leaks and the invalidation of EU-US data protection agreements by Schrems judgments.
https://en.wikipedia.org/wiki/Max_Schrems#Complaints_with_th...
> But what disappoints me a bit about this moment is (the perhaps inevitable?) response to nationalism with more nationalism.
Unfortunately it is now a question of sovereignty and basic risk management, not nationalism ([0] and multiple other sources).
[0]: https://mspoweruser.com/europe-calls-out-us-tech-after-micro...
I switched bank in the UK due to enforced app use, from Starling to Nationwide. They use a card reader to issue codes, so I can still use the web. I see this as a much of a must-have as physical bank branches with real cashier services.
Might be able to file a complaint with the financial services that they're charging you hidden fees to access and manage your money.. (the requirement of having a working mobile, phone, service, etc)
Starling Bank has been officially supporting GrapheneOS using Android's hardware attestation API (not the Play Integrity API) since 2024.
But Starling has always been app only?
You can bank via the website here: https://app.starlingbank.com/login
Might be more limited than the app though.
Starling Bank has been officially supporting GrapheneOS using Android's hardware attestation API (not the Play Integrity API) since 2024.
It's not possible to login to the web-based banking without the app. It's a hard requirement to access the account.
The DSA European digital wallet spec currently requires Google or Apple attestation, so not for much longer.
And that is mandated by the EU.
Sigh.
Reputational awareness is what keeps people safe!
My bank still supports TAN codes with a device too. Unfortunately, once it breaks or the battery goes dead you cannot get a new one and have to use their app. Fortunately, their app works on GrapheneOS without issues.
As long as it includes websites made by commercial entities. Only standardized API endpoints!
Where is the government forcing you here? Does Spain have regulation that obliges the use of apps for banking for certain functionality and disallows websites? Or what are you talking about?
[flagged]
> Not in Spain. I can access my bank's website but I can't do anything without their bank app.
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.
In Estonia you can easily do banking via the website on all the banks (LHV, Swedbank, SEB). That said, we do have it all integrated with our digital-ID (which every ID card has private keys encoded into with a PIN you know) so it's not like you can access it with a simple password (our online voting works the same way).
Can the PIN change? How to issue new key if needed? How does it integrate with the voting?
Voting, much like all other things in Estonia such as getting married/divorced, doing taxes, signing documents, starting/closing companies, notary dealings, bank dealings, selling/buying vehicles, and many more things I can't even think of right now are entirely done via the digital ID that every citizen has. This means that you authorize/sign actions with it, including voting, because only you have your private keys (either in your personal ID card, in your phone's sim card, etc) that you yourself know the PIN for, which then authenticates you as being you. I think we're now at a point where there isn't a single government or business dealing you can not do entirely online (https://e-estonia.com/solutions/).
> in your phone's sim card,
Phones and sim cards a lot more temporary than ID cards. I don't know of a lot of theves that target ID cards for their authorization uses. Phones... people will steal those.
You can close your Mobile-ID when your phone gets stolen so the security keys on it will be useless, and even if you don't close it, nobody can use your security keys without your PIN, which is in your head.
> Can the PIN change?
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.
> You can change it in the app, yes.
Is the app tied to Google or Apple?
Nope, there’s a desktop version, too. And it’s all free/open source: https://github.com/open-eid
(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.)
Wow, that is definitely more sophisticated than we have in the states. It seems like you can use it for things that one would otherwise need a notary for, that is such a timesaver.
Wow, that is nice!
How much the certificate costs and lasts?
It costs as much as your ID card costs by the government, and lasts as long as well. They are one and the same. Applying for a new ID card / national ID document in Estonia costs 35€ and the document is valid for 5 years. If you forget your PIN code, you can reset it with your PUK codes, but if you also lose your PUK codes you need to apply for a new ID card. The process for getting a new ID card from the moment you applied for it takes no more than 30 days. You can also have it fast tracked for 250€ and get it in 2 days.
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.
> but if you also lose your PUK codes you need to apply for a new ID card
Or it seems you can reset the PIN/PUK for 10 €: https://www.politsei.ee/en/instructions/state-fee-amounts
Ah didn't know that! That's way better than applying for a new card indeed.
TOTP not accepted?
(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.)
The question is what generated that TOTP code. The banks must ensure that they "are independent, in that the breach of one does not compromise the reliability of the others," as article 4(30) states. That text is vague as hell, but published opinion of the European Banking Authority on the matter[0] is:
"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...
But they do use apps, and since everything happens on a smartphone - a single point of failure - they aren't independent.
Like most security regimes, it's both overly prescriptive and woefully insufficient. In short, dumb. :(
TOTP not accepted, because the confirmation for payment must include the amount to be paid, which cannot be done under TOTP as far as I know.
Some UK banks (Nationwide and Barclays I know for certain) have had mini card-reader PIN devices since around 2010 that they've given customers, that basically generate on an LCD screen an 8-digit code for authentication.
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.
Moved from the UK to Germany. My German card reader is even better, no manually entering the transaction details, I just scan a QR code from my laptop, and the card reader display shows the IBAN and amounts, before I confirm to get the code.
> And in practise that means a banking app, because most people do not want a separate token they have to buy and can lose.
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.
Probably not for much longer though. Several countries, including mine, have already banned SMS 2FA for banking, and it's likely that that will be implemented for all of Europe in the near future, possibly with PSD3. Not that SMS 2FA was ever a good idea in the first place.
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.
My bank offered that option but not anymore. The use of their app is mandatory now.
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!
I don't know which banks you are using but in my case I work with five Spanish banks and I can do everything from their websites, no app required. Yes, they try to push you to use their app, some tried to activate mobile 2fa for me when this psd2 thing became mandatory but I always told them their app doesn't work on my phone (which is true) and they offered me alternate methods like sms.
In my country we have a large religious population who eschew the smartphone. This means that no government, banking, or other services require a smartphone.
Can you access their websites without the need to confirm 'who you are' with their app? In my case, not anymore.
My bank used to have other options but it has made mandatory the use of their app.
> Can you access their websites without the need to confirm 'who you are' with their app?
Yes, none of them required me to use the app a single time. In fact, for all the banks I work with, I always identified myself at a local office when opening the account for the first time, the last one less than a year ago. And all of them allow me to operate in the website without the need of an app (actually I could never use any banking app as my telephone lacks Google Play).
> 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.
https://triodos.es has 2FA via SMS, for what is worth.
My bank used to have it as well but not anymore. I wonder for how long Triodos will be able to keep that option.
I have been using GrapheneOS for a few months in Spain with and out of three banking apps only one gave me trouble, I had to enable "Exploit Protection Compatibility Mode" on "app information". Personally I refuse to pay with the phone so I am okay not having that option.
If someone wants to try Graphene os maybe that option will work on their banks too.
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'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.
> They do it so they don't have to stand up their own push servers
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.
Why does a banking app that I'm not currently using need to ping a server occasionally?
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.
My comment was about push service sharing generally, not banks, from a technical point of view that many people aren't aware of but may find interesting.
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.
> ...worse visual cues
I'm on Android, and SMS notifications look exactly like every other notification (with one caveat I'll mention below), so I don't know what this guy is on about.
> ...SMSs are just push notificatons with a worse UI...
By this, does OP mean that shit where programs can put buttons and bigass images into their notifications? If yes, I don't want that shit. That's just more opportunity to accidentally trigger unwanted behavior with one's fat fingers, and more screen space gobbled up by overly-self-important software.
The thing that's shitty about SMS is that it's "worst^Wbest effort" delivery... which means that messages can (and will) get delivered late, out of order, or never. Don't use SMS; use email. Email is also best-effort, but -based on my personal experience- far more email server operators give a shit about delivering your messages than SMS relay operators.
That is clearly not the opinon of the product owners and business people. They believe that they own your device, data, and location of when you use it and how you use it. If they want to tell you about their new terrible financial product they will try to force it on you.
Unfortunately it needs push notifications to authorize online payments.
So open the app when performing an online payment.
I thought this was what Larry meant when he said surveillance will keep citizens on their best behavior. If one’s reputation score is low, sorry no money. Also, if anyone in one’s network has bad behavior, no money and no friends. Maybe the kids will learn to accept it, but being of the last analog generation, to me it seems like a painful future.
As far as I remember, last time I needed to use Google play on a shared phone I could just create a random Google address (I mean, completely invented name, etc.) and it allowed me to do anything, just as my normal Android.
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!)
No, they will either immediately or shortly thereafter require you to link a phone number, etc
You can create a Google account without adding a phone number, that's still possible currently. To do this you need to make it within an app, for example Google Play Store or YouTube, not on the websites. You also need to use a trusted IP, so you shouldn't use a VPN. To avoid handing out your home WiFi IP, you can use a public WiFi point or use cellular which cycles IPs more quickly.
Prepare for a subsequent login to result in a 'security check' that asks for more personal details to confirm your account, or you'll be locked out.
In my experience, this can come as soon as the first login after creating the account, or a few logins later.
The original comment was saying:
> 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.
In Germany for some banks you can buy a TAN generator and then you do not need a smartphone app anymore. Is this an option in your area as well?
At my "traditional" bank I even need the TAN generator for my phone. While at my "neo" bank I even need the phone app to access the website. :-) (That is how the neo bank tricked me. I read "website access" in their ad and thought I could still access the bank account if I lose my phone. But no, you can't login without the app.)
It seems like the right time to advocate for open standards in things like banking.
Why? Technofeudalism is not going to impose itself
Especially with how things are currently, I whole heartedly agree - you cannot operate as a human being in Europe without having a good standing with either Alphabet or Apple.
Absolute madness.
Absolute madness or complete nonsense - I have neither an Apple account or device, nor a Google account or mandated device (e/os on Fairphone 3+) and operate perfectly successfully in the UK with (almost [1.]) zero friction.
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.
> Revolut app stopped working so I emptied my account and opened a Wise account
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.
Similar in Canada.
- 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.
Other than the inconvenience, is there any privacy risk in just having a separate device purely for those apps and nothing else?
Or is it more of a principle to resist this being forced on us?
I'd also recommend to slowly migrate to GrapheneOS, getting to know where the boundaries are for specific apps. Once you've got your 'dailies' all up and running predictably, then you're good to go, but it could take a few days depending on how much spare time you have to find said boundaries. Having said that, I turn on most of the higher level security protections, which quite a few apps need exceptions from.
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.
I recommend dividing per persona rather than per app category.
Yes, the way I explained it was misleading, mainly because the different persona's tend to use different sets of apps. The personas, in general, are:
- Personal
- Work
- Sporting Club Committee
- Testing (kinda persona, for things I'm not sure of yet and don't want jumbled together with one of the other personas)
This is where it may become a pain, but for some people it may be worth it: sub-personas or topic-specific like streaming or finance or torrenting or porn or any other category you can think of if you want to keep certain things behind a boundary in case you need to share your phone (main profile) with friends or family members for whatever reason.
> I can use my bank on some linux distro,
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.
It's not really a requirement of a Pixel device. It just happens to be the case that Pixel devices currently are the only devices meeting the hardware requirements listed in the FAQ: https://grapheneos.org/faq#future-devices. The hardware requirements don't contain exoctic things but non-Google and non-Apple companies until now just fail to deliver on the security front. It's also not that GrapheneOS catered these requirements to fit to Google and Google only. They are actively working with an OEM partner since June 2025 to help them meet the hardeware requirements for a subset of their future devices. So they are even willing to assist companies to meet the requirements if they have the ambition to do so. The OEM is not yet disclosed, the launch of the device will be somewhere in 2027.
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.
I hope and pray that is a Samsung S Ultra device. The built-in stylus transforms the whole user experience, I would not go back to a device that I must swipe my dirty fingers across.
I saw one last week. I can't comment about the stylus (but I'm swiping with my thumb to write this message). I held it in my hands and it's a brick but most phones of the last years are bricks so I expect that they will deliver another nearly 7" 200 grams brick. We used to call them phablets. This is one of the models that defined the category in the early 2010s https://m.gsmarena.com/samsung_galaxy_note_n7000-4135.php
It's almost lightweight nowadays and it's definitely small. I remember that we thought that it was insanely huge when pressed to a ear to talk.
I’m just imagining myself pulling out the stylus on the train/plane, dropping it, and watching it roll away forever.
Millions of owners of Samsung devices somehow manage to not do that every day.
I’ve never seen anyone in real life using the stylus on a Samsung phone so I always figured it was a somewhat unused feature of a very specific niche model in the lineup.
The ultra series MSRP is over $1400, I imagine at that price Samsung sells less than 5% of their volume with an integrated S Pen.
They thought of that! The cutaway of the stylus is a rounded rectangle, comfortable in the fingers but does not roll.
In any case, replacement stylii are very cheap online. Less than a screen protector.
Good to know they’re cheap, I actually figured they’d be more like an expensive active stylus.
The Palm Pilot experience. But that stylus was required for operation. Fortunately, just a plastic stick, so 3-pack replacement were cheap.
as long as it is not fairphone. I am out. I don't want to have to choose between privacy and sustainability.
It won't be Fairphone. Fairphone is very far removed from the hardware requirements listed here https://grapheneos.org/faq#future-devices They don't seme to take security seriously at the moment, so the chance is low they are going to make the huge leap needed to meet the requirements. Fairphone heavily markets their sustainability but it's very relative. Fairphone doesn't give proper software support. They don't properly keep up with Android updates and also stop giving updates much more quickly than Google (8 years since Pixel 8) and iPhone. Giving proper software support is also part of what makes a device usable for a longer period of time and hence reduces the need to purchases a new device which has an environmental and climate impact. With regards to the hardware longetivity, Google has good repair programs for their Pixels. It's more difficult and less supported to do repairs yourself but it's certainly possible to repair your device.
> when you can just open the thing in a website anyway. I can use my bank on some linux distro
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.)
> require authentication using their phone app
And banks often have their apps region locked, so if you live abroad or have accounts in more than one country, you’re fucked.
Cough cough, Nationwide UK. I emailed them, they said they had no plans to make the Nationwide UK app available globally on the iOS App Store.
File a complaint to the financial services. They are locking you out from their services.
I was the one that submitted the DNB Bedrift app report to the sec dev repo! I contacted DNB but they never responded to my email. I wonder if we can find a dev? I believe that's how the private app got fixed.
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.
Ah. Where did you send this in?
I wouldn't mind sending in a complaint to both BankID (allow biometric login) and of course DnB corpo edition.
Oh! Sorry, you described the current state of things so well I assumed you were close to the project.
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...
Hah - both were in my browser history, yes I know them :) I misunderstood and thought you had sent direct emails to relevant parties arguing for why they should be allowed on grapheneos.
Thanks anyway!
Oh I also misunderstood! I did send an email to DNB Bedrift customer service about Graphene support, citing the private app fix. They technically gave me a response that it would be looked into, but it felt very handwavy, and that was 3 months ago. It was via the bedrift portal, there is a "Send E-Post" button.
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.
Does the Nordea app work on Graphene? I am curious because I have been itching to switch my main phone to an alternate OS.
Yep! Perfectly, I use it daily. (The private customer one, not sure about business.)
About BankID: There was a regression in the app back in june that broke the app entirely. Back then I emailed the developers complaining about it, and their response indicated that there was no deliberate attempt at breaking BankID on GrapheneOS, and the specific developer who replied to me said he was a fan of the OS.
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.
Fwiw, biometric login works fine for me. You need to install something like DuckDuckGo or Brave and set as default browser during setup. And only Google Password manager works for storing the passkey.
Thanks for the Norwegian perspective.
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.
Those people who root their phone and install alternate OSes sure are less technologically competent than someone with a browser and a laptop
“Installing alternate OSs” is juicy bait for “tech enthusiasts” who know just enough to be effectively worse off than someone with a browser, yes, and at its core is this holier than thou attitude.
I agree that the locking down is truly stupid.
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...
Needing to use a verified boot chain with keys that the bank trusts is essentially the same as using the authenticator device from said bank, except this one costs 100€ or more, has a microphone and camera built in, and you use it for private messages as well. That's not a future I want to live in
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
Needing to use a verified boot chain with keys that the bank trusts is essentially the same as using the authenticator device from said bank,
It's not, because even though the authenticator is secure, you are entering the auth codes in a browser in general purpose desktop OS with (if you use Windows or desktop Linux) little to no sandboxing outside the browser. You are one malware app (or NodeJS package for tech users who claim they'll never download malware) for your session getting hijacked.
The sad reality is that phones (and some tablets) are the only relatively secure computing environments that we have. Thanks to Windows with it decades of piled up legacy and Linux with large sandbox and secure boot-hating parts of its community, we cannot have nice things.
(The part about the Linux community, which I'm also part of is a generalization, but the hostility against Flatpak, secure boot, etc. is pretty big.)
That seems wrong. If malware can fake what the authenticator shows me, the authenticator is broken!
It doesn't matter what device relays the code I typed over or otherwise transmits the approval through untrusted networks to the server
> The sad reality is that phones (and some tablets) are the only relatively secure computing environments that we have
My bank('s authenticator hardware) begs to differ
That seems wrong. If malware can fake what the authenticator shows me, the authenticator is broken!
That's not what I am saying. The authenticator is irrelavant to this attack. If your machine is compromised by malware, the malware could take over the browser session, regardless of how you log in.
Phones are better protected against persistent malware because every application is sandboxed (harder to escalate) and much more of the boot chain/OS is validated (harder to persist).
The authenticator preserves account integrity with the compromised host attack you describe. The device I have shows something like "you are authorising a transaction of 1337€ to RU07BANK012345678, y/n?". What an attacker can do is read along while I log in, but not modify data
The server generates the challenge that's sent to the authenticator. The attacker can modify and replace it by being in your browser and show any text on your computer screen, but the authenticator will either show the truth, or the approval code it generates doesn't match the server's challenge
> That's not what I am saying. The authenticator is irrelavant to this attack.
If you need to change the security measures (take out the authenticator) in order to be able to mount an attack, maybe that means the security measure is working? xD
Trying to understand your point here. If you're merely saying that phones have better process isolation then I can only agree, but I wasn't saying that it doesn't. You can use online banking on your phone OS if you like, or use Android on your laptop. The comment you replied to upthread said that I'd like to have ownership of and freedom within my own hardware, in order to have privacy. When banks require that my phone is DRM'd with some keys from Google, Samsung, or Apple, then suddenly that has a lot of consequences for what I can and cannot do with, or inspect about, the device. Using an external authenticator, which they can attest to their heart's content, is the solution that I'm using and aligns with all parties' goals. Banks don't need to require that everyone's phone is locked down in order to use the banking software, just like it isn't in the browser, while still meeting their security goals
> 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!
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...
> I can use my bank on some linux distro, crazy that they trust me
enjoy it while it lasts. hardware attestation requirement for (at least) banking apps is a question of 'when', not 'if'.
I hope this isn't going to be the case universally. If my bank cuts off my access from my browser-on-linux setup, then I'm finding an alternative bank (hopefully some will always exist), which I don't say lightly since I've been with my current bank since I was old enough to have a bank account.
You'll quickly find out - as people are finding out in EU nowadays - that *no* bank will go through the trouble of fighting checklist security auditors to keep your linuxes working.
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.
Keep complaining to the regulators that you're being locked out of your account. Sue them and keep escalating. Forcing you into a system where you have to pay, maintain, etc for access is often not legal.
The regulators are the ones that support device attestation and security measures though.
My bank has always had hardware attestation, but it was their hardware that was being attested. Customers get it loaned when signing up
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 agree completely, except looking at my 2fa app I'd need 20 physical tokens, so we actually need a super-duper-yubikey
Yeah, I should have pursued the idea ten years ago of making a usable 2fa hardware device (that confirms what you're authenticating and an attacker can't simply pull auth codes for whatever they want)
Still, I'm plenty okay with my phone as a second factor for my laptop and vice versa for nearly all services. The rest is about tying things to a government identity (bank cares only if it's me who's authorising the transaction; government cares only if it's me who's requesting a student loan) and can be done with the chip that's already in my identity document and a single 20€ nfc chip reader or by using a phone as nfc reader
Same with Lineage OS, may daughter has an old Samsung with Lineage on it and the Wallet app doesn't work because the phone's been rooted.
You're doomed to this issue with old phones in general.
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.
Generally Lineage is the latest. Unfortunately, there are other issues (such as the blobs that Lineage needs drifting out of date, and it's usually suggested that you'll should backup and then wipe to upgrade to the next major release, etc.)
Wallet app is still impossible to get working, but there’s been some development recently: https://github.com/microg/GmsCore/issues/361
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.
[0]: https://lineage.microg.org/
Well, I’ve jinxed it. My current “neobank” of choice, TNG eWallet, is onto me now :(
(Not because of my comment, probably – I’ve upgraded LineageOS and had to reinstall everything. But just in case you guys read this – please, just let me bypass it, I’m aware of the risks :)
All of my banking related apps work fine.
The only apps that haven't worked are Google wallet for NFC payments and, strangely "macrofactor" a calorie tracking app.
Google wallet works for things like library cards, tickets etc, just not NFC payment.
Macrofactor since seem to have fixed their app, the features that did not work now do.
Graphene used to lack android auto support but it has since been added and works perfectly.
They maintain a guide for app developers as well as a list of apps that refuse to add comparability here:
https://grapheneos.org/articles/attestation-compatibility-gu...
It sorely needs to break free from the lackluster Pixel hardware. The OEM announcement can't come soon enough (and I hope it's Motorola).
I have a few features that I need that I'm not sure if Graphene supports. If you could check that would help!
Can you record phone calls? Do third party voice recorders continue recording even when the screen is locked? Thank you!
Yes to both.
Thank you!
The last release (as of writing) even had some call recording goodness: https://grapheneos.org/releases#2026021200
Enjoy
> BankID works but not with biometric login
Do you use any authenticator apps such as Okta? My org requires biometrics when using Okta on my phone.
I use microsoft authenticator, in its own work profile for work. I also use fingerprint login for Nordea, the Proton Suite, my personal 2fa program. Biometric works great on the Pixel 9A, at least, and it was fine on the 8 Pro when I had it.
The BankID thing is a SW quirk on their end, but generic fingerprint seems works great across the ecosystem.
This reads like a very norwegian experience!
For the tap to pay I am now using my Garmin smartwatch. Still corporate, but not Google/Apple huge corporate.
Very content with GOS otherwise. I blame app providers for their ridiculous limitations, not custom ROM developers.
[dead]
[flagged]
I personally tend to own two Phones. One all-day carry GrapheneOS device (Pixel 8) and an older WiFi and at home only iPhone for all payment and ensurance stuff.
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.
Some other FOSS apps I use daily:
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/
Some others that I use:
* 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.
> I don't see F-Droid itself mentioned
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.
Additionally, the official F-Droid app creates unnecessary friction for GrapheneOS users they refuse to address: https://gitlab.com/fdroid/fdroidclient/-/issues/2914
Neo Store looks interesting, but the readme in the GitHub repo includes emojis in the feature list, which is a bit of a red flag for me, especially since the project appears to have started only two years ago.
I'd add that KDE Connect works great with Gnome too
I also like AntennaPod for audiobooks--fewer apps that way.
Thanks for the links. I am concerned about supply chain attacks and such with FOSS tools these days. It seems like the easiest attack surface. In my dev opinion it’s not if it’s when. Kinda sucks and I think the adversary is moving faster than the provider. (I have created and maintained public domain software but not currently. Now I’m crapping on the thread sorry. But no one else is sorry for crapping on threads…I need to stop over thinking or maybe just close this tab)
Can't believe I've never heard of Unexpected Keyboard. Installing immediately. Thank you.
I like Organic Maps because it isn't full of the social things. Every time I open Google Maps it shows that card at the bottom with "what's popular in your area", full of pictures of people's breakfasts and other nonsense. Organic Maps is free of this noise.
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).
All map apps I tested so far were kind of usable but nowhere near Apple or Google maps. Especially for longer trips I often got lost and had to re-navigate by different reasons (voice announcement too late, no lane instructions, etc.).
However, I listed it because it is a "usable" alternative that works offline.
Idk, pedestrian navigation has been pretty decent for me so far. (There’s been one case of it showing a path in Tbilisi that would require me to jump from a 3 m wall, but it was exactly once.) I suppose it depends on which city you’re in and how well mapped it is on the OSM.
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
I used OrganicMaps for navigation from the UK through France, Germany, Switzerland, back into France and then Spain last year on a 2 week enjoyable camper van trip. It can take a while for routing changes if you ignore it and decide to drive elsewhere, and I don't really use the voice alerts (I just have it on my phone on the dashboard via a magnet), but all in all it worked really well.
Although I would like speed limits shown in MPH in the UK, OrganicMaps' KMH limits were useful on the Continent.
> I like Organic Maps
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.
Öffi, if it has coverage for the areas relevant to you: https://oeffi.schildbach.de/index.html
Thanks for the tip, I'll check it out for when I am back in central Europe, but I am currently based in south Europe and sadly my country/city are not covered.
FWIW Organic Maps are aware of this issue. In the poll on their mastodon account, lack of public transit information was voted as number one missing feature. As far as I’m aware, they are looking into integrating the public APIs for it wherever possible.
Google maps discover feature is a dumpster fire for fomo driven brain fog
Due to [0] and [1] I'm using the new fork "CoMaps" now, feature comparison: https://www.comaps.app/support/how-do-the-features-differ-fr...
It's pretty excellent! The improved integration with OpenStreetMaps to provide edits/additions is great. I made my first contribution to OSM via CoMaps.
[0] https://www.comaps.app/news/2025-04-16/1/
[1] https://www.comaps.app/news/2025-04-25/2/
I like your recommendations mostly, just wanted to point out that Organic Maps has had a falling out with the Open Source community that built it, so I wouldn't use that anymore. The community fork is called 'CoMaps' now.
Great... I consider this for my next App listing. Unfortunately there is no edit option at the moment. Since I don't use Organic Maps any more, I just remembered it being the most usable alternative.
Comaps seems to have a lot of benefits though.
Isn't organic maps itself a community fork of maps.me?
Thanks for this, it's so helpful for people trying out a new platform.
I'd love to have something like this for Linux desktops as well. Maybe a website that has app-lists, where people can then potentially add info about their use cases and reasoning for their choices. Could be a great subreddit!
I tried Omarchy specifically because installed an opionated selection of apps to covered most bases, and it got me started in Arch fairly quickly. I've now completely swapped out all the components so I no longer use Omarchy at all, but it was a great way to get back into desktop Linux after being away for 20 years.
Maybe you might want to try out my zarch[1] repo, which is a Linux on ZFSBootMenu installer script for ArchLinux with configurable profiles - basically a folder with some package listings.
The t480s profile is my personal Notebook config, which is not fully up to date but probably a pretty good start. You can also only take a look at the archpkg.txt and the aurpkg.txt to see the packages that I'm using.
1: https://github.com/sandreas/zarch
Grayjay is another good YouTube (and other streaming platform) client made by the company that owns Immich
Uh this looks nice. Thank you.
What would sandboxing an app like Google Maps look like? There are definitely situations where a sub-par map app would be detrimental. Obviously it's going to send data to Google, but do I have to sign into an account or will it have some other way of identifying my phone if I used a one-off account just for it?
Google Maps is sandboxed even on the stock Pixel OS. Sandboxing is part of the AOSP. GrapheneOS hardens the sandbox a bit, but it's not the most significant feature of the project. What isn't sandboxed on Android OSes that license Google Mobile Services (GMS) is Google Play (Play Store, Play Services and for older installs also Play Services Framework). On GrapheneOS Google Play is sandboxed as well, so it's treated as any other regular app, it's doesn't get priviliged exceptions.
Sandboxing isn't what would prevent an app from sending data. Sandboxing restricts what an app can access on your device because access is gated behind permissions and apps also can't peek into other apps. So it won't just be able to grab and send out data you don't give it access to, which is the most important of course.
You can install Google Maps and use a dedicated Google account for it with limited personal info. You can avoid giving your real name and also giving a phone number if you make your Google account from within the app and on a trusted network (not a VPN adress but public WiFi or cellular). It won't be able to identify your phone using hardware identifiers because non-system apps don't have access to those, the only regular app that might be able to acces such hardware identifiers is an app which is set as the default SMS app. See: https://grapheneos.org/faq#hardware-identifiers
It doesn't need to be logged on to a Google account, and it supports locally storing map data and generating routes, so you could turn on network access, download local maps, block network access, then use it for navigation without it calling home.
There's also value in live traffic and road closure information.
That's a more difficult one, because that traffic data itself is aggregated from location sharing.
Voice audiobook player is so nice and simple, a pleasure to use
I recently PR'ed some improvements within the search (series and part are now searchable).
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)
"Break free from Google" and buy a Pixel phone from them to do so.
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.
Graphene is supposedly working with a major OEM manufacturer to have future device support independent of google, on a flagship device. It's been in the works for awhile but it's very exciting.
https://www.androidauthority.com/graphene-os-major-android-o...
I hope it's Fairphone.
It won't be Fairphone. Fairphone is very far removed from the hardware requirements listed here https://grapheneos.org/faq#future-devices They don't seme to take security seriously at the moment, so the chance is low they are going to make the huge leap needed to meet the requirements.
The tea leaves are indicating Motorola.
Its not.
Pixels are really great despite being from Google. I hope they will continue to make them unlockable/relockable. As you say they are also surprisingly hard to brick. Here is someone trying to break it intentionally during the GrapheneOS install:
https://www.youtube.com/watch?v=ik0AiO0WtuU
If you don't like giving money to Google, plenty of companies offer refurbished Pixel phones.
In the US, many refurbished Pixel phones are Verizon variants which disallow OEM unlocking.
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.
Oh man, sorry to hear that! On the other side of the pond, carrier-specific/locked phones haven't been a thing for ages. Haven't seen a carrier-specific phone since 2013 or 2014.
Is it not possible to buy a phone in the US without any cellular providers involved? I thought that kind of lock-in was a thing of the past.
It is possible, but many people still buy them from their provider with financing or subsidies. That means people shopping for used Pixels who want to unlock the bootloader need to avoid the special Verizon variant which forbids unlocking the bootloader.
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.
Yep. I lost a restocking fee when I bought a used "unlocked" Pixel. Turned out it was not SIM locked, but it was impossible to unlock the bootloader. It was pretty easy to find a bootloader-unlockable Pixel once I knew what to look out for, but the first time I had no idea this was something you had to look out for.
I have a Pixel 6a with GrapheneOS. Runs great for years, except for one or two apps that require an "official" Android.
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.
That makes no sense. If there is a recall program for safety, surely they have to accept whatever software is on there? It's not relevant to the hardware repair
> "Break free from Google" and buy a Pixel phone from them to do so.
Pretty much yeah.
Also, the surveillance tech is getting ahead of the people now, this article might make sense back in 2015, it’s not the case anymore, even if you use a full linux distribution, hardened too, but connected to the cellular network through a modem, the operator can pinpoint your location accurately, because all new cell modems are equipped with gnss and send the NMEA message either in demand or periodically to the towers.. not to mention if your software is open source and secure, your hardware isn’t, and until we reach that point, I would prefer to have a gray man model and blend in within the crowd rather than standing out like a sore thumb.
I've wanted to try this on my old Pixel 5, but it has the dreaded screen/motherboard failure. It appears there is no solution for that short of replacing the screen/mobo, which i've already done once after cracking it.
[dead]
And once you are on GrapheneOS, break free from your proprietary watch ecosystem and switch to GadgetBridge (https://gadgetbridge.org/)
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.
I tried GadgetBridge because it cannot sync the activity files (.fit and/or .gpx) so I still had to plug the watch into a computer to keep the actual data.
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.
[0] https://github.com/alex-hhh/ActivityLog2
Under settings->automations->auto export, you have "Auto export zip" where you can specify export interval. The zip file includes all the data (personally, I only see .fit files) from your app. For sync, you might have to use something like syncthing.
Alternatively, consider PineTime, which even offers a choice of the OS it runs: https://pine64.org/documentation/PineTime/
Also there's AsteroidOS which is a wrist sized linux for your watch, and looks fantastic! - https://www.youtube.com/watch?v=U6FiQz0yACc
Related discussion: https://news.ycombinator.com/item?id=47051852
Garmin watches seem quite open even without that. I have all my data syncing to influxdb every 15min for a Grafana dashboard and it works great.
In background I also have Withings scale sync the measurements a couple of times a day to Garmin.
How do you sync the data out of Garmin? Something like https://github.com/matin/garth, or syncing directly from the watch?
Probably the reason why Garmin watches are well supported by GadgetBridge
I didn't need anything more on my to-do list, but this is intriguing.
Setting up GadgetBridge is very easy since it's just an android app. No flashing firmware etc. However, not all gadgets are equally supported, and you should check the support status of your device - https://gadgetbridge.org/gadgets/ (I bought my watch only after checking that page for compatibility).
> And once you are on GrapheneOS, break free from your proprietary watch ecosystem and switch to GadgetBridge
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.)
You can lock the bootloader again with GrapheneOS and many banking apps work.
You won't pass Google Play hardware attestation that way, and you won't find a bank in Europe or the UK that doesn't require that to log on to their website within five years.
My bank works fine after relocking (in NL, Europe). And last time I checked all Dutch banks work. My VISA credit card app (from ICS) also works. Same for the government identification app, the government message app, our insurance app. In fact, I haven't encountered anything outside of Google Pay that didn't work.
(I don't deny that there are apps that won't work. Best to check before switching full-time.)
That's a prediction I would disagree with. Firstly, there are application developers which specifically add support for GrapheneOS if they are asked nicely. Secondly, there is a chance that Play Integrity will have to change due to anti-trust regulation.
You pass basic, but not device or strong integrity. This is purely googles fault and is an artificial limitation that requires regulatory restrictions.
> - the pandemic tracking app without which you can’t enter an airport
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.
No banking app on phone because why; no government app because oh fuck why, whats wrong with your government (at least in primary phone and I never needed secondary); app for sport events - thats just me but I prefer doing sports rather than passively watch them, so 0 loss; pandemic what? its 2026 and I never saw such requirement in Europe, Africa nor Asia; no other app requires that.
Thats not coming from some paranoid security person, just regular (software dev) joe.
Most banking apps work perfectly, most government apps work perfectly, etc. It is only an exceptionally small subset of apps using anticompetitive measures such as play integrity.
Also, do not leave your bootloader unlocked. That is an incomplete GOS install and you will need to lock it to secure your device. Not locking it is both insecure and will make a much higher number of apps fail.
YMMV. I run sandboxed Google Play Services on GrapheneOS so almost every app works. My digital payments app works, and the same with most government apps I have tried. My private bank's app doesn't work, but I just use their website for the handful of times a year I need to access it.
Does NFC work with those digital payment apps on Graphene?
In India we use QR codes for payments. NFC in general does work (for example, I use a yubikey for 2FA).
Been running GrapheneOS for a while on a Pixel 9, and extremely happy with it! Apart from the usual perks of the FOSS ecosystem, there are a few things specific to GrapheneOS that are not immediately apparent but have turned out to work very well -
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).
8. External storage works. This is the only mobile OS I've found that has stable support for an External SSD.
I bought a second hand Pixel 7 to test this and an exFat SanDisk Extreme Portable 2TB works with reads/writes perfectly.
> This is the only mobile OS I've found that has stable support for an External SSD.
My Librem 5 running PureOS also supports external storage just fine.
Very good to know!
> 3. Android Auto works!
Does this require installing google play and other google services to work?
Edit: https://grapheneos.org/usage#android-auto
>4. Android QuickShare works!
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.
Unfortunately yes, and I am signed into my Google account for it.
That's a hard pass.
> 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.
There's also GCam https://github.com/lukaspieper/Gcam-Services-Provider
I don't know if it matters, but GPhotosShim doesn't seem to get updated.
I originally wanted to get the Pixel camera app working when I got started with GOS a few years ago, but then I found Open Camera and haven't looked back. Does it do something cool that Open Camera doesn't?
You can select the different cameras and avoid digital zoom.
Open Camera does that though. It's right next to the main "take photo" button. At least on the version I have.
I hadn't seen that button, but at least for me it's not enough: I want to be able to select the camera directly. And in Open Camera I can only select two out of the three cameras.
A quick question from potential buyer of next generation of pixel phones, since samsung keeps disappointing hard with their top line - is there any difference in quality between default photo app and what graphene os bundles with?
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?
Yes, it's a huge difference. However, you can install the very latest Google Camera app through the Aurora app (or Play Market), and it works perfectly except you don't get photo preview within that app; to fix that minor issue, you can install the Gphotoshim which someone else mentioned in the comments.
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...
Duckduckgo's only hit for "Gphotoshim" is your comment. Any hint at what to look for?
https://github.com/CaramelFur/GPhotosShim
Thank you! Double s in the middle was the fix I see :)
If photos are important for you GCam is a must, you can download it
wish my yubikey would work with bitwarden
My Yubikey works with bitwarden on GrapheneOS using NFC.
ooo you must be special. which app store did you use to download bitwarden?
From the Play store.
I've used GrapheneOS on a Pixel 3a, 5, 8 and 10 Pro so far and it's worked really well. I couldn't imagine going back.
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.
> 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
AdAway (in F-Droid) can block with /etc/hosts (no VPN involved) if you have root. The hosts blocking still works even when connected to a VPN. Aside from loading ad domain lists into /etc/hosts, it also allows you to specify custom domains to block - I personally have Reddit and HN in there :)
> AdAway (in F-Droid) can block with /etc/hosts (no VPN involved)
lifts head
> if you have root
Sigh. :)
Sure, on LineageOS back in the day I used to edit /etc/hosts by hand. On GrapheneOS I no longer have root, though (unless I compile it myself), which generally I think is a good idea, weren't it for Linux's absolutely abysmal access control system that requires you to be root for almost everything.
> Being able to install browser extensions in Vanadium.
You can use IronFox - available in Accrescent store that comes with GrapheneOS, and install firefox extensions
So uh… why not just use Firefox directly?
Yes, I already do that but: - Vanadium is said to be safer. - The reality is that websites often don't work in Firefox anymore. - I want to be able to block social media at certain times. (Today I often circumvent such blocking in FF by just opening Vanadium…)
IronFox is Firefox with different settings. IronFox is security focused and hardens gecko preferences - https://ironfoxoss.org/docs/features/
Using a Chrome based browser (i.e. Vanadium) is not an option for me because I need my extensions and generally prefer using firefox everywhere.
You can use labels for contact scope.
You might want to read my comment again. :) If you use labels, the app will have full access to the associated contacts, not just to their names & phone numbers.
So it's not about labels, but you want the ability to restrict the fields an app has access to rather than an all or nothing – full access to a contact or none at all?
Precisely!
I'm annoyed at everyone who shares my name, phone number and any other details with Meta. I never consented to it. The behavior of their app slurping up your contacts database is despicable.
This doesn't answer your question, but in case it helps for others out there: it's possible to use WhatsApp with no access whatsoever to your contacts and I used it that way for years. Connecting with people is slightly jankier but it still works.
> it's possible to use WhatsApp with no access whatsoever to your contacts and I used it that way for years.
Yeah, that's what I do right now.
> Connecting with people is slightly jankier but it still works.
Without GrapheneOS's contact scopes, how exactly do you do that? Doesn't the other person have to message you first?
You can have a second or third VPN active if you use a work profile and private space
Note to self: look for second hand unlocked Pixel 10 pro!
This is especially interesting in regard to the recent HN dicussion on spyware by for-profit intel firms having access to Whatsapp, Telegram, Signal, etc. (https://news.ycombinator.com/item?id=47033976) through OS-level no-click hijacks.
I wonder how secure GrapheneOS is in that regard, and what the other contenders are?
Hard to say how it fares against those specific attacks but some of the vulnerabilities that will go out in the mid-2026 on the mainstream handsets are already patched: https://grapheneos.org/releases#2026021200
(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.
GrapheneOS themselves dont pretend that their secure from that level of attack, but its about evaluating your own threat level. State sponsered actors aren't burning zero days on the vast majority of people, and you only need to look at how badly several european governments want to ban graphene and similar to see that such exploits aren't even being burned on organised crime. Realistically unless you're a journalist or considered a political target you're gonna be fine with graphene.
Thank you for the insight. Indeed, a concerning state of the world where criminals are less at risk from spyware than journalists and activists.
Its definitely a scary world, safe to assume all your online activity could be hacked if so wanted. Just gotta hope its not wanted and that it doesnt become possible to do it on a mass scale (UK is currently pushing to ban E2E lol, and I know the EU has contemplated similar. If you do fall into the wanted category, face 2 face is really the only option. I know a lot of politcal/investigative journalists also constantly cycle and maintain burner devices but even thats a risk of just how long is a safe time before a device is considered burned.
GrapheneOS have hardened_malloc which is a huge advantage, I think. It makes the weird machines problem much harder. I would say be very careful, because you can still get previews of images, or old and weird media formats that could be exploitable, and android/GrapheneOS doesn't have the same sorts of policy as say Apple with the iMessage blast door. They control safari, etc.
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.
Chromium is the only web engine present on a fresh install. If a user doesn't install a browser with another engine, the attack surface doesn't get increased. Chromium/Blink is more secure than Safari/Webkit overall so I don't really think this is an argument in favour of iOS. iOS for sure does some good things though and is better than Android in some areas.
It's quite secure against casual attacks, but a proprietary mobile platform has inherent issues wrt. withstanding even mildly sophisticated attackers, including mercenary spyware services. You still have a huge attack surface from all sorts of proprietary firmware blobs and hardware IP blocks that are running directly on the SoC. It's not clear that it's really worth even trying to secure it as opposed to just treating it like an untrusted toy.
Interesting. What are the alternatives to GrapheneOS that you wouldn't consider a "toy" ?
In my understanding, it's not the OS that makes it a toy but the hardware. I guess something with open schematics (Librem 5, Pinephone) should be better, or an open-hardware device like Precursor.
If the open hardware offers at least comparable security then maybe. If the hardware is an open book then no.
A short list of the hardware security measures necessary to consider it "not a toy" ;) -- https://grapheneos.org/faq#future-devices
I'm not convinced that all of these is required for security. My Qubes OS desktop is probably more secure than any GrapheneOS phone, and it only requires good hardware virtualization for that.
> If the hardware is an open book then no.
So you choose security through obscurity. I have no further questions.
If you choose open platform with barely any hardware security measures then indeed, no questions from me either :)
Which security measures? I do have TMP with Heads.
Let me list several of the more impactful.
- dedicated, certified security coprocessor (Titan M2) - on pixel it's fused with verified boot, offers key storage, firmware isolation and anti rollback.
- verified boot: mandatory and backed by Titan, immutable boot from. Almost all laptops lack as much as anti rollback.
- strong hardware-backed key protection and actually isolated TEE. Yes, I know about Intel (SGX/TDX) and AMD (SEV/SME). Broken into many times over. How many commodity hardware devices offer comprehensive protections like Titan-backed TEE?
- secure hardware-backed disk encryption key derivation (with throttling of course)
- on-device attestation: complete verification of the entire chain. Dreaded Play Integrity or open AOSP / GrapheneOS hardware attestation. Which PC vendors can offer that? Perhaps Apple but that's not a pc and you won't run qubes on that?
- physical anti-tamper: which laptops wipe encryption keys stored in the secure hardware when you're trying to unlock the bootloader?
- physical memory tagging (see ARM MTE). Apple offers some but again, that's not for qubes. Intel promises MKTME in the future.
- does your laptop disable all the unconnected ports whilst the laptop is broken? Does your pin/password verification happen inside TEE/TPM, not in the OS?
- modes similar to PXN/SMEP, SMAP/PAN (to stop these pesky wifi/gpu firmware from reading userpace memory). There's some support for SMEP and SMAP on intel/amd
- microcode and firmware upgrades velocity
There are reasons GOS doesn't support any hardware other than pixels. Regrettably and thankfully that is about to change soon <3
Don't read me wrong, qubes is brilliant and on SOME hardware (business grade laptops with TPM 2.0, verified firmware upgrade process with some protections and proved track progress with rapid hardware drivers and firmware upgrades -- sure, brilliant choice. For pcs.
But is not even remotely close security-wise..
Best available would be probably Purism Libre (lacking TPM if I read it correctly, weak hardware but, oh well, pixel is not super fast either lol), or something with coreboot perhaps?
Whats the safest and still useful laptop hardware you cna think of? Let's compare with with pixel.
Thanks for the detailed answer. Librem laptop is exactly what I use, with TPM and a hardware token. Also with Qubes OS.
x86 virtualization isn't perfect at all
QubesOS certainly has some good things going for it with isolation but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS
Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.
With regards to security through obscurity, the Pixel firmware isn't obfuscated at all. It's closed source but it's easy to decompile the code and inspect it. They don't try to obfuscate it to make that difficult.
> x86 virtualization isn't perfect at all
You cannot just say this without any links. Last escape from VT-d virtualization, which Qubes uses, was found in 2006 by the Qubes founder ("Blue Pill").
> Iirc it's not even possible to run QubesOS on hardware that has proper verified boot or non-meaningless secureboot.
You can run Qubes OS on something even better: Coreboot with Heads and with a hardware key. All based on FLOSS. Works for me.
> but the guest VMs which run traditional desktop OSes are generally much less secure than mobile OSes like Android OSes and iOS
First of all, you can in principle run any OS in Qubes VMs, including hardened ones. You can even disable the root account. Second, with such statement, you misinterpret the Qubes' approach to security. You isolate trusted workflows from untrusted ones, which gives you the strong security. You never open anything untrusted in trusted VMs, so their internal security plays no big role.
There is no way to know whether the phone you buy corresponds to the open schematics that are published. It's not verifiable like with software.
This doesn't sound right to me. Not an expert, but I saw many discussions confirming that this is possible.
well, a concerted attack could easily subvert the baseband if you have a few million dollars and the correct letterhead or private contacts.
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?
> well, a concerted attack could easily subvert the baseband
In theory Pixel phones have IOMMU and GrapheneOS is using them, so even a compromised baseband doesn't result unrestricted access to the system.
GrapheneOS distrusts the network. Connections use HTTPS and the integrity of important things like updates is also verified via signatures.
> 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.
The firmware being proprietary is compeltely unrelated to how much attack surface it has compared to open source firmware. The only thing that matters is how secure the firmware is.
So if a toy OS is the only one to withstand attacks with Cellebrite, what do you consider not a toy?
It's just an Android fork. Almost certainly it's equally affected.
That's too simple. First of all, Pixel (which GrapheneOS requires) is one of the few Android phones with a separate secure enclave. GrapheneOS also applies a lot of hardening that other vendors do not: https://grapheneos.org/features#exploit-protection
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.
I've been using GrapheneOS for about 3 years now. For the most part, it works very well. I don't have any issues with banking apps, nor any other closed source apps. I'm using two profiles both with sandboxed Google play installed. I'm logged in into my private Google account on the work profile.
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.
That's clearly a Uber problem. I'm also a GrapheneOS and used Uber once -- it worked.
It's clearly end user problem who is not able to book a ride. Root cause is on Uber side.
I'm a new GrapheneOS user and stopped using Uber as altogether. Taxis aren't that bad where I'm at, and cheaper than Uber
I wish I could stop using them for these rare occasions I need a transport.
Taxi across the town is £20, Uber usually 5-10. There are no other providers.
Taxi from my airport (some 15 miles away) is £60-80, Uber usually £30-ish. Public transportation (2 trains + 2 buses) over £50.
I wish I had an option.
I get public transport being more "difficult" than uber, but more expensive too? Where are you from if you don't mind me asking?
Yeah, it's more expensive - in this case because of the changes and separate operators on every part of the journey. I could potentially swap one train for a bus and then take different train and skip one of the buses saving some £5 but extending trip by about a hour at least.
Maybe not being able to use Uber isn't the downside you think it is though. UK centric view but call a cab and pay in cash, you haven't comprimised your security and you're not engaging with an unethical business.
Well, you still might engage with an unethical business, but at least the chance goes from 100% to somewhere between 0% and 100%.
I've run into my share of scammy taxi drivers.
Right but at least then you are the one being scammed, and can decline to be scammed if you wish. As opposed to willingly partaking in a shitty system.
I regularly use Uber on Graphene OS and have had no issues.
>there was one case that lead me to thinking about ditching grapheneos to this day
Your aim is misplaced: ditch Uber, not GrapheneOS.
No problem here with Uber on GrapheneOS.
Same. Using it (rarely) off the secondary profile and everything works.
How do you know this was Graphene OS' fault?
Uber works in browser on mobile (and desktop). Last I checked lift did not.
Lyft app works on GrapheneOS.
Using websites instead of apps, while often more annoying, minimizes dramatically the privileges you provide to services.
And the amount of lock-in. If they ever decide to kick out your favorite OS or hardware vendor, well, good luck doing that if you can use the services on a website. They'd have to port all the web users over to mobile and know they'll lose at least some of those customers
Last time I checked you could still book a ride using the website.
What exactly is the risk of getting temporarily banned on Uber? You have to use a different taxi app? As if such a thing even exists?!? Unacceptable!!
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.
The key phrase there is "such services". It's not just about one problem once with Uber, it's the risk of problems like this with any service of that kind, or really any service you rely on.
If using GrapheneOS significantly increases the risk a person won't be able to use a service they rely on, that may be unacceptable.
But that's my point, what one irreplacable app/service do people rely on? The only thing that comes to my mind is messaging apps, but even there, almost everyone I need to talk to is reachable on at least one other app. I have multiple taxi apps because I compare prices and availability, like any reasonable consumer should. I have two banks, but even if I didn't, I can pay by cash or card, not just phone. If I need to make a bank transfer, I can go to a branch or do it online. I have two map and navigation apps because they have different strengths and weaknesses. My email is accessible by browser if the app breaks.
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.
[dead]
If the same thing happens with the Lyft app, you may be stuck at your current location indefinitely, especially in less populated areas/late hours.
And what is preventing Lyft/Uber whatever's algorithm to have a bug and just falsely flag your account after registration? Like there is no guarantee it works on a stock android/apple device either and I'm fairly sure they have a long list of false flaggings that support has to unlock day-to-day.
About his comment:
> 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.
This has been my experience with Windows too. Airpods connect out of the box on Linux, but on Windows they would stop pairing every couple minutes until I fixed some drivers
You can even install GrapheneOS from another GrapheneOS Vanadium browser. No computer required.
It's a shame only Pixel phones are supported. I have PWM sensitivity and Pixel phones are notoriously bad for this, my eyes hurt when I look at one for more than 30mn. Due to the lack of good, secure alternative, I have had to give up on privacy in exchange for manufacturer updates.
The Pixel limitations has been my main concern as well.
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...
That article speculates the OEM is Samsung but I find that very hard to believe. Samsung is totally beholden to Google. The discontinued their own DeX and Tizen smartwatch OS for Google alternatives and as for their "AI" features most of them actually come from Google.
Google would not allow this and they're way too entangled with Samsung.
Interesting article. Let's now hope for a reasonable price, even though it will be challenging for their team. It would be a shame if the target audience is limited to overpaid nerds like most of HN.
> when I look at one for more than 30mn
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.
I'm in the same boat. Bought a 9 Pro XL and had to return it. Hope their OEM will use DC dimming for the screens or have an IPS option.
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.
Seriously. Especially if you're someone who wants to cut ties with Google.
So, buy it refurbished? Google doesn't directly profit from it, you create less pollution, and once you have GrapheneOS on it you can leave Google out the door.
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).
Not a bad idea.
Seconded. Really hope the new Graphene device does not have terrible PWM. Battery benefit to OLED is great but not if I can't look at my phone.
GrapheneOS' approach is to focus more on security than privacy, because they believe increased security leads to increased privacy. Unfortunately, that means their hardware requirements pretty much limit the hardware that you can run it on (currently only the Pixel phone range). Worse, it also means they stop supporting a device when it reaches End-Of-Life as software security updates stop for it (see How long can GrapheneOS support my device for? - https://grapheneos.org/faq#device-lifetime ). Sad though - GrapheneOS on Sony Open Devices ( https://developer.sony.com/open-source/aosp-on-xperia-open-d... ) would have been nice.
The whole reason why GrapheneOS is superior to its alternative is because they do all that.
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.
> The whole reason why GrapheneOS is superior to its alternative is because they do all that.
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...
> What is "its alternative"?
I meant alternativeS, sorry. Well, anything AOSP-based that is not Android.
> The manufacturers aren't blocking the installing of GrapheneOS...
Of course they are not. But they produce hardware that is not secure enough for GrapheneOS to consider. I wish they saw value in GrapheneOS and produced hardware that met their requirements.
It's actually weird, because I'm convinced that it's completely worth it: just add those requirements to the design of one new model, and a potential of hundreds of thousands of people may buy it just for GrapheneOS.
GOS has minimum hardware requirements and most of the available smartphones don't meet them
This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one. Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
> Also some people (me) value independence from Google more than the highest degree of security (which relies on Google hardware).
The requirements are indeed minimal. I have no problem with your valuing independence from Google, but please don't misrepresent GrapheneOS' requirements as the highest degree of security because not even they have said that. They have actually mentioned wanting to be more involved in the hardware/firmware side to implement more pro-user changes.
They are mostly basic requirements that Android OEMs should be embarrassed not to meet in 2026.
> This is a contradiction. There is nothing "minimal" about a requirement that excludes every device but one.
I don't get your logic. Requirements are a choice. It's very easy to create requirements that exclude every device but one.
Example: "It has to be the Samsung Galaxy S23". Done.
Now you can disagree with those requirements, but that's completely different from saying that the requirements are wrong.
I disagree that such requirements are minimal. Nothing prevents running GrapheneOS on a device with lower requirements. It's a questionable choice by the developers restricting the choice for users.
(I agree with you in spirit, namely that GrapheneOS' standards are clearly beyond what most vendors are willing or able to do and a compromise or support of users who want to port the OS might be fitting for the current situation, but notice that the person you replied to never said "minimal", they said "minimum". I'm not a native english speaker but I believe your reading is a value judgement along the lines of "not much work" (in this context) whereas they probably intended it like a statement of fact regarding what the requirements are.)
Aren't requirements defined as the set of minimal constraints that are needed for something to be deemed acceptable by those who define that set?
Again, requirements are not laws of physics. As the author of a project, I am free to make up my own requirements, and when something doesn't meet them, then I am free to reject it because it does not meet my requirements...
If you go to a bank and they refuse to lend you money because you don't meet their requirement, you will have a hard time convincing them that their requirement are wrong and that they should instead replace it with yours :-).
It is not the job of GrapheneOS to lower their standards and deplete their resources supporting every phone under the sun. We already have LineageOS for that. I would rather not be snarky but I don't understand why people keep blaming GrapheneOS instead of the OEMs. Almost every single time.
I don't think that there is anyone to blame.
GrapheneOS has requirements that result in only the Pixels being supported. LineageOS has other requirements that result in most phones being supported.
I may wish that more devices met the requirements of GrapheneOS, because I like GrapheneOS and their requirements, but I find it very weird to with GrapheneOS changed their core vision. What makes GrapheneOS is those requirements.
You are not independent from Google if you purchase an android device from another manufacturer. You're then having your data sent to both Google and that manufacturer, resulting in far worse privacy overall than with just Google, not to mention worse security at hardware level. If you don't want to "support" Google, just buy any used Pixel 6 to 10 series.
I use Librem 5 as a daily driver. It has no dependence on Google.
Sure, you're free to use whatever you want. So am I. I want GrapheneOS :-).
That's like saying Tulip blocked the installation of Vista because they didn't install enough RAM to run it
The OS makers don't have to go out of their way to support a device they don't want to (that's the beauty of open source passion projects), but it's also not like any manufacturer (that allows bootloader unlocking or ships an unlocked bootloader) is blocking GrapheneOS or anyone else from doing it, which the quote implies in my reading (maybe other people read it differently)
> That's like saying Tulip blocked
I agree, but you are the one who talked about "blocking". I did not :-).
You called it a problem coming from the manufacturers. That implies they actively thwart it (woa, another new word! It's crazy how language works). But they don't actually have a problem with it; some of them are actively publishing the info needed for alternative OSes to work on their hardware and GrapheneOS needs only take it if they want to, but they don't. Who has a problem with whom here?
Again, not saying GrapheneOS is doing something wrong. Nobody's under an obligation. Just that, if someone wants to argue that one party is making a problem out of the situation, I don't find it fair to assign that label to every manufacturer on the planet besides google
Would it work if I said "the ball is in the manufacturers' court"? Or would you complain that we're not talking about tennis?
Did you genuinely not understand my point, or are you just usually annoying and condescending with language?
> thwart it (woa, another new word! It's crazy how language works)
This is condescending.
I'm not sure I fully understand this.
Why are GrapheneOS releases dependant on Google releases?
They are dependent on the AOSP releases (which Google develops) and on the manufacturer updates (and because GrapheneOS runs on Pixels, then it goes back to Google again).
I can understand relying on an OEM to provide hardware support for a given model - but I'm finding it hard to understand why they're unable to continue supporting a release just because the upstream removes support for something.
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.
They rely on manufacturer support for device firmware, just like anyone else.
Debian surely doesn't depend on Lenovo or Asus to release OS updates for my laptop. Apparently it's not "everyone else" that needs this but it's some sort of dependency for mobile (qualcomm?) devices
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
Debian does not write the whole software stack running everywhere on your system. So if you want your system to be "supported", as in, "if a security flaw is discovered in a firmware, I want it patched and I want my firmware to be updated", then you need whoever writes that firmware to do 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.
Interesting, so any security patches to kernel level and above (AOSP code, browsers, other apps) can still be fully up-to-date when the manufacturer says a device is out of support. Not sure I understand the fuss then that Fairphone had about selecting a SoC with long support. Really thought it was some sort of problem updating the kernel or other AOSP components when using manufacturer blobs
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
> why they're unable to continue supporting a release just because the upstream removes support for something.
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.
Sounds a bit disingenuous then for an article to have a title that includes the phrase "break free from Google".
I think they mean breaking free from Google Analytics, Google Play Services, Google Play, Google Location Services, etc. Play Services and Play are not installed on GrapheneOS by default, so it is possible to run your phone with just GrapheneOS with your choice of open/closed source apps on top.
I think breaking away from open source Google code is not really meaningful. It's kinda like saying "I don't want to run Linux because it contains code from IBM/Google/Meta". AOSP is a great and useful project. If the day that Google stops releasing AOSP ever comes, a consortium of interested organizations can fork it. But it does not make a whole lot of sense to start a new mobile ecosystem completely from scratch, if one that is great and open source already exists and buys you compatibility with millions of apps.
It was first "break free from Android", but somebody complained so they changed it. Titles are hard, I guess :-).
One of the only big downsides I've noticed with GrapheneOS is that several banking apps don't work with it at all thanks to being tied to Google's verification ecosystem.
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.
I contacted my bank, insisting that GrapheneOS is one of the most secure OS on the market and therefore should be supported if they actually care about users' security (it's actually far more secure than all the old, far less secure but Google-approved devices out there). They acknowledged an fixed their app, one of the most popular in France.
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?!)
German bank Comdirect / Commerzbank did this as well, whitelisting GrapheneOS signing keys for their 2FA app. https://github.com/PrivSec-dev/banking-apps-compat-report/is...
> I wish banks would do something and support NFC payment systems that don't require the device to be controlled by Google
There are countries where it's possible to pay everywhere with the banking app scanning a QR code. No need for NFC :-).
The point of NFC-on-a-phone is that you don't need the damn banking apps and internet and retailer support for all that to validate a simple transaction. My credit card has NFC, no internet and no app, and it's universal.
> you don't need the damn banking apps
You need the Google/Apple app though, don't you? Or can you write your own personal app that will handle that?
There are several banks, especially over here in Europe, that have their own implementations of contactless payments, if that's what you mean. Here's a German article outlining this and mentioning a few examples: https://www.kuketz-blog.de/nfc-datenschutzfreundlich-bezahle...
I use qr based payments regularly where I live, and in my home country I use nfc payments (watch/phone/card) essentially always, when we visit.
NFC is by far more convenient and reliable.
I can't say about "convenient" because I don't use it, but I have been using QR codes for years and I haven't had a single issue. I don't know anyone who has.
QR codes are reliable.
You need an active internet connection to pay via QR.
NFC (EMV) works offline.
Got it, that's a good point! It's so much not an issue where I live that I hadn't realised :-). But it is an issue nonetheless.
It's regularly unreliable here, because it's reliant on a bank app which in turn is reliant on an internet connection, and banks here are kind of shit.
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.
> It's regularly unreliable here, because it's reliant on a bank app which in turn is reliant on an internet connection
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.
Did you miss the part where I said I use both?
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.
I'm confused. You say:
> 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!
> 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...
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.
Oh right, of course the phone has to send information back to the terminal, which NFC does but not the QR code. Hence the internet connection.
I’m interested which french bank is this?
Play Integrity and APIs like it aren't about security, they are about anti-fraud/anti-scam.
"Banking Applications Compatibility with GrapheneOS" https://privsec.dev/posts/android/banking-applications-compa...
Of course that is highly depdendet on the bank used, but so far none of my banking apps didn't work!
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.
What about the small matter of having to purchase a Google phone in the first place?
Most anti-google move: buy a second hand pixel, they receive no revenue on the device which is (assumed) already highly subsidized by google so that they can profit off users' data, then you use their subsidized hardware without running their spyware OS. Google only loses money in this scenario, it is a great protest.
Have you seen those prices? I don't think the devices need subsidising at all. How else could competitors, who aren't selling off your data, offer it for cheaper?
competitors also sell off your data, via uninstallable google spyware in most cases!
That depends on (1) which one you pick and (2) whether you keep the stock OS
Given that there exist vendors like Fairphone/Murena that sell lower-performant hardware at much lower price points, it seems to me that the expensive but decent hardware (like Google's flagship) might be priced appropriately as well
Other competitors (that do track you, like Samsung) have similar price points for their high-end hardware and are again much cheaper for slower hardware. If selling data is so essential, they wouldn't allow removing the tracking. (Samsung may be a bad example because they removed it last summer, but root popularity has been diminishing since early android days anyway so I can't imagine it's a big factor for them)
I see it as a necessity, because the Google phone is the only one worth it if you care about security.
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.
Google makes high quality hardware and untrustworthy software. Graphene's approach is to take the hardware and leave the software.
Besides the already mentioned point of getting one refurbished, Pixels tend to get really cheap towards the end of the yearly cycle. At that point, they were mostly going to make money from you using their ecosystem and then you are sticking it to them by installing GrapheneOS :p (probably they don't care).
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).
Yup, also Google Pay doesn't work, though there are other providers which work fine (Curve Pay I think works in all of EU), but it just made me carry my wallet everywhere and I understood I don't mind that at all.
Since all of comments are about NFC payments, this should be higher. Can confirm Curve Pay works (pixel 9a) at least with one Greek bank and Revilut. Not affiliated in any way with them and don't know this service is actually works just Yeah I'm amazed too.
I still have my Apple Watch configured, so I'm just doing the NFC payments with that :).
Author is installing Google Play Services it seems, wouldn't that work around this?
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.
No, because most banking apps call upon the Google Play Integrity API, which GrapheneOS doesn't (or can't?) use. There's a decent list kicking around of which ones work (Monzo, for instance).
https://privsec.dev/posts/android/banking-applications-compa...
It's more common in banking apps than in other apps to implement Play Integrity but it's cetainly not "most banks" that do it. It's still only a small subset. Sucks of course if it's your bank.
Maybe not in your region, but here in the UK I think the majority of high street banks do not function on GrapheneOS.
> this also sort of defeats the purpose
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".
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
Does anyone know if HSBC's UK app works on it? I've seen inconsistent reports that it does and doesn't.
Edit: ignore this - there's a list elsewhere in this thread!
yep - tried GrapheneOS for the first time today and my banking app detected that the phone was jailbroken.
Did you relock the bootloader and disable OEM unlocking as part of the GrapheneOS onboarding?
While I admire GrapheneOS and its goals, I feel that until we free the proprietary baseband processors and their RTOS from the grips of Qualcomm and friends it's a pyrrhic victory, at best.
When there isn't a perfect solution, the next best thing is... the next best thing :-).
Unless the next best thing makes you think you are already achieving the "perfect solution" for what you think you care about, but in truth does not.
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...
> a zero-day in the closed source firmware from Qualcomm will probably screw you anyway.
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.
Thanks for the clarification (and to the others that answered as well).
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.
fyi a Cell Site Simulator can masquerade as the legitimate telco operator and push type 0 messages to the handset.
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.
> The baseband can do a lot, it has dma
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.
Thanks, this is very good information!
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 don’t have the source (I’ll have to try find it), but I read that the cell site simulators can work on 4G and earlier but don’t work on 5G. So one thing folks can do is set ur phone to use 5G networks only (unless ur stuck and then u can make it looser but be aware your less protected at that time).
I do this on iOS I’m sure it’s do-able on GrapheneOS and hopefully on Android too.
5G CSS is harder yes, but keep in mind that most 5G is the 5G_NSA variety, and is really just riding on the same cell bands, no mmwave here. You probably notice that your phone often slips out of 5g, or you inhabit different modes here.
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.
So no, their target is people who marginally care about privacy and security but don't want to use iOS. I don't think they target any particular demographic but I see security engineers and activists among users.
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 think the appeal and use case for Graphene and similar OS for most users is the Google/privacy/ownership type argument.
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.
> until we free the proprietary baseband processors and their RTOS
How about Pinephone with its partially freed baseband OS [0] or Librem 5 with its removable modem [1]?
[0] https://github.com/the-modem-distro/pinephone_modem_sdk
[1] https://en.wikipedia.org/wiki/Librem_5
iirc Graphene is in talks with an unnamed HW vendor to make a grapheneos specific phone. They refer to the vendor as someone who makes phones and you've likely heard of, but haven't given any more info otherwise.
Yeah spot on. I think this is the only thing that's been announced so far: https://www.androidauthority.com/graphene-os-major-android-o...
Don't allow perfect to be the enemy of good.
To make things worse it needs a google phone, of all things.
That and blocking the query all apps feature on android
Do you also need the WiFi chip to be fully free?
We need Linux OSes and phones to catch up to really break free from this duopoly. Only when there is enough traction, essential infrastructure like banks will start supporting Oses like that. It's a chicken and egg kind of problem.
Android is a Linux OS and is eons ahead anything that would sit on top of "GNU/Linux" userspace.
Why start from scratch?
I think that the main problem is that android has a lot of weird modifications that are not consistent with the rest of linux distros. The user data is suddenly in /data instead of /home, theres no package manager, no systemd (for better or worse), and there's hella lotta security gotchas, for example call recording is impossible without root as far as I know. I'm not saying that Android is not hackable, but it's a different type of hackability than desktop linux, you have to learn it all over again and in my opinion it's much harder to master than desktop linux.
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 :)
[1] https://forums.ubports.com/post/75157
If your criterium for choosing an OS is tinkering and hackability freedom to do modify almost anything to your liking (even if it will compeltely break your system or poke extra security holes in), then desktop Linux OSes ported to mobile might indeed be a good option.
If your goal is security and privacy (which go hand in hand), mobile OSes are clearly the best solution.
Anyway Android is still a Linux OS. The only requirement to be a Linux OS technically is to ship a Linux kernel. Adhering to freedesktop specifications like the FHS, using systemd, using GNU userspace software, etc. isn't necessary.
On Android you can install software by installing directly from APK files or you can use application stores which are package manager, they help you install software and if there are dependencies they can also install the dependencies if they support that.
Call recording is possible on multiple Android OSes, it's possible on stock PixelOS and GrapheneOS, I'm not sure about others but normally it's just part of the Dialer app. You don't need root at all for that.
Yeah, just need to decide where to start the fork. The larger problem is radio firmware. FCC regs were the initial excuse, for wifi and Bluetooth too, but we need to open up the source for all of these and allocate money for enforcement if we are truly worried people are going to start adding wifi channels etc. Open firmware phone radios would let you do things like truly turning off the radio when wifi was present, no gps ping even.
The good news being that the work made by Linux on Mobile projects regarding the radio firmware benefits AOSP projects, and inversely, right?
While I respect the Linux on Mobile work, I believe that AOSP is a lot better, with a much better security model.
Remember that GrapheneOS is not Android: it's an AOSP-based OS.
You’re not wrong. The thing that bothers me is that AOSP is being developed behind close doors and controlled by a single company which wields way too much power and control over our daily lives, and which has a track record of abusing that power.
Agreed. Though my hope is that AOSP could be forked. Without the contributions from Google, it would surely move slower, but... well it may work.
I actually had hopes that Huawei would start that with HarmonyOS.
They for sure control the direction of the development but it's not really that problematic given that things downstream projects take issue with can just be removed from the source and things they want can be added.
what happened to Sailfish? the successor of meego et-al
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 portions of SailfishOS specific to it including the user interface and application layer are nearly entirely closed source, unlike the open source Android Open Source Project (AOSP). SailfishOS has far worse privacy, security, functionality and usability than the Android Open Source Project. It isn't possible to make a fork improving it due to it not being open source like AOSP.
You can run desktop apps on GrapheneOS including on a desktop monitor via the desktop mode with free form windows. There's support for non-native apps via hardware-based virtualization. These features are experimental but already work pretty well.
There's a new Jolla Phone in pre-marketing phase right now (almost 9000 phones have been pre-ordered so far). First device deliveries are scheduled for this summer and this should easily be the new benchmark for officially supported SailfishOS devices.
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.
See https://news.ycombinator.com/item?id=47053198.
They have been underfunded for a decade now, with some unfortunate consequences - the web browser is based on Gecko 91.
See https://news.ycombinator.com/item?id=47053198.
Jolla mishandled the funds they got for the tablets, it went bankrupt and bought up by a company connected to the Russian state. Jolla lied a lot during these events and tried to hide what happened, and I don't think that's an acceptable thing to do when the main selling point of your product is privacy and trust. AFAIK they recently got bankrupted again and bought by the original owners, but it's hard to rebuild trust.
See https://news.ycombinator.com/item?id=47053198.
> For me, it works like this: on the Owner user, because that’s the name of the main account created automatically with the system, I installed the Google Play Store along with Google Play services and GmsCompatConfig
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.
I've found using separate accounts for Non-Play (default) and Play (exception/escape hatch) to be a very happy medium.
Does anyone have a good grasp of the differences between GOS and /e/OS? I'm buying a Fairphone soon and was wondering what both are like
GrapheneOS claims to be a lot more secure, having additional hardening. See https://eylenburg.github.io/android_comparison.htm - keep in mind that it is not an independent comparison, the Graphene guys directly feed what this table is supposed to say in the issue tracker, https://github.com/eylenburg/eylenburg.github.io/issues/. But it gives a good representation of the state of the ROMs according to Graphene.
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.
> I'd never use GrapheneOS since I don't trust the project
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.
I have never seen drama from /e/ or any other project GrapheneOS attacks, like Calyx. Please link me to it - I asked this several times, people never can follow up. So far?
> Please link me to it - I asked this several times, people never can follow up. So far?
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?
Sorry, but then I take this as the usual - GOS is attacking other projects, that I can easily see in all their socials, and the other projects have done nothing wrong. GOS always claims that the other projects attack them since years, and never shows any proof. And indeed, I still never have seen any attack against GOS. Seems like this won't change today.
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.
> Sorry, but then I take this as the usual
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.
I still haven't seen what you describe, the behaviour of other projects. And I dont believe it without proof (since it was claimed so often by GOS without proof being shown, or in some cases with it obviously not existing).
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.
> It is wrong to claim that an unlocked bootloader completely breaks the android security model.
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?
Take what I say with a grain of salt. There are many people that know more than me. But I'll try to answer to the best of my knowledge.
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.
> 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?
They're misrepresenting what has been said by GrapheneOS and also lack a good understanding of it themselves. They're definitely not a good source of information about this.
Could you provide some insights there? That would be appreciated.
1. Is it correct that the secure boot protects again a malicious app escaping the sandbox and persisting into the system?
2. Is it correct that if the system is signed with the Google testing keys, then someone could sign an app with those keys and the app would get more permissions than it should (I believe it's called the "signature" permissions)?
https://mastodon.social/@gael/115067300718940033 https://nitter.net/GrapheneOS/status/1996683131358007487#m
here you go
The nitter thread shows the exact behaviour the article is complaining about, proving it right (at least the toned-down version). Highlighting the abusive behaviour of one person in the GOS project that actually does happen isn't an attack against GOS, and certainly not wrong.
It's exactly the problem: You have one bully here that claims everything criticizing his abhorent behaviour is a libelous attack, thus he attacks other people and projects that attack him, spinning substantiated criticism against him as "projects driving a campaign against GOS". And the Graphene followers believe him. It's absurd.
The founder of /e/OS regularly comments on posts about GrapheneOS on social media, almost always unsubstantive and of a low level.
> GrapheneOS claims to be a lot more secure
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.
/claims/
> GrapheneOS claims to be a lot more secure, having additional hardening.
GrapheneOS has been heavily analyzed by privacy and security experts who say it provides far better privacy and security. There's a large amount of real world evidence showing GrapheneOS very successfully defends against commercial exploits tools. /e/ has been heavily criticized for having poor privacy and atrocious security by many experts. /e/ doesn't keep up with basic privacy/security patches and misses many important standard protections.
> keep in mind that it is not an independent comparison
That's not true. It's an independent comparison and the site compares a lot of other software. Contributors to many of the projects compared by it submit issues to it which doesn't many it not an independent comparison.
> In regular use, main difference will be that /e/OS comes with access to the alternative cloud service that project provides.
GrapheneOS users have many cloud services available including suites from Proton and others. Murena services have poor privacy and security overall due to neglecting server security, updates and more. Their speech-to-text service being a thin wrapper around OpenAI sending this sensitive user data to them rather than doing it locally as our SpeechServices app does similarly to Apple (even Google has that as an option):
https://community.e.foundation/t/voice-to-text-feature-using...
> It uses the default FOSS solution microG for google api compatibility
Their approach with microG gives highly privileged access to Google apps/services by default. GrapheneOS doesn't include sandboxed Google Play by default and they're installed as regular apps. microG doesn't change the fact that the apps are using closed source Google libraries, which are still present with microG and have strictly more access to user data on /e/ than GrapheneOS with sandboxed Google Play. Sandboxed Google Play is an entirely opt-in feature people need to install. /e/ has microG set up where it downloads closed source Google Play components it runs with privileged access as the default.
> /e/OS sets on AppLounge to install and upgrade both play store or F-Droid apps
This is a strange merger of Aurora Store, F-Droid and more. It's very misleading and confusing for users.
> /e/OS is also not my favorite since it feels like it is developing slowly, having had issues with outdated software versions - though it does work well in practice. Have a look at iode for an alternative.
Neither /e/ or iodéOS keeps up with updates to Android, Chromium, firmware, drivers or the Linux kernel. Both mislead users with an inaccurate Android security patch level. iodéOS lags far less behind /e/ and doesn't have nearly as many privacy violating services and added privacy/security flaws but neither is a privacy or security hardened OS. Neither keeps the privacy or security of standard AOSP intact.
[dead]
[dead]
I have been using /e/OS for 5 years, and also GOS. My take is:
- 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.
> I had a Fairphone 3, and after 5 years, /e/OS was outdated by 4 years w.r.t. the manufacturer updates
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.
> Mine is running /e/ and reporting Android 13, which appears to be the last one Fairphone 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.
> It's had continual security updates apart from the Android version.
Nope, it doesn't receive most privacy and security patches. Users are being heavily misled about what's provided. First of all, the kernel is nearly entirely not being updated which is a massive portion of the privacy and security patches. Murena's devices have poor privacy and atrocious security including due to the failure to properly provide basic privacy/security patches. Their claims about what they provide need to be distinguished from what is actually provided. /e/ updates the patch level regularly to claim they provide the security patch backports but that doesn't mean they actually provided all of them. It's an arbitrary value and they don't set it accurately.
Fairphone 3 uses the end-of-life Linux 4.9 branch, Fairphone 4 use the end-of-life Linux 4.19 branch and Fairphone 5 uses the end-of-life 5.4 branch. Each was largely not receiving the upstream LTS updates while they were still provided but now they're not provided. An OS that's not receiving basic kernel updates is definitely not receiving security patches anymore, but they were largely never providing these updates in the first place long before the kernel branch or devices were considered end-of-life.
Similar to iOS and other operating systems, Android only backports a subset of privacy and security patches to older Android branches. Only Android 16 QPR2 has the full set of Android privacy and security patches. You aren't receiving all of the standard Android privacy and security patches if you're not on Android 16 QPR2. Many of the patches are also treated as optional and deferred as being mandatory far into the future. It's also worth noting the dates are misleading. Android's March 2026 security backported have been finalized for a while and up to August 2026 are available to ship by OEMs already but a lot more will be added to June 2026. February 2026 Android security patches are the latest with a public bulletin but not the latest available to ship.
Fairphone and especially /e/ also have very incomplete patches for firmware and drivers. /e/ also has major issues patching other components including the browser engine used by the OS for the WebView.
> If your phone is not supported by GOS, you should look carefully and compare between /e/OS and Stock Android.
If you have an iPhone that's still supported, you have strong privacy and security. If you have a phone that's not an iPhone and not supported by GrapheneOS then you likely have a phone with atrocious privacy and security regardless of OS choice. If people can afford to get a secure device with years of proper support remaining then they should do that rather than using an insecure device with a sidegrade for privacy and security using a problematic AOSP fork. LineageOS is far less problematic than /e/. If people want to switch the OS to something else due to the OEM abandoning it or to avoid Google Mobile Services they should use at least use LineageOS which is less of a privacy and security downgrade from OS. LineageOS does not fully maintain the privacy and security of AOSP or fully keep up with updates but it's a lot less bad than /e/. Most alternate OSes are forks of LineageOS to reuse their work on hardware support and nearly entirely make privacy and security worse, not better, so why not use the upstream project instead?
> I had a Fairphone 3, and after 5 years, /e/OS was outdated by 4 years w.r.t. the manufacturer updates. In other words, Stock Android coming from Fairphone was more secure than /e/OS on that Fairphone.
It's important to note that an alternate OS depends on the OEM for firmware and in practice much more than that including kernel and driver updates. It's theoretically possible to replace the kernel and drivers with much different ones but it's not done in practice by alternate AOSP-based operating systems. If the device is abandoned by the OEM then you aren't going to have a secure device.
/e/ lags far behind on standard privacy and security updates everywhere but misleads users with an inaccurate Android security patch level along with many inaccurate privacy and security claims. LineageOS is much better than the fork of it by /e/ and does much less to mislead users, although it still has the inaccurate Android security patch level and many people still wrongly believe they're getting patches they aren't after the OEM dropped support.
In what ways does LineageOS trail behind AOSP in terms of security? I looked at the comparison chart you linked elsewhere and the privacy/security sections only seem to list advantages over OEM Android (not AOSP), with the exception of secure boot [1], but AOSP (not OEM Android) doesn't have that out-of-the-box either. Unless you are comparing Lineage with OEM Android?
[1] https://eylenburg.github.io/android_comparison.htm
> many people still wrongly believe they're getting patches they aren't after the OEM dropped support.
I can confirm that I did, and was not very happy when I realised it.
The main difference is that GrapheneOS prioritizes security hardening first and foremost (above usability or compatibility). /e/OS focuses on privacy (i.e. reducing data leakage to adtech) and usability over security.
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.
> /e/OS focuses on privacy (i.e. reducing data leakage to adtech)
/e/OS literally sends STT data straight to OpenAI...
/e/OS uses priviliged MicroG, which connects to Google for some of its functionality
/e/OS doesn't keep up with updates properly, making its security suffer, making yoru phone easier to compromise, increasing the likelihood of amongs other things sandbox escabes which open up possibilities to data leakage.
> GrapheneOS recommends running all the proprietary Google apps in a locked "sandbox"
They don't recommend this. The user can choose to do so.
> but obviously Google still gets to see everything you do in their apps
Indeed, obviously. So, obviously, also the case on any other OS.
> 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.
You can install apps you need on GrapheneOS providing those alternatives yourself. Android has a large FOSS app eecosystem.
Much of the things /e/OS bundles for services are just using Nextcloud and their services have been very unreliable in the past, making people unable to access their data for months. Also, Nextcloud isn't end to end encrypted.
GrapheneOS also makes their own apps, like Vanadium, PDF viewer and Secure Camera.
> but obviously Google still gets to see everything you do in their apps
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.
[dead]
> security hardening first and foremost (above usability or compatibility).
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.
I assume this is all technically correct, but in practice I've not noticed any speed difference between stock Pixel and GrapheneOS. Maybe their Vanadium browser when tab switching, that feels slow, but I wasn't planning on being part of the Chromium monoculture anyway so this doesn't matter to me
That's great and, of course, only your experience matters to the choice of which OS you use. I just don't want people to get the impression there are no tradeoffs.
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.
It doesn't make it more possible to irreversibly brick your phone. Even if you set it to the most strict setting the port still works when you are in the bootloader and recovery modes. See https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...
Also, it isn't the only materials difference in that threat model. To just give on example, the autoreboot feature is also useful for that.
Not sure if I'm understanding you right, but I wasn't saying that my experience is the only one that matters. Just that it's not a thing one notices in practice, at least not under conditions I've experienced (I figure a reader can fill in that last bit for a comment written in the first person). Saying AOSP's is "much, much faster" suggests it would be noticeable and afaik it's not (at human timescales), so I wanted to add that info to the thread
Good point about the USB thing btw. It's obvious to me and the reason why I go one step further and leave USB debugging always enabled now that there's this private key authorisation method anyway (it asks for computers whose key it doesn't yet trust), but indeed a lot of users might follow GrapheneOS' advice without realising
Leaving USB dubbing enabled just exposes a lot of attack surface. And if you use USB debugging you are placing a lot of trust in the computer you are connecting to. You don't need USB debugging to reflash GrapheneOS or to sideload updates from the recovery mode. So, it's not relevant to prevent a device brick.
I just want to note that I believe the default setting is that data is disabled for the USB port when the phone is locked except after a reboot (before unlocking the phone for the first time), so if you break your screen you have the option to use the keyboard if you reboot the phone.
GOS creates a complete bunker of a phone that can provide defense against pretty much all but the most dedicated state level actors. If you're worried that someone would steal your phone specifically to target you, Graphene will protect against that. Securitywise it's hard to argue against them, although GOS tends to sacrifice usability in favor of security, which leads to odd decisions. Their device depreciation timeline is also pretty aggressive and really just matches that of the Pixel. (You're also buying the Google phone... to not want Google in your life; this bizarre paradox will always be strange). It's not exactly a recommendation for long-term support. Worth noting however is that usage of GOS is also seen as a signal in and of itself for the authorities that you may have something unsavory to hide, so using it stands out in that regard; some law enforcement officers (I think it was in Spain?) have said that the OS is popular with organized crime. GOS obviously denies the connection and they're probably honest in that the OS isn't deliberately designed for criminals, but it's worth noting at the very least. (Basically GOS is the paradox where someone trying their hardest to be anonymous ends up standing out way too much from the crowd and drawing attention to themselves.)
/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.
I have been a user of /e/OS for 5 years, and also of GOS and would like to share my opinion on this:
> 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.
I'm also not involved with any mobile privacy/security project, unless OpenStreetMap data and self-hosting can be said to be such
> 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)
>Not everyone is running from an intelligence agency or cellebrite border checkpoints
OK, but would it be such a bad thing if most people's personal devices were pretty damn resilient to mercenary spyware by default? I really don't think the standards GrapheneOS are aspiring to are the problem with this picture.
Certainly not, but there's more goals than singular security from government agents at all cost
With the current mobile OS landscape, getting away from ubiquitous overseas dependencies, constant tracking, and closed-source mandatory apps is, to me, much more direct-impact than protecting against this extremely remote chance of having an exploit, customised to my software stack, finding its way onto my device somehow. I'd much rather have the freedom to do with my hardware what I wish
Some people will prefer one thing, and other people another. Neither is a bad choice if it fits your goals and you know the risks of each one. So what I'm saying (and seem to be repeating over and over and over in any graphene fanboy thread) is that it's a choice, not a one-size-fits-all, and not a foregone conclusion (as GOS authors pretend it is, which this subthread started with)
/e/OS/ was bad with updates for a long time (I had to switch 2022). IodéOS is very good at it, in my experience (I have used all three)
> /e/OS/ was bad with updates for a long time (I had to switch 2022).
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.
iodéOS lags far behind on Android, Linux kernel, browser engine and other updates too. It's much less behind than /e/ and misleads users less but they still do. They set an inaccurate Android security patch level which misleads users just as /e/ does.
I didn't know. Do you have a link to one specific announcement where they mislead people about the patch level? It would help to start a conversation to change that.
I guess on /e/OS you can just run Google Maps in a browser if you really want Google Maps features (like searching for a restaurant). Organicmaps works fine if you just need to get from A to B. It does lack live traffic, but you'll have to live with fewer features if you really want to not use Google for most stuff.
> Organicmaps
I would suggest having a look at CoMaps, a recent fork of OrganicMaps :-).
The founder and CEO of /e/ and Murena openly spreads content from Kiwi Farms and neo-nazi sites. He directly engages in harassment towards the GrapheneOS team. Here's him supporting authoritarians smearing GrapheneOS by replying to threads about it linking to harassment content based on fabrications on a neo-nazi conspiracy site:
https://archive.is/SWXPJ https://archive.is/n4yTO
The communities of several projects including /e/ have heavily engaged in spreading misinformation about GrapheneOS including fabricated stories about our team. They've even taken it to the point of repeated swatting attacks aimed at killing our team members. There are relentless raids on the GrapheneOS community platforms including our chat rooms where Child Sex Abuse Material, gore and endless harassment towards our team members including fabricated stories and harassment content from Kiwi Farms and elsewhere is posted.
Extraordinary claims require extraordinary evidence.
I find it very hard to reconcile claims like "repeated swatting attacks aimed at killing our team members...Child Sex Abuse Material..." with the proof offered being a blog post that makes the fairly anodyne (especially read in light of this comment) case that you are an extremely paranoid person whose paranoia leads you to extreme judgements that may harm users. If you are the target of extreme attacks, it seems far more plausible to me that those originate from state actors and security adversaries, rather than from erstwhile allies also trying to build better mobile OSes.
Rather than reading this as "harassment", I would suggest you should try to take it as constructive feedback: You do not play well with others and your prickly interpersonal demeanor hampers the adoption of what is (by all accounts) technically strong software.
> Extraordinary claims require extraordinary evidence.
It's your claims which are extraordinarily and have been thoroughly debunked. You're directly engaging in bullying with baseless personal attacks. You make false accusations about us while you're actively engaging in those things.
> I find it very hard to reconcile claims like "repeated swatting attacks aimed at killing our team members...Child Sex Abuse Material..." with the proof offered being a blog post that makes the fairly anodyne (especially read in light of this comment) case that you are an extremely paranoid person whose paranoia leads you to extreme judgements that may harm users. If you are the target of extreme attacks, it seems far more plausible to me that those originate from state actors and security adversaries, rather than from erstwhile allies also trying to build better mobile OSes.
It's very easy to see that the site which was linked is a neo-nazi conspiracy site. Gaël Duval knew that when linking to it. Gaël Duval has repeatedly spread harassment and libel content from Kiwi Farms and elsewhere. He has linked to the same harassment content linked in the post. Both of those videos are from Kiwi Farmers and one of them participates on the site with an account in their real name which received identity verification. They openly use the site as their personal army and were the one to involve them.
Duval very clearly knows that he's directing his community to target our team with harassment by spreading fabricated stories about us. Anyone can take a look around the site which was linked and see a whole lot of the paranoia and delusion you falsely attribute to me with no basis. Duval is opportunistically spreading harassment content to benefit his for-profit business for the same reason he has heavily invested in spreading misinformation about GrapheneOS.
Duval is not an ally. He's a grifter selling phony privacy products with dramatically worse privacy and security than an iPhone. They're scamming people with false marketing for their products. The supposedly private speech-to-text service from Murena actually just sends user data to an OpenAI service vs. iOS and GrapheneOS doing it locally which is very representative of their overall approach to the apps, services and OS.
https://community.e.foundation/t/voice-to-text-feature-using...
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
GrapheneOS is the only open source privacy and security hardened mobile OS based on AOSP in practice. Products using privacywashing for marketing aren't in the same space. They're not allies but rather the misinformation they propagate and the attacks they make on our team are extremely harmful to us. They're the main adversaries. Companies like Microsoft tend to be very friendly to us and open to collaboration vs. these small companies building a business around false marketing who feel very threatened by us so they engage in spreading misinformation and personal attacks on us. Claiming that it's state sponsored is ridiculous. It has been ongoing since long before GrapheneOS had significant adoption and has always been primarily caused by companies who feel threatened by GrapheneOS trying to harm it. Multiple companies have engaged in it because it's very convenient for them to hop onto the existing bandwagon of fabrications/harassment started in 2018. The privacy and security industries are filled with charlatans and scams. We have good relationships with a bunch of legitimate privacy and security projects including QubesOS, secureblue, Molly, Accrescent and MANY others. It's these companies selling supposedly private/secure phones which are in reality not very private and extraordinarily insecure where nearly all the attacks originate from.
> Rather than reading this as "harassment", I would suggest you should try to take it as constructive feedback: You do not play well with others and your prickly interpersonal demeanor hampers the adoption of what is (by all accounts) technically strong software.
It's libelous harassment content based on fabricated stories. You're claiming it's not happening while directly engaging in it. You're making the ridiculous claim that it's from state actors while the actual perpetrators are plainly visible and include yourself. It's the community around /e/ and several other projects which are extraordinarily toxic and engaging in harassment. Our community and project doesn't do it. You folks cross-reference your libel, bullying and harassment content entirely based on making up stories, personal insults, etc. while claiming a bunch of fabrications referencing each other is evidence. Calling me paranoid, delusional, etc. with no basis is nothing more than sociopathic bullying. Hacker News moderators shouldn't be allowing it.
Please print out this comment and the one that preceded it and show it to a friend you trust to be honest. You should seek therapy, and it will make you a more effective technical leader.
I'm surprised Graphene foundation haven't banned or heavily restricted Daniel Micay from publicly representing GOS. He's fine when he's providing product updates and technical information but he absolutely needs to see a therapist. I know he's been told this a million times and I'm not sure if he takes it serious enough. If he doesn't do something about this behaviour, his spiraling will be the downfall of GOS.
> /e/OS (and similar "non-LineageOS" ROMs really)
LineageOS is degoogled unless you install google apps as a deliberate choice, so I don't really see any advantage or /e/OS or Murena over it.
It's a misconception that GrapheneOS is focused on security over everything else. It's a privacy project and privacy depends on security so it heavily focuses on both. It also provides major privacy improvements on a technical level rather than only avoiding privacy invasive apps and services. Privacy involves a lot more than which apps and services are bundled with the OS, contrary to how most supposedly private phone options are marketed.
> Securitywise it's hard to argue against them, although GOS tends to sacrifice usability in favor of security, which leads to odd decisions.
GrapheneOS doesn't make any major usability sacrifices for security. Privacy or security features with usability compromises are either opt-in or opt-out.
> Worth noting however is that usage of GOS is also seen as a signal in and of itself for the authorities that you may have something unsavory to hide
GrapheneOS is far more widely used than most alternate mobile operating systems and there's a lack of basis to claim that it's widely seen in the way you're describing in a way that other operating systems are not. In fact, they're largely conflating other operating systems with GrapheneOS because it's the most widely talked about and known about. They're calling devices GrapheneOS devices which aren't running it. In many cases it's not even a fork of it.
> have said that the OS is popular with organized crime
This is completely unsubstantiated and not evidence has ever been provided. On the other hand, it's known that law enforcement in Europe has widely sold devices to organized crime which they marketed by claiming they were based on GrapheneOS:
https://darknetdiaries.com/episode/146/
Using portions of our code doesn't make something GrapheneOS and marketing is also a different thing than reality. Most of what's claimed to be GrapheneOS in this context is not GrapheneOS but rather trademark infringement by forks or even non-forks.
> /e/OS (and similar "non-LineageOS" ROMs really) instead focus more on de-Googling.
Nope, /e/ always connects to multiple Google services regardless of configuration and gives highly privileged access to them. GrapheneOS doesn't connect to Google servers by default and avoids giving privileged access to installed Google apps via our sandboxed Google Play compatibility layer.
> They're still generally security focused.
No, that's definitely not the case. /e/ has absolutely atrocious security and fails to provide even basic security patches and protections. This is also part of why it provides poor privacy due to lagging far behind on privacy patches in addition to security patches along with being missing important standard Android privacy and security protections due to being far behind and not having it all set up. /e/ doesn't provide comparable privacy features to GrapheneOS Storage Scopes, Contact Scopes, Sensors toggle and far more not only the security features. /e/ isn't just not a security hardened OS, it's also not a privacy hardened OS. LineageOS has better privacy and security than /e/. AOSP has better privacy and security than LineageOS.
> Because of this, they usually have better depreciation timelines
/e/ doesn't provide proper updates for any devices. Many of the devices they support aren't getting driver and firmware updates from them even when they're available. They lag far behind on kernel, Android, Chromium (including WebView) and other updates too. They support many devices without kernel, driver and firmware updates available but they're usually way behind even when they are. /e/ simply doesn't care about providing basic privacy and security so they continue having people buy and use highly non-private and insecure devices lacking basic patches.
> Finally, it's worth noting that the GOS community is absurdly toxic to anyone doing anything privacy-related that isn't under the banner of GOS. It's extremely maximalist, tends to get very upset at other projects whenever they get attention (see sibling reply to this, where they pretty much melted down because an outlet dared to recommend a Fair phone+/e/OS) and the projects official channels have generally encouraged this sort of behavior. It doesn't really damage the software itself, but it's worth considering.
No, completely backwards. The massive amount of false marketing, misinformation and harassment engaged in by the /e/ project and community is what's toxic. The founder and CEO of /e/ and Murena openly spreads content from Kiwi Farms and neo-nazi sites. He directly engages in harassment towards the GrapheneOS team. Here's him supporting authoritarians smearing GrapheneOS by replying to threads about it linking to harassment content based on fabrications on a neo-nazi conspiracy site:
https://archive.is/SWXPJ https://archive.is/n4yTO
The communities of several projects including /e/ have heavily engaged in spreading misinformation about GrapheneOS including fabricated stories about our team. They've even taken it to the point of repeated swatting attacks aimed at killing our team members. There are relentless raids on the GrapheneOS community platforms including our chat rooms where Child Sex Abuse Material, gore and endless harassment towards our team members including fabricated stories and harassment content from Kiwi Farms and elsewhere is posted.
People should review https://eylenburg.github.io/android_comparison.htm which is a third party maintained comparison between AOSP-based operating systems which addresses many of the misconceptions you have about how GrapheneOS compares to AOSP, /e/ and other operating systems. You're not at all correct about what's provided by /e/ which fails to keep up with basic updates or provide the standard protections.
We can provide large amounts of further examples of the founder and CEO of /e/ and Murena participating in this harassment.
The attacks towards us including your libelous claims about us here are what's absurdly toxic.
> It's extremely maximalist
It isn't but rather is very pragmatic and focused on usability, robustness and compatibility alongside the major focus on privacy. The focus on security is to protect privacy because it depends on it.
Given I don't disagree with you about GOS being the best on security, I think there's only one thing really worth mentioning:
> The attacks towards us including your libelous claims about us here are what's absurdly toxic.
I want to make this clear upfront: I have no connection to /e/, Calyx, DivestOS or whatever other projects you've had issues with over the years. If you've had trouble with them I find that very unfortunate for you, but they are entirely unrelated to this conclusion. I do not consider these claims to be libelous when they're fairly easy to check:
The reason I consider GOS' community to be extremely toxic and find official channels enabling this is for a few very simple reasons:
1. I've seen several incidents of GOS users coming into adjacent Android communities to start beef with those communities while giving off the attitude of zealots. For a concrete example, the F-Droid forums have a thread about Googles impending changes to letting users install their own software ( https://web.archive.org/web/20250903081432/https://forum.f-d... ). The original OP for this thread has a pointless attack on the F-Droid project, declaring GOS to be superior. Moderators eventually changed this to be more mild (but it's why the first replies are snarking on low-hanging fruit about GOS), but I've seen similar behavior in other places - there's a reason that a lot of Android communities generally respond with trepidation and annoyance whenever the project is brought up and it's because of this behavior from the userbase.
2. I can read the GrapheneOS forums; they're public. Nearly every issue I've seen people have with GOS on the forums is effectively met by a "you're holding it wrong". This sets a tone for the community that makes it come across as extremely hostile to potentially interested users.
3. In the same sense, it's trivial to notice that the official GrapheneOS account on this forum is a frequent participant in these discussions, generally backing up the hostility on the virtue of technical accuracy. This to me suggests endorsement of this attitude. (See a sibling to my initial comment where the official account makes a post on the GOS forums about an unrelated blog for daring to recommend a different ROM/phone combo. This to me is not indicative of healthy communications, but rather of an obsession to promote GrapheneOS at every corner.)
4. I remember, as a Bromite user, the futzing with the Vanadium license in order to prevent other Android Chromium forks from making use of it's patches for the crime of... considering a contribution from someone the GOS project has beef with. That to me is the most telling thing really. The goal with that license futzing was never to actually help advance privacy/security or anything like that. It was to try and force a different project to conform to GrapheneOS' demands over something extremely minor and GOS went ballistic and threatened license changes (which they eventually did) the moment the maintainer asked for a bit more information because "GOS doesn't like this person" isn't enough to immediately warrant kicking someone off a project. Cromite (the fork of Bromite, as Bromite's maintainer went AWOL) still doesn't include Vanadiums hardening patches because of this. It's fucking absurd.
4 is the big one for me. It is absolutely unacceptable, unbecoming and to put it plainly: toxic behavior from an official voice in the project. It's fucking rich and borderline hypocritical to talk about GOS' consistent upstreaming of Android hardening patches while making it impossible through a license change for other projects to share it's contributions.
(Here's a source for that btw; https://github.com/bromite/bromite/issues/2141 and https://github.com/bromite/bromite/pull/2102 for the original incident. csagan5 essentially got jumped with extreme hostility for something they couldn't have been aware of and was very reasonable about, and all they got in response was more threats and hostility.)
[dead]
Consider this (by Graphene OS): https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
/e/OS community talking about it: https://community.e.foundation/t/article-from-grapheneos-abo...
And then maybe this: https://eylenburg.github.io/android_comparison.htm
Hope that helps.
I like GrapheneOS but they fail to understand in this post that the #1 security concern an android user face is the lack of privacy.
Sure they have hardened everything but realistically, that's not the main threat for your average user.
Their top contribution to android is the sandboxed Google Play, by far.
I think it's more of a marketing claim from less secure systems that "privacy is not security, and GrapheneOS focuses on security while we focus on privacy".
GrapheneOS does care about both, quite obviously. And GrapheneOS tends to say that if your security is bad, then it is affecting your privacy too. Whereas others say "sure, we break the Android security model by unlocking the bootloader and signing our system with the Google test keys, but your apps will contact Google through microG instead of the Play Services, so it's more private". Which is worth what it is worth...
> I think it's more of a marketing claim from less secure systems that "privacy is not security
I'm not sure Cyanogenmod had a marketing team that convinced me of anything when I first installed their rom in 2013 and explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS, you can only use the Android APIs, same as on stock
Am I brainwashed by marketing?!
I am not sure what you are trying to say.
My point is that
1. If you care about privacy, you should care about security. If your email server is compromised and your emails leak in the public internet, then they are not private anymore.
2. GrapheneOS does care about both security and privacy.
> explored my phone's capabilities with root. Accessing the sensor devices, inspecting what the different apps do, what the OS is doing, installing Xprivacy to provide fake data to tracking apps... none of that is possible on GrapheneOS
I think you're talking about something like "freedom", here. GrapheneOS doesn't claim to give you the freedom to do whatever you want. In fact, part of the Android security model is to limit your freedom.
Which is not to say that you should not want the freedom to have root access on your phone. But if that's what you want, GrapheneOS is probably not it.
My phone isn't my email server though? It's not exposed to the public internet. It connects outwards but you can't simply connect inwards to the IMAP client
You can invert your logic as well: Why care about security without privacy? If your apps are leaking everything to the internet, what's there to keep secure. One could argue this is the essential dependency, not the other way around, since security depends on the threat model but, without privacy, there's no more secrets
> I think you're talking about something like "freedom", here
In part, as well as a means to an end, yes. (GrapheneOS uses this as well, since without the freedom to bring your own OS, they couldn't run on Google's devices. I would think we all enjoy having the freedom to do what we want with our own hardware.) Note also the part where it says "provide fake data to tracking apps": that's privacy which GOS doesn't offer but a user root device / any desktop OS would
> You can invert your logic as well: Why care about security without privacy?
That's EXACTLY my point here. GrapheneOS cares about both, because GrapheneOS considers that they go together.
People come and say "GrapheneOS doesn't understand that people care about privacy and not security, therefore people are happier with less secure systems like /e/OS because /e/OS doesn't care much about security but cares about privacy".
My point is that I care about both, and I am therefore happier with GrapheneOS because GrapheneOS cares about both.
> Note also the part where it says "provide fake data to tracking apps": that's privacy which GOS
GrapheneOS offers such privacy features (like giving a permission to the app but telling the system to feed it dummy data). But yeah, maybe it's not exactly doing what you want (actually it sounds more like you just don't know what GrapheneOS can do, but it's not stopping you), therefore you can probably go around and claim that "GrapheneOS doesn't provide privacy", because why not?
This is only my opinion, but GrapheneOS's approach to privacy seems obtuse to me. They will claim that an unlocked bootloader is a risk, but then turn around and recommend you install proprietary apps GApps in their sandbox. The sandbox doesn't matter if all the private data is in the same sandbox!
Reminds me of https://xkcd.com/1200/
> recommend you install proprietary apps GApps in their sandbox
They don't recommend you to do that. They tell people that if people want to install apps, Google Play Store is a secure and easy way to get apps. They inform people about this because some have the misconception that using the Play Store defeats the whole purpose of GOS (which it doesn't) or that the Play Store is highly problematic (it's better than most alternatives). But, the user itself is free to decide what they do. If you look at project members of GrapheneOS, some say they use Play, some say they don't.
> The sandbox doesn't matter if all the private data is in the same sandbox!
That's not how sandboxing works. The sandbox is around the app. Each app is in the sandbox. On GrapheneOS even the componenents of Google Play (Play Store, Play Services and on older installs Play Services Framework) are sandboxed. On Android OSes that bundle Google Mobile Services (GMS), Play gets an exception and is a priviliged app. On GrapheneOS they are regular apps. They are each put in their own sandbox. The access of each is controlled by their own set of fine-grained run-time permissions.
With all due respect, you fundamentally misunderstand how sandboxing works, even on Android in general. I recommend reading this to understand sandboxing in the AOSP: https://source.android.com/docs/security/app-sandbox . On GrapheneOS the sandbox is hardened a bit, but that's not the most significant feature of the OS at all, and Play is forced to run sandboxed if users choose to install it.
Feels like you don't know what "the sandbox" is. It's not "their" sandbox, it's from AOSP.
When you run an app on Android, it runs in a sandbox. Meaning that your social media app cannot access the files of your banking app by default. They are "sandboxed".
On a normal Android, the Play Services are installed as a system app. It is privileged app that has "system" access. A system app is not sandboxed.
GrapheneOS allows you to install the Play Services and the Play Store as "sandboxed" apps in that they run unprivileged, just like WhatsApp or TikTok or your banking app.
So running the proprietary Google apps in the sandbox is obviously more private than running them as system apps, wouldn't you say?
If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
I agree there's some marginal benefit that sandboxed GApps need to prompt the user for permissions (rather than having privileged system level access) but at the end of the day, Google Maps will get GPS perms and Google will know everywhere your phone goes.
> If the Tiktok app passes your data to Play Services (say, to support notifications with GCM) then it doesn't make any difference that Play Services is nominally "sandboxed".
Sure, but that's the same if you run TikTok with microG (which will relay your data to the Google servers just like the Play Services) or in waydroid on a Mobile Linux. But you can't blame the system for what the apps are allowed to do by the user.
Take your Google Maps example: if the user wants to run Google Maps, obviously they will be sharing data with Google. It's very weird to blame the system for that.
What the sandbox brings is that for users who want to run the Play Services (because they want to run TikTok, knowing that it will share data with some servers, including but not limited to the Google servers through the Play Services), then at least the Play Services are not root on their OS. So then instead of running microG, you can run the Play Services and have the same kind of benefits.
Now if you don't want your apps to contact Google, then by all means, don't install the Play Services! But don't install microG either! And don't install Google Maps!
It's all about trade-offs, it's not an all or nothing situation. Sandboxed Play Services is better than privileged Play Services.
I agree it's about trade-offs. I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
You're of course correct that we can't blame the system for choices made by users, but I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play
Regarding location, please see my comment higher in the thread about the location rerouting through GrapheneOS.
Also, it's not a better option to use MicroG. MicroG is in most OSes where it's bundled running priviliged and still connects to Google. Moreover, their reimpementation isn't complete and also not as well odne as Google's.
> encouraging users to install sandboxed GApps
What you link isn't an encouragement at all. It's offered as an option, because there is a demand for it in order to keep compatability with apps high. It's a usability feature (compatability) that's implemented much more securely and privately than on other OSes because it runs in the sandbox. Users are not forced at all to use it nor are they pushed to it.
Not all GrapheneOS project members (devs and moderators) even use Google Play, so how would they be "lulling us into complacency".
> focusing on the security angle only
The app sandbox isn't only a security feature, it's a privacy feature. Access to your data is gated behind permissions due to the sandbox. This is privacy.
> I think MicroG - which provides dummy no-op implementations of Google Play tracking APIs, and allows you to select alternative Location Providers and notification backends - is a better option than running first-party Google software.
microG still forwards the requests to the Google servers. Not sure what you mean by "tracking APIs"? microG is a reverse-engineered, open source implementation of a subset of Play Services, right? It's not obviously a better option: for instance, some things that are supported in Play Services are not supported in microG, and microG sometimes breaks (because of changes in the API).
> allows you to select alternative Location Providers
GOS does that, too.
> I do think GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps
I don't get that. It does not encourage them to install Play Services, it makes it available. Because for many (most?) users, it is important to have it.
I am not sure what you are trying to say: is your opinion that there is no point in using an alternative OS (like GOS, /e/OS, LineageOS, IodeOS, ...) or are you trying to say that GOS is not the most secure/private alternative OS?
I'm trying to say the same thing I said up at the top: GOS's approach to privacy is obtuse. They deliberately conflate security with privacy (you even write "secure/private" as though they're the same thing) in a way that does a disservice to users.
My opinion is that GOS is very successful at its own stated goal of having an extremely secure mobile OS that rolls out patch updates quickly. I think it's far less successful at protecting user privacy because — as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play and help them securely upload their personal data to the world's biggest adtech firm.
I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
> as you even admit, many/most of them will find their phones unusable with vanilla GOS and immediately follow the GOS user guide to install Google Play
I installed the Play Services right away, just like I installed microG right away on a LineageOS system (I don't know about iodeOS, but /e/OS comes with microG by default). In terms of privacy, I don't think it is very different: microG is an open source implementation of the Play Services, that also contacts the Google servers. Many will use something like the Aurora store, which is a client for the Play Store. Etc.
GrapheneOS has proxies, e.g. for the location service. They are doing a lot for privacy, that's very clear.
> I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
And that's your right. I think that GrapheneOS is more secure, and not less private than those. Actually in my experience with /e/OS, it was less secure than Stock Android (though more private, admittedly).
> They deliberately conflate security with privacy (you even write "secure/private" as though they're the same thing) in a way that does a disservice to users.
That's not really true. In fact, the way you are presenting it, as if they were seperate is doing a disservice to the reality and therefore to the users.
You can't have privacy without security. Security is what enforces the privacy. If your system is insecure, privacy controls can be bypassed.
> 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.
GOS' "own stated goal" is privacy, security and usability. The main reason the project is made is to give people privacy, and the reality is that in order to give privacy you need strong security. Usability is also striven for by trying to match other mobile OSes in app compatability and accessibility features (the latter being a current work in progress with TTS and STT coming soon).
> 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.
Many people are able to use their phone fine without installing Google Play. It depends on choices people make. If you use a different set of apps not relying on Play, it's perfectly possible to use it. If you care so much, just change the apps you use. Also installing Google Play doesn't equate to "securely uploaidng their personal data to the world's biggest adtech firm". Again totally misunderstanding how the app sandbox works.
> I think iodéOS and /e/OS are more in line with what I want from a mobile OS.
Unclear what you want. If you want something aligning to your vibes and ideology, probably. If you want privacy, not really.
> You can't have privacy without security. Security is what enforces the privacy. If your system is insecure, privacy controls can be bypassed.
Again, this is an obtuse perspective. A system that doesn't collect or store private data never needs to concern itself with securing that data.
I am concerned with reducing casual data exposure to the adtech industry. I am not worried about being targeted by nation state actors.
>GOS lulls users into complacency by focusing on the security angle only and encouraging users to install sandboxed GApps: https://grapheneos.org/usage#sandboxed-google-play
Sandboxed-Google-Play is not encouraged or promoted. It is suggested if you need apps only accessible via Google Play or needing Google services purely because it provides the maximum compatibility. GrapheneOS have always said that Android's strnegth is a large wealth of open source apps (many of which do not need Google). If more everyday apps (media streaming, taxi, food delivery & rewards, banking, government, social media) did not depend on Google, GrapheneOS would not spend the time, resources and effort that they have on sandboxed-google-play.
Communication between apps using IPC happens on mutual consent and is explicit. You can't just throw data to Play Services and expect it to accept it and process it well, that's not how it works. Communication via IPC is always very intentional and specific, so it will be very structured data for specific purposes, not just a dump of all your data. Firebase Cloud Messaging (FCM) is a push messaging service, it doesn't need to be used to send the actual notification. It's perfectly possible to just use FCM to wake the device and then handle notifications by yourself as app. The way FCM can be used is much different from Apple's system. Apple forces you to use their services for notifications while Google allows you to use FCM just for waking your device. It's also possible for apps to not use FCM at all and to just use WebSockets or UnifiedPush.
If you just grant Google Maps location permission and don't give it to Play Services and keep your sandboxed google play settings to the default, the location requests are rerouted through the GrapheneOS servers. If you want to use network location to get quicker location locks and location indoors, you can also use GrapheneOS network location, so you don't need to use the Google implementation for that.
And, even if you would decide to use Google directly for the location, you can perfectly avoid giving permanent location access. You can hand it over only once or only when the app is in use. So Google doesn't know everywhere your phone goes, at all.
They recommend you install google play services if you need it. Privacy is in no small part a user-decision - no matter how secure your device is if you just scroll Facebook all day.
GrapheneOS is primarily privacy project. It keeps up with important Android updates with major privacy enhancements and very important privacy patches. It builds crucial privacy protections such as Storage Scopes, Contact Scopes, Sensors toggle and much more into the OS. Privacy depends on security so security protections and security patches are part of providing strong privacy too.
It's a misconception that GrapheneOS is focused on security over privacy. It heavily works on privacy features and the work on security features is entirely to protect privacy. There's widespread use of commercial exploit tools and GrapheneOS is proven to provide far better real world protection against those. Most alternate operating systems reduce privacy from AOSP and massively reduce security while GrapheneOS is preserving the baseline and heavily improving both side by side.
GrapheneOS is also very focused on usability and app compatibility, making sure to preserve those with the major privacy and security enhancements.
The #1 security problem your average Android user face isn't an attack by some Israeli firm but data leaks by advertisers and unless I missed something (it's possible), GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.
Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.
I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.
>GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
Content filtering is built into the browser. GrapheneOS have always maintained that you cannot prevent an app from exfiltrating data, especially if it has internet access. Enumerating badness is an unsustainable approach they don't want to encourage. Instead they attack the heart of the issue with Storage Scopes/Contact Scopes/Network Permission/Sensors Permission etc. They allow aps to think they have full access when they do not, so you can control exactly what data they get in the first place. Maybe all of the other AOSP projects could contribute App Communication Scopes/Enhanced Clipboard Privacy and other things because this approach makes a lot of sense to me. Like preventing an illness instead of wasting energy treating symptoms.
>The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
Something similar was addressed some years ago as a feature request for GrapheneOS https://github.com/GrapheneOS/os-issue-tracker/issues/284. To summarise there was no way to do this without an unacceptable security cost to the OS, but this is sort of doable if you run your own userdebug build which you have the power to do.
> Something similar was addressed some years ago as a feature request for GrapheneOS https://github.com/GrapheneOS/os-issue-tracker/issues/284. To summarise there was no way to do this without an unacceptable security cost to the OS, but this is sort of doable if you run your own userdebug build which you have the power to do.
It's badness enumeration which is an unworkable approach to providing strong privacy. It fundamentally can't provide it, only weak case-by-case improvements which are very fragile and trivially bypassed. It can also be done by modifying APKs instead of having a hooking framework within the OS heavily compromising security. You don't need the OS providing anything to use arbitrarily modified APKs. We also don't want to give apps a legitimate reason to ban GrapheneOS as opposed to being able to convince the tiny number of apps enforcing Google certification to allow it.
> You don't need the OS providing anything to use arbitrarily modified APKs. We also don't want to give apps a legitimate reason to ban GrapheneOS as opposed to being able to convince the tiny number of apps enforcing Google certification to allow it.
I think you said the truth out loud, a rom which tries too much to fight for your privacy would just be banned. (And I do agree with that)
Protecting strong privacy conflicts with the kind of hooking features unable to actually protect privacy without being easily bypassed. The reason apps would ban doing that is due to compromising the privacy and security model for applications, not protecting user privacy.
Nearly the only thing which would potentially result in the OS being banned which is a legitimate privacy feature would be hiding that the Mock Location feature is enabled which is pretty much pointless since apps can ban the OS as a whole instead of only banning using them when Mock Location being enabled. Our planned per-app Location Scopes feature doesn't necessarily need to say that Mock Location is enabled but it should be possible for apps to detect so they don't have an excuse to ban GrapheneOS as a whole. It's far better that they ban using Location Scopes than banning using GrapheneOS at all. We could make our own API for detecting it's enabled so that apps detecting Mock Location work but apps aware of GrapheneOS can choose to ban Location Scopes rather than banning GrapheneOS. We aren't going to do something which simply hurts users should reducing the apps they can use for no actual benefit.
GrapheneOS provides greatly improved privacy including through features like Contact Scopes and Storage Scopes.
> GrapheneOS does not have an equivalent of ublock origin built into the OS which I'd consider step 1 of fighting the problem.
Enumerating badness by trying to list domains which are solely used for advertising, telemetry, etc. doesn't address any of the main privacy invasive behavior by apps which is done through their own services and server side contact with third parties.
uBlock Origin has the same problems in the browser but the rules within a browser are a lot more flexible than the extreme limitations of domain-based blocking whether any useful purpose of the domain results in blocklists not being able to include it or apps would break. Domain-based filtering is also far less usable in practice and is typically not per-app either.
RethinkDNS on GrapheneOS works far better than the domain blocklist in /e/ but it's not a strong approach to privacy and does not address much.
Apps can easily work around it and prevent the filtering, as can the SDKs. One way is doing server-side connections and another is using DNS-over-HTTPS for DNS resolution. Facebook has fallback IPs and DNS resolution in a growing number of their apps and can do it in their SDKs too.
Using a fundamentally unworkable approach that's increasingly becoming less useful is not how GrapheneOS approaches privacy.
> The "ideal android" in my head would just have a dynamic ruleset to patch/nop tracking libraries as the app loads, which as far as I know, nobody does that, eOS doesn't either. Kind of like Revanced but on steroids and built into Android.
This is another fundamentally unworkable enumerating badness approach which is not how GrapheneOS approaches privacy. GrapheneOS avoids apps getting access to sensitive data rather than trying to stop them sending it to specific places.
> I feel like you can't really fix android anyways, the design is just broken and if you care about security / privacy, you should just use everything in a browser or a Linux distribution.
GrapheneOS is a Linux distribution. Desktop Linux distributions have far worse privacy and security than GrapheneOS. The ports of desktop Linux distributions to mobile are largely losing even more security. That's a huge setback for privacy and security, not progress. They don't have similar privacy protections, don't have a similarly strict approach to privacy for default services and lack security to keep privacy intact. Using mostly or only open source software doesn't mean you don't need privacy and security protections. Aside from that, the open source mobile app ecosystem for Android and GrapheneOS is far better than it is for those operating systems.
> Sure the work GrapheneOS does is valuable but it's like removing water from a lake with a bucket.
GrapheneOS provides drastically better privacy and security than the desktop operating you think are better. It has a great open source app ecosystem available with lots of high quality apps. You're portraying it as if people must use privacy invasive apps but that's not at all the case. Plenty of desktop users are using apps like Discord where they can access the entirety of their data as opposed to GrapheneOS where it's a heavily sandboxed app with lots of user control along with prevention of coercion to get access via the scopes features we add for pretending to grant permissions while actually granting access to no files/media/contacts by default where it simply appears there are none until users explicitly opt-in to adding them.
> I feel like shielding the mess that Android is into something like an improved Waydroid with a mindset of "yeah let's keep it there and the sane stack for the rest" sounds a better approach to me.
Waydroid has far worse privacy and security from Android apps than running them on AOSP or especially GrapheneOS. It loses the Android app sandbox and permission model. It uses a very outdated fork of AOSP and breaks the privacy/security model through how it's implemented. It runs on top of a far less secure host OS with worse isolation for the apps inside it from the rest of the OS than exists on Android itself. Moving to a drastically less private/secure host OS while running Android apps in a much less private/secure way is hardly progress.
> Using a fundamentally unworkable approach that's increasingly becoming less useful is not how GrapheneOS approaches privacy.
I feel like we agree on the premises but not the conclusion then.
If there's no way to make a Revanced on steroids system work on Android, it means that Android's security model is fundamentally broken for me and beyond repair.
Fundamentally, Android is built with untrusted as its core value. Google doesn't trust Qualcomm, which doesn't trust the manufacturer, which doesn't trust app makers, which doesn't trust the user. It's a chain of untrusted parties all the way to the user. With one single exception, in your average phone, the user has to trust all the the above. So the user is the one trusting everybody blindly and nobody else has to do it.
The only way to make this untrusted chain model work is to go one step further, make the user not trust all of the above with a heavily modified system, including dynamic patching and that's almost impossible.
The reason why it works differently on a Linux distribution is it's built on the opposite values. The maintainers trust contributors which trust app makers ... all the way to the user. If one of them breaks that trust, they are out for good, they know they have one chance and this makes the stack fundamentally less hostile.
You can't easily fix a broken social contract like in Android with just tech.
Since you seem to be one of the developers, one thing that I wish Graphene focused on more is browser fingerprinting. This is is probably the number one threat against privacy nowadays. Vanadium is very usable, but it seems to be quite easily fingerprintable.
GrapheneOS does focus on browser fingerprinting with a long term approach that's being implemented. That's why adblocking is implemented the way that it is with a specific list of filters and then regional/language filters activated based on which languages are enabled. Vanadium does provide good protection against instances of Vanadium being distinguished from each other in ways other than the IP addresses, language, time zone, etc. Adding support for using a universal UTC time zone in Vanadium is one of many planned features for countering fingerprinting. Expanding the Vanadium userbase beyond GrapheneOS would be the main way to reduce fingerprinting since it heavily depends on the number of people using the browser so we eventually plan to launch it for use outside of GrapheneOS once it has more features.
Brave has the best anti-fingerprinting on Android right now but it's not all implemented in a good way and they have a lot of features with privacy and security downsides too. Vanadium is gradually working towards having stronger anti-fingerprinting than it. It will take time. In general, our approach is focusing on doing things properly with the long term in mind. It takes longer but the end results will be better as can be seen for what we ship in many areas. Our network-based location implementation is a nice example among many others.
The founder, afaik, not just a developer.
Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans.
Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a little frustrating that they couldn't collaborate some base like this to the open source community.
> Tor Browser seems to be a project that requires multiple full time developers. I don't think GrapheneOS have the resources right now to do this alongside their OS development, device support and app overhaul plans.
We're in the process of hiring a bunch of full time developers and will have more people working on Vanadium soon. The bottleneck isn't money but rather building out the organization and hiring people. We get a lot of donations and are going to be greatly expanding the project, particularly with the funding being offered by Vitalik Buterin for hiring 5 more full time developers.
> Also please don't take this as any criticism of your suggestion, but there have been multiple 'privacy' browser projects based on Chromium for Android. It's a little frustrating that they couldn't collaborate some base like this to the open source community.
Many aren't using permissive licensing and a lot of it is a mess that's not possible to include in Vanadium rather than making our own implementation that's more focused on correctness and maintainability. GrapheneOS is going to have an increasingly large amount of resources so we wouldn't get much from working with tiny projects. We could hire people to work on Vanadium instead. Working with Brave would be compelling but not much else. Brave has a lot of stuff we want but usually it's quite messy and complex compared to what we want to have. We're using work from Microsoft on Chromium hardening that's not used in Chrome / Chromium such as the WebAssembly interpreter.
I missed this in the bustle of this thread but that's fantastic news. Hugely appreciative of the work yourself and your team at GrapheneOS are doing and it is great to hear it will be expanding/growing too.
> 'privacy' browser projects based on Chromium for Android
As far as I know none of these projects have tackled the JS fingerprinting problem. The most earnest attempts seem to be Brave and Firefox with the Arkenfox user.js, but they have their own problems. The basic issue is that JS gives websites far too much control over the user's device. The JS spec should have never allowed websites control over the clipboard (e.g. to disable paste), to know if the user is active, when the mouse is being moved, etc. Since it is too late now, short of disabling JS entirely, there will be usability tradeoffs, but I think these are necessary (at least optionally) in an OS like Graphene.
Unfortunately, browsers have often done too little, too late when it comes to privacy. For example, until recently, most browsers allowed third party cookies by default.
GrapheneOS has a lot planned for Vanadium. It could become a project almost as large as the core OS project. We're going to be greatly expanding our team and that needs to happen before Vanadium can have substantially more changes than it currently does. Full state partitioning including for cookies is a much better approach than disabling third party cookies. Vanadium does disable third party cookies but that doesn't really do as much as you'd think because the way third party cookies are defined and what disabling them means is not intuitive. Third party cookies would not be a significant issue if cookies were fully partitioned by the top level site. Chromium has implemented state partitioning for the vast majority of the state but specifically not cookies by default where it's opt-in, so we need to handle that ourselves. They do support partitioned cookies but it's opt-in. Strictly partitioning cookies breaks a lot of cross-site functionality so no mainstream browser is doing it but rather they use heuristics to support cases like cross-site login and their partitioning is easy to bypass through that.
Fundamentally, almost all "innovation" in browser and JS development for the last 20 years has been about giving new powers to website authors, not to the people actually using the browser. The idea of telling website authors "no, you can't do that" seems to be anathema to browser authors and standards groups. The result is that they make it easy for website authors to wrap their content in shinier and shinier wrapping paper and then tell users how great it is that they can now see all that shininess. Probably 50% of what a website can do today is stuff we would be better off not having available.
privacy != security.
And sandboxed Google Play services serve both goals -- it runs the service as a regular android service, not an exceptional one that has a bunch of extra permissions. So you can allow/restrict it as you seem fit, while not "getting behind" on features/apps that mandate it.
GrapheneOS provides major privacy enhancements including Contact Scopes, Storage Scopes, Sensors toggle, per-connection Wi-Fi privacy via per-connection DHCP state + MAC randomization and far more. It's a privacy project and privacy depends on security so it heavily focuses on protecting against exploitation of privacy and security vulnerabilities too. Privacy and security are not separate things from each other but rather closely tied together and our work is on both for the sake of improving privacy. Our only reason to work on security features is protecting privacy.
I won't argue with you on the project-related part of it, you obviously know best there :) Thank you for all the work!
But how would you "rate" for example desktop "GNU/Linux" with this in mind? Quite clearly privacy is important here and none of the major components leak/store unnecessary personal data. But the security story is quite sad, everything runs as the same user so a random `npm install` can just do whatever it wants with my browser caches, ssh keys, etc. I would say that GNU/Linux is privacy-friendly, but has terrible security. Would you not agree here? How does this fit with the "privacy and security are not separate things" part? Genuinely curious about your opinion here, not arguing for the sake of it, they are just not as closely connected in my mind. For example Google has a good track record of having safe practices regarding data storage -- but privacy is not their strong suit/hard to define what it means for a company to begin with.
I disagree, privacy is an essential part of security, if there's no privacy, then there's no security.
That's also why I don't keep anything important on my phone as I don't trust what's going on there despite having all the secure features that you would want.
Other way around, actually. It's possible to make concessions to privacy, like providing crash reports, or running applications in sandboxes which limits what they can harvest, while keeping the platform secure.
Any privacy you have on a system is reliant on no one tampering with that system and on software behaving itself. Without security, you can't trust the system to implement any privacy.
I also disagree with that, I trust my Linux distribution to behave well much more than I trust any Android platform and it doesn't even have much app sandboxing at all.
You can't fix a lack of trust like you have in Android with technical solutions. The flaw in Android is fundamentally a social problem.
There's a massive open source app ecosystem for Android which is far larger than the subset available in F-Droid. Open source does not imply private or trustworthy. Completely trusting applications with access to all your data with no insight in to what they're accessing or sending to services means you wouldn't know if your privacy is being violating anyway.
The (desktop) Linux security model is different. You trust the distro maintainers in the same way you trust the GOS devs, and instead of "app sandboxing" you use user accounts, containers or VMs to protect personal information. The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.
> The (desktop) Linux security model is different.
Desktop Linux distributions lack a viable privacy and security model for applications and far more. They don't have comparable protections against exploitation or comparable privacy protection as a systemic part of the OS either. The approaches are very incomplete and apps generally aren't contained unless they're run in another OS in a virtual machine such as the approach in QubesOS which is not really a Linux distribution but rather a Xen distribution acting as a meta-Linux-distribution. It can use Windows too.
> user accounts
This isn't an application sandbox and doesn't provide similar isolation for desktops.
> containers
Containers do not directly work for sandboxing desktop applications. It still requires that the UI and application layer of the OS provides sandboxing. Containers can be used to isolate things at the filesystem level, etc. as part of a sandbox but are not a sandbox for desktop applications on their own.
> VMs to protect personal information
GrapheneOS has hardware accelerated virtualization on all supported devices. Running a separate OS in a VM is a much different thing from providing a working privacy and security model within the OS. Using virtualization as part of an app sandbox that's integrated into the OS itself with a separate VM for each app is a far different thing than just running another OS in a VM.
> The Android security model makes sense in the context of laypeople using mostly commercial malware on the stock OS however.
Android has a far larger open source app ecosystem for mobile than those operating systems. Open source applications still need to be sandboxed to provide reasonable privacy and security. Otherwise, you're not only trusting those applications and their supply chains to not do anything privacy invasive which does happen extremely frequently but also to avoid having vulnerabilities. The vast majority of applications do not take privacy and security very seriously so an OS not containing them and protecting them against exploits with modern exploit protections won't provide good privacy and security itself. Application vulnerabilities are the main attack vector for remote attacks. Open source software as an overall ecosystem is also not nearly as privacy respecting as you make it out to be. Most is not focused on privacy or security, which means they regularly do things which are privacy invasive to provide functionality and also aren't providing strong privacy or security protections at all.
> The (desktop) Linux security model is different
In that it doesn't really exist. Sure, linux has all the capabilities to do it properly, but defaults matter in security so the way it currently works, basically every program has access to everything actually important (personal files, photos, ssh keys, etc). It just can't upgrade your GPU driver.
Security goes way beyond a technical checklist.
I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user.
You can't fix the lack of trust you have on Android with just sandboxing.
I do trust the Linux distro maintainers that they don't have nefarious purposes. But they can't and won't verify third party projects' code, nor the huge number of contributors that come and go on any of these projects, or their transitive dependencies.
As has been shown, it's almost trivial to get malicious code merged into open source projects, so not really sure where your "trust" comes from. It's not trust, it's naiveness.
The proof is in the pudding at the end of the day, how many privacy scandals Debian had vs how many privacy scandals Android had? One model seems to clearly work better than the other. Talk is cheap, I like to see the results.
And to answer your question, of course they can't check everything, that's why it's a model based on trust and not a model based on verify.
What would happen if let's say VLC would upload your user documents in the background? They would get nuked out of the repository and never be seen again. That's why apps do not tend to do that.
I'm not against sandboxing and a strong technical model myself, it's just that if I have to pick between a trust model and technical features, well the trust model wins hands down 10 times out of 10 as it has a better proven track record.
> The proof is in the pudding at the end of the day, how many privacy scandals Debian had vs how many privacy scandals Android had? One model seems to clearly work better than the other. Talk is cheap, I like to see the results.
You're drawing completely false equivalences between a specific OS and an entire ecosystem with tens of thousands of operating systems. For some reason you're including apps like Discord as part of your evaluation for the OS for Android but not desktop Linux. On desktop Linux, Discord gets access to everything. On Android, it's a sandboxed app. On GrapheneOS, it's a much stronger app sandbox with far better user control including features to avoid apps coercing giving access to files/media and contacts, etc.
> And to answer your question, of course they can't check everything, that's why it's a model based on trust and not a model based on verify.
Distributions aren't doing any significant review of what they package in practice. Debian ended up with backdoored sshd not because their review missed something in xz but because they don't review it in the first place.
Open source software very regularly has privacy invasive services and practices. It's very common and not at all rare. Actual backdoors and malware is rare but the same goes for proprietary software from reputable companies. Privacy invasive behavior is more common for proprietary apps. You're portraying it as if Android doesn't have a large open source app ecosystem when it absolutely does and as if proprietary software doesn't exist for desktop Linux when it absolutely does. The basis of all your arguments about this are these false premises.
> What would happen if let's say VLC would upload your user documents in the background? They would get nuked out of the repository and never be seen again. That's why apps do not tend to do that.
VLC is available as an Android app. VLC is not a privacy or security focused app. It doesn't provide strong protection against exploitation from maliciously crafted media files or malicious services. Running it on an OS with strong exploit protections for apps and a sandbox around it not giving it access to everything is very valuable. VLC on GrapheneOS has far stronger exploit protections including hardware memory tagging along with being in a very good sandbox. Users don't need to grant it access to most of their files and generally won't since they can use it without granting access to any files, grant access to specific indexed files types, specific directories or do it on a case-by-case basis.
> I'm not against sandboxing and a strong technical model myself, it's just that if I have to pick between a trust model and technical features, well the trust model wins hands down 10 times out of 10 as it has a better proven track record.
GrapheneOS has a large open source app ecosystem far bigger than what's available for non-AOSP Linux distributions on mobile. It has a strong app sandbox with a permission model that's getting increasing good both from upstream AOSP improvements and our growing privacy protections. Our Contact Scopes and Storage Scopes features are an approach we're taking for other permissions too to gradually phase out permissions where an app either works or doesn't work based on granting a specific permission even though it doesn't need to be that way. We took care of the main ones already but there's a lot more to do. This is very useful even for open source apps which rarely focus on privacy and usually doesn't care much about security. It's extremely valuable to avoid giving open source apps access to more than they need. You brought up VLC as an example which has atrocious security and is a great example of an app heavily benefit from sandboxing even if you fully trust not only the VLC developers but also the developers of the large dependency graph.
> I trust my Linux distribution because there's a chain of trust, from the maintainers, the contributors down to the user to make sure that the software is respecting the user.
Nope, that's not actually how it works. In reality, there's little to no review of what's being packaged. The distribution packagers are additional trusted parties. You're also trusting the upstream developers and their dependencies which are largely not very interested in privacy and especially security. There's extremely little systemic work on privacy and security in desktop Linux operating systems which is why they still haven't fully deployed basic exploit protections from the early 2000s, let alone providing a strong privacy and security model with strong defenses throughout the OS.
> You can't fix the lack of trust you have on Android with just sandboxing.
Contrary to what you keep saying, Android has a large open source app ecosystem. Those open source apps run in a sandbox avoiding them being a single point of failure for the entirety of privacy and security of the OS. The vast majority of open source developers are not writing privacy and security focused software. Security is extremely neglected in the vast majority of open source projects and many do privacy invasive things. Open source does not provide privacy and security itself. Publishing sources under an open source license doesn't make software more private or secure itself. Most open source projects aren't getting significant privacy and security benefits from doing so since little of it gets deeply reviewed. Most projects do not get a lot of external contributions to the code. Open source code doesn't mean the developers aren't heavily trusted and only theoretically provides the ability to check everything extremely thoroughly which simply doesn't happen. If it worked the way you believe, there wouldn't be an endless stream of vulnerabilities being fixed which have often been present for a long time including years or decades. See https://lore.kernel.org/linux-cve-announce/ for a major example.
That reads more as sports team flag wavey thoughts and feelings trust than anything actually backed by objective data.
That's the difference between trusted computing (Linux distribution) and untrusted computing (Android).
If you want something backed by objective data, my phone has an advertising ID built in the OS and my laptop doesn't. My phone had 100s of privacy scandals and my laptop doesn't have one.
I do applaud GrapheneOS don't get me wrong but I have a feeling that they are fighting a losing battle.
There's a huge open source app ecosystem available for Android. The distinction you're trying to draw is inaccurate. Open source apps also very open do privacy invasive things. On Android, people can see that many open source privacy even including Signal include dark patterns such as repeatedly asking for access to contacts when it works without it. On a desktop OS, the apps and services will simply have access to nearly everything by default so you aren't aware of it happening for the most part.
GrapheneOS provides far better privacy and security than a desktop OS. There's no such thing as an advertising ID built into GrapheneOS so it's a strange thing to bring up. There are plenty of privacy invasive things built into desktop operating systems and applications, including open source ones. They nearly entirely lack the ability to protect against apps and services being privacy invasive in the first place. They also have far weaker protection against exploitation.
What advertising ID is built into the OS?
See https://support.google.com/googleplay/android-developer/answ... for Android and https://developer.apple.com/documentation/adsupport/asidenti... for iOS
You're linking to Google Play's documentation, not Android code itself that GrapheneOS etc. are built upon
You can find hardware identifiers exposed by Linux distributions more than by Android itself. That Google adds a nice sauce on top... yeah that's a sorry state of affairs, but an optional layer if you don't use the stock OS if it ships with Google Play
edit: but I appreciate looking it up nonetheless! I wasn't completely sure that I hadn't missed that Android (AOSP) includes this now as well
You can't really use Android without the Google Play anyways so that's a moot point, none of the popular apps will work. Google Play is very much a core part of the Android OS.
Even EOS and GrapheneOS realized that themselves.
You can perfectly fine use it without, many people do. If you can tell us what issues you exactly bump into when trying to use the phone without Play, feel free to share, we might be able to suggest you some apps or workflows to work around the issues you are having.
[dead]
Read this:
https://eylenburg.github.io/android_comparison.htm
In short, GrapheneOS is vastly superior.
Read the rest of the thread here. The blanket statement is a bit short-sighted (some people might even say 'vastly')
GrapheneOS is a privacy and security hardened OS. It preserves the standard privacy and security of the Android Open Source Project (AOSP) along with keeping up with the updates. It builds major privacy and security improvements on top of that. /e/ is the direct opposite and reduces privacy and especially security compared to AOSP. /e/ doesn't keep up with updates, has huge delays for important privacy and security patches along with reducing privacy and especially security in many other ways. GrapheneOS is a much more widely used OS with much more testing and provides much broader app compatibility. Unlike /e/, GrapheneOS only connects to GrapheneOS services by default and provides a high level of control over it. /e/ still uses a bunch of Google services by default and gives extensive privilege access to Google apps/services. Our approach is that Google apps/services are an optional thing people can install which do not receive any special access and can't do more than other regular apps since they're installed as regular sandboxed apps on GrapheneOS via our Sandboxed Google Play compatibility layer.
A common misconception is that people believe GrapheneOS is less usable than much less private and far less secure options but it's the other way around. GrapheneOS provides nearly perfect app compatibility when taking into account the per-app exploit protection compatibility toggle and sandboxed Google Play. Nearly the only apps not working on GrapheneOS are ones banning any alternate OS and a larger number of those work on GrapheneOS than elsewhere due to a subset specifically permitting GrapheneOS due to far higher rather than weaker security. Apps have legitimate reasons for being concerned about the poor security of many alternate operating systems but they're wrongly grouping it all together as if GrapheneOS.
/e/ lags weeks, months and even years behind on providing updates for drivers, firmware, the Linux kernel and more. They miss a large portion of the monthly Android security bulletins which are a limited subset of the patches in the first place but then claim to provide the latest patch level despite many of the required patches being missing.
/e/ has a supposedly private speech-to-text sends data to OpenAI and their own servers without obtaining explicit user consent to share sensitive data with a third party.
https://community.e.foundation/t/voice-to-text-feature-using...
They say the data is anonymized based on passing it through their own servers before OpenAI but OpenAI is receiving all of the user speech data under their usual terms of service enabling them to store and leverage it.
Fairphone lags significantly behind on OS updates and patches with only a small subset of what should be provided being shipped. Their hardware omits important security protections required by GrapheneOS which it uses to protect users against widespread commercial exploit tools. Fairphone doesn't provide upstream Linux kernel updates in practice which is a massive omission for their updates. Fairphone 4 has an end-of-life 4.19 kernel branch and the Fairphone 5 despite not being very old already has an end-of-life 5.4 kernel branch. Neither was providing the LTS revisions prior to end-of-life so from their perspective nothing really changed but it means it's a huge task for an alternative OS to provide basic updates since they'd need to port everything to a newer kernel branch.
/e/ does not provide similar privacy features to GrapheneOS such as Contact Scopes, Storage Scopes, Sensors toggle and much more. It focuses on bundling things which can be provided with apps such as RethinkDNS on GrapheneOS with a higher quality implementation. GrapheneOS delegates as much as it can to apps while focused on the core OS. If a feature can be done better with an open source app, we'd rather leave it up to that app and many provide privacy and security protections which apps cannot. For the most part, apps can't improve OS privacy and security. Enumerating badness via blocklists which cannot block anything that's dual purpose functionality is also a very weak approach to privacy which is increasingly less useful. The most privacy invasive behavior of apps is nearly all done through their own services which also provide their functionality. Among other things, /e/ uses this system for labeling app tracking and permissions which is incorrect and misleading as shown by this example:
https://reports.exodus-privacy.eu.org/en/reports/com.faceboo...
Facebook clearly doesn't have no tracking but rather this system only detects a small number of specific third party libraries they've decided are trackers. Those choices are often very questionable such as portraying even opt-in crash reporting as tracking because it used a third party library on their list. Meanwhile, Facebook's lite app supposedly has no trackers. The permissions list is thoroughly inaccurate and not how Android permissions work. The core permissions are opt-in with apps having to request them so listing those as if they're granted on install and mandatory due to being possible to grant is incorrect. Most of the rest have special access toggles which are opt-in for the sensitive ones or other toggles such as the battery optimization mode where Restricted stops apps starting themselves and delays those things until it's run by another app or the user.
Privacy requires providing privacy patches and strong privacy protections. It also depends on security which means providing security patches and strong security protections. GrapheneOS is heavily focused on all of that rather than simply treating not having bundled Google apps and services as meaning a private OS. There are also worse things for privacy than Google apps and services. /e/ sending speech data to OpenAI vs. Apple doing the processing locally as we've it implemented for GrapheneOS is a good example. Google at least has partial local speech-to-text support and a better privacy policy than OpenAI for the cloud portion. Avoiding Google apps/services is not the same thing as providing strong privacy.
I use and appreciate GrapheneOS due to it being one of, if not the best, option we currently have.
That said, I do not like how much the project depends on Google.
- GrapheneOS is based on Android, which is solely developed by Google.
- GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
- They recommend using the Google Play Store (requires a Google account) to get apps and recommend against using F-Droid.
- Their Vanadium web browser is based on Chromium, which is controlled by Google. It also does not have an ad blocker or support extensions. They recommend against using Firefox. Firefox, and Safari to a more limited extent, are the only web browsers keeping Google from having complete control over web standards and the way we can access the internet.
This is not a criticism of the GrapheneOS project or developers. I understand that security is the biggest priority of GrapheneOS and I understand that Google is often good at security. They are following the goals of the project. It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered. Most users do not need security at all costs. Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
> It also does not have an ad blocker
It does have a network-level ad blocker. What it doesn't have is a blocker which modifies/injects Javascript into pages, which iiuc is the main reason that the blocker doesn't help with ads on YouTube much, or pages which employ similar techniques.
> They recommend against using Firefox.
To clarify: they recommend against Firefox Mobile because it didn't support site isolation until last month's v147 updates. I don't know if the goalpost has moved since, but in any case: there's nothing on Graphene that would prevent you from using Firefox.
Firefox 147 doesn't provide site sandboxing or even basic content sandboxing on Android. They enabled multi-process support by default but still don't provide any form of sandbox for the separate processes. They enabled the separation part of site isolation which is partially implemented for Firefox desktop and now mobile but do not have content sandboxing and partial site sandboxing as they do for the desktop browser. See https://bugzilla.mozilla.org/show_bug.cgi?id=1565196 for their still open issue with many other issues as dependencies for sandboxing.
The complete lack of content and site sandboxing on Firefox for Android is only one of the reasons we recommend against it. It has major security deficiencies beyond this and cannot benefit from many of the hardware and OS protections due to it. Vanadium is much more secure than standard Chromium while Firefox is much less secure than it, so there's quite a stark difference between them.
Recommending against using Firefox and F-Droid due to major security deficiencies doesn't in any way reduce user choice as the post above portrays it. Having a lot of accurate information provided by GrapheneOS enables our users to make more well informed decisions. We also do not specifically recommend the Play Store as the post says above but rather we provide nuanced information about the available choices. Specifically for obtaining apps from the Play Store which aren't available directly from the developers, we recommend using the sandboxed Play Store for users who using sandboxed Google Play in a profile for app compatibility already. Play Store itself has signature verification while Aurora Store only has TLS with a smaller set of trusted CAs by default similar to many Google apps. Aurora Store is sometimes needed to work around app's filtering who can install it so we do recommend it for that specific purpose. Aurora Store still logs into a Play Store account and making a throwaway account to use the Play Store app doesn't reduce privacy compared to using sandboxed Google Play without one.
> GrapheneOS is based on Android, which is solely developed by Google.
GrapheneOS is based on the Android Open Source Project. It's incorrect to say it's solely developed by Google and it's open source software which we're free to change as we see fit.
> GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
No, we already have a partnership with a major Android OEM. It's not something we're working on obtaining and we've provided a fair bit of details including that it will be publicly announced by the OEM in March, that the devices will launch in 2027 and that they'll use a high end Snapdragon SoC which is either the flagship (most likely) or one step below it.
> They recommend using the Google Play Store
No, that's not our recommendation.
> recommend against using F-Droid
We recommend against F-Droid due to it being an unnecessary middleman between users and app developers which does not truly reduce trust the app developers. F-Droid apps are consistently out-of-date and often lag months being on important privacy and security fixes. F-Droid consistently makes problematic undocumented changes to apps including rolling back dependency updates. F-Droid is known to use highly outdated build infrastructure which is very poorly secured. They have a bunch of bad security practices throughout their approach and have made it clear it isn't a priority for them. They've repeatedly said they don't believe app sandboxing is useful and much more than that. Many open source apps including Signal and WireGuard have asked to have their apps omitted from F-Droid due to the security and trustworthiness issues with the project. That's not at all something specific to GrapheneOS.
> Their Vanadium web browser is based on Chromium, which is controlled by Google.
Chromium is an open source project which is collaboratively worked on by multiple projects using it as the basis for their browsers. That includes Microsoft who implemented the WebAssembly interpreter available in the upstream Chromium codebase which is used by Vanadium but is dead code in Chrome and regular Chromium builds since it was added for Edge.
> It also does not have an ad blocker
No, that's not true. Vanadium has a default enabled ad blocker which uses EasyList, EasyPrivacy, EasyList's Adblock Warning Removal List and also selectively activates a whole bunch of EasyList affiliated language/regional lists based on the currently active languages. This approach avoids adblocking being used for fingerprinting, avoids greatly weakening site isolation sandboxing as extensions do and is much higher performance which is important on mobile. It very clearly has ad blocking and a per-site toggle for it.
> or support extensions
Extensions greatly weaken site isolation and give third party code without verified boot extensive access to website content similar to dangerous Android accessibility service apps. Very few extensions are focused on privacy and security in a similar way to GrapheneOS and would compromise what we're trying to build. It's not the approach we want to use in Vanadium. If you want to use extensions then you can use a browser with them but it doesn't fit into what we're building with Vanadium where we want to implement features ourselves in a very private, secure and robust way which cannot be done with extensions. Extensions fundamentally reduce security including because they used a shared process across all isolated websites which inherently reduces isolation. Few extensions take this seriously, even the ones focused on privacy. They commonly add leaks between sites. There are plenty of other browsers available but ours is aiming for a standard of privacy and security which cannot be achieved with extensions.
> They recommend against using Firefox.
Firefox's Android app has atrocious privacy and security. A browser without even basic content sandboxing let alone sandboxing with full site isolation. That's combined with major other major security deficiencies and it isn't something we could recommend using. Recommending against it doesn't mean people can't use it...
You'll still be using Vanadium as the web content engine within apps using the WebView such as email clients rendering HTML email and many more. Many people have a misunderstanding of what the WebView is and confuse it with custom tabs which are provided by the user's selected default browser rather than the WebView used within other apps.
> This is not a criticism of the GrapheneOS project or developers.
How isn't it criticism of GrapheneOS? Regardless, Vanadium does have an adblocker and we don't specifically recommend the Play Store as you said. The biggest issue is that what you're saying about what we prioritize, advise or provide isn't accurate.
> I understand that security is the biggest priority of GrapheneOS
Privacy is the biggest priority of GrapheneOS and privacy depends on security. GrapheneOS is a privacy project.
> It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered.
Our project and community regularly recommends iOS as an alternative which provides far better privacy and security than non-GrapheneOS options. Most other options have very poor privacy/security including lacking even basic privacy/security patches and protections. Similarly, our project and community regularly recommends using macOS for better privacy and security than either Windows or desktop Linux. What you're saying are blind recommendations are anything but that but rather very well informed information provided by the GrapheneOS project.
> Most users do not need security at all costs.
GrapheneOS is not about security at all costs and this misconception which regularly comes up that it's about security rather than privacy is completely wrong. Many projects failing to provide decent privacy treat it as if privacy is solely about which apps/services are bundled rather than needing to provide privacy patches, privacy protections and solid security to protect that from being bypassed. Much of what GrapheneOS provides are privacy features such as Contact Scopes, Storage Scopes and the Sensors/Network toggles along with much more. The security protections it provides exist to protect privacy. Why else would the security protections be there other than to protect privacy? It's not a separate thing from privacy but rather is a huge part of providing it. There's no other reason for us to work on security than protecting privacy. It doesn't make sense to say we work on security instead of privacy.
Most users do need basic privacy/security updates and protections. Failing to keep up with basic updates and misleading users about it is a severe issue. There isn't any major non-GrapheneOS AOSP-based OS that's doing the bare minimum of keeping up with updates.
> Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
You aren't accurately representing what GrapheneOS provides, our approach or our priorities. People can see for themselves from the detailed article that it provides a highly usable and compatible system with a huge amount of user choice. People can choose from a wide range of approaches based on their privacy and security goals. It doesn't impose choices on people. You treat it as if people are forced to use Vanadium when it's another choice of browser which people have on GrapheneOS but not elsewhere. GrapheneOS users have more choice among browsers and the one we have DOES provide ad blocking contrary to what you said. GrapheneOS users can use F-Droid despite us recommending against it due to the major security deficiencies. Providing well informed recommendations with detailed explanations does not in any way hinder user choice but rather informs people so they can make better choices. Our recommendations not aligning with your personal beliefs or preferences doesn't mean we're somehow reducing user choice.
The main problem with the Pixel phones, along with most Android phones these days, is the lack of a μSD card slot and a 3.5mm headphone jack. When I recently had to purchase a new phone, I had to go with a Motorolo G, as it had both of those features.
There are some problems with this, often if a microSD card is used the storage on that SD card isn't encrypted because of the portability goal of it. It would be a bad fit for the project. As per the headphone jack, the headphone jack is much less durable than a USB-C port and has less use cases. Two USB-C ports on a phone would be nice however. For audio with audio devices not accepting digital audio in you would need to add an adaptor with a DAC in between but this is mostly good for audio quality given that those DACs often have better quality than the ones built into the phones. This is my opinion though, you may have different needs.
How is it a break from google/appple if the only supported devices are Pixels? I can't use my sony or other vendors hardware at all.
Are there valid reasons to only support pixels?
Pixels are the only devices providing the required updates and security features. These requirements are listed here:
https://grapheneos.org/faq#future-devices
GrapheneOS is partnered with a major Android OEM working on improving their future devices to meet our requirements. The first devices with official GrapheneOS support from them are planned for 2027. It takes time and resources to make reasonably secure devices. Future generations can improve further including adding hardware-based privacy/security protections unavailable on Pixels.
They are the only Android phones that have the proper security primitives to build a secure OS on top.
Also, they are working on bringing a non-Pixel alternative to market:
https://www.androidauthority.com/graphene-os-major-android-o...
One thing that is a game changer on GrapheneOS is the network toggle for apps. Turn off network access for your keyboard, camera app, calculator, files, etc.
Definitely one of the best features to have this in the native UI, though it's also possible in other ways
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...
That's not at all a similar approach so it doesn't quality as "if anyone wants *this*). The GrapheneOS feature pretends the network is down and local host is also inaccessible. This is good for compatability (apps generally take into account that a network can be down) and too avoid apps knowing you are using the feature.
"Break Free from Android and iOS" looks inside - Android
It should probably be "break free from Google and Apple"?
As long as it is based on AOSP, it is at the mercy of Google to release source code and updates. Given recent trends, I wouldn't be surprised if Google stops shipping Android source completely.
You are right! I will change the title :)
how will it help you to break free from apple if it only supports pixel phones?
One reason that people use Apple phones is they are seen as a less privacy-invasive option than Android/Google.
So it would follow that a valid privacy-respecting third option would potentially help Apple customers as well as Google customers.
They are working on making their own phone hardware.
...on a google phone.
They are working with a partner to provide their own hardware.
GrapheneOS is not Android. It's AOSP-based.
You may be surprised to learn what that "A" stands for.
You may be surprised to realise that you actually don't understand the difference between AOSP and Android :-). See https://news.ycombinator.com/item?id=47047167
I would love if there were a different OS name to designate "Android phones with Google Services snooping in the background" but with the Android Open Source Project being called what it is, I fear "Android" will continue to be understood as a word for either variant
> I fear "Android" will continue to be understood as a word for either variant
Well, "Android" generally means either variant. I run GrapheneOS and I call it Android. If someone asks, I say I run Android, not GrapheneOS. Actually in terms of experience, it is Android to me.
But in a context where we oppose GrapheneOS to Android, then I think it's important to be clear. GrapheneOS belongs to the family of OSes that are based on AOSP (like Android, LineageOS, IodeOS, /e/OS, CalyxOS), while Android is itself a "subfamily" of that, including the Google Android, the Samsung Android, the Xiaomi Android, etc.
In a way, I personally feel like GrapheneOS is closer to Google Android than the Samsung Android is from the Google Android, if that makes sense. Moving from GrapheneOS to Google Android, I really don't see significant differences. Now Moving to a Samsung Android, I need to adapt a little.
All that to say, I really only make a difference when we are talking about AOSP-based systems as a distinct group, by opposition to "Android certified" systems. Just like it sometimes make sense to talk about GNU/Linux in specific conversations, but generally, we refer to a Linux distribution as "Linux".
I take that point, that's a useful thing to do. Not sure that many people even in threads like these will get it unless explained (at which point you might as well word around it) but on a close forum or chat this is definitely a useful approach
I am honestly getting tired of people complaining about the fact that there is a less ambiguous way to name things. Those projects are more and more converging into saying "AOSP-based" (but that's evolving, interesting how language works!). GrapheneOS always says AOSP-based. The English wikipedia page of LineageOS says AOSP-based. In the past we used to call them custom ROMs, but the naming has evolved.
Of course, it is only relevant when it is relevant.
You can join a discussion about cars, where people talk about their Honda or Opel or Fiat, and when they ask you what you drive, you say "a car". And when they say "no but... which brand", you can go on and explain to them that they don't know how to use language, that "a car" is the common way to talk about those vehicles and that nobody in the world cares about a brand, even though you just witnessed a discussion where those people did care about the brand. Sure, you can do that.
But don't expect to have an enjoyable social interaction this way. And don't tell me "but you started it!": I answered to a comment that was making the article sound ridiculous by proudly conflating the two concepts.
You're vastly exaggerating that difference. It's ridiculous to say it's incorrect that GOS is not Android based.
> It's ridiculous to say it's incorrect that GOS is not Android based.
I totally agree, but that's not what I'm saying, is it?
Someone said:
> "Break Free from Android and iOS" looks inside - Android
I answered that there is actually a nuance that is relevant in the context of this article. Ignoring that nuance to make the article sound stupid is simply unfair.
We are all well aware of that nuance, and it doesn't make a poor title less silly.
It's not necessary to spam the comments with your personal reinterpretations of widely known project names that don't match how these names are actually being used. If you really feel the need to be wrong on the Internet at least try to not repeat yourself.
Until these OS also start putting forward something like WebOS that tried to get phones back to on open web, there is no breaking the binary format and Appstore monopoly.
I wish Europe would have forced that 10 years ago since the US is beyond saving.
There's a huge open source app ecosystem for Android and it has the best support of any major platform for well integrated web applications. There are a bunch of alternatives for getting apps including getting them directly from the developers which has been automated without needing an app store. The linked post talks about using Obtainium for getting apps more directly from developers when possible.
What binary format?? Go read facebook's "source code", is that any more open than a random apk? If anything, apks decompile quite well.
So long as browsers allow you to open the developer tools and inspect memory etc., they're more open than remote attestation of a stock android or ios device
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
> but you do need to break terms of service to get the files if you don't have a phone with Google services installed
Why would I care? It's not like what Big Tech does is ethical or legal. You need to fight fire with fire.
Was WebOS really that much about openness? Are you not thinking of FirefoxOS/B2G?
You have to understand that this is yo replace your os on your phone. No phone is designed for that to happen. If you find it difficult, try to do it on an iphone.
I really don't want to give Google money so the Pixel is off for me until GrapheneOS supports something else.
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.
Phones, to just give one example, at least have fine-grained run-time permission controls while on Linux apps can just access anything the user can, except if you use something like Flatpak which gives you sandboxing but the quality of that sandboxing is still worse than Android 4.4 KitKat. How can you protect your sensitive info without such permission controls that gate access to your personal data?
Note that this is just one example, there are also other problems with traditional desktop OSes and a large portion of desktop hardware.
You could buy a used Pixel.
Also, they are working with a partner to get their own phone hardware, hopefully by next year.
What about device attestation? Will you be able to run banking apps and Netflix et. al.?
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.
All Swedish banking apps I've tried works great. Including BankID, swish, Sparbanken, Nordea, LF, Revolut and more.
I've had less issues than with CalyxOS for example, where more apps broke.
I only use Firefox. It has been years since I ran into a chrome only website. Though recently I ran into an edge only websit on my corporate network, not even sure how that happens.
This might be one of those things were if there is big enough user base, companies will start to take it seriously.
Nearly all non-banking apps work with very few exceptions. A large majority of banking apps work. A growing number of banking apps were adding checks for Google certification but now a growing number of those are explicitly allowing GrapheneOS via the Android hardware-based attestation system it supports which can be used to verify the hardware, OS and app with an alternate OS or non-Google-certified hardware if it adds the hardware support for it.
Here's a community maintained list of apps and whether or not they work:
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.
Netflix and almost all banking apps work fine.
https://grapheneos.org/articles/attestation-compatibility-gu...
https://privsec.dev/posts/android/banking-applications-compa...
Well i do use banking and netflix on graphene os on my pixel 8a and everything works perfectly
> 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.
Although this is not the case, moving away from proprietary services (and self-hosting your own) is an important goal in itself. See for instance the recent controversy regarding Discord's age verification.
Been using GOS since roughly 2020. I refuse to use a Phone without GOS on it. It's been amazing.
I am really hoping that other phone manufacturers will eventually realise that and start making phones that can be supported by GOS.
GrapheneOS was contacted by one of the largest Android OEMs in June 2025 and we're actively working with them. They're going to be announcing our partnership in March 2026 and the phones meeting our requirements with official GrapheneOS support are scheduled for 2027.
March? Wow that it huge! Congrats!
Yes, March 2026 is when the first announcement from the OEM will be which is when people will find out which OEM it is. A fair bit into 2027 is when the devices supporting GrapheneOS will be launched. It was theoretically possible for it to happen for 2026 but not very realistic and the hardware wasn't quite there yet.
In my opinion (which is worth what it is worth), 2027 is perfectly fine (my Pixel should live a lot longer than that anyway). What I find huge is that it is concretely happening! It will show recognition for GrapheneOS, and it will be great to have an alternative to the Google Pixels.
Also, people looking at GrapheneOS want technical excellence, so better not rush it :-).
I've found that your experience with GrapheneOS greatly depends on which country you're in and which mobile provider you use. I'm on Freedom Mobile in Canada and I had enough issues that I went back to stock. RCS didn't work at all, and my phone would regularly lose the cellular connection to the point I had to reboot the phone and reset the cellular network settings. I didn't feel like I could trust it in an emergency situation so I reverted. There are also times I'm out of cell coverage and having satellite SOS would be invaluable.
Some of these issues are known and some are just features the project won't support. Last I heard they aren't going to support satellite messaging at all.
I’m with Freedom Mobile in Vancouver, currently using a rather old iPhone. My next phone will probably run GOS.
I have issues with Freedom on my iPhone too. Poor signal, or else “good” signal but poor data backhaul.
Are you pretty sure your issues went away after going back to stock Android? Or is it possible it’s just Freedom Mobile’s general issues?
It's not breaking free from Google, but pretending it does not affect you. You are still at mercy of app developers and Google which may introduce some changes that will affect you. Additionally you never know what will work or stop working.
If something truly unacceptable happens, you still have a while to switch to something else, in the meantime you will still have a working system.
That's pretty unavoidable at that level unless you are able and willing to build your own phone hardware, OS, and all the apps you need.
They are working with a partner to create their one phone hardware.
Should be noted that in order for OEM unlocking toggle to work, you need to turn on WiFi and connect to the internet.
Huh, and here I thought Google was one of the few manufacturers left that simply support it on their hardware. So it depends on some cloud service being alive.
Do you know if it's the same for Fairphone or Shiftphone? Or is there another manufacturer that doesn't require this?
I've recently bought a new phone so it's not relevant for me anymore but when I next go looking, it can factor into it. As it was, I had Google marked in my spreadsheet as the most accessible unlock method together with brands like Oneplus and Fairphone
It's probably worth pointing out that the online process is one time and it installs a token that permanently lets the setting be toggled offline afterwards. This persists across factory resets and flashing any OS.
I wrote more details about it works under the hood here: https://news.ycombinator.com/item?id=35856171
Epic level comment! Very interesting to read about in this technical detail, thanks for taking the time to write it up.
As a long time iOS user, I now mainly run Graphene + GadgetBridge with a helio strap. Pretty nice and private setup.
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
Switched to this from Apple a year and a half ago. Works for most things. Unexpectedly, replacement apps lack polish. Also, RCS works very inconsistently (been without it for months), seems to be Google's fault. There may be workarounds, but I haven't had the energy to try the more complicated suggestions.
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.
Are you in the US? I get the impression that iMessage and RCS are only big there. Almost nobody uses them here in Europe. (It's mostly WhatsApp where I live and Signal is slowly getting more popular.)
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)
https://grapheneos.org/releases#2026021200
https://grapheneos.org/usage#rcs
The RCS issue is why I switched back to iPhone, reluctantly.
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.
> Also, RCS works very inconsistently (been without it for months), seems to be Google's fault.
The best thing would be to switch to Signal (Molly) for texting.
The list of open source apps in this article was very informative and something you can benefit from even if you don't use GrapheneOS. Many of the apps listed I hadn't heard of.
I switch from iPhone to a pixel 9 fold, and installed graphene after 2 weeks on stock android.
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.
You can bypass Play Store restrictions on app installs by using Aurora Store. There's a high chance your banking app can be used but it may require toggling the per-app exploit protection compatibility mode. Most banking apps work on GrapheneOS. X is one of extremely few apps disallowing using a non-Google-certified OS but it only partially disallows it in their store listing which can be worked around and for regular password login. Login is still possible to X via a passkey or Google login. X should stop doing that but they're quite understaffed and did this as a misguided anti-spam measure.
Aurora store is a horrible placeabo. Not only is it using other folks anonymized accounts, which violates several privacy laws internationally it also still has the Google libraries in their apks like everything else. You are not gaining any privacy or security using Aurora Store or F Droid for that matter but are indeed opening up more attack surface in the supply chain that ends at your device.
GrapheneOS strongly recommends against F-Droid because it has major security deficiencies and adds an unnecessary middleman. Our recommendation is using developer builds of apps. F-Droid doesn't review the code for app updates but rather automatically fetches and builds it. They make questionable downstream changes introducing security vulnerabilities. The Accrescent app store provides developer builds of apps signed by the developers for everything included which can be verified. Play Store provides developer builds but only a subset of older apps are still signed by developers since they phased it out and heavily recommend switching to Play Signing.
Aurora Store is not recommended by GrapheneOS in general. Our recommendation is to use the sandboxed Play Store for installing apps when using sandboxed Google Play in a profile. We recommend only using Aurora Store for bypassing restrictions set by app developers on where their apps can be installed. That's what was said above. It would be better if the Play Store didn't do this.
Contrary to what you're saying, Android apps do not include Google Play libraries by default. They're only included if developers explicitly go out of the way to include them in order to use Google service APIs. Android SDK, etc. is open source as part of AOSP and both the OS and AndroidX libraries are open source too. The proprietary Play libraries are clearly marked as such via being in the GMS namespace.
> So keep that in mind if you're switching away from apple to it, as android still feels like decade plus old software.
I think this might just be what you're used to. Android doesn't feel old to me at all, conversely iOS always felt aged even when it was new with the lack of basic features it had for a long time.
ios ui is sleek but in terms of security and privacy, it doesn't hold up to grapheneos. i used ios for 10 years before switching over and quite honestly, grapheneos on my p8 runs really smoothly.
for apps that demand invasive permissions i don't wish to grant, i use web pwas, like for banking. they work like a charm.
being able to grant or revoke permissions that are of paramount importance for security like MTE, JIT, DCL etc on a granular level for each and every user-installed app, and to grant/revoke network permission alone is such a huge W using GOS.
u will not find this in any iphone, now or in the future (i would bet).
I wish there were a good iPhone Mini sized phone I could install GrapheneOS on.
They are working with a partner to provide their own hardware to run GrapheneOS on. Maybe they will have more than one model.
Wallet Apps and Tap-to-pay do not work. Even got banned from PayPal. Android needs an architectural change from the ground up.
I'm happy with grapheneOS as a daily driver. Can you elaborate on being banned from paypal so I don't do the same ?
I use the PayPal app with Tap-to-pay on GrapheneOS and I haven't been banned.
But of course that's entirely up to how their algorithm happens to feel about you.
I mean you're not degoogling yourself if you put all your transactions through a google server. Cash if possible, card if not.
(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)
If you don't use the paypal app, you should be fine, right?
> "Perplexity - I switched to Gemini, but I confirm it works"
Oh the irony.
Where is it? I had a really hard time finding the irony.
If they switch mostly for privacy reason, then starting using Gemini might be counter productive as Google might learn far more about the end-user than if they just did some basic search on any other Android devices. To enable Gemini, one was to accept some crazy T&C and accept that Google collects an incredible amount of personal data.
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.
I mean... yes? But I really don't think there is any 'irony' here. The author clearly stated:
> 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.
I've been using /e/OS for years. Since 2025 I'm on Pixel 9A and GOS. It's excellent. Everything I need works great. Updates are so frequent. Attention to details regarded to security is amazing. My favorite mobile OS.
We need an Euroepean vendor or organ or consortium taking up Android or Graphene or whatever and stamping a cert on phones allowed to run bank apps, after which banks (etc) have to support those phones. And/Or having to offer all functionality in the app(s) also in mobile web, but having users who want to use that requiring an OTP (or so) hardware token. I would be in favour of having the latter no matter what; no I can do this with my bank, but it doesn't offer the same as the mobile app and the site is not mobile optimised either.
Break free from Android... by installing Android? 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.
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 the 50% of banking apps still wont work because it wants an android signed by google.
And no tap to pay.
Hopefully the new EU banking system will work on Graphene and Ill switch back
I would put the focus on having capable web-banking. I never install the banking app on my phone.
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)?
Agreed about NFC, I'm happy to scan a QR code.
> 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.
> Card is usually linked to the US. Some people would like to not depend on that.
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.
> And the 50% of banking apps still wont work because it wants an android signed by google.
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 :-).
The new payment networks are not an independent app. They are a protocol your banking app has to implement, so unless your bank supports non-Google phones you are out of luck (not my case, thankfully).
[dead]
I tried Ubuntu Touch and Droidian
https://blog.tomaszdunia.pl/ubuntu-touch-eng/
https://blog.tomaszdunia.pl/droidian-eng/
You're confused. GrapheneOS is not Android, it's an AOSP-based OS.
> 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.
What is the difference here between "Android" and "AOSP" (Android Open Source Project)?
AOSP is Android without the Google proprietary stuff (and without the manufacturer proprietary stuff, e.g. Samsung's). If you install bare AOSP, it will look like the Android on a Pixel phone, but the biggest difference you will see is that it won't have the Play Services or some Google apps.
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 :-).
You're confused.
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.
Just like Linux can mean "the Linux kernel" or "a Linux distribution" in "common use of the terms", Android can mean "a device that can legally be advertised using the Android trademark" or "whatever looks like Android to people".
Now when someone says "Break free from Android... by installing Android?", either they are having fun by using the two different meanings in the same sentence, or they are confused and genuinely believe that using GrapheneOS does not allow you to break free from the system running on a device that can legally be advertised using the Android trademark.
To that, I answer that GrapheneOS is not a system that can legally be advertised using the Android trademark, but rather a system that is based on what is commonly (and can legally be) called AOSP, which is made of the open source codebase that builds the system that can legally be advertised as Android.
Similarly, in a discussion about kernels, Android is a Linux system, but in a discussion about OSes, Android is not a Linux system. If I write an article about "breaking free from Linux by using Android", where the context makes it exceedingly clear that I'm talking about Linux as an OS and not Linux as a kernel, and you say "it makes no sense, you're talking about breaking free from Linux by installing... Linux", then I think you're confused. As in: you did not understand what the article was talking about.
You're vigorously defending a poorly thought out title by inventing irrelevant contexts and falsely accusing multiple people of being wrong because they claimed such uncontroversial things like "AOSP is Android". Sure, if we want to be strictly correct then AOSP is not Android, but rather the name of a Google project that distributes the source code of Android - but that's not how the term is commonly used in these discussions nor how you used it either.
What people objected to is the concept of "breaking free from Android" by using a distribution of Google-developed Android. Interpreting the title as "break free from flavors of Android that can use the Google's trademark in their marketing; here's one that can't" is just ridiculous and not what anyone will think about when reading it. The current one ("break free from Google") is still objectionable, but slightly less since one could perhaps make a somewhat correct point that relying on Google-developed codebase that's soft-forked by someone else actually is significant enough step away from using something that comes straight from Google and tightly integrates with their proprietary services. It's still quite obviously hyperbolic, especially when actual non-Android alternatives also exist.
> Sure, if we want to be strictly correct then AOSP is not Android, but rather the name of a Google project that distributes the source code of Android
Thank you.
I do find it ironic that you could not understand what I mean given that you're the kind of people who say "GNU/Linux".
This means GOS is not AOSP either, because it's not that particular project. It takes the Android source produced by AOSP and builds on it. But what you agreed to is just pointless pedantry that leads directly to this outcome, as everyone uses "AOSP" to refer to what AOSP produces (which is a particular flavor of Android that serves as a base to build other flavors on).
It stops being ironic when you take some time to understand that the two cases only appear related superficially, but are actually quite different. You could even say opposite.
> This means GOS is not AOSP either, because it's not that particular project.
Exactly, GrapheneOS is not AOSP. It is AOSP-based.
Many are complaining about banking app compatability, but I've never felt compelled to use anything other than my browser for banking. What's the big deal with the banking apps? Am missing out on some huge advantage here?
Some banks force you to validate transfers on your phone; unfortunately its not the user who decides
Depositing checks by taking a picture of them.
If I knew what a cheque even looks like, that might be a benefit
I don't think that comes across how you intend.
That being?
FYI: Google Fi + GrapheneOS doesn't work. My son recently tried setting up GrapheneOS and got everything working but couldn't get connected to Google Fi to work, even with a SIM card.
It works but you need to install the Google Fi app from the Google Play Store.
How does this break free from Google? Isn't the Android that Google themselves writes and maintains the upstream of Graphene? Are they going to disconnect completely from upstream Android or something?
The article directly answers your questions, specifically in the “what is GrapheneOS?” section.
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.”
I've been using it for more than 2 years, and I can't think of ever going back to a stock OS. I had to send my phone for a screen repair, in the meantime I picked up my old Samsung, and the sheer amount of apps I didn't want, notifications and dark patterns to tricking me into handing over my data made me anxious. I couldn't finish setting the phone up and drove to my parent's home to pick up their old, remotely nerfed by Google, Pixel 4a so I could install GrapheneOS into it and use it while I waited for my repaired Pixel 8.
Same. Not only has using it been no trouble, but having a barebones core app selection, a few picks from F-Droid, and using the browser for the rest makes my phone feel refreshingly under my control. It lasts for 3-4 days of low usage to boot, when nothing is phoning home constantly.
~6 months here. In my case, it became almost a full daily driver ( putting corporate spyware on it would kinda defeat the purpose ). It is by no means perfect, but I can recommend it ( and I could not do the same with other phones that should have been better on paper -- linux phones like pinephone or purism ).
Do they just not have ANY screenshots of the OS anywhere on the web site
It is just Android. If you're familiar with the usual Material styling of Android, you're familiar with what Graphene looks like.
If they'd put a screenshot, that would then have been immediately clear to casual visitors.
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.
It looks about the same as stock android.
It's weird that here on HN some people are trying to break free from Google and Apple and on the other side some people are married to Gemini, and both look like to be the majority at times.
I had a Pixel 6a with Graphene OS for a year before the phone started to glitch and eventually die. It ran pretty hot; sometimes it was hard to even hold the phone in my hands without burning myself.
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.
> I had a Pixel 6a with Graphene OS for a year before the phone started to glitch and eventually die. It ran pretty hot; sometimes it was hard to even hold the phone in my hands without burning myself.
This sounds like your phone may have been one of the Pixel 6a models with a defective battery[1]. It was a major problem for which Google pushed out an update that nerfed the battery life. There is a tool online where you can check if your particular 6a was one with a battery from the bad production batch[2].
But that unfortunately doesn't help if you are in Brazil where, as you say, Pixels aren't officially sold and import/export controls tend to make tech warranties useless in practice.
[1] https://www.lifewire.com/pixel-6a-battery-overheating-warnin...
[2] https://support.google.com/pixelphone/answer/16340779?hl=en
Yeah Pixels are poor quality. Mine developed the common pink vertical line display issue after 18 months
The flag ship should not be more than $500
> The flag ship should not be more than $500
Which is (almost) the case during sales. The P10 was on sale for $599 not long ago, and you could buy a 9a for little more than $300. That is extremely good value compared to any iThing repoted your every move to Apple.
$600 to last 18 months? Disagree
Switched a couple of weeks ago and works perfectly. I also found so many better apps that dont steal your data for basic stuff like weather, notes, messaging,...
Break free from Google by paying money to Google for a Pixel phone? Even with a used Pixel, you're helping prop up their used market value which helps Google
You could buy a used Pixel. Also, they are working with a partner to create their own phone hardware.
This statement implies ignorance to the reasons the project selected Pixel devices.
How are the cameras on the latest devices running GrapheneOS? My last Android experience was the Oneplus One and the experience left me with the feeling that cameras are just too proprietary to work well once you go tinkering with custom ROMs and camera apps.
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.
GrapheneOS has the same camera features and quality as the stock Pixel OS within the same apps. You can use Pixel Camera on GrapheneOS even without sandboxed Google Play in the same profile if you want the full feature set. If you want extremely good cameras, the Pixel 10 Pro and Pixel 10 Pro XL are the best choices. Those provide the highest quality image sensors among the available supported devices and the Pro mode in Pixel Camera. See https://www.dxomark.com/smartphones/ for how those compare to other devices. Our own Camera app will be heavily overhauled to narrow the gap more with the Pixel Camera app but you can already use that especially if you care a lot about this.
GrapheneOS only works on Pixel devices so it only targets a very limited set of Android camera hardware.
You can run the proprietary Pixel camera software on GrapheneOS just fine (properly sandboxed).
The biggest hold-back for me is that, here in Australia, Google Wallet (aka Google Pay) is the only way you can do tap credit card payments that I know of. Can't with Paypal. Not with any banking apps that I know of.
It's just so damned convenient. And the recording of transactions on the phone saves me having to collect paper receipts.
If you want to fight back‚ let convenience take the back seat.
"Break free from Google ..." by purchasing Google hardware and using [software "based on"] Google software
Is it really "breaking free" from a company if the method of "breaking free" requires continued cooperation from the company
This is not to suggest using a modified version of Android isn't useful. This comment is not about GrapheneOS. (But there will be HN replies that will try to redirect focus to it anyway.) This comment is about claiming it's possible to "break free" from something while still remaining inextricably tied to it
In addition to using a custom ROM, there are methods of stopping the Pixel's attempts to "phone home" to the company that work even with the version of Android pre-installed by the company intact. However if a method requires software, e.g., drivers, or is "based on" software controlled by the company, then ultimately the company holds the cards. IMHO, this is not what it means to "break free"
Perhaps the most reliable method of stopping these connections to the company is one that does not rely on cooperation by the company. This is because if the company decides to stop cooperating, the method still works
Your "perfect" is a massive enemy of the "good" that is GrapheneOS compared to using stock Android.
They are working with a partner to create their own hardware to run GrapheneOS on.
What is the smallest phone that Graphene will run on? I would love to switch but these massive pixel phones are a no go for me.
From a quick look online it may be the Pixel 8 https://www.gsmarena.com/google_pixel_8-12546.php at 150.5 x 70.8 x 8.9 mm based on recommended devices.
Maybe an old Pixel with an old version of GrapheneOS, but at that point you're losing most of the security benefits and, depending on your goals, you may be better served with a small phone running a different OS
After reading this blog post, going to grapheneos's site, and browsing a half-dozen or so pages that I thought might show me what it looked like... I cannot find a single image of it.
GrapheneOS team, I'm begging you... Hire or recruit one person with advertising or copy-for-public-consumption experience. Just one.
Answered 2h ago before your comment: https://news.ycombinator.com/item?id=47047720
Saving a click, it looks like any bare Android without vendor customisations. You just get extra settings like turning off network per app
I don't disagree that some screenshots might be good marketing
> Break free from Google and Apple
Step 1: Buy a Google phone
They are working with a partner to get their own phone hardware.
GrapheneOS is Android isn't it? Same binary blob issues and such? Or is that not an issue on Pixel devices?
It is not. GrapheneOS is AOSP-based.
But yeah, same binary blob issues for firmwares, but Linux on Mobile has the same issues.
It's not very important but what are you referring to with "it is not" ? AOSP is Android (it's in the name) so I don't get it. Are you talking about blobs re Pixel devices?
No, I really meant that AOSP is not Android. Android builds on top of AOSP. I elaborated here: https://news.ycombinator.com/item?id=47047167
Well. I do get your point and I am aware of the situation and how Google pivoted away from a truly open source OS by systematically moving components like the keyboard to separate closed source apps. The fact remains though that it's Android Open Source Project where all Android systems are based on. It's become sort of a GNU/Linux kind of distinction where the "certified" Android is AOSP + Google. Though the situation is not that clear because there are other Android based phones that do not contain the Google layer but are still Android.
> Though the situation is not that clear because there are other Android based phones that do not contain the Google layer but are still Android.
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.
Yeah, it is.
Google is so much engrained in our lives that we can't really break free. You can't just don't use youtube and for that you need a google account.These projects are nice and good for tinkering, but can't use this as a dialy driver.
GrapheneOS is very usable as a daily driver. Nearly every Android app can be used on it and there's a huge ecosystem of open source Android apps. You should read the whole linked article which explains in depth how someone new to using it set up their device. They chose a certain way of doing it to balance their priorities. Only a tiny portion of apps can't be used on GrapheneOS which are mostly a subset of around 15% of banking apps which ban using a non-Google-certified OS in a way we can't easily work around. Most banking apps do work and extremely very other apps are unavailable. Google apps and services aren't used by GrapheneOS by default but can be installed as regular sandboxed apps.
You don't need a Google account to use YouTube and can use it via the browser, NewPipe or several other alternatives rather than their app.
The linked article covers someone's first experience with it with a lot of detail. They're using it as their daily driver with mainly open source apps and separate profiles with mainstream apps they still need. They're using those with much better privacy protections including having sandboxed Google Play in those profiles for using mainstream apps rather than regular highly privileged Google Play heavily integrated into the OS and not running with the standard app sandbox or privileges.
Why do I need a Google account for Youtube? It seems I can watch nearly any video I want without logging in. Moreover there are anonymity proxies like Invidious.
As someone who doesn't have a Google account, I can use YouTube just fine on my GrapheneOS phone using apps like NewPipe.
Like others have said, you can use Youtube without Google account. Moreover, you can give Google the middle finger by using uBlock Origin or viewing though a third party client like VacuumTube. Also don't forget the shorts filter recently featured on HN to remove those annoying portrait format videos.
Some privacy settings for GrapheneOS:
https://inteltechniques.com/blog/2026/01/05/grapheneos-2026-...
The article is a wall of text with not a single screenshot.
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)
GrapheneOS is based on the latest release of the Android Open Source Project (AOSP) which is Android 16 QPR2. It looks nearly the same as the stock Pixel OS also based on the same AOSP release. The main UI differences are user-facing portions of the many privacy and security features added by GrapheneOS. There are minor differences such as the stock Pixel OS having a few different fonts than AOSP. The main thing to show would be the UI for features such as Contact Scopes, Storage Scopes, per-app exploit protection controls, etc. It looks like the stock Pixel OS without the Google app/service integration not present in AOSP with added privacy and security controls.
There are many useful videos about GrapheneOS here:
https://www.youtube.com/@sideofburritos/videos
Any of the videos older than December 2025 will be prior to Android 16 QPR2 so the overall UI will be outdated. That's part of why we don't focus on screenshots or videos because many would need to get updated every 4 months. We'd mainly be using them for our own features which often improve more frequently than that.
There's several AOSP based ROMs in forums like xda. Mostly developed by enthusiasts.
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?
This is a production grade OS, it's made by professionals, it's not hobbyist. It keeps up with updates of upstream Android and Linux kernel. It has a ton of good security and privacy features.
This is the phone version of saying “the power utility is an evil awful monopoly that treats me like shit, so I’m gonna get solar and batteries and go off grid.”
It’s cool it’s possible, but it’s not practical for most people.
What do you think the major practical downsides are? Maybe you are not aware of how many things perfectly work or how easy some workaround are, so I am wondering.
Using Brave (Chromium based software) is a strange choice from privacy oriented person imo...
GrapheneOS needs at least the modem blob provided by the OEM. It runs as root, it has full network control. Same could go for other "drivers" like wifi+bluetooth.
Privacy is more a dream than a real thing.
No, that's a misconception. GrapheneOS has only ever supported devices where the cellular radio is isolated from the OS and unprivileged. It does not have access to memory it hasn't been permitted to access by GrapheneOS. Wi-Fi, Bluetooth, NFC, UWB, etc. are isolated components too. Our hardware requirements are listed in our FAQ and require proper isolation for radios:
https://grapheneos.org/faq#future-devices
8th, 9th and 10th gen Pixels provide our full set of requirements with 7 years of support from launch. 6th and 7th gen Pixels are missing the ARMv9 security features including the extremely important hardware memory tagging (MTE) feature we heavily use to protect against exploitation. Even the first devices we supported back in 2014 including the Nexus 5 had isolation for the cellular radio but similar isolation for Wi-Fi/Bluetooth started with the Nexus 5X.
They are working on getting their own hardware.
I've been using GOS for 3years give or take on a Pixel 7 PRO. Yes, GOS also stops you from buying new phone every year and personally, I am hopping Pixel 10 PRO is worth the upgrade, doubt it.
In Australia, everything works, from banking to gov services, they do not block or have limited function. CommBank App supports NFC payment via its app for example.
Dual profiles is silly and utterly unnecessary.
List of my open-source applications:
- Aurora Store: Should be avoided, it like F-Droid have broken security in place. You have a high risk of installing crappy on your phone via those stores. That is why I still use Google Play and download apk once here in there from GitHub project.
- Organic Maps: Dead project, a lot of things have happened and that is why CoMaps was created/forked. It is a beautiful and mega lightweight offline GPS map with tons of features.
CoMaps replaced Earth Magic that got completely destroyed to greedy, and Sygic which I have an old lifetime premium license which now is somewhat limited unless you pay for premium plus :)
OP didn't mentioned but GOS + Android Auto works like a dream wirelessly, GOS provided is Google-free dependency version and it just works.
Does anyone have an answer to the problem of an OS for a laptop? I'm thinking about strong security here, less so about privacy (which is doable, for example via a Linux distribution).
ChromeOS (most secure OS), MacOS (most secure firmware and still much more secure OS compared to non-ChromeOS competitors)
Graphene is very attractive, the two things that prevent me from going are a) using your phone as a credit card, I'm too attached to that now. b) work profile does not work with rooted phones
There are multiple options for tap-to-pay on GrapheneOS in the UK and European Economic Area. It depends on where you are.
GrapheneOS isn't rooted. Did you mean that your corporate MDM app doesn't run on non-certified OSes?
Is there a great phone with high end specs this runs on?
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.
You can use GrapheneOS with the Google Pixel lineup, or in particular the Pixel 10 Pro XL [1].
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...
What if I don't want to give money to Google at all?
Then GrapheneOS is currently not an option, however they are working with another OEM to have non-Google phones available with GrapheneOS by next year [1].
[1] https://grapheneos.social/@GrapheneOS/115987006592879172
Ok that is great news, thanks for sharing.
I had to replace my old phone a few months back and I went with a used Pixel 8 pro from Backmarket specifically so I could try GrapheneOS. I'll never go back if I can help it. I love this OS.
I want to break free - Queen :)
Lyrics https://genius.com/Queen-i-want-to-break-free-lyrics
It's a sign of how far we've come that this article says "Break Free from Google and Apple", not "Break Free from Google, Apple and Microsoft".
People seem to fondly remember the Microsoft phones. If they made them now though, I can't really imagine what sort of Copilot-filled abomination they would be.
Yeah that's not actually good. As much as I'd never use anything from Microsoft, having less diversity is not a step in the right direction.
I heard that Windows on phones is about to make a return later this year, thanks to NexPhone.
I use this and lineage, but in a few years time this could be moot if Google decides to completely lock down devices. That leaves commercial options like Fairphone
Fairphone is far from meeting the update and security requirements for GrapheneOS. It isn't a viable platform for a hardened OS to use and isn't likely to ever become one due to security being very far from a priority for them.
GrapheneOS has a partnership with one of the largest Android OEMs. They're going to be announcing it in March 2026. Devices meeting all of the update and security requirements from them with official GrapheneOS support are planned for 2027. We don't expect future Pixels to prevent installing GrapheneOS but we'll be fine if they do. We'd still like to keep supporting new Pixels but they'll become a secondary option in the future since there will be devices with official support.
That OEM has yet to be named. It would be nice to see it happen, but it's yet to materialize.
> It isn't a viable platform for a hardened OS
Breaking from google/Apple doesn't in itself require a hardened OS, as we see in LineageOS.
Our OEM partner is announcing the partnership in March 2026. It's an active partnership with work under way for devices launching in 2027.
If you are using social media, you might get a shadowban, just because you needed to unlock your bootloader to install this OS.
the OS is great, but too risky in certain situations.
i use social media and have never gotten a shadowban. to the contrary grapheneos actually is very effective against apps like reddit shadowbanning you - if you get banned outright on reddit, for example, you can create a new profile in private space and reddit will not be able to detect that you're ban evading.
if you get banned from the profile u use in the app in private space, again, if you just delete private space and recreate it, download the reddit app again, it will be unable to detect that you're evading the ban. i previously tried doing this on other os's and reddit detected the ban evasion.
don't ask me how i know. (just correcting this misinfo)
you're correcting nothing, my business revolves around evading these kind of checks especially on mobile apps. TikTok, for example, it is very aggressive. If you have something different than stock ROM, your reach will be greatly diminished.
There's a little bit information here [0].
[0]:https://discuss.grapheneos.org/d/18118-play-integrity-meets-...
Try a social media that is not antisocial. HN, Mastodon, Tildes, various forums... lots of communities and tech content are available in browsers or via open source apps
I'm not aware of any that bans you when not using an allowlisted OS, so maybe it was something else that caused this shadowban, or (more likely) that's just my bubble
This is so well-written with obvious care! Answers so much of what I've been wanting to know, as someone who's thinking about taking this plunge.
They should get the same level of financing (donations) as Tor project at least. Some big organization like Open Technology Fund or NLnet should give them yearly grants.
900+ donors on github (https://grapheneos.org/donate#github) is not *too* bad, but likely not enough to cover a full salary.
GrapheneOS is like using Firefox. Works on most sites, but those few things just don’t. Maybe it’s a dealbreaker for some. And they’re dependent on Google.
Break free from Google*. As long as you buy a Google phone. I really want to use it, but the Pixel only requirement is a deal breaker
They are working with a partner to get their own phone hardware.
You could also buy a used Pixel.
As great as GrapheneOS has been, I'm still tempted to switch to LineageOS. Sure, it would be objectively less secure, but at least then I might be able to disable the obnoxious "automatically disabled 3 unused background apps" notifications.
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?
> Even if it improves accessibility, it must be rejected out of hand
GrapheneOS has many exploit mitigations and those that would break compatability with too much apps are opt-in instead of opt-out. They also have per app toggles so you can decide to use them per app. So they certainly don't sacrifice accessibility for the highest level of security.
> GrapheneOS promises to liberate us from the enshittification of Google's anticompetitive moat
This isn't something GrapheneOS promises anywhere on their website. They aim to offer a secure and private OS with good compatability with Android apps.
> but it focuses that effort exclusively on security.
They focus on privacy and usability as well. Security is actually only focused on because the privacy features aren't enforceable without security.
> Why is that constantly treated as an unreasonable fantasy?
Because tinkering, hackability and unrestricted freedom aren't the purposes for which GrapheneOS was made.
It's good enough for you, and therefore it can't get any better. Interrupting the user with pointless notifications is not security. Removing the ability to disable those notifications is only a security feature if the user wants then in the first place!
The problem here is more than the lack of interest in making a system that is both secure and usable. It's the outright rejection of usability as a goal.
Unless govts make web a primary citizen of information dissemination and acceptance, it will be only apple/google on the sim card linked access
It's very annoying that they restrict themselves to Pixels. I get they can't guarantee all the security features they want on other phones, but even a subset of those security features and the other advantages like the lack of cruft would make it very attractive to be able to run on other phones.
I can understand the frustration, but it wouldn't be right to say they 'restrict themselves to Pixels'. They believe strongly in a standard for privacy/security of people's personal devices, and unfortunately only Pixels are close to meeting those standards. It's not even like Pixels are their ideal device.
I feel the frustration should be targeted at OEMs that don't meet very reasonable requirements like minimum 5 years of monthly (timely) security updates.
> I can understand the frustration
It's not frustration, just disapproval.
> but it wouldn't be right to say they 'restrict themselves to Pixels'.
It's absolutely right to say that. You justify why in your next sentence.
> They believe strongly in a standard for privacy/security of people's personal devices, and unfortunately only Pixels are close to meeting those standards.
That doesn't prohibit them from releasing a version that runs on other phones, even if it's missing a few (and it would only be very few) features. Most of the graphene users are not using it because of those features.
> I feel the frustration should be targeted at OEMs that don't meet very reasonable requirements like minimum 5 years of monthly (timely) security updates.
Again, though, no frustration; I wouldn't run graphene even if I could as I have my own setup I'm quite happy with. Just disapproval at an arbitrarily high standard that isn't doing the good they think it is, and ultimately, actually does more harm in not making their product accessible to the hundreds of thousands of people it would benefit.
They are working with a partner to get their own phone hardware, hopefully by next year.
Has anyone tried monitoring traffic from this ROM and see whether their claim of having minimal analytics and booseted privacy is true?
https://www.kuketz-blog.de/grapheneos-der-goldstandard-unter...
Let’s just say, it took a while for the Stingray to get in while moving at 70mph. But it got in when it’s 0mph
Why is it that Google find my doesn’t work? I can’t get it running on my pixel, seems like a known issue.
Anyone like GrapheneOS better? Like it has some features? Or is it a locked down version of Android?
I love the ability to block apps from accessing the network. There is no reason apps like the keyboard, camera, or other offline apps and games need access to the internet.
Why only pixel phones are supported?
Because phones have device-specific code. Effectively, each single model is running its own fork of Android. Naturally, Google has no incentive to change this - it makes it difficult to update (planned obsolescence) and install other software (like GrapheneOS).
Because google actually cares about hardware and software security. Read the FAQ: https://grapheneos.org/faq#supported-devices
>Because google actually cares about hardware and software security.
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.
There is a difference between security and privacy or freedom of use. Locking down the device to only allow a subset of apps that Google has some control over (by requiring developers to register) is a measure that can increase security, even though it obviously takes some control away from the end-user.
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.
That's not at all what Google announced.
It has nothing to do with devices. It has to do with OSes, most notably OSes certified by Google, which GrapheneOS isn't.
Also, it will be possible to bypass it even on certified OSes.
Don't mix security and freedom. They're commonly opposed to each other.
This is true, I don't get the downvotes.
I believe (as it's open source) there is nothing impeding anybody else to compile grapheneOS in a samsung S10, which would not be as secure, but should still work as any lineage
However I haven't seen anybody try
They are working with a partner to get their own phone hardware, hopefully by next year.
Hah, just talked with my colleague, his feedback is that it’s too raw to be used daily
You might want to reconsider trusting your colleague's technical opinions.
If you're tech-literate enough to find the bootloader unlock, I find that a strange statement. Could $colleague be anymore specific?
Breaking free from Google by using a Google phone with a Google designed processor
They are working with a partner to get their own phone hardware, hopefully by next year.
I really doubt they have an issue tracking you despite all this added effort.
Don't let perfect be the enemy of good.
My observation is - It is the ecosystem that is sticky not just the OS.
You can install Google Apps as a regular set of user apps rather than a system-level admin monstrosity, and it mostly works - Play Store included.
Whether or not that defeats the purpose is an exercise left to the reader.
You're not the first to notice! It's called the network effect
is it worth to buy google pixel just for installing grapheneos? in my country, it is kinda pricey and of course it cannot install bank apps because almost all of them are must non root phone.
Break free from Google by buying their hardware and be dependant on them to actively support the device. Things are absurd at this stage. I guess there is different motivations behind mobile OSes.
"Break free from Google," is not GrapheneOS's motivation, just so people are aware. That is the blog writer's motivation.
I need to try this out.
> Break free from Google
Looks inside.
Only Google phones are supported.
Curtain drops ...
What you want is a solar 6502 with lots of memory and GMRS mesh
If Apple partners with Starlink, this is my next mobile OS
So you were happy in your orchard/garden but then plenti arrived offering the forbidden fruit; android. This is the slippery slope that led us here, open rebellion against the tech patriarchy
Combine it with OnemanBSD to be really FREE. Lookhere: https://www.youtube.com/watch?v=2wHaoQhXOYY
Citibank app does not work in GrapheneOS
I can't take this seriously when their mission statement is to "break free from Google and Apple" and their entire output is a fork of a Google repo.
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.
You'd be pleased to hear, then, that "break free from Google and Apple" is not Graphene's mission statement, because this is a blog.
i don't understand your issue - using grapheneos does allow you to break free from google in the sense that you have an android OS that works well, is secure and private, and gives you the choice to use google or not. if you choose to use play store/services, they run as sandboxed, unprivileged applications like every other app. on samsung/stock pixels etc, play services is a privileged component of the os and you can't avoid this. grapheneos gives you the freedom to break free from it in this sense.
soon enough grapheneos will be available on non-pixel devices, but if you really have, say, a philosophical problem with using google devices, get a used 2nd hand pixel. or wait til the oem partnership announcement.
For some (and other not-so) obvious reasons I switched to Graphene a few weeks ago. For years I've been pushing towards de-cloudifying my digital life and there were several reasons for it: On one hand it was the constant content subscription which gave me 0 guarantees that what I am interested in will still be available the next morning, even though I've paid for it, and the other was, you guessed it, the idiotic LLMs everywhere and subsequently the complete annihilation of security practices by giving a probabilistic model unrestricted access to all of your data.
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.
You can use a different keyboard than the default AOSP keyboard with more modern features including but not limited to swipe typing. We plan to replace AOSP keyboard with a fork of a more modern app but there isn't yet one meeting the functionality requirements which is under a license we can use. FlorisBoard is what we have plans to eventually use, although it might not be what we end up using.
Check out FUTO Keyboard, It has swipe-typing feature.
FUTO has many issues, beyond licensing like it's lack of privacy features.
Am I the only one who finds monospace font barely readable for articles? Good for code, bad for longer forms of text.
No, I also click away articles in that font style if it's not exceptionally interesting or relevant to me
In this case, reader mode fixes it (your browser probably has a button built in)
I always forget about it, thanks for the tip.
"Break free from Google"
All supported devices are exclusively Pixels.
They are working with a partner to get their own phone hardware, hopefully by next year.
A lot like Linux zealots people say a lot of things along these lines:
“It’s perfect. I love it. It works great. No complaints” and then go on to list 100 rough edges that mainstream phone OS users never have any issues with. It’s funny.
[dead]
[dead]
If you're willing to invest in a smartwatch principally as a secure payment appliance, tap-to-pay with Garmin Pay works when configured on Graphene OS, and most Garmin Smartwatches will happily stay in airplane mode for months once configured.
AFAICT, Garmin Pay works like Apple Pay, meaning (unlike Google Pay) no network connection is required.
[dead]
[dead]
[dead]
https://news.ycombinator.com/item?id=40667147
Apple's OSes do not include an Application Firewall that allows you to control which app can access the internet. Graphene OS does.
[dead]
Break free from Google and Apple by buying a phone from Google /s
I commented elsewhere but GrapheneOS on Pixels actively siphon resources from Google and is arguably a good protest against google.
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).
How about they start supporting more devices instead?
You should probably be asking Android OEMs why the requirements listed here https://grapheneos.org/faq#future-devices are unreasonable.
There are currently no other devices meeting the update and security requirements. GrapheneOS is partnered with a major Android OEM working on making devices meeting all of those requirements along with providing official GrapheneOS support. The devices are planned for 2027 but is being announced by the OEM in March 2026 so people will know which OEM it is soon.
Good news they are making their own devices. But until then pixels are technically the most secure android devices and graphene would not be as robust on other devices.
Small correction, GrapheneOS are not making them. They are partnering with an existing large OEM to ensure one or a number of future flagship devices meets their security, privacy and support requirements.
No, there are no such news yet, only hearsay.
It has been officially stated that GrapheneOS is partnered with a major Android OEM working on making devices meeting all of those requirements along with providing official GrapheneOS support. The devices are planned for 2027 but is being announced by the OEM in March 2026 so people will know which OEM it is soon.
[dead]
[flagged]