Discussion

Back

emilfihlman: This is huge and amazing!

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

fsflover: > GrapheneOS always strikes me as "perfect is the enemy of good"... I've been all right with all kinds of Android phonesI 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

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

farkanoid: Not sure how I feel about this. Motorola seems to be the exclusive provider of encrypted cellular networks and associated devices to the Israeli military [1][2].I'm under the impression that basebands still require a proprietary/binary blob, basically rendering the security features of the underlying Open Source OS useless, since it sits between the user and outside connectivity.How can GrapheneOS ensure that there are no hidden backdoors (ie: Pegasus-like spyware, which was created by ex-IDF soldiers via NSO Group), etc, in the baseband?[1] https://www.whoprofits.org/companies/company/3808[2] https://www.motorolasolutions.com/newsroom/press-releases/mo...

raffael_de: > Not sure how I feel about this. Motorola seems to be the exclusive provider of encrypted cellular networks and associated devices to the Israeli military [1][2].makes me feel good about it.

Aeglaecia: what exactly makes you feel good about a privacy black hole with the worlds foremost anti privacy captain at the helm ?

imcritic: The opportunity to be blown up by your phone upon a trigger pulled by mossad. Obviously.

strcat: You're confusing Motorola Mobility with Motorola Solutions. These haven't been part of the same company since 2011. We would happily support devices from Motorola Solutions with their collaboration too but have no contact or partnership with them as they're an entirely different company. We want to support more devices meeting our requirements and if people have issues with one of the choices due to their opinions on geopolitics they can use another.

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

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

gruez: >Latest attempt: https://news.ycombinator.com/item?id=47182376Your 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.

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

handedness: You keep coming back to this. GrapheneOS accepting community patches with a reduced feature set 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.

strcat: You're confusing Motorola Mobility with Motorola Solutions. These haven't been part of the same company since 2011. We would happily support devices from Motorola Solutions with their collaboration too but have no contact or partnership with them as they're an entirely different company. We want to support more devices meeting our requirements and if people have issues with one of the choices due to their opinions on geopolitics they can use another.

fluffypony: I don't want to gush about this too much, but it's SUCH a big deal. Graphene has languished with hardware support for so long - they basically only had Pixel devices as first-class citizens, which are not bad devices per se, but it's hard when you're spending most of your time doing something without the manufacturer's support.There is a very real possibility that we end up with devices that can play modern mobile games at high frame rates on a secure, privacy-focused mobile OS, which is a huge step towards general adoption of something like this as a daily driver.

bubblethink: This is such a strange comment that is full of contradictions. Pixels are supported because the manufacturer supports alternate OSes. I don't get what languishing means here. Pixel hardware lags behind the latest Snapdragon hardware, but it's not something that average people know or care about. So, you can gush all you want, but I don't see why it's a big deal. It's great that they found an OEM and it's great for the overall health of the project, but not because of gaming or the latest Snapdragon.

gchamonlive: Does pixel support alternate OSes or it just doesn't get in the way of custom firmware developers?And for the gaming aspect, there is a huge market for mobile gaming, specially in Asia, so having a manufacturer like Motorola adopting GrapheneOS as a first class citizen will improve the chances that high performance applications will have better performance in such OSes which is a big win.

throawayonthe: i mean, that sounds like a subjective distinction, but it lets you unlock the bootloader and then re-lock it with your own keys so eh..?

gchamonlive: [delayed]

thisislife2: This is great news - would love to run Sailfish OS on it. Wonder if it can dual boot?

strcat: SailfishOS is a largely closed source OS with poor privacy and atrocious security compared to the Android Open Source Project even without the improvements made by GrapheneOS. It doesn't and likely won't use any of the security features which are being worked on with Motorola and Qualcomm. Why buy a device based on it providing GrapheneOS support to run an OS without similar needs?

m00dy: I think banking apps especially the ones in UK, won't work on this device.

strcat: 90% of banking apps work on GrapheneOS. Curve Pay works for tap-to-pay.https://privsec.dev/posts/android/banking-applications-compa... has a UK section.

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

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

t0bia_s: Hopefully those Motorola devices will be smaller than Pixels.

strcat: The initial supported devices will be flagships. They have regular, fold and flip variants of the flagships. The main advantage of flip phones is better one-handed use.

wobfan: The biggest argument for me to buy one of these phones - when they actually arrive - next to running GrapheneOS, will be whether these phones, like all others, are way too big to use with only one hand. Like, I don't have a lot of requirements. Just make it run GrapheneOS and let it be >6 inches. I'll immediately buy it.

strcat: The initial supported devices will be flagships. They have regular, fold and flip variants of the flagships. The main advantage of flip phones is better one-handed use.

flawn: It would be amazing if GrapheneOS would distribute rooted versions of their OS with locked bootloader

strcat: Persistent app-accessible root greatly regresses OS security and breaks the verified boot security model. We're definitely not going to increase the number of build variants from 40 to 80 in order to provide an insecure option which would take away from efforts to properly implement features instead of doing it via hacks using apps running commands as root. If you want it you can make your own builds with it instead of us doubling the number of builds and deltas we need to make. Most of the people doing it are modifying the official builds and resigning them. Anyone who can understand the consequences of app-accessible root is capable of doing that.

flawn: I get that but the core issue is not inconvenience but the fact that also doing that still locks you out of applications that many people call essential (tap2pay, banking, streaming, other various apps relying on Play Integrity).Google is actively locking down the ecosystem in that regard and it would be amazing having a company that caters to people that are savvy AND would like to still be attested for integrity tests (assuming Google would be OK with that, but as mentioned in another comment unlikely)

ForHackernews: I think this is great news, but I thought GrapheneOS considered unlocked bootloaders to be a terrible security risk? What's changed?

strcat: It has always been a hardware requirement to be able to unlock the device, install GrapheneOS and lock the device again. Verified boot has been a requirement since it was introduced for Pixels and the is main benefit of locking the device. There are additional security features enabled by verified boot. The overall hardware requirements are listed at https://grapheneos.org/faq#future-devices.

butz: Will this help running Linux mobile OS'es on Motorola phones, like postmarketOS?

Aachen: That would be as big as Signal stepping away from the phone number requirement. Sadly I've lost hope on both of these, no idea why obviously good things (I'd say pro choice if it didn't have another connotation) are always such a no-go

strcat: Persistent app-accessible root greatly regresses OS security and breaks the verified boot security model. We're definitely not going to increase the number of build variants from 40 to 80 in order to provide an insecure option which would take away from efforts to properly implement features instead of doing it via hacks using apps running commands as root. If you want it you can make your own builds with it instead of us doubling the number of builds and deltas we need to make. Most of the people doing it are modifying the official builds and resigning them. Anyone who can understand the consequences of app-accessible root is capable of doing that.

