Motorola GrapheneOS devices will be bootloader unlockable/relockable
grapheneos.social
grapheneos.social
- 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.
That's fine. You don't have to be
That said, I think the marketing of GrapheneOS could be better. Every introduction of GrapheneOS I've seen paints the image of Graphene being "Absolute security, no compromises", whereas in reality GrapheneOS is the most "Things need to work, no compromises. Then make the rest as safe as possible" custom ROM that I've used thus far (in particular regarding them allowing you to install Google Play, rather than using MicroG).
I 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.
There's first-world, upper-middle-class affordable (~$500) and then there's global affordable (<$250).
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.
But the whole idea of GrapheneOS is the reason why it (currently) only runs on Pixels. On other phones you can run anything based on LineageOS...
I don't want GrapheneOS to compromise on that: if I didn't care about it, I would use any other alternative. To me it's a bit like saying "I would be using Linux if it was a lot more like Windows" (that's something I often understand when Windows users explain what it would take for them to use Linux). But I, as a Linux user, really don't want Linux to look a lot more like Windows.
Doesn't help with the current situation though but I hope the partnering between Motorola and GrapheneOS is still up and going in a few years when I'll next have to replace my phone.
Is that something that GrapheneOS fixes?
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?
GrapheneOS presently doesn’t do anything different in this case, they pull it from AOSP without modifications. However you can disable it using the frontend app (SIM Toolkit) as someone pointed out, but as far as I can tell this requires the applet on SIM card to cooperate (offer the opt out).
Otherwise you can disable the STK altogether with ADB but that will also block you out of other SIM card interactive functions, which might not be a big deal however.
Edit: "We plan to add the ability to restrict the capabilities of SIM Toolkit as an attack surface reduction measure. (2022)"[2] and open issue[3].
[1] https://wladimir-tm4pda.github.io/porting/stk.html
[2] https://discuss.grapheneos.org/d/1492-blocking-sim-toolkit-m...
[3] https://github.com/GrapheneOS/os-issue-tracker/issues/875
I did not buy this phone from a carrier, just added the SIM card later.
Really surprised to learn this doesn't happen to others. Always assumed that the SIM card had some special privilege given by Android.
See https://www.browserstack.com/guide/stop-popup-messages-in-an...
Caveat: if they're doing that, then they're almost certainly data mining your data streams (e.g. dns lookups etc.)
I wouldn't feel secure on such a carrier unless I also VPN'd traffic to a reputable provider (Nord, Express, or Proton) and forced DNS over TLS to known servers.
People bill it as making a ton of usability compromises in the name of security, but that doesn't match my experience. The only redeeming observation is that your phone _does_ lean towards secure-er and ungoogled defaults, which _does_ break functionality that a lot of people expect to "just work" OOTB. But it's trivial to restore it, and the upfront effort getting things to work is amortized over the lifetime of the device. It's maybe an hour's worth of work.
The counterfactual world where users need to forumcrawl how to get to secure/private defaults seems worse to me. By contrast, it's pretty easy to recognize when an app isn't working.
> People bill it as making a ton of usability compromises in the name of security, but that doesn't match my experience.
When you are talking about something like GrapheneOS, most of the people who are talking about usability compromises aren't worth listening to since they are looking for something that is pretty much the exact opposite of what GrapheneOS is trying to provide. While there are likely some legitimate criticisms in the mix, the compromises required for "works by default, for everyone" are pretty much the opposite of what GrapheneOS is.
How do I do that? Been using Graphene for many years but did not know this was possible.
> We're making a better per-app Location Scopes feature
Cool!
GrapheneOS, as it ships, is rather bleak but you also need to consider that it is addressing the concerns of a very broad audience. That ranges from people who want to completely get rid of data leaking apps to those who want the apps but expect them to be sandboxed. Shipping two different versions won't really help them. It would only make more work on their end, with the results only reflecting two extremes. You are going to have some people willing to put up with some apps, but not others. You are going to have some people wanting some of those apps feeding fake data, but not others.
It's probably best to think of GrapheneOS as a base system that you build up to serve your personal needs, rather than thinking of them shipping it in a "perfect" state. While a handful of people will be happy with it in its default state, many will install something like F-Droid along with a collection of privacy preserving apps. Many others will install the Google Play Store along with a personally curated list of apps that reflect their needs, providing or denying access to their data as they see fit.
I believe the "build up" approach is the only viable way to handle this situation since we are talking about a group of users who are actively seeking out a third-party OS since they are particular about their needs. This isn't the typical consumer who will (gleefully or begrudgingly) put up with whatever the device vendor feeds them.
How do you do that in graphene os?
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.
And how can they find out how well it meets that need other than receiving (respectful!) feedback?
> Yes, but do these enthusiasts care at all if it meets some need for the users? ... And how can they find out how well it meets that need other than receiving (respectful!) feedback?
What makes you think they don't? Can you point to any instances of them ignoring the community at large?
You can open an issue in any of the open source repositories and request a feature. Others can vote and comment on it. Or you can discuss it in the very lively forum. All methods used to steer the project towards the desires of the users.
In case you can't find them: https://github.com/GrapheneOS https://discuss.grapheneos.org/
This whole conversation just feels weird and specious to me.
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.
> Running GraphineOS without all the security features they want would be better for me than what I currently have.
But then it would be like running LineageOS, which is a great (but different) project. Why not using LineageOS?
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.
I personally believe the project would achieve more overall good if they supported more devices - assuming they are capable of doing so without sacrificing software quality. That includes support of devices which do not meet the project's current security standards.
When did I make any demands of GraphineOS? I have no expectation that they support me. I'm not entitled to benefit from the work they've done. My opinions are merely opinions and those who maintain and contribute to GraphineOS are not obligated to value them.
I fully agree with you. I never received a reasonable reply to this from GrapheneOS fans or developers. Latest attempt: https://news.ycombinator.com/item?id=47182376
Your Qubes OS comparison doesn't really work because Android distributions need extra work to support each new device, whereas for Qubes OS, they're probably using some virtualization framework that makes it pretty trivial to add support for CPUs without virtualization. There's nothing stopping you from starting a new fork that supports your motorola phone, for instance.
I love what they're doing and it's my preferred daily driver, but from a security standpoint they're still pushing molasses up a sandy hill.
Fork it, make your own. Not only are they OK with that, they're actively supportive of it.
Criticizing them for not actively supporting the Balkanization and unavoidable dilution of the security and therefore total value of their project makes me wonder whether the strength with which you hold your opinions has any meaningful connection to the extent to which you even understand the subject matter. It's just mind-boggling the things you assert every single time an OS you don't even use comes up.
Your love of Qubes OS (which I share) somehow even increasingly seems rooted in something that just isn't reality. If it were, you'd be able to fairly assess both projects and see the relative strengths and weakneses of both with useful accuracy.
As it stands, you're just spouting harmful noise. Please don't do that.
GrapheneOS 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.
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.
> You're citing hypothetical weaknesses as a reason to dismiss GrapheneOS
Where did I say this? I do not dismiss GrapheneOS, and I do wish them success. I agree this is a very important project (and I upvoted all their recent posts for more visibility). I just feel that some of their decisions harm them more than they think, which is the reason for my parent question.
I suggest Librem 5 or Pinephone in my HN replies whenever I see people caring about mobile freedom more than about immediate security, which GrapheneOS provides. I do not suggest those phones as a more secure replacement of GrapheneOS devices.
> we shouldn't overstate its position, which you continually do
I do not see where I am doing this, see above. And I certainly didn't do it in my parent comment.
> Their talks of targeting a laptop which meets their hardware requirements is incredibly exciting
I have no idea how anything can be more secure than Qubes OS. I never received a reasonable answer to this question. And yes, virtualization (i.e., compartmentalization) is the best way to achieve security, in my opinion.
> in terms of laptop/desktop security, Apple's doing the best job of anyone on that front at present and is still moving in the direction of improvement
This is not even funny, given how many vulnerabilities are constantly being found in MacOS. You should just compare that with Qubes OS, which I use.
You conflate privacy with security here, "They may be more secure in small ways, depending on your threat model, like avoiding Google," and yet you don't articulate any demonstrated connection between using Google hardware with GrapheneOS and Google's ad tech business. The closest thing there is needing to connect to Wi-FI to unlock the bootloader, but that's easily addressed. You cite a hypothetical backdoor that Google may have placed in the hardware, but unless you're physically examining every chip running every OS (and there are several) in every device you own (even the ones you think you've disabled the MIE on), you simply can't know that. You have to account for that, but you talk about it in ways that imply a project which accounts for it better than others hasn't, while one that inherently can't, has.
When they announce Motorola support, you're still on about avoiding Google. They literally can't win with you.
If you think their decisions harm them more than they think, but can't understand the basic factors at play, it's hard to take your determinations seriously. Good governance of a complex project is hard, and people snipe from the sidelines with virtually no understanding of what the actual situation is. By all indications the project is incredibly well run in all ways that practically impact eventual end-user security.
If you have no idea how anything can be more secure than Qubes OS, consider Qubes OS running on hardware with excellent security features, and the two being tightly integrated. There's your reasonable answer. That is literally the roadmap for Graphene OS. A hypervisor-based OS that's useful for end-user purposes by carefully layering on functionality to make a hypervisor-based OS some degree of usable.
The less reasonable reasonable answer is that you'd have better security if you ran Xen itself, as everything Qubes adds to make it usable potentially weakens it. It's just the nature of the beast.
It wouldn't surprise me if GrapheneOS lands on Xen for all the same reasons Joanna landed on Xen, and they end up contributing massively upstream to Xen security largely by tightly integrating it with said hardware. But I'm sure other patches will flow upstream with whatever project they choose, because their security chops are that good.
Qubes OS also lacks resources. They're supporting a massively bigger variety of hardware with a comparatively tiny user and donor base. By all indications their finances are nowhere near sufficient for what they really need to do. The project is as good as it currently is almost entirely down to the incredible efforts by a very small number of amazing people. If nothing else, the speed at which they can iterate and evolve is highly constrained. Remove 1-2 key players from the equation and the project almost invariably collapses. That alone is constitutes a definite security vulnerability.
Re: Apple, I'm talking hardware security. But even when you factor the software in, for a portfolio of consumer operating systems used by a billion and a half normies who expect it to do every normie task under the sun with very little frictional security overhead, Apple does a great job at security.
Edited to add:
> I would be happy to use GrapheneOS on a more libre hardware (Librem 5), even if the security may be lower. Some people value an additional bit of freedom more than cutting-edge security.
OK, but that's a nonsensical wish at best. There are other AOSP forks out there that would meet your needs. Buy a non-Google Android phone and load another AOSP fork. Or, fork GrapheneOS and modify it to meet your needs, thought that would be a largely pointless exercise. Repeatedly criticizing the project every single time it comes up for not wanting to completely change its fundamental nature in an ill-defined attempt to satisfy your inclination is a real head-scratcher.
Unfortunately you come out as whining that the project focused on security doesn't want to support insecure hardware.
Go for it, fork, call it, say, ClayOS and have GOS on whatever you want. Why would someone else have to do something that's contrary to the project just because you want to lower the security?
Bizarre. Just fork it mate.
https://discuss.grapheneos.org/d/27926-per-profile-location-...
Currently there is a Mock Location feature, but it is globally scoped and not what you asked for.
GrapheneOS 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.
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.
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.
* 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.
What bank does that? If my bank did that, I would find a new bank immediately. That is not OK.
First, how about Philippine National Bank? Compare snapshots of their front page, https://www.pnb.com.ph/, 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://web.archive.org/web/20220605084957/https://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.
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.
https://f-droid.org/packages/helium314.keyboard/
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://github.com/Helium314/HeliBoard/wiki/Tutorial:-How-to...
So an application of course can use other android services if it declared that, that's why it can see whether it's running or not. But you are in full control whether google play services is installed, and what it can use.
Of course this may break certain apps (Google maps location sharing will probably not work with the location permission denied for play services), which may or may not degrade gracefully.
First is very comprehensively delivered, second is halfway done, halfway in progress.
Good luck!
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.
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.
Good enough quality screen for solid video media performance, generally, would be an absolute must I imagine.
normies use consoles, sometimes PCs
my personal beef, after a camera that gets decent photos in low light, would be an accurate GPS that doesn't crap out after half an hour
https://www.cnbc.com/amp/2018/06/05/apple-one-of-the-biggest...
In public transport I see almost as many people playing games on their phones as those watching videos.
This might be true, but the priorities are depressing.
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.
That's not it. The concept is "if you choose to install this particular OS on the device you own, then it comes with this particular security model". That's totally fine. If you own your device, you can run Linux on it and you'll have root access.
"Not owning your device" means "not being able to install the OS you want on it". I want to own my device, obviously. But it does not mean that I own the developers of every OS in the world and that they should do whatever I tell them to do, for free.
If we want to use banking app we have to use a non-rooted/leased device. That is what is really messed up. Personally I only use bank now that has website for banking. If they don't have a web site only app, then it is a red alert for the company.
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.
The answer to every security issue not "add a backdoor".
Problem is, I strongly suspect we'd still be having the same discussion even if we were talking about "allow the user direct access to all files*" instead of "allow the user full root rights".
Because while some of those missing capabilities are "simply" a matter of it being too much effort to provide a dedicated capability for each and every niche use case (though that once again raises the question as to whether you prefer failing open, i.e. provide root as an ultimate fallback solution, or fail closed), with file access I guess that this was very much an intentional design decision.
GrapheneOS is already non-certified, for most apps that care, because it can't pass STRONG_INTEGRITY with play protect.
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?
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
That's what I do to get `adb root` and full file system access.
By rooting your device you can access the app data directories as you wish.
I read that a lot, and I agree that I want to own my device. But that does not mean that I should have root access on the OS I choose to install on it.
Owning my device means that I should be able to install whatever OS I want. It does not mean at all that OS developers must do whatever I tell you to do.
I also don't include a root account in my container images, but you probably have a root account on the sever that runs them in case you need to debug something. But you can probably also build and deploy a new container. At the end of the day you almost always want some last-resort way to access the data stored in case something goes very wrong. Whether that is for backups, "hostile" data export or for other reasons it is important to me.
I think it is important, because I read a lot of comments that imply that "owning their device" means "owning the developers". And that's a wrong fight.
The real fight is that it should be illegal to prevent me from installing my preferred OS on a general-purpose computer.
> It very directly harms the security model
What do you mean by this? You mean that it is a "god permission" that bypasses other permissions? If so then yes, with great power comes great responsibility and it shouldn't be used lightly.
> and is not a good approach to implementing any of the features hacked together through it.
Maybe not, but is there an alternative? What is your recommended way to access all files of any app? This is my primary use case. Modification would also be valuable but I would be ok with read-only access.
> Giving root access to a huge portion of the OS harms security even if you never use the feature.
Can you explain why root access must be given to a huge portion of the OS? Why can't it be limited to specific apps or features (like ADB shell)?
> It does not mean you can't do it, we only recommend you don't.
Of course. It is your right to recommend whatever you want :)
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?
- 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. This means that app data may be lost when migrating to a new phone, as the app data is stored in directories that are not accessible in the filesystem without root.
- 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 while simultaneously blocking ads.
---
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?
> Backing up all app data via Neo Backup
GrapheneOS includes Seedvault by default. https://grapheneos.org/features#encrypted-backups
> High-quality call recording via Call Recorder
Call recording is built into the Dialer app on GrapheneOS. https://grapheneos.org/features#encrypted-backups:~:text=Cal....
> DNS-based ad blocking is possible via apps like AdGuard
DNS-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://grapheneos.org/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://grapheneos.org/features a read.
> If not, can I request these features somewhere?
Check out the issue tracker on GitHub: https://github.com/GrapheneOS/os-issue-tracker/issues
The alternative to "running as root" isn't "not having access to root".
An alternative to accomplish what?
>to provide me, the physical owner of the device with control over the device
Control 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")
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.
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://theinvisiblethings.blogspot.com/2011/04/linux-securi...
- 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 runtime
Root 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 /system partition is mounted in read-only mode, unlike for example your C:\Windows directory, or system directories like /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://source.android.com/docs/security/app-sandbox#protect...
[2] https://arxiv.org/pdf/1904.05572
[3] https://source.android.com/docs/security/overview/implement#...
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 / if the OS is not rooted.
4.2. Let's say I want to X (e.g., backup / to a 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 / and to listen on a network socket, maybe by changing the SELinux policies and/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 /, e.g. `touch /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?
But they do not stop you from doing so, you can fairly easily build your own images with root enabled.
I’m seeing enthusiasts go out of their way to get vivos and xiaomis now that they are surpassing the western counterparts based solely on that.
I think it’s doable, pixels did it with meh hardware for years. But I’m not sure if there’s enough overlap between people who care about selfie quality and open source enthusiasts.
>Pixels have fantastic camera hardware and software which is fully functional on GrapheneOS which isn't something we need to lose on a Motorola flagship.
This is very interesting to me! Does graphene OS manage to keep google’s processing? How does that work?
For now having Android-type OS on a daily driver is a must, but for older devices (thinking of 10 years time) I'd like to explore an OS which doesn't depend of Google open-source drops and delayed security open-source drops, which is the situation for ROMs without an ODM partner.
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.
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...
Easy but for missing Step 1 of “Colocate with friends and business partners”
Not your keys, not your speech!
If I would be to place a bet I would place it on mass propaganda targeting people below average - it might be simpler, easier and cost effective. So lots of this talk about "encryption", "privacy" might be in fact great for those "actors": smart people worry about their precious technology and principles, while "they" talk to "the masses".
1. I can direct my consumer-dollars towards the vendors that promise to respect ownership and privacy in general, and they will also have the most to lose if they are caught enabling spying.
2. Defense in depth. Security features generally add to the spying's difficulty, expense, or risk of detection, and that in turn decreases the incentive for abuse.
Ill leave you to investigate how != they are
Used to be anyways. (My office was a floor below in the mart)
> long term patern cross licensing
> israel
> pegasus
Basically lots of judgment based off of superficial facts with little understanding of implications and the actual consequences of those facts.
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.
"While NSO Group markets Pegasus as a product for fighting crime and terrorism, governments around the world have routinely used the spyware to surveil journalists, lawyers, political dissidents, and human rights activists."[0]
Information these they can be much as powerful as a bomb, for example, I could learn more about your calls and discover that you do something immoral but not illegal and use it to blackmail you.
A recent court case investigating spying on 37 elected representatives [1] (including the prime minister, three ministers, and regional politicians) had to be closed in 2023 and again in 2026 “for lack of cooperation of the Israeli government”.
[1] https://www.rtve.es/noticias/20220510/pegasus-espiados-sanch... (spanish) [2] https://www.rtve.es/noticias/20260122/juez-archiva-caso-pega... (spanish)
And your second paragraph seems to go on the premise that the average person care if there is a backdoor.
I don't know why you wouldn't take security seriously, when even the US government is telling everyone to be careful where they supply their devices because of spying. Just don't trust them to point the finger the right way.
Or think of friends and family. When they become the target, you are prepared, you have the knowledge and tools ready, you can be the guide that helps them navigate a hostile digital world.
This is such a low-iq argument I cannot even. Yes, nobody cares about OP, you, me, whatever - until they do. Not to mention general harvesting for profiling and propaganda reasons.
General: What do people in this city/country/region/etc are thinking - This is the main one where the data is used and collected, then grouped. It is extremely powerful information for targeted agenda whichever it might be.
Targeted: Oh, you or someone from your close ones went to a political protest? Too bad we have all this information to put you and your family in jail - This is where suddenly they will care about you, even when it is NOT YOU but someone from your close circles were the ones upsetting them.
The US government is known to spy on anti ICE protestors.
If you have an opinion your government doesn't like, or a potential future government doesn't like, there's a good chance you have or will be spied on.
Perhaps you lack a single opinion worth caring about, but most people do not.
This is kind of like a mechanic not knowing what a car's exhaust does...
What of it?
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.
Same 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.
> 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.
> 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?
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.
Pixel has an IOMMU - are you implying that’s being defeated, or that you weren’t aware of 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 undetected backdoor 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, 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.
How can a compromised OS exfiltrate any data that was never collected?
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 Android
Which was freed and can run new Linux kernels now: https://github.com/the-modem-distro/pinephone_modem_sdk and https://xnux.eu/devices/feature/modem-pp.html
Your walls of text are disingenuous.
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/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?
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://puri.sm/posts/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 OSes with (partially) closed source.
> 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).
* (Me included; I argue here, because I want to find out where I'm wrong.)
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.
So you confirm that you and strcat were spreading false information about Librem 5 with a convincing tone, while saying that you're "sharpest security minds on the planet" and calling me "disingenuous"?
> Same as if you turn off all radios and sensors on a GrapheneOS device.
This is plain false. Software switches can never be as secure as cutting power from hardware components. Are you saying that GrapheneOS can reliably save you from tracking by a state actor? This is very unlikely. The number of lines of code in Trusted Computing Base of GrapheneOS is likely similar to one in the monolithic Linux kernel (10 MM lines of code, https://doc.qubes-os.org/en/latest/developer/system/security...). (I would be happy to be corrected if I'm wrong here.) This is why it can never be as reliable as hardware virtualization relying on 100000 LoC. I'm happy that GrapheneOS is going to add the virtualization btw.
> 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.
You walls of text are so large and not always constructive, because they frequently contain personal attacks like this one (and words like "disingenuous" I mentioned above).
> You ask basic, easily researched questions relentlessly
If this is so basic, I don't understand why you are making so many false or implausible claims and do not just give me a link with a simple, high-level explanation for noobs like me. Instead you keep attacking me and presenting yourself as very smart, with words like these.
I agree with you that GrapheneOS is a very important project. I disagree that trying to point out its weaknesses or ways to improve it harms the project. I also would like to add that Librem 5 is similarly important project, and you unnecessarily harm it with your false claims. Some people come to discussions about GrapheneOS asking to get root of rely more on free drivers, or expand the supported devices by lowering security requirements. My replies about Librem 5 to these people do not harm GrapheneOS, since they aren't your target audience anyway. I just help them to find what they want.
makes me feel good about it.
Former Mossad Chief Yosi Cohen bragged about having booby trapped and otherwise compromised devices in pretty much every country. [1]
[1] https://the307.substack.com/p/former-mossad-chief-brags-that...
Motorola Mobility is largely owned by the Chinese government.
The Chinese government is not gonna share your data with Israel/USA.
The key quote in this article is:
"Israel has a long record of getting U.S. military technology to China. "
See presentation at DEFCON21 about SIM cards: https://www.youtube.com/watch?v=31D94QOo2gY
All in all: Thank you for making this possible.
When my current phone dies, I'm basically returning to a dumb phone with a removable battery. Now that Xperia dropped open source, every phone out there is terrible and I just don't want any of them. Anything that would support a ROM has features to make my skin crawl.
It's water under the bridge. You're NEVER getting a Graphene phone that supports a microsd. It won't happen. The AUX jack, you will biligerently be told to get a USB DAC or otherwise you are an old man yelling at clouds.
Graphene and Motorola will work together by happy accident. Tell ya what though, if they make a GrapheneOS phone with 3.5mm, dual sim, microsd, and >no notch or hole punch< and I will buy it. I won't even care how much it costs. All the Xperias I've owned were among the most expensive phones on the market.
Most phone aux support microphones and acting as an antenna for FM radio reception. I don't see how either could be used for a security exploit however.
No electric circuit is unidirectional. Beyond the pause/play and volume commands that it supports (edit: and mic as mentioned in a sibling comment), Graphene would probably reason it's an easy way to externally read voltage levels and so an unnamed entity can mount side channel attacks with backdoored headphones
Why not a smartphone with the jack, microsd, and a hardware kill switch for camera?
As for the camera, a webcam sticker seems much more convenient than needing to mess with the hardware internals
Why such a restriction?
> or ones with a chipset that would have been considered fast in 2018
https://puri.sm/posts/the-danger-of-focusing-on-specs/
> webcam sticker seems much more convenient
Except there is also a microphone.
> than needing to mess with the hardware internals
What do you mean? My phone has a convenient, external hardware kill switch. No messing with internals is necessary.
Sorry, that wasn't clear: I meant any phone that I can purchase as of 2025. I was looking for several months and made a decision about 2 months ago. A second-hand Pixel was a big compromise but I don't see another option
> https://puri.sm/posts/the-danger-of-focusing-on-specs/
Do you also have thoughts to add or am I supposed to read and respond to 2000 words of material here?
The reason I'm looking at specs is not because I have no idea what I need. Not sure if there's another possible reading or if the link insinuates that. The software I use (e.g.: OsmAnd) is noticeably faster on more modern systems and was downright sluggish on my previous phone. I could buy my current chipset again, it's doable for now, but neither fluent nor future-proof. The chip's inefficiency also means it's completely empty after 2.5 hours of use (while I'm out mapping, taking notes, recording positions and sometimes pictures, listening to music... I ask a lot of the battery), whereas newer chips can do the same work with less energy
I also need a modern chipset for accurate GNSS. The phone I get from work has dual-frequency GNSS and makes razor sharp traces which are much more usable for my mapping hobby, especially in urban or forested areas or behind coated windows like trains or cars (car navigation isn't that niche, my current phone does a pretty poor job at that)
But yeah, let's not focus on specs. Who cares about any of this right? That's what I'd say if I sold a really basic phone
> Except there is also a microphone.
Respond to the person above. Hardware toggles wasn't my argument but theirs. Great that your librem has this but the thread is about GrapheneOS
Edit: lol that was yourself. You posted about a camera toggle, not me or anyone else
The idea is that relatively low specs do not necessarily mean low performance. It depends on the software a lot. For example, SXMo provides a smooth experience with maps and Youtube even on a Pinephone. The battery life may be a problem though.
> the thread is about GrapheneOS
The subthread you started is about a phone "with a headphone jack that I can actually use more conveniently than a tablet", so I thought I could intervene with some other options. I might be wrong though.
I also hope that the new GrapheneOS device from Motorola will be in the "smaller" size factor so it actually fits in my (apparently) tiny hands, but to be honest I'm probably getting one regardless, as iOS gets worse and worse every time I update it.
* https://www.youtube.com/watch?v=iR9zBsKELVs * https://www.youtube.com/watch?v=vZdbbN3FCzE Not about small form factor, rather enthusiast phones don't last
Currently 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.
All the flagships have huge screens, the big guys would have paid millions on market research, I can't understand why they arent just trying to achieve flagship parity (in terms of specs not price or software). No one is going to say it's unreasonable and they save themselves the market research
Don't banking, security and payment apps detect the unlocked bootloader and prevent them from working on lineageos? At least that's what happened to me after i flashed lineage on my old tablet.
Because then what's the point of a smartphone if it can't do banking, payment, shopping, ticketing, etc? Use it as a gimped pocket web browser and ebook reader? There's not gonna be any mass market adoption for such "smartphones" until they can run all apps out of the box like vanilla androids and IOS phones.
Your average consumer isn't gonna wanna fuck around with signing keys and bootloader relock. Hell, even this tech savvy HN user doesn't want to do that because he has better things to do with his time. The days from my childhood when I always rooted my Android phone, installed custom ROMs with custom kernels, magisk, titanium backup, cerberus to make the phone "my own" are long behind me.
funnily enough my banking app works but the mcdonalds app doesn't, lol
I can run banking apps like that, corporate apps like that, but I can't show a QR code to order happy meal.
In comparison the Burger King app works without problems and is very fast.
It was likely their management doing random shit to fix it. Instead of fixing real problem, which was bogus campaign rules. Reddit was full of people abusing their app discounts and ordering insane amount of food for free. It was well described.
None of that was due to app security holes. It was an issue in their promotional campaign. It was still working after those "secure" app limitations appeared.
The biggest issue is that there is a different way to do this for every device, so most custom ROMs don't bother. It's relatively simple and automatable for Pixel devices, so the GrapheneOS installer takes care of it. e/OS/, which is based on Lineage, allows this for some devices, iirc.
That said, my banking and credit card apps work fine on GrapheneOS.
That's the kicker, they will all eventually block it, so it's not worth your time and sanity constantly swapping banks on the hopes this one will keep lax security.
yeah, clearly nobody buys Samsung Galaxy S series for years, they are like the least popular Android phone model... /s
I'm running Pixel 6a (which was followed bu successors with worse screen:body ratio for years and only now the new Pixels finally matched and slightly improved the ratio, what a progress), but considering all the HW issues (baterries and displays) with Pixels I'd rather avoid it, the worst case will buy as next phone Xiaomi and hopefully somehow unlock it, if there is no suitable Motorola
edit: added HW issues explanation since I am rate limited on comments
I don't think the smaller Galaxy S models are what people generally mean when they talk about small phones, those are still much bigger than the iPhone Mini was.
https://www.phonearena.com/phones/size/Samsung-Galaxy-S26,Ap...
here you have filtered Android phones since 2020 under 71mm with OIS camera
https://www.gsmarena.com/results.php3?nYearMin=2020&nWidthMa...
it's basically just Samsung S series, Pixels, overpriced bad value Sony and few exotic/abandoned phones (Asus is done with phones, they had always horrible SW, Xiaomi only model 12 many years ago, Meizu not available outside China)
till I got the abomination that was a pixel 6a. fucking overheated - then finally battery exploded. Other pixels suffer the same problems as well - overheating n display being finnicky.
And still in every phone topic people complain about phones being too big... I'd love to have a smaller affordable smartphone.
For me, I want to be able to operate the phone with one hand, and the large screen makes it difficult to reach all the spots on the screen even with large hands. I do operate my Fairphone 5 with one hand, but it is super awkward and at some point, the phone will fall into a gully because I cannot hold it tight while navigating.
And I wouldn't mind 2mm more thickness if this means the cameras are flush with the back and the battery is larger.
Whenever I see this when talking about small phones, I'm reminded of the stats, where the iPhone minis were a small proportion of iPhone sales but still by themselves outsold most manufacturers.
The other option is the Samsung S2x line, which you can apply the same strategy to.
I think the issue of small phones is that, while there people saying they would buy if it was available, no one is saying "I would buy one small phone at flagship prices, even if they don't have flagship features".
The root cause is that the phone is not a primary device for me. It's what I use when bringing a PC is too much trouble.
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.
The Nokia 6.1 now feels like a monster in my hand at 75mm.
I agree that 70mm is sweet spot.
Are we really sure "nobody actually wants it"? I need to help my family select the smallest possible phone every time. Meanwhile choices are dwindling and the remaining 2 models are either overpriced or outdated and so I need to tell them it's better to take a (whatever currently goes for) "medium sized" model, which shifts upwards every time I/they need a new one. No wonder that people don't buy small phones anymore if they don't exist
I don't buy this nonsense about small phones being a niche when so many people are actively seeking them out, both online and offline in my practical experience
It's just harder to make, heat dissipation or battery will be restricted, doubly so if you're a niche manufacturer without a big budget, or one who tries to keep it repairable and needs the extra space for screws. So I can understand that Fairphone doesn't release a small model (even if it means I simply cannot use it: I actually put my money down and bought one, but sadly had to sell it onwards after a few weeks of trying) but for Graphenorola I'm not sure that restriction exists. It may just not please everyone if the chip is underclocked for heat and battery efficiency reasons and so they're not likely to. Doesn't mean there's no market for a small variant for any manufacturer that has more than one device on the market
My mom's and my current phone (same model) is what I'd call medium sized (per 2019 standards, when it was new) and the battery life sucks, but I'd buy this model again anyway if it came out with a ≥2025 SoC because I can actually use it unlike nearly any other phone on the market. Not properly reach the top, but at least the left side so that'll have to do
Do regular iphones sell well? If so, the small flagship phones are not dead, because iphones are not dead. If iphones are not counted as small phones, then the small android flagship phones are dead long time ago.
Why it has to be a flagship? Sell them cheap. It's like AAA game makers cry about ballooning costs, and they make 60 hour games that literally nobody plays through....
I'd like to have an Option around 6" and 150x70x9mm, which is not really small. Surprisingly the Pixel 8 has a smaller footprint than the Pixel *a variants while having a bigger display.
So my request would be a device around the size of the Pixel 8, having a similar battery size and if possible a headphone jack at a reasonable price point (350 bucks).
I consider the pixel 8 as really solid device for graphene OS.
They don't even need to fix the longpress for headphone remotes... Just a device that is the right size.
> I'll be forced to go back to dumbphones in the future... along with many others, I guess.
Going back to a dumbphone for me would mean changing my outdoor hobbies (like contributing to openstreetmap), so I'll take my losses and continue on a smartphone, but I share the sentiment. Power to you if you do it!
Motorola has such great quality/price ratio and the user experience is decent. There's still some nagging and such but overall it's much better than the competition.
But I still can't get over my old iPhone 6. That phone size was just perfect. Easy to hold and do everything with one hand, easy to fit into any pocket.
I really want an Android like that. I don't need 3 cameras and bunch of other nonsense.
It's the smallest phone available with a real telephoto lens. I think it was only available in India, but I got one on eBay because it has those two features (not huge with telephoto) I was looking for. I moved to it from a Pixel 6a because I refuse to go any bigger in physical size.
Cursor spent like Million dollars on creating a browser which people were able to make later with a 200$/100$ subscription in the same amount of days as cursor with human assistance.
I don't think that this can be "autonomous", we assumed that making browsers could be autonomous process but it wasn't. That was the take I took from it all.
Will this be an example of autonomous tho? I think we still need a human experienced with reverse engineering in the loop but it might significantly improve their workflow
I wish if cursor, instead of having burnt million $ to something worthless essentially, Could have atleast done this experiment.
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.
(y’all know this one https://arstechnica.com/tech-policy/2014/05/photos-of-an-nsa... )
Mr. Rich Guy sells me his personal device he used in the previous year because he wants new shiny phone, but he may have the very slightest chance of being a super evil genius? The government selling tampered phones on ebay, when they could just.. go directly to vendors and put their backdoors directly into new phones/software?
Sorry for the light snark, but this attack vector seems way too complicated for not much benefit. Unless you are some very VIP person being personally targeted.
b/c as seen in the link buying new isn’t perfect
I wouldn't trust the OS shipped with a used phone.
NSA could technically do this with a new phone also and probably has.
I have read comments from people who buy the new iPhone on day one but do a factory reset before touching it!
Aside: I've noticed over the years that phones die in one of the following ways: - too fast charging (battery dies, charge controller dies) - usb port dies - screen broken - all sorts of falls
A lether folio case, gorilla glass, and a Qi charging adapter solve all of those problems (the charging adapter also limits the current by virtue of being inefficient). It has a magnetic connector (it's a simple two-pin job and it doesn't have any issues) - in the rare occasion I want to charge up real quick, I can still hook up directly via usb c, and meanwhile the port is stuffed with the converter's plug which prevents it from accumulating dirt and fluff.
I'm glad to say that even despite many falls, some directly onto the screen, the phone itself still works very well, even if the case and glass protector are obviously ragged.
I hope once unlockable Moto's come around I'll be able to keep that one for a long while as well.
Fwiw, besides people that crack the screen I have not seen any of the failures you've mentioned. The only phone I saw someone replace, for reasons other than software support, was myself because the gnss chip was cooked after 3 years (would track me perfectly, like if I step to the right it would notice, but with an offset of hundreds of metres so I'm in another town). All other phones I've owned are still perfectly functioning (the oldest Android phone I have, 2012, has a more reliable battery than my daily driver!), I don't use any case or screen protector. They're just software-wise obsolete because no updates and developers require the newer android apis
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?
Because when someone says "buy used" they're obviously telling you to buy the antiques your grandma used to love back in the day on an annual basis. Anything newer than that especially from the last year or two would be new and insane to consider, especially if you keep it more than a year. You really owned me with the flawless argument there.
I was merely pointing out that "buying used" is not necessarily better than "buying new but keeping for 8 years". Many people "buy used" but often.
It's not about Google, it's about OP's personal values
It's one phone's worth of demand either way.
First hand = money goes directly to Google including margin
Second hand = money only goes towards a private person, 0$ for google. At best it prevents usable phones being thrown into landfill.
Right. And if you buy a secondhand one you are increasing their value on the secondhand market. Reducing the depreciation increases the value of the brand new phone.
If you don't think voting with your wallet works, then that is a position you can take. But you can't think it works when buying from the OEM but doesn't work when buying on the secondary market.
And ultimately, if buying it on the secondary market in such small numbers that it doesn't move the market, then it adequately addresses the concern.
Edit: I'm not saying there's zero effect of it, but it's likely statistically insignificant.
> We're collaborating on future devices
Samsung had something as ambitious years ago, but it went nowhere https://www.xda-developers.com/samsung-promised-make-old-pho...
Stay tuned
So likely no existing Motorola phones are good enough and only new ones, developed in collaboration with GrapheneOS developers, will be suitable.
From Wikipedia: https://en.wikipedia.org/wiki/Lenovo
Is it possible that it's backdoored, have a secret opcode / 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'.
They never said or claimed that. They rised concerns and asked about _possible_ backdoors the same way the west does about china e.g. Huawei.
The US invented it.
Doing this has a non negligible political cost. They would only do it for a high value target. If you're that person, you're presumably aware.
* I only recall one news report of this happening years ago.
So unless my local Chinese takeaway is classed as Chinese soil, I'll more than happily buy my phone from there
Most phones are already made over there anyway so know knows what kind of backdoor, listening devices are coded into the chips they put into 'Western Company's' phones.
European tech is in shambles and everyone else is barely holding it together outside of tech.
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.
In the land of the blind, the one-eyed man is king.
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!
[0] https://discuss.grapheneos.org/d/27068-grapheneos-security-p...
edit: looked up the announcement https://www.androidauthority.com/google-android-development-... but it doesn't even mention the word security. I don't know enough about the manufacturer side of things to say whether this means there's also no security updates while they work on new features
Having physical disconnect switches (Bluetooth/Wifi, Modem, Power, Microphone/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.
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.
Sorry, that's what I meant when I said Modem.
> A disconnect switch for power would do the same?
I would think so. I don't necessarily care about removable batteries because I use a portable power bank. Why carry an extra battery that only works for one device, when I can carry a "battery" that works for many devices?
I think moving to micro-PCs is the answer
https://www.aliexpress.com/item/1005005575993915.html
I'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://medium.com/@lee.harding/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.
These ideas would have to go into a new design.
Also see: https://www.aliexpress.com/item/1005004564646188.html
"At just 155 x 80 x 19mm, this pocket-sized M6 mini PC is perfect for travel, fitting easily in handbags or pockets."
So yeah, it's possible but you'd basically be redoing the entire system from scratch.
I think you'd want a tiny switchboard where you could manually-override powering up/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."
Example: the EU Digital Identity (EUDI) wallet, discussed in multiple GH issues e.g. https://github.com/eu-digital-identity-wallet/av-doc-technic...
You can fit several esims on one of these adapters AIUI.
Stored SIMs/eSIMs is not the same as active SIMs/eSIMs.
> You know what would be good for security: Having physical disconnect switches
The Vibrate/Ring switches on the older iPhones seem to hold up though, so maybe something like that?
If you are not aware, US Mobile offers a Super Carrier package that one account can use all three. https://www.usmobile.com/networks
I don't use them, only read about it on r/nocontract.
Stored SIMs/eSIMs is not the same as active SIMs/eSIMs.
The provider isn't required to support this (they can give me 2 weeks' notice any time) but I use very little of my subscription (the smallest one they have) so I assume they're happy with the deal and don't have to pay the roaming carriers much
Assuming you meant < 6 inches I'm all for it as well, it would be another incredible usp for these devices.
If devs can have access to all of the hardware and related documentation and source code, then this is to become very good news.
PCs became popular and widespread because of that: openness.
The current provided desktop mode is rudimentary, and mostly working. But it has so much potential. We could have all in one device with us, and just plug that into an usb-c dock. Or watch things on big screens in hotels if a mouse emulation on touchscreen like samsung would be supported.
Or, as Samsung already has created this, maybe that could be somehow ported to GrapheneOS via some 3rd party patcher? I'd really like to use samsung clock and gallery, as well, as those are quite a lot better than AOSP ones.
I like GrapheneOS, and the promise of it. Just a few minor things and it would be awesome instead of really good.
An acquaintance at a local hackerspace has no laptop, just a Fairphone 5 and a device that looks like a laptop but is really just an external screen and keyboard. He connects his Ubuntu Touch phone and uses that as a laptop, developing software on it etc.
It's not perfect as a phone (Android apps work rather well from what I've seen (I think the emulator is called Waydroid), but e.g. passing through Bluetooth is an issue so there are limitations) but maybe that's an interesting option for you as well
Though I'd expect that all efforts focus on the new Android Desktop Mode now, and then Samsung Dex turns into something akin to what OneUI does with Android, instead of being its own thing
I'm also pretty sure rounded corners are stronger on impact.
It's really a bummer that Google probably won't certify pre-rooted devices. It would obviously only do harm to them and not fit into the scheme of our big tech companies pushing anti-circumvention laws, but some high-spirited side inside of me still has hope.
> and Graphene is under no obligation to provide anything to anyone.
And here I thought it felt repetitive between (sub) threads
I simply agreed with the person who posted this sentiment by mentioning another place where an organisation acts contrary to its stated goal (Signal wants privacy, but also your phone number? I can come up with reasons like that it costs money and thus helps against spam, but it's still at odds and different solutions and opinions are possible)
If someone comes to one of my open source projects' bugtrackers and says "I want you to implement X", I can say "enjoy implementing that", or I can say "this is a bad idea because reasons". GrapheneOS does the latter. Responding to that, waylaying arguments, is not the same as demanding free work. They're free to not care
People who spend huge quantities of time trolling somebody who makes an excellent mobile operating system are really quite something. I used to think he was overselling the quantity and quality of it, but this post's comments have really turned me around on that one. So: thanks for that.
It does bother me that I spend time answering in a clear way, since apparently it wasn't clear previously so I spend more time, and then it gets dismissed as disingenuous flamebait, or whatever the definition of trolling is
¹ (Not sure, as a non-native speaker, but to me that word sounds like there might be a material objective beyond coming to a common understanding. I don't have such an ulterior objective. If I'm right about that connotation then please read "point" in place of this word)
If they distributed rooted versions, then banks and the likes would not be willing to trust them.
[1]: https://grapheneos.org/articles/attestation-compatibility-gu...
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)
I am mainly looking to access my filesystem. Currently a lot of things I want to do (backing up app data, scripting, mounting network drives) are hobbled by the bad wrappers around the same.
I know this might be out of scope, but is there any plan to re-enable direct filesystem access in a more secure way? Even via ADB it would be useful. It just seems like madness to me that a lot of basics tasks are impossible or incredibly convoluted, because everything has to go through weird wrapper interfaces and Java/Kotlin code someone has to write (instead of just using the filesystem and OS which is right there).
Thanks for the great work by the way.
Motorola announces a partnership with GrapheneOS
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...
If you want to invest into software, this should be #1 of your list.
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.
I also am willing to suffer lower specs in short term if it benefits me in the long run.
Motorola has effectively lost in the Android market and are on downward spiral into irrelevance (already there?), so they have to do something different.
My friend the GrapheneOS supported devices list is nothing but pixels, including the very latest models. It'll be good to have more supported devices.
The question for Motorola is: "given the cost of meeting GrapheneOS' requirements, how many more devices will we sell?". Hundreds of thousands of devices is not nothing, I guess. Plus they get free consulting from the team building the most secure phone OS out there.
I really don't understand why smaller smartphone manufacturers didn't fight before for that. Say Fairphone: I don't know about today, but a few years ago they finally got profitable by selling something like 200 thousands units a year. If they had designed a phone to be supported by GrapheneOS, that would surely have increased their sales quite a bit. Now that ship has sailed, GrapheneOS will be focused on Motorola for a few years.
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.
That's great to see. I'm getting flashbacks of doing the "find the blobs" game years ago with LineageOS.
Their most advanced phone is based on a >10 year old SoC, that wasn't even that good when it was first released.
Pine64 has targeted a very different market around extensibility and hacker/maker mindset. However while their phones have a lot of potential, security measures are half baked (microphone cutoff switch doesn't actually cut off the microphone), performance mediocre, and demand missing. While I love my pinephone pro, its not a dailiable device. A phone that cannot access common services like your bank account are non viable for 99% of users.
The only solution would be an emulation layer.
For Motorola to partner with one of the Linux phone projects, someone would have to invest significant resources in mainlining the drivers, replacing blobs with open source drivers where feasible, and maintaining that code when new upstream firmware and drivers make it downstream with patches and fixes. Looking at postmarketOS, you can see it takes years of community effort to port a device to the point of becoming useful. Once the software is done, the hardware is outdated enough that Motorola won't be making any money on sales any more.
In theory all of this would be a lot easier if Qualcomm, MediaTek, and the other SoC manufacturers would take the burden of mainlining drivers upon themselves the way Intel and AMD do. With the recent high-end Qualcomm chips, the company does seem to put in some effort, but these companies simply don't care about Linux support.
GrapheneOS is an Android fork so of course they're partnering with an Android company. They also don't have the capacity to maintain their own kernel + security patches + drivers, which is why they rely on upstream maintenance (from Google, historically) with their own Android-level improvements to remain secure.
The timing is super weird too, when all corporations are pushing for digital ID, are actively lobbying to deanonymize the users, cooperating with gov too to have a smooth pipeline for such process, and motorola the known company of having defense contracts, are suddenly caring about open source privacy?! Cmon
The conclusion here is if you are after anonymity then you should ditch your phone entirely, having a “secure OS” won’t provide such goal but it might bring more attention to you than using of-the-shelf average phone.
Graphene is currently only supported on Pixels, so not sure what you mean by that.
>motorola is a US company
Motorola is owned by Lenovo, a Chinese company.
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..
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.
I've been running on several half-working recent android ports to my Xiaomi Mi 9t for many years now.
If I can get a modern phone, modern android, my privacy preserved and a hackable phone (to the extent an unlockable bootloader allows, which isn't a given nowadays, I especially hate how Xiaomi does it), I'm 100% sold.
We'll see when it comes out I guess!
- https://news.ycombinator.com/item?id=47202808
I'm sure that Google will do something like that as soon as it faced the US's carrot and stick they signed-up for.
You can probably try to use the stock recovery to flash a custom ROM, but I doubt it'll work. Custom ROMs rely on tools like TWRP or LineageOS Recovery for a reason.
I wouldn't think this applies to Motorola.
The key point is being able to lock it again after installation.
Do we have any idea if they'll have something ready before September?
https://privsec.dev/posts/android/banking-applications-compa...
Google Wallet is not supported at all.
If they don't support it -> notify them and change bank. Enough people doing this, something will change.
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.
It's probably a pipe dream but I do hope that someone like Motorola officially supporting GrapheneOS will make businesses take support somewhat seriously. If nothing else you sound less like a crazy person when you tell your bank's customer support "I bought a Motorola phone and now your app doesn't work" than "I flashed a custom ROM to my Pixel and now your app doesn't work".
https://privsec.dev/posts/android/banking-applications-compa... has a UK section.
I mean, they already have RISC-V.
https://frame.work/se/en/products/deep-computing-risc-v-main...
https://www.clicks.tech/en/products/clicks-keyboard-for-moto...
I cannot overstate my excitement.