If you care about your actually owning your device, install something else than stock OS. I would recommend GrapheneOS, since the security of some/most other alternatives is pretty bad.

So, you have to wonder whether you want such a phone anyway if you care about security and privacy. If you don't care about security anyway, you could as well run /e/OS, etc.

Above-mentioned Samsung phones could perhaps make the cut, but don't support unlocking anymore (and when they still did, would blow a Knox eFuse).

I get all or nothing when your threat model is state actors. However, for most people, the benefit is just freedom from corporate agendas.

Not everyone needs kernel hardening, or always E2EE (as with signal). Personally I just like the features it provides (e.g. scoped storage, disabling any app including Google play services, profiles etc etc

Its also an easier sell to people who are apathetic to security when the product is just better and more secure, the same way apple does (for whatever their reasons may be).

All that said, I get they're limited in funds and manpower, plus the things mentioned at the end there, so I can only be so peeved they chose a target and stuck with it. They typically cite security as the reason, not those other ones, however.

   org.thoughtcrime.securesms

I'll only use it for the specified purpose since I far prefer my own XMPP server with OMEMO encryption - which is based on the same 'double ratchet' keying as Signal uses.

Security is one of one of the main selling points of GrapheneOS, I can fully understand that they don't want to weaken that by supporting fundamentally insecure devices.

I think a nice side-effect is that they only focus on a small number of devices (Pixels) and support those really well. I have followed the /e/OS forums for a while and many devices have constant regressions because it is hard to validate each release on tens of devices.

I get all or nothing when your threat model is state actors.

People do have different thread models, though I think up-to-date software should be the baseline for everyone and where pretty much every phone outside iPhone, Google Pixel, and a subset of Samsung phones fail. Also, I think having a secure enclave should be the baseline, since phones do get stolen.

Its also an easier sell to people who are apathetic to security when the product is just better and more secure, the same way apple does

That's really a weird example though for supporting the argument that GrapheneOS should support more devices. Isn't Pixel + GrapheneOS then pretty much iPhone + iOS? Privacy-respecting, secure, not pushing AI subscriptions all the time (though iOS is getting worse in that respect), offering useful functionality?

At any rate, I understand if you have another phone, you wouldn't buy a Pixel for GrapheneOS, but it does make sense to buy your next phone for running GrapheneOS. Pixel covers a pretty wide price range to, e.g. the Pixel 9a was 349 Euro here recently, all the way up to the Pixel fold.

Except that there is nothing fundamentally insecure about them, they just don't support a specific convenience feature. You can straightforwardly support PIN-based unlocking by encrypting the PIN in ordinary persistent storage using a longer passphrase that only has to be entered during boot.

This is arguably even more secure because it allows the PIN to be dumped from active memory and require the longer passphrase again after a timeout, a limited number of bad attempts or in response to a panic button on the lock screen. Then the device doesn't contain the long passphrase whatsoever, instead of having it permanently stored inside of an opaque enclave that itself could (and often does!) have its own vulnerabilities.

The problem for those of us in the USA, that labels anyone who disagrees with the current administration and ICE as a domestic terrorist, means that now everyone's threat model is a state actor.

The threat model of every citizen that dares to exercise their first amendment rights now escalated beyond corporate agendas to "How do I make sure Israeli & Palantir spyware doesn't end up on my phone? How do I make sure if my phone does get confiscated, Cellebrite can't image it or access the data?"

Even if that weren't the case, I see no valid reason to be lax with security in 2026. There's no excuse anymore, I mean we still have OEMs selling phones that they do not issue security updates for after purchase. That's just gross negligence.

In this context one super-nice feature of GrapheneOS (do check the legal ramifications though, IANAL) is that it supports a duress PIN. It's an alternative PIN that immediately erases your phone (probably throws away your FDE keys?) and clears your eSIM.

Besides that, it also supports configurable time to reboot after no unlocks. This is relevant because it is typically much harder to exfiltrate data BFU (before first unlock) than after. iPhone also supports this, but only does it after I think 3 or 4 days. On GrapheneOS, this can be set as short as 10 minutes when there is a risk of your phone getting confiscated. Of course, you can also manually reboot, but that's not possible in every situation.

If application processors and hardware crypto accelerators are good enough to make this invisible to the end user, then why not? Why not have everyone be on hardened kernels by default and let them opt-in to insecure ones instead of the other way around?

That's also an unfair take when one considers how many improvements they've upstreamed to AOSP and how many quality of life features they've implemented.

This seems like a bad reason for not supporting a device. If the device doesn't have a hardware feature then the OS it came with can't be doing it either, and then all you're doing is leaving the user with all of the other security problems in the OEM OS that otherwise could have been improved by replacing it.

We need the people who buy $100 phones to have the ability to put a better OS on them than the burning mudslide that comes with them, is all I'm saying.

Without having an kind of authoritative knowledge or experience on the topic, those people are wrong and please ignore them. The argument has generally been that if you are specifically after privacy and security in your personal device then GrapheneOS or post-MIE iOS will be your most sensible choices. You CAN choose devices for other reasons, as has always been your prerogative.

The question of whether to support 'alternatives' is fraught. It used to be that there were two other OS projects that happened to be collaborating and adopting features from GrapheneOS and that would have been reasonable. The main argument (from GrapheneOS) in that case has been for people to please invest in alternatives with approaches to privacy and security that stand up to threat-model driven design and real world attacker/defender experience.

GrapheneOS was never meant to be alone in pushing for things like hardened secure element-based protection of secrets and side-channel resistant rate-limiting of unlock attempts, memory tagging/hardened memory allocators/secure application spawning/dynamic code loading control, anti-persistence hardening, prompt security patching, network/sensor permissions, contact/storage scopes, PIN scrambling, auto reboot etc. Unfortunately very few other projects that I am aware of are looking into doing things like this to give the device owner control and mastery over their data.

>and now that GrapheneOS isn't for everyone and anyone -- the majority of people -- without a specific narrow selection of hardware should get lost.

GrapheneOS tries to make most of their hardening transparent and non-intrusive by default. They also spend a lot of time and resources working on usability (sandboxed-Google-play and the web installer) and now accessibility (upcoming text-to-speech implementation?). The idea is that if you have a Pixel and choose to use GrapheneOS then it should be as easy to use as they can manage without compromising their efforts improving privacy/security. In that sense, GrapheneOS is for anyone and not just security nerds or tinfoil hats.

The exclusivity to Pixels is an unfortunate consequence of being the only platform equipped to provide what they need to achieve their goals. If multiple devices supported what they needed from the beginning, they would have probably supported three or four models from different brands as targets (for example you could imagine a couple Pixel lines + one Samsung line (Europe/North America/Oceania), one Xiaomi line (East Asia/South East Asia/South Asia/South America), one Tecno line (Africa). This is speculation on my part, but the main point is that the Android OEMs have been seriously slacking on basic privacy/security leading to this kind of situation.

>We need the people who buy $100 phones to have the ability to put a better OS on them than the burning mudslide that comes with them, is all I'm saying.

No disagreement here. This relies on AOSP adopting improvements and also on Google tightening their certification (for Play Store) requirements to include stronger privacy and security guarantees.

Meanwhile, others are completely free to fork numerous GrapheneOS improvements or benefit from their upstream improvements (as some have, including Google).

Why can't you understand that?

You're not being consistent in what you're advocating. You mentioned accepting pull requests in the context of wanting to see broader device support. You want broader device support. I do too, which is the value of the Motorola announcement. Your suggestion isn't the way to achieve that. It just isn't viable for reasons you should reasonably already understand. But since you don't...

It shows yet again you just don't understand the project, how it's structured, and what its goals are. I'd say you should try running it, but you're still murky on the actual nature of the OS you use daily, so there would be no point in my suggesting that.

Assuming all you want is broader device support while magically not increasing the GrapheneOS team's overhead, but for reasons you haven't stated won't accept forking it, you're out of luck, which is right where you should be.

Still, why? If you want hardware which lacks security features to run an OS, the primary value of which is its close integration with said hardware security features, what is it you really want, then? A degoogled Android OS? That already exists. Are GrapheneOS's "software" security enhancements (as if we can say "software" in the context of security in total isolation) their quality-of-life improvements to the OS that you're after? Many of those would greatly degrade in value if you couldn't trust the hardware it's running on. You'd get storage scopes, but you'd get it without a file system you could trust. You'd get network permissions but you'd get it without baseband isolation you could trust. You'd get x, y and z, without memory tagging.

If that's what you want, you can get that elsewhere, and should.

But by the conditions you set up, you're also effectively asking for code contributions by outsiders, when the project very deliberately and by all indications very tightly manages who can contribute code, and for good reason. The history of open source is the history of malicious code injection and social engineering attacks. If you want the device to be secure you have to address security from all angles.

Unless you're really, genuinely, nonsensically proposing the project commit resources to allowing people to suggest code changes they have no intention of ever implementing. Though I suspect at that point you'd argue in favor of some code base changes, while not having addressed the fundamental implications of doing so.

You're doing a great job of arguing against yourself, here, and have highlighted a fundamental challenge with Qubes OS. As an active user on the forum I'm sure you've seen the reasoned discussions weighing the pros and cons of accepting code contributions. If your response to that is, again, 'there hasn't been a relevant Xen bug in two decades and my data has been safe this whole time,' that's a dead-end for understanding anything.

Your rhetoric in all this is very similar to the kind of thing one easily finds on normie websites about commonly divisive issues. At some point I just can't keep insisting you're either informed or sincere about all this, HN guidelines notwithstanding.

"Trusted Boot" is a meme on x86. If you really want something like that you need to do what Oxide Computer is doing and rip out UEFI for good and implement your own secure boot chain.

Qubes is great but at the end of the day cannot protect against evil maid attacks to the level that pixel or apple phones can. Its great at making sure a browser exploit cannot steal your banking credentials you have open in a different virtual machine but cannot overcome the limitations of the platforms it builds off of.

So I understand why the GrapheneOS folks do what they do.

See also: "X86 considered harmful" by the founder of Qubes OS (posted in 2015!)

https://blog.invisiblethings.org/papers/2015/x86_harmful.pdf

That's the crux of it you blow past every single time it comes up, and then disparage others as having not stuck around long enough to educate you (as if that's their responsibility).

Yes, it can. Heads, TPM with a hardware key do exactly that, don't they? I'm not sure what you mean by "level". You would need to use a nail polish, too, to be sure your laptop wasn't tampered with.

> but cannot overcome the limitations of the platforms it builds off of

Yes, it can, if you use it correctly. Tell me your threat model, and I will explain how Qubes can protect you.

Qubes AEM hasn't had an update in years, either.

For desktop TPM at least to me they seem a bit of a black box with many past vulnerabilities https://en.wikipedia.org/w/index.php?title=Trusted_Platform_....

I think at cold boot as long as one doesn't store the encryption key in the TPM (external hardware key?) then one should be secure. I am not so sure about post boot however, once the system is already running.

This actually prompted me to research a bit on the scale of the security impact of SMM

https://en.wikipedia.org/wiki/System_Management_Mode

https://doc.coreboot.org/security/smm.html

It seems that coreboot is aware and supposedly for some computers can be implemented to catch calls to SMM (ideally this would prevent the attacker from triggering SMM - if they do it's game over).

I do suspect though that if the system bus is not protected from malicious calls then someone can trigger SMM and have carte blanche to one's computer.

https://www.infoworld.com/article/2167684/hackers-find-a-new...

https://hothardware.com/news/researchers-discover-rootkit-ex...

I don't know what processes Apple / Android use but I suspect ARM chips don't have SMM and that they tie certain functions to their secure enclave. In X86 its backwards, with SMM having control over the TPM (at least in some implementations).

Though some SMM vulnerabilities are patched by now given its history I take X86 security with a grain of salt. I think the potential for a secure platform is there, but I suspect one would want to make their own boards engineered with security in mind to be certain (I hope this happens in the future - it seems to be happening in the server space already).

Yes: https://en.wikipedia.org/wiki/Librem#Librem_Key

Beyond that, there have been known vulnerabilities of NitroKey's Librem Key, to say nothing of the Nitro Key App.

Nothing's perfect but I would vastly prefer something like the Titan M2's implementation over a USB key with all of the complexity and attack surface that introduces.

The magic of Qubes isn't its isolation, it doesn't even provide its own isolation. Qubes is an integration layer added on top of an isolation foundation. So you have a clipboard, file transfers, window dressing, easy configuration of device pass-through rules, all that. It's great.

It's phenomenal at that. But you have to understand what it is. You have to layer on a whole bunch of additional cruft to the Type-1 hypervisor, potentially all of which introduces potential vulnerabilities to dom0 and/or relevant appVMs. (Fortunately the project moves very slowly even for its size, which gives me some reasonable degree of confidence in its third-party code contributions, if less than I have in GrapheneOS's team's contributions.)

GrapheneOS solves a lot of these practical issues in very real and excellent ways, and it does it in large part via its tight integration with the excellent hardware it runs on, "Google" notwithstanding. (Now, "Motorola." "Lenovo." "China." A poor architecture even when made in America is not a practical improvement.)

Qubes-by-way-of-Xen does it despite running on pretty horrendous architecture. Even with your labor-intensive and super geeky improvements you've made to your setup, an evil maid attack, a theft, coercion, legal and political forces, all of these factors hit a harder target in GrapheneOS than they do in any QubesOS configuration currently achievable. But, as stated, trying to contain the most dangerous software most people ever run, a web browser, from leaking into your password manager? It's great. If that's your primary threat model, it's difficult to beat. Profiles on GrapheneOS are also excellent for that, if less well-integrated and therefore usable as Qubes.

Qubes still wins in terms of virtualization, of course, and you're comparing the benefits of virtualization to all of the many other benefits GrapheneOS brings (and in many instances iOS too), but you're not comparing them meaningfully.

Type-1 style virtualization is on the GrapheneOS roadmap, and once they achieve that it will be vastly more secure than QubesOS running on any x86 concoction you can devise. Give me a ThinkPad that meets GrapheneOS's hardware requirements running a virtualization-based GrapheneOS implementation and I would have little reason to ever run Qubes OS again. That would be some kind of peak practical end-user security solution, and I'd imagine enterprise and state customers would flock to that, if the broader enterprise requirements of it all were met, too.

Both lines of thinking are faulty, and attempting to directly extrapolate from one project to the other (in either direction) mostly only conveys a lack of understanding of both projects, even (especially?) one's favored project.

Joanna Rutkowska herself admitted that the difficult nature of trying to contain the PC hardware stack made it ultimately feel like she lost the war. Qubes OS is inherently vastly more vulnerable than GrapheneOS, in large part precisely because of their different approaches to hardware. Some of this has been mitigated by developments made since she stepped back from the project, but some of it will always remain. How to deal with this inherent conflict is not a simple matter and the two projects have taken two distinctly different approaches.

In the cases of both projects, I think they made justifiable decisions in their approaches. I use and contribute to both projects.

If you've been using Qubes OS long enough, you'll remember a time when trying to run it on anything that wasn't essentially identical to the ThinkPads used by Qubes OS devs often presented a major challenge.

GrapheneOS is a fundamentally different project in scope, and each project has a subset of users which seem unable to do anything but evaluate the other project based on the criteria set by the one they like.

"The goal of the project is not to slightly improve some aspects of insecure devices and supporting a broad set of devices would be directly counter to the values of the project. A lot of the low-level work also ends up being fairly tied to the hardware."

GrapheneOS achieves significantly more security on the hardware level than Qubes OS, in very large part specifically due to the nature of the project. It's also an infinitely simpler OS to get up and running with, on both current-gen flagship hardware and current-gen value-prop hardware available in just about any store which sells cell phones.

In addition to all that, by the nature of the respective code bases it presents a significantly smaller attack surface than a computer running Qubes OS.

Securing a single device type with excellent hardware security is simply much more viable a project than securing a broad range of devices with hardware security that is, at best, pretty terrible.

Repeatedly criticizing one project without significant familiarity with both is not just pointless, it's counterproductive to aims of FOSS privacy and security.

I critisize precisely because I don't understand what you're talking about. The last relevant VM escape was in 2006, discovered by Rutkowska herself. Since then, nothing could access my secrets in an offline vault VM. I would appreciate a clarification, how GrapheneOS can be more secure without reliable virtualization.

AFAIK Xen security relies on 100k LoC. And this is in addition to the virtualization. How many LoC does GrapheneOS require to provide its security? How can it have less attack surface than Xen? Developers replying to me here never provided an understandable reasoning, only keep repeating that it's "very, very secure", without even mentioning any threat model.

Doesn't GrapheneOS rely on closed Google's hardware to provide its security? I would never trust Google with that. How can I not critisize such approach?

Framing closed blobs as fatal flaws while advocating for other situations also containing different closed blobs is disingenuous.

Saying no hardware designed by Google could be trustworthy while advocating for x86 architecture and hand-waving IME (or PSP to whatever degree) as being "disabled," when no such thing is fully possible, is lazy. You don't get to care about this stuff selectively. IME when disabled to our fullest ability can still receive and apply microcode updates without the user's knowledge, making access to full unrestricted PCI lanes, DMA and USB possible. Wi-Fi certainly, at least in some specific scenarios. I'm not as concerned by IME/PSP as some, though I am much more concerned by it than some others, but the consistent selectiveness of your approach to attempting to understand that (and I'm taking it in good faith that you are) is precisely the kind of thing that makes people give up on attempting to give you additional information by which to reconsider your opinion.

Citing Joanna's research without any relevant context when you find it convenient yet ignoring it when it doesn't isn't helpful, either. You raise issues, people provide relevant research, and you ignore it while accusing broad swaths of people of doing the same. At some point it feels like projection.

I don't like even the appearance of unfairly criticizing the Qubes team publicly, because it's an important yet still-fledgling-in-resources project and they're doing amazing work nonetheless, but "the last relevant VM escape" overly relies on "relevant," and you overstate Xen's security because you're looking at it in isolation as if you can compare the relative security of operating systems while selectively comparing their hardware. The Qubes OS team has allowed significant Xen vulnerabilities to remain unpatched for weeks to months, sometimes not even capturing them in their XSA tracker. The GrapheneOS team seems fairly exemplary in pushing out important patches. I say this not to knock the Qubes OS team which does great work with very limited resources, but there are real, practical, significant differences in the two approaches and so long as you're comparing specific points in isolation of their broader context you're going to miss significant fundamentals.

Qubes OS's encryption situation out of the box is lacking in numerous ways which some Qubes OS users attempt to manually address. Consider the rigor it would take one to replicate your config vs. the rigor it would take to buy a Pixel and install Graphene OS. A journalist or dissident who is massively concerned with being in possession of data, the discovery of which could see them jailed or killed, is significantly better off storing that on a device running Graphene OS. That's not a hand-wavy thing, when you consider the full stack the advantages are numerous and concrete. There are many other practical differences between the two security models, when compared holistically. File system security of GrapheneOS is miles ahead of where Qubes OS is, and it's partly due to the OS, partly due to the differences in hardware. Brute force resistance is leagues better on GrapheneOS in part because the hardware facilitates it, and the OS does a best-of-class job at taking full advantage of that hardware.

At what point will you stop repeating your line of, "I keep asking for examples but they never answer"?

> Attempting to compare line counts of 'security-related code' in isolation, if such a thing can even be framed that way, as if that's a useful metric indicates a fundamental misunderstanding of the issue.

I didn't invent this. Isn't this exactly how Qubes developers frame it? Are you saying their approach is wrong? https://doc.qubes-os.org/en/latest/introduction/faq.html#wha... and https://doc.qubes-os.org/en/latest/developer/system/security...

> Framing closed blobs as fatal flaws while advocating for other situations also containing different closed blobs is disingenuous

Isn't this an important milestone, when the OS has no proprietary bits at all? This not the end, but something worth celebrating, I guess. Apart from that, doesn't Librem 5 has a lower number of blobs in general? I might be wrong of course.

> hand-waving IME (or PSP to whatever degree) as being "disabled,"

It seems you misunderstand me or didn't really read my previous posts carefully. I never considered "disabled" ME sufficiently secure. I strongly prefer "disabled and neutralized" instead, which I btw have on my laptop. It doesn't completely kill it, but it certainly makes it quite unlikely to make any harm.

> yet ignoring it when it doesn't isn't

I guess if I ignored something, I did not notice that it was relevant. Therefore I have no idea what you are talking about, i.e., which exact posts of mine you mean. If you actually want to be helpful, this is not how it's done.

> but "the last relevant VM escape" overly relies on "relevant,"

I admit that, and I specifically mentioned my threat model with passwords in relation to this. You didn't show how my threat model was wrong or not secured against.

Your other points are well articulated, although the corresponding threat model you mentioned is definitely not for everyone. Thanks again.

You also continue to shift the goalposts on things which I trust is not from malice but a hazy grasp of some basic fundamental concepts. You've already had it explained to you by people much more qualified than I how the Librem 5 has some entirely closed-source components running woefully outdated firmware, but now it's about celebrating something else entirely.

"Disabled and neutralized" IME is still IME that's highly privileged hardware running a closed-source operating system outside of your ability to monitor it. By the standards of evaluation you set in other comments baselessly criticizing Pixel hardware, you should object all the more to the x86 architecture, even with your ultimately insufficient attempts to reduce harm. The hand-wringing over the possibility that Google has embedded a still-undiscovered way to exfiltrate data from their phones even when running GrapheneOS, is misguided and unfair at best, and if nothing else you should be consistent in your application of these principles.

I trust I shouldn't need to cite every point you repetitiously make in order for you to stop complaining that I'm not limiting the scope of my reply perfectly to one particular comment of yours, as if this is some kind of contest of form.

If you kept current or really spent any time at all researching XSAs you'd know that its shared memory architecture alone has resulted in numerous XSAs, some of which could very much apply to your threat model. Hardware MTE would go a long way to mitigating that, which Pixels have. In the hypothetical scenario of Qubes OS running on more secure hardware than even your home brew situation, that would be a significant improvement over the status quo which you say you can't even imagine. You're defining your threat model overly narrowly by excluding all kinds of relevant factors and then declaring it wholly met. That's not how this stuff works.

If, after all this, you still can't imagine how Qubes could be improved upon for your particular threat model (having passwords in a vault appVM exfiltrated) after hearing just a couple hypothetical benefits of running it on more secure hardware, it's unsurprising you can't recognize the comparative advantages of GrapheneOS and instead want to rely on things like counting lines of security code because you once saw someone else do it in a different context.

My goal here is not to change your mind, that part is up to you and you've already had one of the finest minds in the field address your issues point by point elsewhere (that was a fun surprise to see). My goal is to reduce the ease with which you can continue to filibuster people into moving on with their lives so you can then continue making the same unjustifiable claim that nobody ever offers a meaningful explanation to you when you merely ask simple questions about the benefits of the project. Unstoppable Force Meets Argumentum ad nauseam.

I guess you only opened my first link but not the second. Here is a quote from the second link for you:

> The size of the current TCB is on the order of hundreds of thousands of lines of C code, which is several orders of magnitude less than other OSes. (In Windows, Linux, and Mac OSes, the amount of trusted code is typically on the order of tens of millions of lines of C code.)

This is just false. Looks like you mix false accusations with reasonable arguments.

I still didn't receive any reply concerning the lines of code for the Trusted Computing Base (TCB) of GrapheneOS.

And while some machines have problems like that, there are plenty of manufacturers who will sell you Linux devices with better support.

Also I don't think Linux's reputation is as problamatic as you make it seem. It is astoundingly popular and continues to grow - owing in no small part to its accessibility.

(/s in case it is needed.)

As a smaller project, choosing a small set of hardware and supporting it really well (aside from security reasons) seems like a much better strategy than supporting tens of devices badly (go to e.g. the /e/OS forums to see what regressions people are dealing with after monthly updates).

But for Apple that is not necessarily a bad thing. They're a company. Their goal is to make money and they are highly successful at it. GraphineOS is not a company. They don't make money. Which begs the question of what is GraphineOS's real goal and is it valuable? Creating a maximally secure mobile OS seems valuable on its face, but that value is undercut by its inaccessibility.

You are saying this like GrapheneOS only runs on some unobtanium hardware. I can literally hop on my bike and pick up a phone that runs GrapheneOS in 5 minutes, every day of the week. Also, it's available in pretty much all price classes except maybe a 100-200 Euro phone that runs on a Unisoc CPU. Pixel 9a regularly goes for 350 Euro here and you can go all the way up to an expensive flagship with a Pixel Fold (or anything in between). Even in the 100-200 bracket you can probably pick up a refurbished 8a that should still be supported until 2031.

I know that they are not sold in every country, but worst case it should be possible to get your hands on one second hand or refurbished.

> We're working with a major OEM and the devices will be the future versions of existing models they have now. The devices will be priced similarly to Pixels. The initial devices will have a flagship Snapdragon SoC for the best security and support time. Snapdragon flagships have significantly better CPU and GPU performance than Pixels. Snapdragon provides high quality Wi-Fi, Bluetooth, GNSS and cellular support as part of the SoC. eSIM and other functionality is also provided by the SoC. Snapdragon has decent image processing functionality included too, and good neural network acceleration.

[0]: https://old.reddit.com/r/GrapheneOS/comments/1o32gpg/deleted...

https://privsec.dev/posts/android/banking-applications-compa...

Many banking apps do work on GrapheneOS, the list had already been linked to by others

grapheneOS only works with google phones.

And I don't really think that people mean using google hardware but rather being mined by google software.

May I ask, if you (a) just want to be technically correct, (b) don't see the difference or (c) are trying to make a point I don't understand and if so would be willing to explain?

---

[0] https://piunikaweb.com/2026/02/02/grapheneos-non-pixel-hardw...

Better yet, you can buy a used pixel phone.

Not a bad deal and pretty crazy how fast smartphones depreciate now.

https://grapheneos.org/articles/attestation-compatibility-gu...

If the bank is very hard-nosed about it, you could consider keeping an old iPhone or Pixel (because long security updates) for banking if it is practical to do for you. 95% without big tech is also a big win. Of course, if you need to have it with you at all times, that might not be a worthwhile option.

edit: https://privsec.dev/posts/android/banking-applications-compa...

Also, what kind of banking are people doing that requires an app? I genuinely don't know what it could be.

Close to every bank in the EU requires their user to have an app, for MFA (both for logging in and for validating transactions - transfers, payments). They use the smartphone's TPM. I have yet to see one that allows you to use your own MFA app.

The few I've seen that don't require it will validate the same through text messages (not everyone has a smartphone); though if you associate their app even once, you're screwed - the app it is from now on.

Possibly this was hyperbole but in any case it's not correct at all.

Anecdotally, of my two EU (massive legacy French) banks, neither requires a mobile app. SMS all the way.

Even Wise, a cutting-edge neobank, does not require you to use its app. And its website accepts standard TOTP authenticator for 2FA.

Revolut is app-only, which is why I never use it.

No SMS at all (which is not surprising, because SMS is not secure).

Also, IMO fingerprint/face-based authentication is much nicer/quicker, especially for online payment flows like iDEAL (Dutch predecessor to Wero). And banks here work on GrapheneOS, so not much is lost.

Until they don't.

My wording was bad, sorry; but try to install their app just once. After that, I'd bet you won't ever be able to go back to SMS validation (which is what I was talking about at the end of my comment).

If not, I'd be curious to know the banks you're talking about (to consider switching to them, for one thing). What I said above is true of Caisse d'Epargne, HSBC, CCF, among others.

Fortuneo (internet-only subsidiary of Crédit Mutuel) and LCL. I have had both their apps installed at points in the past. In both cases they defaulted back to SMS 2FA upon uninstalling, though I remember worrying I would have the problem you describe.

Ultimately I can't see how a bank could get away with forcing (rather than just pushing) existing customers to install an app. This would surely be a breach of contract.

Can you go in branch and get that fixed?

Especially since in many countries it requires a national e-ID that is an app on your phone.

2FA. I was a smartphone hold-out for longer than anyone I know, but banks mandating 2FA with no options for doing it in a standards-compliant way or any way that doesn't involve the app stores was what finally broke my resistance.

I'm just wondering since I'm currently using 3 different European banks without any biometric authentication to unlock my phone, password manager or provide a 2FA.

I'm asking so that I can adjust in time to any new regulations I'm not aware of.

I kind of jumped at the "biometric" part of your original comment.

Now I understand what you mean better and I'm not worried about my setup (although I question how it complies, but that is another matter).

Credit cards, which are US companies, use 3D secure. It's a 6 digits PIN plus a code sent to me by SMS. Amazon stores the card data and very seldom asks me for those PINs.

One bank gave me a hardware OTP generator. I type in the code, plus the bank PIN, plus a random number they show on screen.

Other banks send a push notification to their app on my authorized device (only one of my devices can be authorized at a given time). I must confirm the operation with my fingerprint or with the bank PIN. The fingerprint is easier, no password manager to open.

The result is that I can do online banking anywhere around the world but I can't use credit cards online unless I am in my home country, because for some reasons SMSes don't reach me abroad. There might be something wrong in my contract but I've not been able to sort it out.

The last time I've been in Australia I put a local SIM in slot 2 of my phone and used it for local communications and data. I could receive calls on my home SIM but no SMS. I even contacted the customer service of a credit card to attempt to make SMSes reach me on the Australian number. Fat chance.

There is common knowledge to suggest that it is not the case (or maybe is no longer the case):

>Mainstream smartphones do not provide DMA access from the baseband to the application processor's memory... Yes, getting baseband access then lets you monitor regular voice and SMS comms. But no, it does not instantly compromise the AP so using the Signal app would still be secure. https://news.ycombinator.com/item?id=10906488

>Apple mitigates baseband processor vulnerabilities by putting it behind what's essentially an IOMMU. https://news.ycombinator.com/item?id=29440154

>This is false FUD that keeps being repeated. It's not true. No iPhone ever has had a baseband with DMA access to my knowledge, and modern Qualcomm devices have advanced IOMMU systems to firewall away the baseband from the rest of system memory. I'm sure some phones somewhere existed where the baseband was privileged, but it's not the norm. https://news.ycombinator.com/item?id=30393283

>Connecting a cellular radio via USB provides far less isolation than the approach of a tiny kernel driver connected to an IOMMU isolated cellular radio on mainstream devices. USB has immense complexity and attack surface, especially with a standard Linux kernel configuration. Forensic data extraction companies mostly haven't bothered using attack vectors other than USB due to it being such a weak point. Many of the things people claim about cellular radios in mainstream smartphones are largely not true and they're missing that other radios are implemented in a very comparable way. https://news.ycombinator.com/item?id=46841004

Citation needed?

> This was common knowledge after the Snowden stuff.

Not to me, it isn't? As far as I'm aware, most of the Snowden stuff were centered around PRISM, which allowed widescale wiretapping of internet backbone, as well as agreements with big cloud providers to allow tapping into their data.

I haven't seen anything indicating that there was widespread compromise of personal computing devices at such a deep level of the root of trust. I haven't seen any indication that the NSA has a backdoor in the earlyboot CPU of any device, whether that is the Qualcomm boot processor, the Intel Management Engine or the AMD Platform Security Processor (which all have similar capabilities and hidden firmware).

If I missed anything/have links to research into these backdoors, I'd like to see them!

Horizontally splitting Google into multiple companies.

Not division via department splits, but equal partitioning across the company into multiple horizontal businesses that compete on the same offerings.

The EU and next DOJ/FTC need to force this.

The EU is not going to force this, because it has enough fights to pick with the US, and this is not the hill that they are willing to die on. It would be far more likely for them to financially support an AOSP-based OS.

Google lost all three cases. The DOJ in all three recommended the company be broken up, but the judges disagreed. If you want to blame someone, then blame the judges, not the current admin or Bidens DOJ - both of whom said Google should be broken up.

Anyway, I am going to stop here, since this will probably derail in a non-productive political discussion otherwise.

If I’m charitable, I could assume they intended to make a controversial move to drive public attention to the growing government restrictions on innocuous apps. As far as I know, though, nobody at F-Droid admitted to this; and if they were, why didn’t they mark other widely used apps like Wikipedia and Reddit frontends that provide easy access to much more sexually explicit content in the same protest?

If I’m less charitable, and go by what F-Droid admins actually said, they took this action out of a sincere belief that these apps contained content unsafe for minors that necessitated flagging, and sincerely believed that Wikipedia and Reddit frontends somehow don’t qualify for the same. If they honestly believed this, it demonstrates (to me) poor judgment; and since the action was walked back almost immediately due to negative public response, that indicates further that they never actually believed this in the first place, and that instead somebody took it upon himself to specifically target religious apps out of his own bias.

Either way, it really soured me on the judgment of the F-Droid maintainers. After a stunt like that, I no longer trust them to fight the battle against oppressive government restrictions on operating systems effectively. Formerly an F-Droid user of many years, this caused me to switch away completely: I’ve started donating monthly to Accrescent instead, download as many apps as I can from there, and switched from F-Droid to Obtanium for any apps not yet on Accrescent.

Ezekiel 23:20

Meanwhile Reddit is a doubly poor example because even though the service contains NSFW content, it marks it as such, and then the client not only doesn't itself contain it but gives the user a separate opportunity to select against it when using the app to download pages.

And clearly that wasn’t the standard anyway. Before the introduction of the policy restricting religious texts, the only apps F-Droid had marked NSFW were frontends to porn sites, even though the apps presumably contained no sexual content directly.

Which would also explain the Bible apps without an initial copy. Choosing which translation to download when substantially all of them are translations of the same NSFW text means that substantially all of the users would end up with NSFW content on their device by using the app.

Nothing could be further from the truth. The Bible has been around for a while, and translations exist to serve the current sensibilities of every period within that time.

Here's Ezekiel 23:20 in the King James Version:

For she doted upon their paramours, whose flesh is as the flesh of asses, and whose issue is like the issue of horses.

This has been euphemized so heavily that much of the original meaning is no longer present.

1. They have a policy of marking apps as NSFW if using them has a high probability of loading NSFW content onto the device. We can't easily rule this out. It's a small project so they have to be reserved about compliance issues because they don't have the resources to defend against expensive litigation and they could just be exercising an abundance of caution.

2. They're trolling Republicans with malicious compliance. They don't like the laws being enacted, they know the people enacting them like the Bible, so they apply the policy in the way which is maximally adversarial to the opponents imposing it on them. "If you don't like the consequences of your law then feel free to repeal it."

Which one of these is even objectionable? It seems like you want that if they're doing the second one they should admit to it, but in that case they're just maintaining kayfabe. The trolling is more effective when it's ambiguous. It's obvious that it could be that. If the message is to invite their opponents to go eat sand then it's not being lost in translation. But making that explicit only makes it easier to dismiss them as antagonists, or retaliate against them for being overtly defiant.

Whereas if they play it straight, what is someone going to say? That it shouldn't apply to this, right? Okay, then we need to pin down the rules for how exceptions work. Exceptions that could then be applied to other things. Which is to their advantage to have their opponents doing in this context because then they want the exceptions to be broad and reasonable instead of not caring if someone else is getting screwed by them.

If F-Droid were being cautious:

• They would have restricted social media apps, which a lot of public hysteria targets, which many of the new laws explicitly target, and which other app store providers like Google and Apple have already faced and continue to face massive financial and legal consequences over. If F-Droid is unwilling to take a stand against censorship, this would be an obvious step to begin shielding themselves from liability.

• They would not have prioritized blocking apps providing ancient religious texts, since there’s no public hysteria over Bible and Quran apps, none of the new laws explicitly target them, and no app store provider has faced consequence or threat of consequence over providing them.

• Once the policy was in place, they would not have reversed it simply after receiving angry comments.

I’m completely comfortable disbelieving F-Droid was ever actually concerned that religious apps could be a liability risk.

> They're trolling Republicans with malicious compliance. They don't like the laws being enacted, they know the people enacting them like the Bible, so they apply the policy in the way which is maximally adversarial to the opponents imposing it on them.

If the targets of their trolling (and I’m glad you agree, it is trolling) are legislators in backwards U.S. states, they hit far off the mark. The only people impacted by F-Droid’s censorship have been its users, who are (for the most part) members of the free software community. What’s the point of a troll that is unnoticed by your enemies and only harms your friends who already agree with you?

> "If you don't like the consequences of your law then feel free to repeal it."

In case you haven’t noticed, these laws are being passed everywhere from the UK to Brazil to Australia to Singapore to the EU. And yes, some U.S. states, too. So your “realpolitik” remark in another comment is similarly pointless, because those other politicians and regulators are also completely unaffected by F-Droid’s actions.

> Which one of these is even objectionable?

In response to a law saying F-Droid must punch some of its users in the face, F-Droid of its own volition decided to punch a different set of users in the face rather than refusing to punch anyone at all. I find that objectionable, and the flurry of comments they received shows others do too. Instead of taking principled actions or practical actions, F-Droid’s maintainers decided to take a swipe at users of religious apps on F-Droid, refused to explain themselves (“kayfabe,” as you called it), then upon receipt of unexpected blowback on their forums and issue trackers, backtracked and reversed the policy without further comment. It was a boneheaded move that drove away some app developers and some users like me. How can I trust them to not make some other boneheaded move in the future? Can you imagine Debian or OpenBSD doing such a thing? Now F-Droid has a big banner up top pointing to https://keepandroidopen.org/ and making themselves (noticeably, not other FOSS app stores) out to be the defenders of app freedom. It’s completely tone‐deaf and shows poor judgment. If current or future F-Droid leadership actually addressed the issue, I might be convinced to use it again. But I won’t hold my breath.

Not only is this not going to convince anyone that there's anything behind it other than an attempt to formulate a winning argument (having set that as your goal) irrespective whether there's any actual sincerity to the words you're choosing, but it's going to come comes across to a healthy portion the world's population as the opposite of clever: that anyone who's convinced themselves that it really is clever and that no one can possibly permeate this forcefield of insincerity is a perhaps-delusional, and definitely-insufferable halfwit.

The original complaint was that if they were doing it to be controversial, why not do the same thing to viewer apps for Reddit or Wikipedia? But those are necessarily distinguishable. If the standard was that a viewer merely could load external NSFW content rather than was likely to, you would have to do web browsers, mail clients, podcast managers, file transfer apps, video players that can open external links -- it'd be most of the repository. And that would be far less defensible, because you can point to specific controversial Bible verses, but how are you going to make the case that generic FTP clients and web browsers are NSFW with a straight face? But conversely, how would you argue that a Reddit viewer is NSFW but a web browser that can open Reddit isn't?

The fork where they need "a sincere belief that these apps contained content unsafe for minors" was the other fork, where they're doing it because of potential liability rather than to make a statement. But that fork was flawed to begin with, because they're not required to think that it actually is unsafe. They could also be concerned that someone else could claim that and then even if the people claiming that are jerks and even if the jerks could ultimately lose, they could prefer to be risk-averse when they don't have the resources to handle things like that.

No, I don't. (How could I have been any clearer?)

Which is another reason the Bible should be banned from being accessed by minors. If a child needs an abortion, they should consult a medical professional. They should not read about how to perform an abortion in an app on their phone and attempt to perform the procedure themselves.

Not really. And biblical times does not mean people's lives were run according to commandments in the Jewish bible (neither in ancient Judea nor elsewhere).

Does the Bible encourage violence or promiscuity? Not really, no. Does it mention and describe those things in some detail? Yes, absolutely. If that's the kind of content you need to remove from your store, then obviously you need to remove the Bible from your store. Whether that was really the case seems questionable at best, but the stated logic seemed pretty coherent to me.

(As an aside, if they indeed had to follow some Dutch law and remove Bible and Quran apps, maybe F-Droid can be hosted by freedom.gov, US govt's new anticensorship portal..)

If F-Droid were being overcautious, they would have blocked social media apps too. Social media is explicitly the single biggest target of these “think of the children” app store laws after outright porn sites. F-Droid left Reddit and Mastodon clients unmarked. Am I supposed to believe that F-Droid honestly thought the law applied to apps containing only ancient religious texts, and not to social media? Has any other app store interpreted the regulations the same way? And if they truly believed that was a legal requirement, why did they reverse the policy after only a couple days of user complaints?

Hey I believe that too. If people are entitled to believe whatever is written in those books, surely people are also entitled to believe it's nonsense and actively harmful.

kernel is locked and most phones can't be rooted anymore