GrapheneOS always strikes me as "perfect is the enemy of good". I don't necessarily need top-notch security features, I've been all right with all kinds of Android phones. The things I'd like are:
- ability to sandbox Google Play and Google Apps so that they live in their nice little Google bubble and have no control over my phone overall
- ability to run all applications sandboxed with fake permissions that I can whitelist for each application and without letting the app know it doesn't have the permissions it wants. Want location? Give the app a location point I've fixed for that app. (Or pass through real GPS location if I've chosen so.) Want contacts? Give the app empty contacts list. Or if I've allowed, give the app the contacts I've whitelisted.
The Android/Google ecosystem is all right in itself, I just want to limit all of it inside a cage that I control. I want the exact same for my browser: I want webpages to run in a highly controlled sandbox with my choice of spoofed environment and permissions instead of assuming any power over my system. Or my Linux desktop where I firejail or sandbox certain proprietary apps outside of my distro's repositories.
GrapheneOS has an OEM partnership with Motorola where they're working on improving their devices to meet our requirements because we won't lower our standards for updates and security features. A lot of work needs to be done for each supported device. There's a massive amount of work bringing the security-oriented, production-quality hardware memory tagging integration from Tensor to Snapdragon. We're working with Motorola and Qualcomm on it. If we simply ported it to many insecure devices we'd need have the time to work on features like this or the power to get an OEM and SoC vendor to work with us on it.
GrapheneOS has Contact Scopes and Storage Scopes for pretending all of the contacts, media and storage permissions are granted with the app unable to access any additional user data without the user explicitly adding it on a case-by-case basis. Unlike the recent iOS feature, apps can't see the Contacts permission group isn't granted and it supports giving less data than the whole contact too. It also supports labels for groups of contacts shared between apps.
Mock Location is a standard Android feature. We're working on a per-app Location Scopes replacement. We're also working on Camera Scopes and Microphone Scopes. We plan to continue down that road covering less major permissions too.
Sandboxed Google Play already works near perfectly with close to 100% app compatibility. It's only apps disallowing using a non-stock OS via the Play Integrity API or to a lesser extent certain other methods which aren't compatible. McDonalds is a major example. X forbids password login but you can use Vanadium to login with a passkey and then use that in the app. ~10% of banking apps do it but not most. We've convinced multiple banks to permit GrapheneOS, and that's going to become MUCH easier now.
This is very useful context. Especially around Contact Scopes etc. It's never made sense to me that iOS shares if the user is choosing to not share their contacts.
Apple seems to basically do privacy-related things to an 80% level but not bothering with getting it totally correct. This makes business sense because the extra 20% is way more difficult, but it's great to see GrapheneOS going all the way.
> We've convinced multiple banks to permit GrapheneOS, and that's going to become MUCH easier now.
I did not know that. That is very interesting.
On that topic, an honest question: what is the killer feature of banking apps that everyone is so hot on? Are we talking like retail banking or money transmitters? I am not using any bespoke banking apps, and I don't feel like I'm missing out, but maybe I just don't know what I'm missing.
What does detract from my GrapheneOS experience is the keyboard. It's just ok. I need swipe typing though, and I haven't found anything even close to gboard glide.
We are talking about banking and pseudo-banking apps with the following typical features:
* A wallet for QR-code based payments backed by a national standard for their content and by the money in your bank account;
* A software implementation of an NFC-enabled credit or debit card, or sometimes with a magnetic strip emulation in addition to that;
* An interface to transfer money to other bank accounts in the same country or abroad, or to convert between local and foreign currency if you have a foreign currency bank account;
* A way to pay common utility bills - in some cases, by scanning the QR code on the bill;
* A way to manage banking and investment accounts - e.g., if you want an extra savings account in Japanese yen with a new debit card attached to it, tap a few times and it's there;
* A chat with bank representatives - for example, to provide supporting documents by photographing them, without ever visiting the bank;
* A second factor (as in 2FA) to approve money transfers initiated from the desktop web browser, meeting the bank standards where TOTP can't meet them (e.g., due to the legal requirement to say what transaction the code is for).
The real problem is that many banks are deprecating their browser-based interfaces and are turning app-only.
> The real problem is that many banks are deprecating their browser-based interfaces and are turning app-only.
What bank does that? If my bank did that, I would find a new bank immediately. That is not OK.
> On that topic, an honest question: what is the killer feature of banking apps that everyone is so hot on? Are we talking like retail banking or money transmitters? I am not using any bespoke banking apps, and I don't feel like I'm missing out, but maybe I just don't know what I'm missing.
For me, the killer "feature" is that I need to generate an auth code on my bank's app to be able to log in to my account and make transfers via my browser (or I can use the app directly). In other words, it's considerably more difficult to actually do (retail) banking without my bank's app.
Got it. That makes more sense, i.e., that you're essentially required to use it rather than getting something in addition.
My bank's killer feature is that they're app-first and web-first because they only have one physical branch in San Antonio. They were one of the first banks in the nation to allow you to electronically represent checks for deposit, and they did that first through their web app and then later through their mobile app.
For the keyboard I recently discovered HeliBoard. You have to add a gboard's library to enable glide typing, but so far I really like it.
Woah. I've been looking around for months. That's huge. Thanks.
What, exactly, is sandboxed Google play prevented from accessing? Can I feed it a fake location or disable location access? Is it prevented from running in the background 24/7? Can I force it and just it through a VPN? Or is it just blocked from accessing apps and files that aren't in the sandbox? There are many such questions and all could be considered "sandbox".
Sandboxed Google Play receives no special access at all, so you can deny it all permissions if you want, but you should grant network (and maybe notifications) permission for it to actually function.
Well that's a bit misleading answer. Some apps refuse to work if G services are disabled, so they clearly communicate with them. It would be nice to know what exactly G learned about the phone through those "sandboxed" apps.
It's an Android service. But unlike on regular Android where Google play services have hard-coded special permissions, on Graphene it is an ordinary android service with all the same strict rules applying to it, as to any other service you could write.
So an application of course can use other android services if it declared that, that's why it can see whether it's running or not. But you are in full control whether google play services is installed, and what it can use.
Of course this may break certain apps (Google maps location sharing will probably not work with the location permission denied for play services), which may or may not degrade gracefully.
I denied the contacts permission to the Play Services. It just shows a notification when it tries to access them, which is actually not common at all.
In what ways has the pursuit of perfection harmed the good in their development? (Your words, I don't agree.)
Graphene does everything you're asking, except for the niche fixed location feature you specifically want, which you're welcome to request, or just implement yourself and make a PR.
I'm going to be a bit snarky here, but I always find the entitlement around features in open source software baffling. This isn't a multi billion dollar corporation selling you something. It's enthusiasts making you something (honestly, incredible), for free, in their spare time, outside of their daily jobs. They're doing their absolute best here.
Our approach is why we have a partnership with Motorola where we're working with Motorola and Qualcomm on improving security of the devices to meet our requirements. It takes longer to get things done the way we want but that's part of the purpose of GrapheneOS. For example, it took us longer to have our own network-based location and geocoding but now we have great implementations of both. Our network-based location currently closely matches iOS but is going to have full offline support developed for it. We're working on our own local model text-to-speech at the moment too, although our focus is currently Android 16 QPR3 related work as a higher priority which delayed it. We do plan to overhaul or replace all the legacy AOSP apps, but our priority has been working on things people can't simply replace by installing more apps.
- [deleted]
> In what ways has the pursuit of perfection harmed the good in their development?
Their lack of device support means I am still running Google's Android and will continue to be until a GraphineOS-supported device that meets my needs becomes available. This means I'm not just lacking in security, but I'm also stuck with Google and all of their anti-consumer practices.
Running GraphineOS without all the security features they want would be better for me than what I currently have.
When the complaint people have about a product is "I can't use it and I really wish I could", I feel like it's a good problem :-).
> Running GraphineOS without all the security features they want would be better for me than what I currently have.
But then it would be like running LineageOS, which is a great (but different) project. Why not using LineageOS?
And this is somehow harming who?
You're free to fork it to adapt it to your device.
The expectation that the entire project brand must be diluted (by lowering the security) to support you specifically, or you feel wronged, is a little, my apologies -- absurd.
Yes, but do these enthusiasts care at all if it meets some need for the users? I suspect that they do.
And how can they find out how well it meets that need other than receiving (respectful!) feedback?
I don't follow. The poster above my comment complained that graphene os was lacking a list of features is already has, so I corrected that.
> Yes, but do these enthusiasts care at all if it meets some need for the users? ... And how can they find out how well it meets that need other than receiving (respectful!) feedback?
What makes you think they don't? Can you point to any instances of them ignoring the community at large?
You can open an issue in any of the open source repositories and request a feature. Others can vote and comment on it. Or you can discuss it in the very lively forum. All methods used to steer the project towards the desires of the users.
In case you can't find them: https://github.com/GrapheneOS https://discuss.grapheneos.org/
This whole conversation just feels weird and specious to me.
I want them to implement a feature where the phone prints money.
The ability to fake the location on a per-app basis is called "location scopes". It is being worked on, as mentioned here:
https://discuss.grapheneos.org/d/27926-per-profile-location-...
Currently there is a Mock Location feature, but it is globally scoped and not what you asked for.
> GrapheneOS always strikes me as "perfect is the enemy of good".
GrapheneOS, as it ships, is rather bleak but you also need to consider that it is addressing the concerns of a very broad audience. That ranges from people who want to completely get rid of data leaking apps to those who want the apps but expect them to be sandboxed. Shipping two different versions won't really help them. It would only make more work on their end, with the results only reflecting two extremes. You are going to have some people willing to put up with some apps, but not others. You are going to have some people wanting some of those apps feeding fake data, but not others.
It's probably best to think of GrapheneOS as a base system that you build up to serve your personal needs, rather than thinking of them shipping it in a "perfect" state. While a handful of people will be happy with it in its default state, many will install something like F-Droid along with a collection of privacy preserving apps. Many others will install the Google Play Store along with a personally curated list of apps that reflect their needs, providing or denying access to their data as they see fit.
I believe the "build up" approach is the only viable way to handle this situation since we are talking about a group of users who are actively seeking out a third-party OS since they are particular about their needs. This isn't the typical consumer who will (gleefully or begrudgingly) put up with whatever the device vendor feeds them.
Our approach is why we have a partnership with Motorola where we're working with Motorola and Qualcomm on improving security of the devices to meet our requirements. It takes longer to get things done the way we want but that's part of the purpose of GrapheneOS. For example, it took us longer to have our own network-based location and geocoding but now we have great implementations of both. Our network-based location currently closely matches iOS but is going to have full offline support developed for it. We're working on our own local model text-to-speech at the moment too, although our focus is currently Android 16 QPR3 related work as a higher priority which delayed it. We do plan to overhaul or replace all the legacy AOSP apps, but our priority has been working on things people can't simply replace by installing more apps.
i don't understand, doesn't that make graphene the opposite of what that saying refers to? it's a real life project that has almost all of the features you mention while not being lagged down by pursuit of perfectionism?
That relates more to the public rhetoric surrounding Graphene than with how the OS itself operates imo. It's pretty practical and enables (or allows you to enable) everything that a typical Android does, except where Google Play Integrity checks fail, which is not in Graphene's control (e.g Google Wallet payments).
People bill it as making a ton of usability compromises in the name of security, but that doesn't match my experience. The only redeeming observation is that your phone _does_ lean towards secure-er and ungoogled defaults, which _does_ break functionality that a lot of people expect to "just work" OOTB. But it's trivial to restore it, and the upfront effort getting things to work is amortized over the lifetime of the device. It's maybe an hour's worth of work.
The counterfactual world where users need to forumcrawl how to get to secure/private defaults seems worse to me. By contrast, it's pretty easy to recognize when an app isn't working.
I agree with your post, but I wanted to point out one thing:
> People bill it as making a ton of usability compromises in the name of security, but that doesn't match my experience.
When you are talking about something like GrapheneOS, most of the people who are talking about usability compromises aren't worth listening to since they are looking for something that is pretty much the exact opposite of what GrapheneOS is trying to provide. While there are likely some legitimate criticisms in the mix, the compromises required for "works by default, for everyone" are pretty much the opposite of what GrapheneOS is.
It's worth noting tap-to-pay is available via Curve Pay and other options in Europe. We intend to get the Google Pay issue resolved.
I mean, GrapheneOS hits at least 2/3 of your demands pretty well. The Play services are "regular" apps with permissions that you can take away. For contacts and files you get "scopes", i.e. you decide what the app can see, while the app is left to believe that it can see everything there is.
That said, I think the marketing of GrapheneOS could be better. Every introduction of GrapheneOS I've seen paints the image of Graphene being "Absolute security, no compromises", whereas in reality GrapheneOS is the most "Things need to work, no compromises. Then make the rest as safe as possible" custom ROM that I've used thus far (in particular regarding them allowing you to install Google Play, rather than using MicroG).
I would certainly be using GrapheneOS if only I could get one to run on something else than a Pixel.
I have a perfectly good phone whose bootloader can be unlocked and I can install LineageOS or other AOSP installations there but all I'm aware of and I've researched come short on the sandboxing and permissions. I'd be willing to use GrapheneOS without support for specific security hardware (if only they supported that configuration) just for the features mentioned but Pixel phones are just too expensive. I've always been more than happy with a decent low-tier phone and I don't see a technical reason to change that. Nothing wrong with my phone.
> I would certainly be using GrapheneOS if only I could get one to run on something else than a Pixel.
But the whole idea of GrapheneOS is the reason why it (currently) only runs on Pixels. On other phones you can run anything based on LineageOS...
I don't want GrapheneOS to compromise on that: if I didn't care about it, I would use any other alternative. To me it's a bit like saying "I would be using Linux if it was a lot more like Windows" (that's something I often understand when Windows users explain what it would take for them to use Linux). But I, as a Linux user, really don't want Linux to look a lot more like Windows.
Pixel A's are quite affordable. GrapheneOS is open source so if there was a need, people could get it to run on insecure devices that aren't Pixels. Expecting that to be done by GrapheneOS developers who care about security just seems weird.
> Pixel A's are quite affordable
There's first-world, upper-middle-class affordable (~$500) and then there's global affordable (<$250).
I got a Pixel 7 secondhand (but good condition) for the equivalent of about $270. It would have been less but I needed 256 gb of storage.
FTFA: it will run on upcoming Motorola devices as well.
Yes, that's why I was reading this thread :)
Doesn't help with the current situation though but I hope the partnering between Motorola and GrapheneOS is still up and going in a few years when I'll next have to replace my phone.
I'm personally happy with LineageOS on OnePlus stuff, but have you considered getting a Pixel that's 2 gens or so old from eBay? I find old flagships drop in price pretty quick and are often a better deal than a new low-end phone.
Mock Location exists but our Location Scopes feature will largely replace it for non-development use. Camera, Microphone and other scopes features will be provided too. We haven't fully fleshed out what the ones for other permission groups such as Phone will look like yet but it's planned.
Would there be any means of preventing apps from seeing one's phone number, IMEI etc.?
> Want location? Give the app a location point I've fixed for that app.
How do you do that in graphene os?
There's a standard Mock Location feature in Android usable for it. We're making a better per-app Location Scopes feature as a replacement. Mock Location is global which has bad usability.
That's doesn't seem to be a thing [yet]. All I managed to find was this comment from the developer which talks about it (CTRL+F, "location"):
There's a standard Mock Location feature in Android usable for it. We're making a better per-app Location Scopes feature as a replacement. Mock Location is global which has bad usability.
That's true. Do those caveats from that older comment still apply? Will apps be able to tell that location is being spoofed when using location scopes?
This is your lucky day!
First is very comprehensively delivered, second is halfway done, halfway in progress.
Good luck!
I'd also like to remove as many apps as I want. If something breaks I'd eat it and re-install the whole system.
You can disable many system apps via the Settings UI. For ones where the naive heuristics or manual exceptions believe it may break something and have it disabled, you can use ADB. You can also uninstall apps from a profile including Owner with ADB instead of disabling them which is NOT a good idea but you can do it...
- [deleted]
- [deleted]
> Want location? Give the app a location point I've fixed for that app.
How do I do that? Been using Graphene for many years but did not know this was possible.
You can't; OP was making a list of GrapheneOS wants without realizing they were mostly just describing how GOS works. That bit was the only miss.
There's a standard Mock Location feature in Android usable for it. We're making a better per-app Location Scopes feature as a replacement. Mock Location is global which has bad usability.
Thanks. So, a misunderstanding from the OP and not a feature specific to Graphene?
> We're making a better per-app Location Scopes feature
Cool!
There's a standard Mock Location feature in Android usable for it. We're making a better per-app Location Scopes feature as a replacement. Mock Location is global which has bad usability.
I want to know too.
There's a standard Mock Location feature in Android usable for it. We're making a better per-app Location Scopes feature as a replacement. Mock Location is global which has bad usability.
Sounds like you might not be the target audience of GrapheneOS then?
That's fine. You don't have to be
One thing that annoys me is the ability that my mobile carrier has to just throw ad popups.
Is that something that GrapheneOS fixes?
Wtf‽ I didn't know that was possible.
Your carrier does what now?
I have a pixel 8a with a TIM SIM card and every once in a while I see an ad popup on my phone.
Like a popup how? What kind of dialog is it? It's more likely to be an app that's bundled by your carrier than your carrier MitM'ing ads into your stuff which is kinda what it sounded like
Just a message popup, a window with dark background and some text ad on it.
I did not buy this phone from a carrier, just added the SIM card later.
Really surprised to learn this doesn't happen to others. Always assumed that the SIM card had some special privilege given by Android.
Sounds like your carrier is abusing STK to display ads.
See https://www.browserstack.com/guide/stop-popup-messages-in-an...
Caveat: if they're doing that, then they're almost certainly data mining your data streams (e.g. dns lookups etc.)
I wouldn't feel secure on such a carrier unless I also VPN'd traffic to a reputable provider (Nord, Express, or Proton) and forced DNS over TLS to known servers.
SIM cards can come with apps preloaded. There was a carrier in Mexico that would load a SIM app for Dominos Pizza and you could order a pizza from your phone if you were on that carrier. I learned this because of some carrier certification feedback I had to disposition at one job.
Go to [Settings] » [Apps] » [Special app access] » [Display over other apps] and check if any preinstalled carrier apps or anything suspicious has this permission granted.
Just checked, and only "Phone" and "Google" have this permission.
There are no preinstalled apps, I bought this phone clean on Germany and then added a Brazil's SIM card when I got back.
Could it be that the SIM card has some control over the Phone app?
Apparently this is handled by the privileged STK[1] service. It can launch browser which is I think what's happening.
GrapheneOS presently doesn’t do anything different in this case, they pull it from AOSP without modifications. However you can disable it using the frontend app (SIM Toolkit) as someone pointed out, but as far as I can tell this requires the applet on SIM card to cooperate (offer the opt out).
Otherwise you can disable the STK altogether with ADB but that will also block you out of other SIM card interactive functions, which might not be a big deal however.
Edit: "We plan to add the ability to restrict the capabilities of SIM Toolkit as an attack surface reduction measure. (2022)"[2] and open issue[3].
[1] https://wladimir-tm4pda.github.io/porting/stk.html
[2] https://discuss.grapheneos.org/d/1492-blocking-sim-toolkit-m...
[3] https://github.com/GrapheneOS/os-issue-tracker/issues/875
- [deleted]
Can't you just change your carrier?
I would rather have a phone that doesn't let my carrier show random messages whenever they feel like it.
- [deleted]
> GrapheneOS always strikes me as "perfect is the enemy of good"... I've been all right with all kinds of Android phones
I fully agree with you. I never received a reasonable reply to this from GrapheneOS fans or developers. Latest attempt: https://news.ycombinator.com/item?id=47182376
>Latest attempt: https://news.ycombinator.com/item?id=47182376
Your Qubes OS comparison doesn't really work because Android distributions need extra work to support each new device, whereas for Qubes OS, they're probably using some virtualization framework that makes it pretty trivial to add support for CPUs without virtualization. There's nothing stopping you from starting a new fork that supports your motorola phone, for instance.
I understand that supporting new phones is a lot of extra work. My only question is whether the developers of GrapheneOS would accept patches from community for such support without full set of security features.
"accepting patches" is still a lot of work and often means taking on the maintenance burden; i suspect that if qubes had to do extra hardware enablement work/maintenance for VT-d-less devices they might've had the same position
Qubes hasn't always shipped Xen patches nearly as quickly as I would like. It's the unfortunate reality of the situation they're in, simultaneously trying to catch up with broad-spectrum device support, with a miles-long HCL with many entries having sub-threads attempting to resolve significant compatibility issues. Don't buy hardware that's too new, don't buy hardware that's too old, certified hardware doesn't necessarily stay certified, and so on. It's a mess.
I love what they're doing and it's my preferred daily driver, but from a security standpoint they're still pushing molasses up a sandy hill.
You keep coming back to this. GrapheneOS accepting community patches with a reduced feature set (hardware security) degrades the nature of the project. It's an absurd proposal.
Fork it, make your own. Not only are they OK with that, they're actively supportive of it.
Criticizing them for not actively supporting the Balkanization and unavoidable dilution of the security and therefore total value of their project makes me wonder whether the strength with which you hold your opinions has any meaningful connection to the extent to which you even understand the subject matter. It's just mind-boggling the things you assert every single time an OS you don't even use comes up.
Your love of Qubes OS (which I share) somehow even increasingly seems rooted in something that just isn't reality. If it were, you'd be able to fairly assess both projects and see the relative strengths and weakneses of both with useful accuracy.
As it stands, you're just spouting harmful noise. Please don't do that.
GrapheneOS is not QubesOS. We have our own approach and goals. Our approach includes heavily focusing on our resources on our mission which includes needing to do a lot of hardware-related work to deploy features like hardware memory tagging. We're actively working with Motorola and Qualcomm on improving their hardware to meet our requirements. We're also going to work with Qualcomm on improving Linux kernel security. It's not part of our mission to support devices where we can't provide our core feature set. It would drain a huge amount of our resources and lead to people buying those instead of devices with real GrapheneOS providing all the features. Supporting devices with less than 7 years of support also isn't very appealing when we have those via Pixels and can have the same for the new devices.
GrapheneOS does support budget devices. Pixel 8a, Pixel 9a and Pixel 10a are budget devices. It's true that they aren't on the low side of budget pricing at launch but they have 7 years of support from launch. Pixel 8a is approaching 2 years old but has over 5 years of support remaining. The only limitation in practice is that Pixels aren't sold officially in enough countries yet, which can be solved by our Motorola partnership. We don't need more than a range of devices fulfilling what most people want which are available internationally. People would still need to go out of the way to buy a device with GrapheneOS support if we supported more than the 20 models we do.
You're also ignoring all of the work we have to do on devices which is already a massive amount with 20 supported models of Pixels. We build specialized releases with minimum attack surface for each with plans to use per-device RANDSTRUCT and other similar features too. We could make most of the OS builds generic as AOSP has support for it but it goes against our goals. We also have to test it on each device ourselves before Alpha. Each device needs to be tested more broadly by our community.
Our goals have never included supported a huge range of devices. It would drain our limited resources and destroy our ability to provide what we do. It would water down what GrapheneOS provides and sabotage our ability to partner with OEMs. It simply doesn't interest us. People are free to use LineageOS but we strongly recommend avoiding the supposed privacy-focused forks of it which are worse at privacy and security. On nearly any device you won't get basic kernel, driver and firmware updates with LineageOS and it's not a privacy or security hardened OS. Their time is largely spent on device support and it massively slows down how quickly they can do updates too. They wouldn't have time to work on the kinds of privacy features we do let alone the security ones. It isn't as if they're not working hard on their project, they just chose different things to work on and we aren't choosing those over what we work on.
GrapheneOS will run on more than Pixels soon. It will start with a regular flagship and then both flip/fold variants. It can then start supporting lower end devices once they improve. The OEM is going to be helping us implement and maintain it which is the only reason it's going to be practical to do it. We already struggle to support as many devices as we do but it's going to be easier on our end to support the ones from Motorola than supporting Pixels due to collaboration.
There it is.
Ahahah.... This thread doesn't show what you think does.
Unfortunately you come out as whining that the project focused on security doesn't want to support insecure hardware.
Go for it, fork, call it, say, ClayOS and have GOS on whatever you want. Why would someone else have to do something that's contrary to the project just because you want to lower the security?
Bizarre. Just fork it mate.
If you feel like you can't get a reasonable reply from anyone on a given subject, it's possible that the subject matter is purely indefensible and everyone but you is wrong about it, or it's possible that there's one constant in all this which you're overlooking.
Anyway, in terms of laptop/desktop security, Apple's doing the best job of anyone on that front at present and is still moving in the direction of improvement. Overall, modern Pixels running GrapheneOS are still the most resistant to a variety attacks, compared to just about any consumer device with any practical value.
Most laptop/desktop hardware architecture is wildly vulnerable in some specific ways that Pixels and iPhones just aren't, and no amount of OS enhancements built on that foundation will fully overcome its limitations. Your refutation to that is typically, "But, Google." I get it. I'm no fan of Google, but their architectural chops on modern Pixels is excellent.
Suggesting in the next breath that people look at the Librem 5 or PinePhone while criticizing the security of GrapheneOS makes me think you might just be completely out to lunch on this one. The Purism project is just not a serious security project in so many ways, and while I appreciate the appeal of hardware switches, the rest of their approach makes the hardware switches and domestic supply chain option and shipping protocols little more than security theatrics. The Librem 5 is so easily compromised that the switches are practically a necessity, I suppose, because the hardware and the software (from the OS to device drivers and--gasp--closed blobs!) just isn't trustworthy. With the clever rhetorical games they play to overstate the reality of the device it's difficult to place any trust in them.
'You shouldn't use this device because Google drove the architecture,' just isn't as compelling to me as, 'you should use this device with outdated drivers, no secure element, no sandboxing, and no IOMMU, no hardware resistance to attacks, baseband isolation that's literally an all-or-nothing affair,' and so on, is a terrible followup recommendation which completely undermines credibility.
You're citing hypothetical weaknesses as a reason to dismiss GrapheneOS while advocating devices with numerous demonstrable weaknesses. The Librem 5 not only isn't very resistant to attacks, it's highly vulnerable to attacks. And then you complain when serious people stop engaging with you. (Not being a serious person, I persist.)
As a former PinePhone user, it's a wonderful effort and I love that they're doing what they're doing, but the device and its software is just completely lacking in security to any real degree. Which is fine, because that isn't the device's reason for being, but we shouldn't overstate its position, which you continually do.
All that said, I genuinely think if you take the time to really fairly understand the situation, you'll find value in GrapheneOS as a project. Whether or not it's for you is another matter, but the only reason I'm bothering to quibble with a faceless stranger on the internet over the issue is because I think the project is one of the most important consumer-device security projects of this era, and I massively hope it succeeds. The planet will be better off for it if it does. And yet, every single time it comes up you make the same lazy dismissals of it, ignore substantive responses, then invariably play the victim when people eventually tire of playing your game.
A broader ecosystem of supported devices is something I very much hope for, and am excited to seem take the step into working directly with one OEM, and I hope for more. The virtualization aspects of their roadmap are exciting, and I expect they'll bring great upstream contributions to whatever hypervisor they choose, as they have for AOSP. Their talks of targeting a laptop which meets their hardware requirements is incredibly exciting, and here's hoping it's a ThinkPad, which seems genuinely possible now.
All this is the most compelling alternative to something like Apple, which, while great at leveraging the advantages of being the behemoth in the market, is too inherently motivated in its pursuit of commercial outcomes to be something I'm likely to want to use.
I lack any real hope that you'll come around on this one, but if you're going to play the game of linking to prior discussions to settle an argument, at least I now have a comment to link to, too. Thanks for fueling my future efficiency.
Oh wow, sir or madam, I adore your dedication and persistence.
Thanks for your extended reply, but many of your points are strawman. I never suggested that Librem 5 or Pinephone were seriously more secure than GrapheneOS. They may be more secure in small ways, depending on your threat model, like avoiding Google or allowing to use the kill switches. However I explicitly said more than once that I would be happy to use GrapheneOS on a more libre hardware (Librem 5), even if the security may be lower. Some people value an additional bit of freedom more than cutting-edge security.
> You're citing hypothetical weaknesses as a reason to dismiss GrapheneOS
Where did I say this? I do not dismiss GrapheneOS, and I do wish them success. I agree this is a very important project (and I upvoted all their recent posts for more visibility). I just feel that some of their decisions harm them more than they think, which is the reason for my parent question.
I suggest Librem 5 or Pinephone in my HN replies whenever I see people caring about mobile freedom more than about immediate security, which GrapheneOS provides. I do not suggest those phones as a more secure replacement of GrapheneOS devices.
> we shouldn't overstate its position, which you continually do
I do not see where I am doing this, see above. And I certainly didn't do it in my parent comment.
> Their talks of targeting a laptop which meets their hardware requirements is incredibly exciting
I have no idea how anything can be more secure than Qubes OS. I never received a reasonable answer to this question. And yes, virtualization (i.e., compartmentalization) is the best way to achieve security, in my opinion.
> in terms of laptop/desktop security, Apple's doing the best job of anyone on that front at present and is still moving in the direction of improvement
This is not even funny, given how many vulnerabilities are constantly being found in MacOS. You should just compare that with Qubes OS, which I use.
And I appreciate that you wish them success and think it's important. If you think so, please try to better understand the nature of what it is you're criticizing. If you're repeatedly met with push-back from numerous individuals but can't evolve in your understanding, you have to start asking yourself harder questions.
They aren't strawman. You pop up in Graphene OS threads like clockwork and recommend other devices. You say, "but Google hardware." I get not wanting to contribute to Google financially, I get not wanting their logo on a device, I get the general discomfort with anything Google. But it's akin to people being so anti-Google that even when Firefox on Android lacked nearly any sandboxing whatsoever and had downright reprehensible security practices, they'd continue to use Firefox on Android when visiting untrusted websites, because, well, at least it's not Google-adjacent. It's completely irrational and unjustifiable on anything but a totally emotional level.
You conflate privacy with security here, "They may be more secure in small ways, depending on your threat model, like avoiding Google," and yet you don't articulate any demonstrated connection between using Google hardware with GrapheneOS and Google's ad tech business. The closest thing there is needing to connect to Wi-FI to unlock the bootloader, but that's easily addressed. You cite a hypothetical backdoor that Google may have placed in the hardware, but unless you're physically examining every chip running every OS (and there are several) in every device you own (even the ones you think you've disabled the MIE on), you simply can't know that. You have to account for that, but you talk about it in ways that imply a project which accounts for it better than others hasn't, while one that inherently can't, has.
When they announce Motorola support, you're still on about avoiding Google. They literally can't win with you.
If you think their decisions harm them more than they think, but can't understand the basic factors at play, it's hard to take your determinations seriously. Good governance of a complex project is hard, and people snipe from the sidelines with virtually no understanding of what the actual situation is. By all indications the project is incredibly well run in all ways that practically impact eventual end-user security.
If you have no idea how anything can be more secure than Qubes OS, consider Qubes OS running on hardware with excellent security features, and the two being tightly integrated. There's your reasonable answer. That is literally the roadmap for Graphene OS. A hypervisor-based OS that's useful for end-user purposes by carefully layering on functionality to make a hypervisor-based OS some degree of usable.
The less reasonable reasonable answer is that you'd have better security if you ran Xen itself, as everything Qubes adds to make it usable potentially weakens it. It's just the nature of the beast.
It wouldn't surprise me if GrapheneOS lands on Xen for all the same reasons Joanna landed on Xen, and they end up contributing massively upstream to Xen security largely by tightly integrating it with said hardware. But I'm sure other patches will flow upstream with whatever project they choose, because their security chops are that good.
Qubes OS also lacks resources. They're supporting a massively bigger variety of hardware with a comparatively tiny user and donor base. By all indications their finances are nowhere near sufficient for what they really need to do. The project is as good as it currently is almost entirely down to the incredible efforts by a very small number of amazing people. If nothing else, the speed at which they can iterate and evolve is highly constrained. Remove 1-2 key players from the equation and the project almost invariably collapses. That alone is constitutes a definite security vulnerability.
Re: Apple, I'm talking hardware security. But even when you factor the software in, for a portfolio of consumer operating systems used by a billion and a half normies who expect it to do every normie task under the sun with very little frictional security overhead, Apple does a great job at security.
Edited to add:
> I would be happy to use GrapheneOS on a more libre hardware (Librem 5), even if the security may be lower. Some people value an additional bit of freedom more than cutting-edge security.
OK, but that's a nonsensical wish at best. There are other AOSP forks out there that would meet your needs. Buy a non-Google Android phone and load another AOSP fork. Or, fork GrapheneOS and modify it to meet your needs, thought that would be a largely pointless exercise. Repeatedly criticizing the project every single time it comes up for not wanting to completely change its fundamental nature in an ill-defined attempt to satisfy your inclination is a real head-scratcher.