baatliwalaGrapheneOS could break Pixel exclusivity in 2026 with major OEM deal
ScrubblesSo who do we think? It’s not Fair phone and it sounds like it’s not oneplus. I’ll be needing a new phone within the next couple of years, if they roll it out soonish
First_Thunder
Avid AmoebaThere aren’t too many OEMs that sell worldwide. So that would be one of Samsung, Sony, Moto, OnePlus.
Jo MiranI agree, Motorola is owned by Lenovo. They have found middling success with the return of their Razr line and with phones in the lower to mid tier range. But they really want something super flagship. Something like the Think Phone would have probably sold really well with a Graphene option.
Scott
Andromxda 🇺🇦🇵🇸🇹🇼There are several supported apps, such as Curve Pay, PayPal, and banking apps that have their own tap-to-pay implementation.
shkspr.mobi/…/contactless-payments-with-grapheneo…
grapheneos.social/@GrapheneOS/115295538501760765
You can also use the contactless payments supported tag when searching the GrapheneOS banking app compatibility list on GitHub. github.com/PrivSec-dev/…/issues?q=is%3Aissue+labe…
Contactless Payments with GrapheneOS
Google's monopolistic stranglehold on Android results in poor experience for power-users, and artificially restricts choice for those who have older phones. For example, Google Wallet is the de facto way to use NFC payments on Android. There's one problem though - it only works with Google's Android. If you have the temerity to install a 3rd party Android OS - like the hyper-secure GrapheneOS - …
Device hardware, firmware, and software are integrated to protect your most sensitive data from mobile threats. With Moto KeySafe, PINs, passwords, and cryptographic keys are isolated from other device data for an added layer of high-level security.
Yeah this sounds like what Graphene insists on.
deafboyThat sounds like a fancy speak for a Trusted Platform Module. Isn’t some kind of TPM mandatory to obtain a google certification for a new device?
Yeah, a TPM or secure element. I don’t think it’s required.
It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.
Are you sure there’s no rate limiting? My phone definitely does rate limit the on-boot disk decryption prompt. Do you mean there’s no rate limiting if someone detaches the NAND and brute-forces it off-device?
That rate limiting can easily be bypassed by an attacker. In order to be effective, the rate limit needs to be enforced by tamper-resistant hardware, i.e. a secure element. Here are some of the requirements for a secure element: developer.android.com/…/keystore#StrongBoxKeyMint
An implementation of StrongBox KeyMint must contain the following:
Its own CPU
Secure storage
A true random-number generator
Additional mechanisms to resist package tampering and unauthorized sideloading of apps
A secure timer
A reboot notification pin (or equivalent), like general-purpose input/output (GPIO)
For details, I recommend reading:
Only devices with a proper implementation of a secure element (Titan M2, i.e. Pixel 6 or later, or the Apple SEP, i.e. iPhone 12 or later) are actually resistant to brute-force attacks by forensic data extraction tools, such as Cellebrite or GrayKey. GrapheneOS has obtained some internal documents from multiple forensics companies. They published the Cellebrite docs at …grapheneos.org/…/14344-cellebrite-premium-july-2…
Specifically, I recommend looking at this chart:
It clearly shows that data cannot be extracted from iPhones with the SEP, unless the device is in the AFU state, meaning that the encryption keys are kept in memory.
Those are the charts for Pixels:
It (unfortunately) isn’t required. Most current Android devices on the market have serious security issues (most notably, full disk encryption can easily be bypassed due to a lack of effective unlock attempt rate limiting) due to their lack of a secure element.
I wouldn’t bet on it. Lenovo is used across North American corporations, banks and government institutions.
What makes you think so? This (admittedly pretty vague) response indicates quite the opposite: grapheneos.social/@GrapheneOS/115118480213473033
GrapheneOS (@[email protected])
@[email protected] @[email protected] @[email protected] Nearly all phones are either made in China or use a bunch of important components from there. iPhones and Pixels are made in China. It's unavoidable in practice and people would complain about a phone made in the US too.
Possibly linuxThat would make sense as Motorola is fairly supportive of custom roms
I hope Sony simply because I want a headphone jack and an MicroSD card reader. Their phones are already pretty bloat free and their custom apps, usually focused on the camera system, would mesh very well with GrapheneOS. Would be a great way for them to become relevant again.
How repairable are Sony smartphones?
Snapdragons finally somewhat caught up to Google’s Tensors and the Titan M with the Qualcomm SPU and by implementing the ARM MTE
I wonder if this will have a significant negative impact on Pixel sales.
SynapseYes it well. Their chips are pathetic and they seem to have no motivation to do anything about it.
The phone market is very saturated
I doubt it will have any effect
SeductiveTortoiseAccording to details shared on Reddit, the partnered manufacturer will offer GrapheneOS support on future versions of their existing models, priced similarly to Pixels. These initial devices will feature flagship Snapdragon processors, which GrapheneOS notes provide significantly better CPU and GPU performance compared to Google’s Tensor chips. The Snapdragon platform also bundles high-quality wireless connectivity, eSIM support, and decent image processing capabilities directly into the system-on-chip.
Oh thank you. Let’s hope for something nice for a change.
FizzI’m skeptical. Even knowing how paranoid Daniel is about, well…everything.
Who remembers the last time a custom ROM got an OEM deal? It is the reason Lineage OS exists today…
With everything Google is doing with Android, they might not have a choice. It’s either this or possibly one day no longer being able to work on Graphene.
Graphene would be better off cutting themselves off from Google’s OS future entirely and pivot the fork as quickly as possible to remove all dependencies. Probably too arrogant to consider it, though. Also becomes much more work.
Google will forever control Android. I would prefer if he just worked on Linux (phone & desktop) to the benefit of all.
You’re under-thinking it.
In pseudo-correct but probably not order:
- Step 1: Collect underpants
- Step 2: Keep receiving Google security updates but stop updating Google mainline
- Step 3: Start replacing the underbelly to just raw Linux (or BSD or whatever) and slowly shift the “Android” portion to a VM/container
- Step 4: RIL and other stuff (probably should happen first) have to be packaged up and become their new entity on the modem side (also probably the biggest challenge, but manufacturers and ODMs provide dev kits)
- Step 5: ???
- Step 6: Once the Android side is safely firewalled away from the core OS, start embracing something like PostmarketOS
- Step 7: GUI/graphics are built out with the Android pieces still running in a container
- Step 8: Start writing applications that replace the Android applications, go one by one, remove dependence on each Android application as you go while still maintaining compatibility (I mean the core OS ones that make the device at least basically functional, the F/OSS devs will have to each rewrite/change their apps, or some other magic can be inserted here that isn’t really magic.)
- Step 9: Once the OS itself is beefed up enough, retain Android container for the needs of some for some uncomfortably long frustrating time to maintain, but not too long
- Step 10: Have Obtainium/F-Droid/etc. all simultaneously pivot and start providing apps for the native OS as well as maintaining backwards compatibility with the Android apps in the container
- Step 11: Once some magic point, forced or otherwise happens, sunset the Android portion of the app stores. Keep the containerized Android around a little longer
- Step 12: Sunset the Android container, at this point the phone should be running 100% “native” OS and apps and store
- Step 14: Profit!
There are industry blueprints for this. Apple is probably the best example of how to implement these shifts, from OS 9 (co-op MT proprietary OS)->OS X (BSD-NextStep-based Unix OS), 68k->PPC, Replacing Unix underpinnings with Apple Frameworks, PPC->Intel, OS X->iOS, Mac from Intel->ARM, etc. etc. They frequently used containerization to keep the old running while the new was built up around it and replaced. It is a solid proven design pattern.
And edit72: I’m not just saying “hey magic people do this” - I’ve done this shit. I’m down to help, and I will. But the project owners need to step up for some actual work instead of just putting potpourri on something someone else built. Annoying side-story, I figured out how to cross-compile/rebuild/fix dependencies on a CPAP app called Oscar so it would be ARM-native on ARM Macs. Couldn’t figure out how to contact the devs after much digging to let them know, so. I have 1 of 1 copy of that app running ARM-MacOS native. Would be neat to help them replicate it though.
ProdigalFrogI think that sounds like a damn solid plan, personally. Not sure if the GrapheneOS devs would go for it. The lead dev (who I think stepped down, so may not be a factor now) had some strongly negative opinions towards a Linux phone due to all of its security holes compared to Android, but like… It’s not as if those things couldn’t be addressed like you describe. It would just take time.
Disappointed to learn about Fairphone lagging behind in terms of security… I really wanted to get one. But still good news I guess.
I’m not saying the information about Fairphone is wrong, but you shouldn’t assume it’s all as bad as they made it out to be. You’re reading a marketing pitch from one group that works with one vendor saying why another vendor isn’t that good.
GrapheneOS has criticized Fairphone from a security perspective for a long time, long before any partnerships with OEMs were ever made. GrapheneOS chose to partner with this specific company (which they don’t want to broadly disclose yet) because they have shown, that they actually care about security, and are willing to invest time and effort to meet the GrapheneOS device requirements, not the other way around.
Seefra 1manufacturer will offer GrapheneOS support on future versions of their existing models, priced similarly to Pixels.
Great, so I still won’t afford it…
Pixels will be supported until EoL. You can get a used Pixel 8a or 9a, which will get supported until May 2031 and April 2032 respectively. Both feature modern, important hardware security features, such as the ARM memory tagging extension.
Certainly not
I’ll hold off on a new phone to watch for this. Android could be great without Google’s nonsense. An OS that has high end hardware support and continues to work on convergence with desktop Linux both by the communities development and Google’s
ikiddDon’t know if that’s an existing phone because from what I read the new integration will be for a new/next gen device. So not anything that’s on the market now
𝕸𝖔𝖘𝖘But if google goes on with locking out the app store with the developer verification bs, how would would this play into that? If Aurora won’t install the app or the app won’t run, then we’ve accomplished little in that area. I’m really hoping I’m missing something.
Custom ROMs should be able to disable the checks. My bigger concern is what it does to the open app ecosystem as a whole.
TBH I would actually expect GrapheneOS not to disable these checks. GrapheneOS devs pride themselves to have the best implementation of the official Android security model, and enforcing signature checks is likely part of that…
They might add additional certificates I guess, to allow their own apps, and maybe a selected few others.
This is incorrect. The sideloading checks are implemented in Play Protect, which needs elevated privileges to function. On GrapheneOS, Google Play services run with normal privileges, just like any other user-installed app. This means, there are no Play Protect checks in GrapheneOS, and there will never be. It would only be possible on ROMs, such as LineageOS with Gapps, where Play services are installed as system apps, running with higher privileges than all other apps.
Well, good to know.
I was thinking more about the way of Android security models, and that it would make sense for GOS to restrict available storefronts to stay consistent with their way to implement them. But good to know that it will not automatically happen just by updating the google services.
And I would also think that people would likely complain if they where to implement it in a different way.
Sandboxed Google Play is one of the key features of GrapheneOS. So far no other OS has allowed users to enjoy the full functionality of Android Auto, the Pixel LPA for managing eSIMs, and the Google Mobile Services suite (not talking about the other Pixel OS stuff) with the only exception being GPay, without full sandboxing, and without granting excessive privileges (SGP is unprivileged, the eUICC LPA obviously requires higher privileges for managing eSIMs, but it’s fully sandboxed and can’t communicate with Play services, or access the internet)
Nothing needs to be disabled, since it isn’t present in GrapheneOS in the first place. The sideloading checks are implemented in Play Protect, which needs elevated privileges to function. On GrapheneOS, Google Play services run with normal privileges, just like any other user-installed app.