Aachen: Hi strcat, we had this conversation often enough that I'm starting to recognise the username. It's the same every time: Graphene argues it's dangerous, tech-savvy users want it but aren't necessarily interested in the upkeep (even if they're technically capable of making such a build), plus missing security patches (part of the point of this OS, otherwise you can use Lineage or whatever), and Graphene is under no obligation to provide anything to anyone. Same arguments today as they were from the start except now maybe the security patches' embargo time makes it even more hostile to do custom builds by power users

Frannky: Damn I would love to buy it. In the past I tried different mods trying to get rid of google, the problem was always the same, lot of little annoyances making it very painful for daily usage. A de Googled phone without annoyances and security would be very cool.Another interesting thing is that I haven't had any reason to buy a new phone in a very long time so we are probably in a time where the hardware is commodotized enough for motorola to be able to ship exactly what I need.Never thought I would have think of routing for Motorola in 2026 but you never know!

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

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

gvurrdon: Would there be any means of preventing apps from seeing one's phone number, IMEI etc.?

tarruda: One thing that annoys me is the ability that my mobile carrier has to just throw ad popups.Is that something that GrapheneOS fixes?

pluc: Your carrier does what now?

tarruda: I have a pixel 8a with a TIM SIM card and every once in a while I see an ad popup on my phone.

pluc: 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

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

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

mmh0000: If true. And I put a big if on that.I WILL be buying their flagship model.My go to for Graphene has been used Pixels from eBay. Because I can’t give money to Google in good conscience.

dataflow: You should really try to buy any phone used if you can, whether Pixel or Google or not.

scrollop: Why?

dataflow: For the environment? To reduce e-waste? And you'll almost certainly save substantial money too.

palata: How good is it for the environment / e-waste? If you buy a used phone every year from someone buying a new phone every year, it means that you both use one phone every two years, right? It's a lot worse than buying a new phone and keeping it for 8 years.If I said "I buy new phones regularly, but I sell them in second hand, for the environment". Would you consider I actually make an effort for the environment?

dataflow: [delayed]

thot_experiment: I'm not holding my breath but it would be amazing to have root and be able to tap to pay without constantly playing cat and mouse with google.

diacritical: Unfortunately from what I read a couple of times, including a month or so ago, GrapheneOS discourages and doesn't support rooting the phone for security reasons that seem vague to me and don't appeal to my need to actually own my phone and OS. You could still root it with some third party tools from what I know, but not having root as the default makes it less of a secure FOSS OS and more of a closed down toy.As for payment apps and other crap that refuses to run if I, the owner and administrator of my own device, don't have admin access, I would just refuse to run it. What's next - websites refusing to work if I have root on my Linux desktop?

strcat: LineageOS also discourages and doesn't support replacing the core of the OS with a rootkit providing persistent app accessible root. GrapheneOS is no different from LineageOS in that regard. People do this with GrapheneOS regardless of our strong recommendation not do it. Our reasons for discouraging it aren't vague. It very directly harms the security model and is not a good approach to implementing any of the features hacked together through it. Those features should be properly implemented to fit within the overall approach taken by GrapheneOS. Giving root access to a huge portion of the OS harms security even if you never use the feature. It does not mean you can't do it, we only recommend you don't.

Narushia: I agree that the features should ideally be provided by the base system so that the user does not have to "hack them in" with root-powered apps. But the reality is that most Android "distros" simply do not support the features that I would consider basic functionality. I mainly root for three reasons:- Backing up all app data via Neo Backup. Android has an auto-backup feature that backs up app data to the user's Google Drive, but unfortunately the app developer can simply opt out of this, and the user cannot do anything about it. The app data may be lost when migrating to a new phone.- High-quality call recording via Call Recorder. For some reason, some (most?) phones do not allow apps to access the raw incoming audio stream. Non-root apps have to rely on capturing the other end through the microphone, which is horrible.- /etc/hosts-based ad blocking while using a VPN via AdAway. DNS-based ad blocking is possible via apps like AdGuard, which use a local VPN to accomplish this. Unfortunately, Android only allows one VPN connection at a time, which means that without root I would not be able to use a VPN for any other purpose and block ads simultaneously.---I have no experience with GrapheneOS, so I'd be interested to hear if these features are possible on it without rooting. If not, can I request these features somewhere?

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

handedness: There it is.

handedness: "Every time someone makes the same unreasonable demand of you, you offer the same explanation of why their demand is unreasonable."

Imustaskforhelp: Is this feature gonna be on All phones including Low-end/mid-end (4-8Gb ram) and their flagship phones?It's gonna be huge if that's the case because Pixel's here are expensive, their second hand prices are in "non-global" countries[0] and you have to pay a premium. Also I live in world's largest second-hand phone market and it can have its worries as well.You can't say to anyone who wants privacy, oh just buy a second-hand pixel. It's just not that easy.But if Motorola can launch multiple phones and there are always gonna be some deals one way or another (with cards) and as motorola phones are pretty competitive in price, Finally we can have phones worldwide where privacy isn't charged extra.I have spent some hours looking at online second hand phone stores to find but due to its somewhat rarity, I always feel like being frugal, I am just paying extra for privacy and so I am really happy with decision from motorola using their supply chain of phones and partnering up with Graphene.I was gonna buy a phone for myself, I was thinking a second hand pixel phone but given the things I said earlier at this point, I might as well wait for a few more months to get the moto phone.I just hope that they launch an affordable phone with grapheneos. I really don't care about specs as I have been able to live my life with 7 year old motorola phones too in 2026 for sometime.I will definitely recommend my family Motorola phones in the future and slowly convert everyone to motorola if motorola releases an affordable phone with actual privacy.[0]:https://www.xcitium.com/blog/news/why-is-google-pixel-not-gl...

backscratches: graphene has said only flagships at first, but eventually they hope to end up on lower tier devices.

Imustaskforhelp: Looks like I might have to wait for sometime then but still I am pretty excited about it yea!

HugoTea: GrapheneOS doesn't give you root access, citing security issues it introduces. You could re-compile your own copy with root access, though not sure if we'll then be back to some non-certified OS that can't make payments...

thot_experiment: Yikes. Nevermind. The whole phone security model is one of the worst things to happen to computing, the concept that you shouldn't own your device for safety is so fucked.

charcircuit: Android is not UNIX, and that's a good thing. The root account was a historical mistake and not having access to it doesn't mean you don't own your device. That mindset is just trying to project how things worked with a half century old operating system with how modern operating systems work.

fsflover: Perhaps you may be interested in Librem 5 or Pinephone, both of which have hardware kill switches for modem and available schematics. The latter even has most of the modem software freed.

strcat: Those devices have atrocious security at a hardware, firmware and software level. Their microphone kill switch also doesn't prevent audio recording. They aren't open hardware despite many attempts to mislead people with the marketing.> The latter even has most of the modem software freed.Pinephones have entirely closed source baseband firmware. They use a highly unusual cellular radio which includes both an incredibly outdated Qualcomm baseband processor with atrocious updates and security combined with an extremely outdated proprietary fork of Android running on an extra CPU core which isn't present in any mainstream smartphone. It's only replacing the unusual extra OS which has been done. That whole component doesn't exist on other smartphones and the only reason it's possible to replace it is because the whole radio has absolutely atrocious security. The radio is connected via a far higher attack surface USB connection providing far less isolation for the OS and the USB connection can be used to flash the proprietary Android OS via the fastboot protocol. The baseband firmware itself doesn't have any replacement available.

daneel_w: > Pinephones have entirely closed source baseband firmware.> The baseband firmware itself doesn't have any replacement available.Same with the Google Pixels and their Samsung Exynos modem. Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceivers. What will it be for the upcoming Motorola phone?

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

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

Itoldmyselfso: 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.https://grapheneos.org/features#sandboxed-google-play

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

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

distantranges: The only thing that keeps me from switching to GrapheneOS on my Pixel 10 pro is satellite SOS which isn't supported on GrapheneOS. It's something important to me as I do mountain sports and in some locations there is no network signal.I know that in the US Verizon and Tmobile customers have access to satellite connectivity and it's possible to get this feature working on a GrapheneOS phone if you are one of their customers, but I am in Europe and European providers don't provide satellite connectivity.

fsflover: Removing access of users to their device is not security. At least not when users do not want this.

ibejoeb: Got it. That makes more sense, i.e., that you're essentially required to use it rather than getting something in addition.

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

hn_acc1: There are a couple of apps I use that I kind of need: jb4 and Mando ECS (both for my car). Would be nice if they worked - anyone know?My S21 FE 5G is still fine (for now), going on 3 years. But I'm sure Samsung will cripple the battery life at some point..

thisislife2: Let me give you another perspective - you cannot fight a foreign state that wants to hack your device and access your personal data. Even Apple iPhones, who often taut how "secure" their devices are, remain vulnerable to state spywares. A secured device, at most, will protect your data from the police or lay cracker or malware, who lack the means to use more sophisticated methods to access your data. When Android forks (like Lineage OS or Graphene OS) advertise that their Oses are more "secure", with better "data protection", what they mean is that their OSes try and prevent data leakages to the OS vendors (like Google or Apple or other BigTech) or to online services integrated with the OS or through system and user installed apps. In other words, "privacy and security" primarily means that they try and prevent surveillance capitalism.

chpatrick: Actually Graphene has been shown to be resilient (uniquely) to some of the forensic tools used by governments.

M95D: Probably because nobody targeted them yet.

latentsea: Which demographics do you think run GrapheneOS as a daily driver other than people who have shit to hide? They've definitely been targeted.

NotPractical: ...apparently most of HN, judging by these recent threads?

yooastan: A physical keyboard device with GrapheneOS would mog

WithinReason: Just buy a keyboard case for it, no need for permanent attachment. Or carry a tiny bluetooth keyboard in your pocket:https://www.amazon.co.uk/dp/B0FWC8G2Q8/

bitwize: Ah, Doohoeek, a time-honored, trusted brand.

hn_acc1: I'd rather buy from Doohickey.

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

tarruda: 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?

deno: You can tap on the three dots to show System apps and see if you can disable the permission for SIM Toolkit.

ysnp: The Google Pixel has first-class support for alternate OSes (not custom firmware like a Chromebook). The OEM has to go out of their way to support avb_custom_key as mentioned in https://android.googlesource.com/platform/external/avb/+/mas... and I believe the GrapheneOS founder strcat was heavily involved in helping Google design this feature and flow for Android Verified Boot.

Ms-J: While it's nice to have somewhat of a choice between terrible and bad, we need a Linux based OS that doesn't depend on Google at all.While I'm at it, I don't trust GrapheneOS. The devs injecting certain types of politics into the project.But it's better than both Apple and Google who both are known to spy and have tons of backdoors.

deno: Apparently this is handled by the privileged STK[1] service. It can launch browser which is I think what's happening.GrapheneOS doesn’t do anything different in this case, they pull it from AOSP without modifications. However you can disable it using SIM Toolkit App as someone pointed out.[1] https://wladimir-tm4pda.github.io/porting/stk.html

Fokamul: Banking apps will be catastrophe in the future. Petition your bank, you want to use PC web app with certificate authentication.If they don't support it -> notify them and change bank. Enough people doing this, something will change.

dns_snek: Good luck with that. Of all the things people don't really care about, I think that might be at the far end of the list.Certification authentication is neat technology in principle, I use it internally, but in my experience anyone who recognizes it also hates it passionately. It's the thing that seemingly stops working every time their taxes are due, courtesy of terrible government software.If I started telling people that they should be demanding certificate authentication from their banks, they'd probably think that I escaped an asylum.

DANmode: > Neither you nor GrapheneOS users have any idea at all what's going on in their cellular transceiversPixel has an IOMMU - are you implying that’s being defeated, or that you weren’t aware of it?

Aachen: Read what I wrote, "demanding" was addressed (though with the word obligation, functionally the same here):> and Graphene is under no obligation to provide anything to anyone.And here I thought it felt repetitive between (sub) threads

dns_snek: You say you understand that they're under no obligation to do anything, you already knew their reasoning, yet you still wrote a comment [seemingly] complaining about it. Was there a different purpose to it?

DANmode: Yeah, I hide that I’m using apps from other spyware apps.What of it?

kevincox: Yeah, this is the deal breaker for me as well. The fact that I own my device is non-negotiable. It is the reason I left the stock OS and I'm not going back. The idea that I can't access my own files if an app doesn't explicitly give me access is wild to me. I understand there are security risks of a root permission but it is important to have that fallback when you need it and the existing permissions aren't sufficient.

thot_experiment: The "access your own files" thing is so insane! Hard to describe my feelings [negative] when I found out that all of my voice notes were in the voice recorder and the easiest way to get them out was to manually send each one to myself over discord. Google helpfully mentions that you can just "download them through google takeout" and doesn't leave any option for people who don't just give all their personal data to google.

MSFT_Edging: I use a FOSS voice recorder app from F-Droid. It's just called "Voice Recorder" with an orange icon. It does exactly what it says, records audio from your microphone, lets you play them back. They're just files on the device.Anytime I need a "simple" utility, I check f-droid first to get the one-trick-pony app over spyware from the play store.Other utilities I use are: WorkTimer: pomodoro app DiskUsage: self explanatory Http Request Shortcuts: setup home screen app shortcuts that run http requests

thot_experiment: Yeah I swapped to using the f-droid version after that debacle, though the one i use has a green icon. XD

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

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

ethbr1: > Pixel A's are quite affordableThere's first-world, upper-middle-class affordable (~$500) and then there's global affordable (<$250).

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

thot_experiment: What a disgusting take. It's actually so depressing to see anyone say this, presumably sincerely. It's how all the modern operating systems I use work.It's what makes computers so wonderful and powerful, you can just have it do whatever you want. Turning that into "whatever google decides i should be allowed to do" is not gonna lead us to a bright future.

daneel_w: Neither. It's great that the Pixels' baseband ACPU doesn't have free reign in system memory, but if we're gonna underline the deficient state of the cellular modem in the Pine Phone we should also remind ourselves that the firmware situation with the Pixels is an almost equally sore thumb.

milkytron: This is great to hear, I've been wanting a flip phone for a while. GrapheneOS on a Moto Razr would actually be incredible. Thank you for all of your hard work and being active in this thread. I'm looking forward to getting my hands on a Motorola with GrapheneOS :)

