Reduced security has always annoyed me a bit as an argument. Sort of in the same way as signal deprecating SMS because it's insecure.
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.
Oh man, I am still annoyed about Signal removing SMS support. Had to add another app to my phone and I can now no longer accidentally discover that someone I'm texting has Signal, which happened more than once to me!
I only just installed Signal in some abandoned corner of one of my devices to be able to communicate with my 'highschool' classmates (in reality a Dutch Gymnasium so a totally different school system and age group but you get the idea) and had to get the blasted thing working without Google services on a device which for some specific purposes sometimes enables these but mostly has them disabled. As soon as Signal gets a whiff of even a stub of Google services is refuses to work without a fully fledged Google services implementation. To fix this I had to add 'disable Signal' to my 'enable rudimentary Google services' script and to do that I had to find the package name:
So yes, they're still called 'secure SMS' even though that is no longer part of the deal.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.
Reduced security has always annoyed me a bit as an argument.
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.
> I can fully understand that they don't want to weaken that by supporting fundamentally insecure devices.
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.
>Not everyone needs kernel hardening, or always E2EE (as with signal).
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?
> I get all or nothing when your threat model is state actors.
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.
How do I make sure if my phone does get confiscated, Cellebrite can't image it or access the data?"
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.
Graphene is OSS, so if you want to create a fork that supports other phones, you are free to do so. The maintainers have limited amount of resources, why wouldn't they focus those resources on the most secure hardware if that is what aligns with their goals? If you have different goals, create or fund a fork to support more hardware.
Really? Wow? What an insight.
That being said, am I allowed to complain. Or simply dismiss them for supporting only Google hardware?
Or should I create a fork instead?