hckrnws

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.

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.

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.

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.

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.

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.

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

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.

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

> 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

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

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.

Starling Bank has been officially supporting GrapheneOS using Android's hardware attestation API (not the Play Integrity API) since 2024.

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)

But Starling has always been app only?

It's not possible to login to the web-based banking without the app. It's a hard requirement to access the account.

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.

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!

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!

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.

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

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.

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

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

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

> 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

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

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.

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/

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

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.

  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

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

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.

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.

Öffi, if it has coverage for the areas relevant to you: https://oeffi.schildbach.de/index.html

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

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.

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

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.

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

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

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

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.

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

You pass basic, but not device or strong integrity. This is purely googles fault and is an artificial limitation that requires regulatory restrictions.

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.

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

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

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.

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

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

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.

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.

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?

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

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…)

You can have a second or third VPN active if you use a work profile and private space

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?

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.

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.

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.

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.

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.

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.

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.

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.

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

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?

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.

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?

Last time I checked you could still book a ride using the website.

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

>there was one case that lead me to thinking about ditching grapheneos to this day

Your aim is misplaced: ditch Uber, not GrapheneOS.

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.

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

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.

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 :-).

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

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.

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

Google makes high quality hardware and untrustworthy software. Graphene's approach is to take the hardware and leave the software.

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.

> 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!

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.

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.

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.

That and blocking the query all apps feature on android

> 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

To make things worse it needs a google phone, of all things.

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.

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.

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.

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.

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.

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.

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.

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.

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 critic against him as "projects driving a campaign against GOS". And the Graphene followers believe him. It's absurd.

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

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

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

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

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.

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

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

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

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

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.

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.

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

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.

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]

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.

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.

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