ysnp: Hi daneel, what would you like GrapheneOS to do while you develop your own formally verified, open hardware, open source firmware&#x2F;OS baseband processor they can use? Sit on their hands doing nothing or making the best of the least worst options currently available?

daneel_w: The Pixels already are the best of the least worst options currently available. Anything new must categorically bring improvements, and the closed source firmware of the Pixels is a pressing point.

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

patrakov: Speaking about the Philippines here.First, how about Philippine National Bank? Compare snapshots of their front page, https:&#x2F;&#x2F;www.pnb.com.ph&#x2F;, on web.archive.org, and see that they have completely removed the link to their Internet Banking system. Only Mobile Banking remains.See also https:&#x2F;&#x2F;web.archive.org&#x2F;web&#x2F;20220605084957&#x2F;https:&#x2F;&#x2F;portal.pn...Also, Metrobank threatens to make it impossible to log into their online banking website without the mobile app installed. This is already officially the case for their corporate banking, but it's just TOTP with a non-extractable (on a non-rooted phone) seed and some anti-root checks under the hood.Finally, the following mobile wallets and "digital banks" are app-only: GCash, Maya, GoTyme Bank. The first two are the only ways to pay for water here, other than going to a kiosk where someone else would use their GCash account to process your payment.

aussieguy1234: I too have been buying used Pixels, mostly for environmental reasons. But from a local shop phonebot. Got 3 phones from there, no issues at all.

Barbing: Buying used introduces such a big supply chain risk. I stay safe by buying direct and asking the NSA not to open the shipment in the order notes.(y’all know this one https:&#x2F;&#x2F;arstechnica.com&#x2F;tech-policy&#x2F;2014&#x2F;05&#x2F;photos-of-an-nsa... )

aussieguy1234: I put GrapheneOS on the phone myself.I wouldn't trust the OS shipped with a used phone.NSA could technically do this with a new phone also and probably has.

subscribed: These reasons for not supporting the root have been stated on their discussion forum multiple times.But they do not stop you from doing so, you can fairly easily build your own images with root enabled.

subscribed: I usually buy refurbs similarly like I buy 2 year old cars.Currently I can get brand new Pixel 8a on ebay for £250 or similar, and refurbs from "flawless" to mint" conditions for half of it.Still good enough.

rationalist: You know what would be good for security:Having physical disconnect switches (Bluetooth&#x2F;Wifi, Modem, Power, Microphone&#x2F;Speaker), and integrated lens cover like Lenovo laptops (at least for the front camera whereas a case can cover the rear cameras).On a side-note:Triple active SIM would be amazing, but one can dream. I would love to have a phone that has an active AT&T, T-Mobile, and Verizon SIM at the same time.

dotancohen: > You know what would be good for security: Having physical disconnect switches Wouldn't those become failure points? Anything mechanical will not only wear, but will be affected by dust, dirt, sand, dead skin cells, body oils, etc.

mmooss: It depends on how durable they make the switches. Lightswitches, for example, tend to be durable.

yehoshuapw: the smaller something of that type is, the harder to make it durable (I think)

rationalist: A reasonable assumption.The Vibrate&#x2F;Ring switches on the older iPhones seem to hold up though, so maybe something like that?

DANmode: It doesn’t feel equal to me, here in my real-world usecase.

Andromxda: Rooting is a very bad idea. https:&#x2F;&#x2F;madaidans-insecurities.github.io&#x2F;android.html#rootin... But GrapheneOS is fully open source and provides great build instructions, so you can always make your own build and add whatever features or privileged apps you like within the standard AOSP frameworks for privileged apps with system integration.> Backing up all app data via Neo BackupGrapheneOS includes Seedvault by default. https:&#x2F;&#x2F;grapheneos.org&#x2F;features#encrypted-backups> High-quality call recording via Call RecorderCall recording is built into the Dialer app on GrapheneOS. https:&#x2F;&#x2F;grapheneos.org&#x2F;features#encrypted-backups:~:text=Cal....> DNS-based ad blocking is possible via apps like AdGuardDNS-based blocking can also be accomplished by using Android's native Private DNS feature with a resolver that blocks ads. You could even host your own on a VPS if you are more comfortable running name resolution and DNS-level adblocking on infrastructure you control.The RethinkDNS app also lets you use DNS-level adblocking and a VPN at the same time. https:&#x2F;&#x2F;grapheneos.org&#x2F;faq#ad-blocking-apps> I have no experience with GrapheneOS, so I'd be interested to hear if these features are possible on it without rooting.I recommend giving https:&#x2F;&#x2F;grapheneos.org&#x2F;features a read.> If not, can I request these features somewhere?Check out the issue tracker on GitHub: https:&#x2F;&#x2F;github.com&#x2F;GrapheneOS&#x2F;os-issue-tracker&#x2F;issues

thot_experiment: Rooting is only a bad idea if there is an alternative. Unfortunately I have to root my devices because there isn't an alternative method to provide me, the physical owner of the device with control over the device. I would much prefer not to generally have root on my phone but to be able to access root externally or via a hardware switch or some other scheme. ADB root is fine.The alternative to "running as root" isn't "not having access to root".

thunderfork: >Rooting is only a bad idea if there is an alternative.An alternative to accomplish what?>to provide me, the physical owner of the device with control over the deviceControl over what properties or behaviours of the device, exactly?No offense, but these complaints feel more like aesthetic ("I want to log into a user named root") than practical ("I want to be able to do things that could only be done under root")

konform: > I need swipe typing though, and I haven't found anything even close to gboard glide.https:&#x2F;&#x2F;f-droid.org&#x2F;packages&#x2F;helium314.keyboard&#x2F;HeliBoard is currently asking people to volunteer swipe data so they can further improve on free and open alternative for swipe keyboard. Please consider helping out!https:&#x2F;&#x2F;github.com&#x2F;Helium314&#x2F;HeliBoard&#x2F;wiki&#x2F;Tutorial:-How-to...https:&#x2F;&#x2F;makertube.net&#x2F;w&#x2F;cQECfDkuLGR9eUQquUEo4K

adrianwaj: Also a disconnect switch for the telco signal. Yet in my experience, even when turned off, a phone may send out a signal periodically anyway for tracking &#x2F; triangulation purposes.However to avoid that, removal of the battery is required. A disconnect switch for power would do the same?I think moving to micro-PCs is the answer, and then having an add-on to get a telco-signal. Why trust Motorola? Start at grass roots where possible. Everything needs to be open-source and based on open standards. No trojans, telemetry or remote overrides.Maybe the product is an adapter case for a Pi that adds a screen, battery, antenna and whatever else is required to make it a smartphone alternative?Also, looking forward to Mecha Comet.

staplers: I think moving to micro-PCs is the answer Would be shocked if hardware is affordable enough for such a thing in a decade

adrianwaj: This is the most cost-effective mini PC right now, that I've found. Also, one of the smallest.https:&#x2F;&#x2F;www.aliexpress.com&#x2F;item&#x2F;1005005575993915.htmlI'm not so fond of it because it has a fan. But if you could use it at home, and then had a "phone conversion housing" you could attach it to a belt and have a smartphone. Run wired earbuds out it. Have a trackpoint nub.Here is a $15 screen. https:&#x2F;&#x2F;medium.com&#x2F;@lee.harding&#x2F;building-a-real-time-hn-disp...There's something elegant about only requiring 1 computing device for everything. Even put it in the car!It's what Steve Jobs would want.

scheme271: The power draw looks like it's at least 4W with a max of maybe 45W. That's maybe 7 hr with a 10000 mAh battery assuming it's sleeping the entire time and not really doing anything. Not very practical for people used to a small phone lasting all day without a charge.

adrianwaj: Surely there's a way to power down parts of it to reduce the draw? Is that a thing? Like having a V8 and only bringing in cylinders when they're needed. Couldn't cores be disabled? On-demand telco and wi-fi. Even having minimal threads activated and perhaps on-demand DRAM over a typically DRAM-less SSD.These ideas would have to go into a new design.

NotPractical: You should probably ask the parent commenter. I think GrapheneOS is a good choice even for those that don't have something to hide.

thot_experiment: You're missing the point completely, of course there are more secure ways to do a lot of things, the problem is that if there isn't an alternative "secure" mechanism to accomplish what I want if I have root I can just get it done whatever way works for me. I do not want to run into a situation like I did prior to having root, where my voice memos unbeknownst to me end up in some sort of elevated privileged enclave and I can't copy them over to my computer.There's a myriad of reasons to have root, like baseline I want to be able to watch my network traffic. I want to be able to spoof my location, I want to be able to sftp into my phone and mount it as a drive because it's convenient. I want to access sensors and log them in the background. I wanna just run normal linux daemons.I don't need any of these reasons though, all I need is the desire to be the ultimate arbiter of what happens on my devices. I don't need to or want to control all aspects of what goes on my device, I'm fine giving up control, I'm not fine with it being taken away from me. Everything else is secondary, the person with final say on what happens on my device should be me.

gruez: >but not having root as the default makes it less of a secure FOSS OS and more of a closed down toy.I don't get it, it's "less of a secure FOSS OS" to not have root by default, but it's secure to run random apps as root and breaking android's security model? What's the threat model here?

treyd: Those "random apps" are foss terminal emulators and other various foss apps I explicitly installed.

gruez: So what's wrong with using avbroot or magisk to root?

infogulch: The FUTO keyboard is pretty good. All offline, customizable design, good speech recognition, tolerable swipe typing. It's published under a distinct opensource-ish license if you care about that. It's technically a paid app but with an indefinite trial period and and a license checking scheme based on human trust (click the 'yes I bought it' button and it accepts). Worth $5 imo, I bought additional copies for friends and family too.https:&#x2F;&#x2F;keyboard.futo.org&#x2F;https:&#x2F;&#x2F;github.com&#x2F;futo-org&#x2F;android-keyboard

smusamashah: Didn't know more people are doing this. I am also using a used Pixel 4a which I got from eBay. Still has good battery. I don't see any reason to upgrade any time soon.

DANmode: Security patches.

DANmode: Imagine downvoting “security patches” on Hacker News.

NewJazz: Triple active SIM would be amazing, but one can dream. I would love to have a phone that has an active AT&T, T-Mobile, and Verizon SIM at the same time.You can fit several esims on one of these adapters AIUI.https:&#x2F;&#x2F;jmp.chat&#x2F;esim-adapter

rationalist: That doesn't allow you to have all of them active at the same time. You can already store multiple eSIMs in newer Pixel and iPhones (you just cannot use more than two SIMs&#x2F;eSIMs at a time).Stored SIMs&#x2F;eSIMs is not the same as active SIMs&#x2F;eSIMs.

NewJazz: [delayed]

worldsavior: I'd say you're paranoid. Nobody cares about you, and they won't invest billions just so they can see your hot nude pictures. There are much easier ways to get information out of a phone, no need for a backdoor.If there were ever any backdoor in some phone, it would have been found. No smartphone company is gonna take that chance that someone will find their backdoor, it will literally kill the company.

samplatt: >If there were ever any backdoor in some phone, it would have been found. Not only have MANY been found, but the whole security industry is aware of them and works with&#x2F;against those backdoors.This is kind of like a mechanic not knowing what a car's exhaust does...

bornfreddy: Let me guess - you like Apple?

charcircuit: I think they build good products and their operating systems are ahead of their competitors in the space.

Barbing: Def gotta wipe used stuff.I have read comments from people who buy the new iPhone on day one but do a factory reset before touching it!

t1234s: With Motorola being owned by the Chinese company Lenovo can these new devices be used in secure environments? I remember when Lenovo took over making ThinkPads they were banned in some secure environments because of Lenovo links to CCP.

Charon77: The whole point about having an open platform from boot is you don't have to trust it. You run your own code from first power on.Is it possible that it's backdoored, have a secret opcode &#x2F; management engine? Probably, but that goes to everyone, as it's not practical to analyze what's in the chip (unless you're decapping them and all)I don't know what secure environments you're talking about, if it's an airgapped system then you should be secure even when what's inside 'tries to get out'.

Haven880: Korean and western made stuff guarantee to have such thing. CNC devices in Russia stopped working. Even NVIDIA gpu has back door according to China and NVIDIA had to settle this matter behind the scene with China government. At this point, your phone is 100% backdoorable by western government. The only thing protect you is you are non-threat and too small to be bother with.

akimbostrawman: >Even NVIDIA gpu has back door according to China and NVIDIAThey never said or claimed that. They rised concerns about and asked about _possible_ backdoors the same way the west does about china e.g. Huawei.

strcat: SailfishOS doesn't use the security features which are being worked on and doesn't keep up with kernel, driver and firmware updates. It doesn't use secure elements, verified boot or hardware memory tagging so it doesn't need the work being done on those things. They don't have similar requirements for hardware and have little use for what's being worked on for these devices.The portions of SailfishOS specific to it are largely closed source including the user interface and application layer. It isn't possible to fork the overall operating system. It has much worse privacy and drastically worse security than the Android Open Source Project even without taking the GrapheneOS improvements into account. It's in an entirely different space and this has no connection to it.

thisislife2: True, for the most parts, and that's because they are resource constrained and Jolla is on the verge of bankruptcy. But all that's not important to me. I care more about privacy (surveillance capitalism) than "security" (from state actors or malicious hackers). And seek diversity in software system by not supporting the duopoly of Android and ios, both from American BigTech. Sailfish OS ( https:&#x2F;&#x2F;sailfishos.org&#x2F; ) meets those requirement better. If Graphene OS becomes popular, it likely to be gobbled up by one of the BigTech, just like Microsoft's investment in Cynaogenmod ... moreover, with Google slowly making Android more and more proprietary, I personally don't see a good future for GrapheneOS, and bet on Sailfish OS outlasting it.

fsflover: > Their microphone kill switch also doesn't prevent audio recording.Unless you provide some evidence, I will consider this false accusation.> They aren't open hardware despite many attempts to mislead people with the marketing.Who and where said they were open hardware?> extremely outdated proprietary fork of AndroidWhich was freed and can run new Linux kernels now: https:&#x2F;&#x2F;github.com&#x2F;the-modem-distro&#x2F;pinephone_modem_sdk and https:&#x2F;&#x2F;xnux.eu&#x2F;devices&#x2F;feature&#x2F;modem-pp.htmlYour walls of text are disingenuous.

sandreas: If anyone from Motorola is reading this: Please add a smaller device to your Portfolio, about max the size of a Pixel 8. I'm not hoping for an audio jack any more but at least small it could be.All in all: Thank you for making this possible.

simonmales: The small form factor phones simply do not sell. Some great thoughts on the topic:* https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=iR9zBsKELVs * https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=vZdbbN3FCzE Not about small form factor, rather enthusiast phones don't lastCurrently running a Sony Xperia 5 V which farm factor is acceptable, and still will get a number of months of updates. And the winning point is that the bootloader can be unlocked and is supported by LineageOS.

Propelloni: I run a Xperia 10 V. Great phone, great form factor, easy to unlock. It runs for days, almost a week, on one battery charge. Sony is doing something right here.

Tarsul: I got the same or similar but let's not kid ourselves that this is in any way small. It would have been giant by 2015 standards. That's how much the overton window has shifted.

Propelloni: I have several points to say to that.1) 2015 saw the iPhone 6s, which was only 15 mm shorter than the Xperia 5 or 10 V, while being about the same width and thickness. It had a tiny screen in comparison. The 6s Plus was larger, and heavier, than the Xperia 10 V, in all dimensions (OK, not thickness, this was the time of "paperthin" phones) while still having a smaller screen.2) I don't want a tiny 2008 smartphone, I want a phone I can use with one hand. A width of 70 mm or less lets me do that. Today, that is small, in 2015 it was about normal.3) My perfect phone was the Samsung Galaxy S6 Edge from 2015, which has about the same dimensions like the Xperia 10 V but the rounded screen edges made it easier to use with one hand.

dotancohen: Doesn't buying a used pixel encourage the sale of new pixels by demonstrating a healthy resale value?

alt187: Yes, because everyone is a perfectly rational agent in the economy.

jMyles: Even though there doesn't seem to be huge mainstream consumer demand for this (although I actually question how well consumer demand for privacy and customization can ever be ascertained when the price signals are corrupted by a market where the winning players are essentially chosen by the state, as is arguably the case with both TSMC and Qualcomm), it still feels like the world simply couldn't go on with both iOS and Android become caged, cheapened, fragile shadows of the visions we once had for them (particularly AOSP).

windexh8er: Not to be flippant but who cares? People don't know there's an option. I've run Graphene for years and will gladly pay a premium for it. Beyond the bolstered security the battery life is exponentially better than a default Android device because of all the constant background traffic that Google doesn't allow any control over that you instantly have a choice with on GrapheneOS.And as soon as you start showing these things to people they do start to care and ask how. So the fact that the mainstream is ignorant and doesn't care enough yet doesn't matter because it's very likely a much larger segment of users will care when the tech evangelists they trust stop using IOS and Google Android. That's how these things started and that's how they could very well play out in this scenario as well.

jMyles: Yes, I agree in full. Did you think I was taking a position contrary to this one?

windexh8er: My point was irrespective of your position: it doesn't matter. The mainstream won't break the Apple&#x2F;Google cycle the same way the mainstream didn't break the lock carriers once had on software updates for phones. Apple broke that through its small but influential technologists and prosumers. Motorola can potentially be that for breaking out of the locks Apple and Google have bound through hardware manufacturers. The only reason AOSP can't exist without Google has nothing to do with Google, but more with Qualcomm. Motorola has the opportunity to broker that breakout. And we need this right now. Lawmakers and big tech are locking themselves in further, the longer we don't have another option the harder it will be to move outside of these greedy corporations.

b112: I think is great, if there are no ramifications when skilled people unlock it.There's just too much hacking going on, malicious behaviour, to allow uneducated masses to have root on a phone. I've seen so many people just not understanding the outcome of their actions. You'd get people rooting because some shady app lied about why, and just wanted control.And we don't need more botnets. And it's why banks sometimes throw a fit.So if a recompile does the trick, and no downside, then it'd be fine.

thot_experiment: Lots of freedoms have downsides that are outweighed by the upsides, I'm absolutely unconvinced that the line lands on the far side of allowing you to control your phone.

ChocolateGod: [delayed]

clot27: My next device is going to be moto if it fits in budget

diacritical: > https:&#x2F;&#x2F;madaidans-insecurities.github.io&#x2F;android.html#rootin...I'm trying to understand why rooting Android is such a sin.If I give root to my terminal so I can browse and edit any files I want, I'm placing a lot of trust in the terminal, sure. But trusting the terminal seems reasonable, as it's an important (basic; fundamental; necessary) part of any "real" OS. If I don't trust the terminal to not be malicious, why should I trust my OS? Anything could be compromised from a supply-chain attack. If we don't trust anything, we can turn off the computer and have perfect security, but if we accept that there's a trade-off between security and usability, we have to place some trust in some parts of the system.> It does not matter if you have to whitelist apps that have root — an attacker can fake user input by, for example, clickjacking, or they can exploit vulnerabilities in apps that you have granted root to. Rooting turns huge portions of the operating system into root attack surface; vulnerabilities in the UI layer — such as in the display server, among other things — can now be abused to gain complete root access.So if some app can somehow exploit the display server, it can inject commands on the terminal and hide the real output? I know the X server on Linux has (or has had) major security issues [1] that don't provide any real GUI isolation. Is that the type of issues Madaidan is talking about?I don't know much about Android's display server, but if it's possible for an app without root access to exploit it, couldn't that app inject touch events or keystrokes in another app, or read the other app's screen? How would not having root benefit me if a random can view or control other apps without my knowledge by exploiting the display server? [2]From what I gather if an app with root access has vulnerabilities, it makes it easier for another app (or other type of malicious code) to use it to gain root. But if the UI layer, to use Madaidan's example, has a vulnerability, it seems like it could be exploited successfully, with awful consequences, even if the malicious code doesn't get root in the end. So if I choose several apps to give root access to, I would just extend the attack surface from {all of the OS and its various layers} to {all of the OS and its various layers and those several apps}.> root fundamentally breaks verified boot and other security features by placing excessive trust in persistent state.I don't understand this. Could someone explain it with more details to me, please?[1] https:&#x2F;&#x2F;theinvisiblethings.blogspot.com&#x2F;2011&#x2F;04&#x2F;linux-securi...[2] https:&#x2F;&#x2F;xkcd.com&#x2F;1200&#x2F;

Andromxda: Of course the topic as a whole is much more complex than that, but I'll try to summarize it. Android has 3 systems of access control [1][2]:- Discretionary Access Control, i.e. the standard Unix file permissions- Mandatory Access Control, implemented in the form of the SELinux and YAMA LSMs (GrapheneOS stopped using YAMA in the 2024031400 release and replaced it with advanced SELinux policies)- Android permissions which have to be disclosed in the AndroidManifest.xml, and most of the time need to be granted by the user at runtimeRoot simply bypasses ALL of these security mechanisms. This is a clear violation of the principle of least privilege, since most of the stuff you are doing with root probably doesn't require access to your entire filesystem, and could easily run within an SELinux context. But writing and deploying a modified SELinux policy would take extra time and effort, and devs are lazy, so they just use root to completely bypass it.As madaidan points out, only a tiny subset of system processes on Android run as root. [3] And Android has clear guidelines about what root process are and aren't allowed to do. From the AOSP documentation:> Where possible, root code should be isolated from untrusted data and accessed via IPC.> Root processes must not listen on a network socket.> Root processes must not provide a general-purpose runtime for apps (for example, a Java VM).Desktop systems are very different from Android and iOS. Out of Android's three major security mechanisms, they typically only implement one. This is why ransomware is so insanely successful. Every program has access to all the files and folders of the logged in user, including network shares, etc. Even on systems that implement application sandboxing and a permission system, such as macOS, it's only an afterthought, and isn't enforced properly. (macOS is still miles ahead of Windows and Linux though) For example, when installing a 3rd-party terminal emulator such as iTerm2 on macOS, you have to grant it the permission to access your entire file system (otherwise you will be limited to the home directory IIRC). But this permission also applies recursively to every process started within the terminal, greatly limiting its usefulness.> I don't understand this. Could someone explain it with more details to me, please?Android uses Verified Boot to protect against both Evil maid attacks [4], i.e. someone modifying the operating system on the hard drive, and malware persistence. By default, the Android &#x2F;system partition is mounted in read-only mode, unlike for example your C:\Windows directory, or system directories like &#x2F;bin on Linux. This prevents malware from modifying the operating system. If you ever get malware on Android or iOS, in most cases you can get rid of it, by simply rebooting your device. Unless of course, the malware has some persistence mechanism. Root obviously provides a great vector for persistence, since the system partition could simply be remounted in a writable mode, and the system could be modified however the attacker wants to.When you build your own copy of AOSP or GrapheneOS, include your modifications, and sign the image with your own Verified Boot keys, that image can't be modified or tampered with by an attacker. It's perfectly secure to do that (of course only if you can trust the extra code you're including).[1] https:&#x2F;&#x2F;source.android.com&#x2F;docs&#x2F;security&#x2F;app-sandbox#protect...[2] https:&#x2F;&#x2F;arxiv.org&#x2F;pdf&#x2F;1904.05572[3] https:&#x2F;&#x2F;source.android.com&#x2F;docs&#x2F;security&#x2F;overview&#x2F;implement#...[4] https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Evil_maid_attack

scheme271: You could power down portions and that's what a lot of modern systems do but you need to incorporate that into the design at a fundamental level. The entire PC would have to be redesigned and you even need a whole new cpu and motherboard design in order to be able to power down enough things while still being able to do useful work.So yeah, it's possible but you'd basically be redoing the entire system from scratch.

adrianwaj: I still think it's a good idea. Apple could do it.I think you'd want a tiny switchboard where you could manually-override powering up&#x2F;down parts of the system. Also, just because you're at a desk doesn't mean you want all cores going and when traveling only a couple - it could be on-demand. The other key thing is damage resistance. Just because you've got it in your pocket doesn't mean you want to risk it being damaged. Maybe a free-floating housing for traveling like with the old Sony Action cams."The X3000’s entire lens and sensor unit moves physically inside the body to compensate for shake. It is widely considered some of the best stabilization ever put into an action camera."https:&#x2F;&#x2F;gemini.google.com&#x2F;share&#x2F;2839d2aa0a68

handedness: There's a lot of hand-wringing in this thread about Motorola's location, and a lot of support from a few for a modem made by a company headquartered in....Shanghai. If consistency here is what we claim to be pursuing, then let's actually pursue it.The opacity of the firmware situation isn't great on either, but one contains numerous excellent mitigations and is very proactively maintained, and the other is something that relies heavily on reverse engineering and community projects to even use.And it has a physical switch and has some physical distance between it and the CPU, both of which given the previous limitations are mostly theater, in practice. "My modem is so vulnerable it needs to be turned off during extra-important times, but I don't mind leaving it on during times that are merely important." As if a compromised OS can't just wait to exfil data. If your goal is to make it to Checkpoint Charlie and don't want the hassle of having to buy a new phone after you reach freedom, fine, but I haven't seen many well-articulated needs that would be satisfied by a hardware switch when everything behind that switch is filled with vulnerabilities.For my threat model, using the modern modem with a bounds sanitizer, an integer overflow sanitizer, stack canaries, control flow integrity, automatic initialization of stack variables, very active updates and a large commercial user base and a large market cap in part depending on it, makes a lot more sense.Google's highly lucrative ad tech business is what makes everyone nervous about anything Google, rightly so, but their share price would plummet if they were caught using Pixel hardware in nefarious ways, or did an unreasonably insufficient job in securing it. I'm not saying it's not possible that the modem is compromised, but for my threat model I have to put a lot into the possibility of an unknown defect inside a modem which is by all indications constructed very well, to make using a weird old modem known to be massively lacking in dozens of ways, running an OS with all kinds of issues, to make more sense.And I say that as someone who tried the PinePhone at one point. Fun idea, but no commercial or state organization with an elevated risk profile would trust their data to a PinePhone as it stands. It's fun for hobbyists, but it doesn't belong in the conversation with iPhones and Pixels from a security standpoint. It won't be making it onto the DoDIN APL any time soon.

handedness: That's reasonable, and I hope we get there.Qualcomm is an American company, and it sounds like the GrapheneOS team is working directly with them on developing the spec for this, including hardware MTE support. That's promising and I think could bring improvements over the current situation, if not open source modem firmware, unfortunately. I'm hoping to be surprised, though.

diacritical: Thanks a lot for the thorough reply!I'll read the links you posted a bit later, but for now I have a few questions that could help me clear some misconceptions I might have. I haven't used a rooted Android device yet, so I might be wrong about how it works. I've read about magisk and other methods a bit and am at familiar with the security concepts you wrote.Let's say I give root permissions to a terminal app TermGood and I don't give root permissions to an app GameEvil. I trust TermGood fully - I accept that if TermGood is malicious or if it has some exploitable bugs, it's game over. I don't trust GameEvil at all, but I trust the OS to limit the damage it could do since it doesn't have root permissions.1. Could I run TermGood with root only sometimes? Run it with root, close it, then run it with the normal restricted permissions. That's just to clarify how rooting works in general.2. For MacOS you wrote "this permission also applies recursively to every process started within the terminal, greatly limiting its usefulness.". For Android, if I run a program like ls or vi from TermGood, will it be launched with root permissions, too? Will I have fully trust that ls or vi are not malicious or exploitable in certain ways (e.g., running vi on a file created by GameEvil that exploits vi).3. Will GameEvil have any way to compromise the OS, to circumvent some security boundaries or to do any other damage it wouldn't have been able to do if I hadn't "rooted" the OS?3.1. Would GameEvil be able to launch TermGood on its own without my knowledge? Or somehow piggyback on TermGood to take advantage of its root permissions?3.2. If there's a bug in the UI layer (the "display server" - what Madaidan gave as an example) and I had TermGood open as root, GameEvil could inject some keystrokes into TermGood to read its screen (like the output of a cat command, for example).3.3. Just because TermGood could have root access, does that somehow make GameEvil more likely to gain root access itself? On Linux, if there is sudo installed, it might increase the attack surface because sudo might have exploitable bugs. What could GameEvil exploit?4. If I don't root my OS by any of the available means, what would my alternatives be for full control and customization?4.1. AFAIK with adb you don't get rw access on &#x2F; if the OS is not rooted.4.2. Let's say I want to X (e.g., backup &#x2F; to server when it commands it to) without rooting. Would I have to create the app, then modify security policies in a way that would enable it to run without root, but with granular permissions for X specifically and nothing else, like permissions to read &#x2F; and to listen on a network socket, maybe by changing the SELinux policies and&#x2F;or the Android permissions of the app? Or would that be impossible? I don't really have a specific X in mind, but I want X to be as broad as possible. That's what makes it a real OS for me - being able to do anything on it.5. If TermGood is compromised, it could reinfect the root filesystem after booting and effectively bypass Verified Boot. Or, if I used TermGood to change something on &#x2F;, e.g. `touch &#x2F;testfile`, would I be able to sign the new root filesystem? Ideally I should be able to control all the keys and sign the whole chain of trust whenever I make a change.6. Android doesn't have FDE, so evil maid seems relatively easy (although any unrestricted physical access to the device should be treated extremely seriously, even with FDE in place). Is that correct?Basically, if we assume that:* I fully trust TermGood and the processes it spawns to not be malicious or have exploitable bugs;* I could resign any changes I've made so I can keep Verified Boot working.Then, would I be able to give TermGood root and keep my security?

whatsupdog: > Want location? Give the app a location point I've fixed for that app.How do you do that in graphene os?

dns_snek: 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"):https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=42536302

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

dns_snek: 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?

whatsupdog: Hopefully not.. Otherwise it defeats the whole purpose. Right now there is no way for apps to find out media and contact scopes, so it might be something similar.

simonmales: Here is my recent history of phones: https:&#x2F;&#x2F;www.gsmarena.com&#x2F;compare.php3?idPhone1=8972&idPhone2...The Nokia 6.1 now feels like a monster in my hand at 75mm.I agree that 70mm is sweet spot.

handedness: > Unless you provide some evidence, I will consider this false accusation.The line of thinking is, if you're so concerned about your device being compromised that you need to enable the mic kill switch (because of aforementioned lack of trust in the device), then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own.On a device that's that compromised one would have to physically power off every sensor on the device, and even then there would still be some things to consider. Air gaps are a thing for a reason, and yet some incredibly clever exploits have been demonstrated to jump that gap. Many components that aren't microphones, cameras or radios can be turned into cameras, microphones or radios pretty effectively.Still, I see the appeal of hardware switches as another practical layer against basic human factors, like a webcam lens cover adding another step beyond firing up the camera's permissions&#x2F;appVM. But if we're being practical, a phone I can get wet is much more practical than a phone with physical hardware switches when I already have a high degree of trust the OS's ability to control sensors, and a low degree of rust in the OS's ability to control liquids and debris.> Which was freed and can run new Linux kernels now:Unfortunately that has kernel dependencies that haven't been updated in years. If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.> Your walls of text are disingenuous.You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?"Unless you provide some evidence, I will consider this false accusation." is bizarre, especially given your audience. You're capable of learning all this stuff on your own without asking everyone to do that for you.Regardless, nine sentences across two paragraphs isn't a wall of text. The guy took time out of his day to respond to banality and that's what he gets.It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?

fsflover: > then other sensors which have been demonstrated to be able to capture audio can't be trusted, either, and in many demonstrations some of those sensors have been shown to be capable of recording what is effectively audio. That's old news, so you shouldn't have any difficulty finding evidence of your own.You (and strcat) have no idea what you are talking about. And you are constantly shifting goals. Sensors are much harder to use as microphones. Was it ever caught in the wild, not in a lab? Sensors are also switched off on Librem 5 by the three kill switches: https:&#x2F;&#x2F;puri.sm&#x2F;posts&#x2F;lockdown-mode-on-the-librem-5-beyond-h...> If you think the kernels in well-maintained Debian and Fedora VMs still need to be separated by a hypervisor to be trustworthy, you're in for a bad time trying to run that kernel on a PinePhone.This is misleading. There are different degrees of security. Qubes provides the highest achievable degree (for certain threat models). It doesn't mean that Debian and Fedora have no security at all. Moreover, if you only run trusted application, they are reasonably secure, unlike closed OSes.> You've got the attention of one of the sharpest security minds on the planet and that is what you come up with?I don't care about personalities. Famous and smart people are wrong more often than you seem to think. I care about arguments. This is why I'm on HN.> Regardless, nine sentences across two paragraphs isn't a wall of text.I am talking about all comments together, not one comment.> It's becoming increasingly difficult to see you as anything but someone who deliberately attempts to derail any threads relating to Graphene OS. Help me out: why shouldn't I?I do not have any hope that you try to understand me, since you immediately started fighting with me, without even considering my point of view. Many of your replies (see example in this very answer of mine) did not address my concerns. Some of your replies ignored my links (LoC).

Milpotel: > The small form factor phones simply do not sell.And still in every phone topic people complain about phones being too big... I'd love to have a smaller affordable smartphone.

paol: I was in the same boat and literally this week bought a Pixel 8. It's a 2 year old phone but with the extended support period that's no longer a problem, and being old means you can get it new for about €300 or refurbished for even less.The other option is the Samsung S2x line, which you can apply the same strategy to.

simonmales: The Pixel 8 might be my next "upgrade" (sidegrade?)

tho2i3423400: At this point in time, esp. given the raving lunacy of the US White House, those of us outside the "West", wonder the same thing about US companies.

eckelhesten: Honestly I’d prefer Chinese backdoors over western ones. China is still a land far far away and I couldn’t care less about what they’d do with my data, unlike western alphabet boys who could freeze my accounts and assets for ”wrongthinking” in the future.

mdni007: I've been saying this for years and people thought I was going insane.

latentsea: My point was it's the OS of choice for those in organised crime, so yes, it has been targeted.

handedness: Sure, if you switch off every kill switch you're in pretty good shape for the time being. Same as if you turn off all radios and sensors on a GrapheneOS device. And then you're way ahead of the game when you turn all of the software switches back on.The trusted application thing is hard, same as the trusted kernel thing is hard. Some monolithic kernels are adding bugs faster than they're being addressed. It's a really hard problem and I don't see monolithic kernels as being the best solution of the future. That's relevant to threat modeling, which is why virtualization is so valuable, but it needs to be built on a secure hardware platform. Part of the benefits of significant sandboxing, much like virtualization, is you can ultimately run all apps as some degree of untrusted. Both together would be best. Saying you can't imagine how something could be more secure than your Qubes setup is a better indication of your ability to imagine than it is of any security reality. And then you recommend people check out two solutions with the benefits of neither approach (and other issues).Anyway, I'm still going at this because your comments (which frequently commit the errors of which you accuse others) go unreplied in too many threads, so I engage so that others who skim threads containing questionable assertions will at least see a different viewpoint.When I recently didn't continue to play along with you, you tried to use that thread as evidence supporting some kind of weird dunking on me, and others. It's a project you claim to care about and want to see succeed, and then you repeatedly approach it in a highly insufficient way, often invoking the project in threads not even about it just to go ahead and dismiss it. You ask basic, easily researched questions relentlessly and when people stop answering point to the lack of a final response as justification, despite your claims of awareness of your own ignorance. There's an actual name for what it is you're doing.It's a weird axe you have to grind, and I'm content to let others see it all in context and decide for themselves. I only bother because I think it's an important project, genuinely want to see it succeed, and think on this important site of tech culture, you're damaging it unfairly. Whether that's intentional or not, I don't know, nor do I need to.

gf000: Security theater, it has absolutely no use. If you can't trust your hardware that it won't actively listen to the microphone without your knowledge and permission then what are you even doing with that device?!

fsflover: I do trust my device. However in specific circumstances where privacy may be critical, an additional protection might save me even from a state-sponsored attack.

handedness: If your threat model is state-sponsored then I hope for your sake you're just LARPing, because if not you're in for a bad time with some of the solutions you advocate.

fsflover: This is just a shallow dismissal. I'm sure state actors can break into my phone. I'm also sure that they can't track or record me when kill switches are off (unless there is another device nearby). Tell me why I'm wrong and please stop repeating how surprised you are that people are so very stupid.

handedness: For kill switches on a device with otherwise comparatively abysmal security to be the better security choice over a device with thorough and comprehensive security paired with OS-level radio and sensor switches, you would have to demonstrate that the infinitely more vulnerable device's physical kill switches are somehow significantly more effective at addressing your threat model than software switches in a trustworthy OS. If they are approximately equally effective then you have given up a lot for no benefit, and are net much worse off.Again, I get the human factors appeal of physical kill switches, and if all else were equal they may be worth having, but people are place far too much faith in the value of physical kill switches.

fsflover: > For kill switches on a device with otherwise comparatively abysmal security to be the better security choiceSame strawman as earlier: I already replied that I never said that Librem 5 was more secure. At least you accepted that the kill switches do work, so there is progress.> If they are approximately equally effective then you have given up a lot for no benefit, and are net much worse off.(I won't claim they are, but) there is another benefit in freedom, apart from the security. Some people care about freedom. When I see that, I suggest Librem 5 in my replies, and not as a more secure solution. Maybe you should read my replies more carefully before answering.

tensegrist: i'm surprised this works, in the sense that there aren't tons of technical safeguards and&#x2F;or lawsuits getting in the way of someone doing this

kay_o: tried using this on ATT and was refused with not on esim whitelist

aaravchen: I have to say up front, that I think GrapheneOS in its most locked down mode needs to exist. There are important audiences for which most nation state actors and their related corporate entities are real threats (e.g. journalists). That said, I don't think the majority of users want or need that level of lockdown.I do agree with the OP somewhat. While GrapheneOS has a hard job with too much to do and too few resources, they also take a very all-or-nothing stance when it comes to real world practicalities for the average user. Specifically: they're all or nothing on app stores and Google.For some reason some of the key developers seem to constantly bash every "store" except Accrescent, ignoring the fact that Accresent is missing the key feature of telling you what you're even installing (which fails security 101: "you're only secure if you're usable and secure"). It's a very all or nothing viewpoint. No there is no secure app "store". None. Every one of them has security issues in one way or another. But short of an ultra locked down burner device for national secrets (a real use case in fact), users need to be able to get apps. The only "acceptable" solution seems to be to use the (patched) official Google Play Store. Which brings me to the second all-or-nothing area.Google is the single biggest threat actor for most users. They control the upstream AOSP, so you start with constant attempts to compromise your supply chain in nefarious ways. They're one of the key gateways to the Internet, and they run the world's largest surveillance network (by a factor of many thousands). They're the very reason most users come to GrapheneOS in the first place. Every one of Googles apps is, or can safely be assumed to be, malware to violate your privacy as much as it can, and may incidentally provide some functionality. GrapheneOS has done well to replace many of the OS-baked in functionality that normally uses Google with alternatives, but is very adamant that they will not try to support allowing non-Google-signed apps in place of Google signed ones for any purpose. While I understand it ensures the AOSP feature of verifying against a trusted source, Google itself is not inf act a trusted source. It won't try and mine crypto on your device or use the passwords and wallet keys it steals to drain your accounts or steal your identity, but it will almost always cooperate with authoritarian nation states to install targeted surveillance tools on your devices instead of the "real" apps, and track all data it can possibly get access to. Sandboxing the system apps helps a lot, but as we know from Stock Android devices, that's not sufficient to completely protect systems from known malicious apps. The counterpoint is always "then don't install any Google apps". Great, I'd love to. But I live in the real world where Google controls most of the electronic world, and everyone else has mandates Google usage. I need to control my level of exposure for my personal usage requirements and threat model, and neither 0 or 100 are feasible options. Just like almost all users.I definitely understand from a practical sense that GrapheneOS doesn't have the resources to supply de-Googled version of Google Maps (unfortunately the only map navigation that works in most of the US still), or implement and maintain a rework of the binder and intents system to allow custom per-app filtering of all IPC. But I don't hear about the practicalities and maintenance costs (especially for complex drive-by contributions), or risks of accidental misuse causing severely degraded security. I only hear "that's not secure" (which is often incorrect for the actual user's threat model) as the reason something won't be supported, pursued, or allowed to be contributed.