GrapheneOSWe're happy to announce a long-term partnership with Motorola. We're collaborating on future devices meeting our privacy and security standards with official GrapheneOS support.
https://motorolanews.com/motorola-three-new-b2b-solutions-at-mwc-2026/
🌸 Ⓐnarkitty lumi-nhac 
@GrapheneOS does this mean i will be able to get a degoogled motorola device in the future?
Alexia 
@alexia @GrapheneOS yeah, ofc the end goal is using a proper linux phone, to get maximal freedom and security
but having a degoogled android device is a step along the way. though i have been stuck at that step since around 2014
but having a degoogled android device is a step along the way. though i have been stuck at that step since around 2014
@lumi @alexia GrapheneOS and the Android Open Source Project are Linux distributions. We strongly disagree with the premise that glibc, systemd and GNOME are preferable to the much more private and secure AOSP software stack. Moving to the desktop software stack would be a huge regression for nearly everything we care about and focus on improving. It's already possible to run desktop Linux apps in GrapheneOS including GUI apps via the hardware virtualization support and there's a desktop mode.
witch_t *navi@GrapheneOS @lumi
me with a musl, openrc, and sway system looking over -- i think you're starting with the wrong premise here
me with a musl, openrc, and sway system looking over -- i think you're starting with the wrong premise here
@navi @lumi Where's the application sandboxing, memory safe languages, modern exploit protections, deep integration of powerful hardware-based security features and everything else we focus on in GrapheneOS?
Aside from any of that, the concept that the Android Open Source Project isn't a Linux distribution is wrong. Linux isn't the userspace software that's largely portable to other operating systems. There was a Debian variant using the FreeBSD kernel which is clearly not Linux.
Luci ☯⚛@GrapheneOS @navi @lumi That doesn't take away from what navi said. Either way. What of the concern that AOSP might not be open anymore at some point? The whole ecosystem is being closed down. I think that's definitely a genuine concern. What's your plan when that happens, if you can disclose? Will you maintain a fork of AOSP with Motorola, or by yourselves? That's kind of what I would like to know so I can feel reassured that there's a future for the platform even if Google further alters the deal.
Edit: This comment was followed up by the type of activity we've all come to expect from whoever seems to run GrapheneOS' social media, but they since deleted their side of it and blocked me... :') I summed it up here:
zivi@quantumsys @GrapheneOS @navi @lumi AOSP should not be relied on if you give any amount of fucks about freedom. sure it’s technically a linux distribution, but that says little when you have to plead OEMs for what little up to date source code is available. it’s being actively crippled by google into a complete dead end.
zyxhere💭
@zyx @quantumsys @GrapheneOS @lumi
that mentions relying less on linux, and more... on aosp tools, which is the opposite of safeguarding things against google
that mentions relying less on linux, and more... on aosp tools, which is the opposite of safeguarding things against google
@GrapheneOS @lumi
where's your vetted package repository and actually end-user verifiable system booting and bootstrapping (aosp taking 3 days to build on a fairly high end personal hardware makes it fail at that, hard, not to mention the cursed build system), and open community based development model (which google is dead set on removing from aosp)
where's your vetted package repository and actually end-user verifiable system booting and bootstrapping (aosp taking 3 days to build on a fairly high end personal hardware makes it fail at that, hard, not to mention the cursed build system), and open community based development model (which google is dead set on removing from aosp)
LisPi@navi @GrapheneOS @lumi > (aosp taking 3 days to build on a fairly high end personal hardware makes it fail at that
How was that ever considered reasonable? Astonishing and appalling.
How was that ever considered reasonable? Astonishing and appalling.
David Heidelberg@GrapheneOS @navi @lumi let me disagree here. Android is fork of Linux.
Fork with huge change-set - hard to review.
With drivers written to "get to market fast", not quality.
With other closed drivers in userspace to avoid open sourcing.
Naaaah, this ain't Linux I'm running on my laptop.
I won't argue — security features of AOSP may be superior. But what runs beneath these features isn't!
> let me disagree here
Okay, but you're objectively wrong.
> Android is fork of Linux.
No, Android isn't a fork of Linux. Android works fine with mainline, stable and longterm Linux kernels from kernel.org. It doesn't have any required downstream patch set.
> Fork with huge change-set - hard to review.
It's not a fork and has no required changes to the kernel.
> With drivers written to "get to market fast", not quality.
Hardware vendor drivers aren't Android.
> With other closed drivers in userspace to avoid open sourcing.
That's not part of Android and is in no way required to use it. Desktop Linux distributions ported to the same hardware nearly entirely relying on the same drivers regardless.
> I won't argue
You're just making objectively inaccurate claims to promote massively rolling back privacy and security by moving to legacy desktop software. Replacing vendor drivers has nothing to do with that whatsoever.
> No, Android isn't a fork of Linux. Android works fine with mainline, stable and longterm Linux kernels from kernel.org. It doesn't have any required downstream patch set.
Show me one vendor of phone shipping clean kernel. One.
Hardware vendor drivers are part of Linux I use, are you implying Android != Linux? 😉
HybridStaticAnimate@okias @GrapheneOS @navi @lumi They do not need to show you that. Your subjective criteria for this is invalid. An example doesnt need to exist for it to be accurate. It just means Phone vendors decided not to do it.
@okias @GrapheneOS @navi @lumi That is incorrect. Android and GrapheneOS are Linux distros and are perfectly capable of running mainline linux kernels. Linux is not a badge of honor that you apply to what you like about a distro and what you dont.
d@nny disc@ mc²@navi @GrapheneOS @lumi hate seeing people fight over this as if sandboxing is something that can never be made freedom-respecting. i consider it a distinct lack of imagination not to re-evaluate and seek to virtualize OS interactions which impose relatively generic models of trust and access that are heavily overloaded in the standard linux userspace and cannot be simply reused
@hipsterelectron @GrapheneOS @lumi
> i consider it a distinct lack of imagination not to re-evaluate and seek to virtualize OS interactions which impose relatively generic models of trust and access that are heavily overloaded in the standard linux userspace and cannot be simply reused
well grapheneOS is trying something like that https://grapheneos.org/faq#roadmap -- aosp only, but it feels like the same vibe to me?
> i consider it a distinct lack of imagination not to re-evaluate and seek to virtualize OS interactions which impose relatively generic models of trust and access that are heavily overloaded in the standard linux userspace and cannot be simply reused
well grapheneOS is trying something like that https://grapheneos.org/faq#roadmap -- aosp only, but it feels like the same vibe to me?
@navi @GrapheneOS @lumi linux is in fact a corporate project and has been for a while and it's ridiculous and unserious to me to portray it as the apex of "freedom-respecting" because of the many vested corporate interests who are inextricable from the linux governance structure. linus demonstrated that you can get corps to invest in your open source code like this but the coercion and inertia works both ways
@navi @GrapheneOS @lumi i'm working on bootstrapping build and packaging logic atm and sandboxing mechanisms like unshare paired with virtualization like overlayfs is a tool that enables surgical precision in constructing dependency graphs that don't make overly broad assumptions about the user environment, enabled by crafting OS interfaces to model the trust and access specific to my application context.
@navi @GrapheneOS @lumi it is just remarkably obtuse to claim (as the fdroid entourage is so fond of doing) that the interaction model advanced by mainline linux distros is inherently freedom-respecting when it is being specifically invoked to rule out R&D into e.g. privacy-respecting models of trust and access that are simply not interesting to mainline linux
@navi @GrapheneOS @lumi "freedom-respecting" is not a measure of how closely it hews to the vision of linus torvalds but a measure of how much a software ecosystem precludes alternative imaginings of the user's relationship to their computing hardware. no one in this discussion would argue that android is not a corporate project, but the implicit and ridiculous assertion that goes unchallenged is that when linus torvalds got corps to work for him that he was necessarily still working for you the user. systemd too seeks to apply corporate computing models to distros with actual users and was notably to blame for enabling the xz-utils vuln. we can do so much better! this should be an exciting new frontier where we can push each other to shake off the chains that bind us to hierarchical power relations! linux is the floor!
King_of_Ooo@GrapheneOS @lumi @alexia The current default software stack for desktop Linux is kind of terrible and the lack of coherent threat model or proper ecosystem of sandboxed applications are major issues with desktop right now. What I am still questioning is whether it is even possible to make a proper competitor to ChromeOS (if we ignore the hardware insecurity of basically all PCs).
So example software choices:
systemd -> dinit or s6
sudo -> s6-sudo (setuidless)
glibc -> muslc
glibc malloc or jemalloc -> hardened_malloc, malloc-ng, or mimalloc-secure (which supports more CPU architectures)
bubblewrap (sandbox used by Flatpak) -> #syd (it's written in Rust, has many important exploit protections, and can even be the user login: https://gitlab.exherbo.org/sydbox/sydbox)
GNOME or KDE -> XFCE (when their new Rust Wayland native WM is finished)
gnutils -> *BSD or uutils
The issue of course with most of these alternatives is that they are separate projects and therefore dont have the same goals, methods, or threat models. Also most of these projects are written in C which does not help at all. Also there is of course the lack of a proper chain of trust from the hardware to loading the kernel and userspace.
It may just not be reasonably possible to provide a alternative without millions of dollars of funding and a decade of development. It would be nice for there to be an alternative to AOSP/ChromeOS or even MacOS for desktop computing which actually takes security seriously. It doesnt even need to have be completely on par when it comes to security, just do better than current Linux distros (not a very high bar).
What are your thoughts on what to do in case the day comes that Google kills AOSP?
@King_of_Ooo @GrapheneOS @lumi @alexia why would you ever replace gnu coreutils with any of the bsd ones? uutils I can see but anything other than that??
@zyx @GrapheneOS @lumi @alexia Simpler and cleaner code bass. Much easier to audit. More POSIX compliant.
Uutils is cool, but is intentionally striving for feature parity with gnutils. This means the same feature scope as gnutils which is rather large. Rust code is a definite advantage though.
> systemd -> dinit or s6
Lots of these are giving up even more security features.
> hardened_malloc, malloc-ng, or mimalloc-secure
These aren't the same classes of allocators at all. Neither the musl malloc or mimalloc is a hardened allocator. mimalloc is performance focused and musl's is focused on low memory usage.
> What are your thoughts on what to do in case the day comes that Google kills AOSP?
What about when IBM decides to kill systemd, GCC and GNOME?
1. What security features? I understand these init and service managers lack service sandboxing, but that is what sydbox can provide. systemd is do massive that it isnt reasonable for a small team to audit it (alongside all the other OS components) when considering whether to depend on it for critical systems. Lacking features are better than architectural problems because it is easier to refactor and extend a small projects than do the same for a massive project. Every project starts somewhere, why choose a project based on what it provides now (eg systemd) instead of what we can make another do tomorrow?
2. These may not be hardened memory allocs when compared to GOS' hardened_malloc, but they are definite imptovements over the default memory allocs of most Linux distros. I only mentioned mimalloc because hardened_malloc does not support other archs than amd64 or arm64, which could be useful to someone. Do you know of other hardened memory allocators? I heard of ISO Alloc but idk if is actively developed.
3. This doesn't really answer my question. If you look at my original comment I don't even think that GNOME, systemd, or GCC should be even considered for a developing a secure desktop OS. These projects have decades of technical baggage and would be near impossible to repurpose. My question was what happens if Google kills AOSP, separate from any consideration about trying to use Linux as a base.
None of the projects I mentioned are in a place to be used for a secure OS. None of them use any of the Linux sandboxing or security features in their code to limit access or enforce least privilege. Simpler projects is much easier to extend than trying to detangle and debloat the likes of GNOME, systemd, or GCC. If these projects die there are hundreds to replace them. None take security that seriously, which is an architectural problem with basically all Linux software, but a rival for Android isn't going to just pop out and surprise us without a decade of development. My question also "Is it even possible without a multibillion dollar company to develop a secure OS on par with an Android OS?"
So my question again: what do we do if Google kills AOSP. They aren't right now, they might not ever, but they are malicious and for profit. They will make (more) bad choices that harm the health of their admittedly useful/important projects.
@GrapheneOS @King_of_Ooo @lumi @alexia
What about when IBM decides to kill systemd, GCC and GNOME?
systemd
Between GNU Shepherd, supervise-daemon and runit? 
GCC
You'll have to explain why/how IBM owns GCC. Fairly sure it's an actual FSF project. 
GNOME?
RIP lol 
Other than the accessibility stuff most of it I don't care much about, and with the ensloppification going on & Red Hat apparently insisting on it, it might well die anyway.
What are your thoughts on what to do in case the day comes that Google kills AOSP?
This however has real chances of happening and already has a largely closed development process with no community.
Which means it doesn't even need a poison pill contributor agreement, all the necessary rights are probably already in Google's possession for malicious license changes.
Not to mention that the main useful part of Android, the drivers & their documentation, aren't even included anyway. Everything else could be replaced by something better with some work.
@lispi314 @King_of_Ooo @alexia @lumi AOSP has a far larger development community than desktop Linux. There are a huge number of both corporate and community AOSP-based projects. There's a massive community of people working on all kinds of projects related to it. Desktop Linux is assembled out of a bunch of barely maintained or developed projects with one of two developers each. It has nearly non-existent systemic work on almost anything aside from systemd gobbling up components into itself.
@GrapheneOS @King_of_Ooo @alexia @lumi So, how many of those community projects aren't simply downstream like the Mozilla Firefox ones?
How many are actually credibly in a position to take development over entirely with a dead upstream?
How many are actually credibly in a position to take development over entirely with a dead upstream?
@lispi314 @King_of_Ooo @alexia @lumi systemd won not because it's good but because it actually exists as a somewhat coherent basis for an OS providing the features which are wanted. It didn't have to be a sensible or good implementation of almost anything. It's far from only an init system and the overall desktop and server ecosystems are increasing based around it. All the non-tiny desktop Linux stack ports to mobile are heavily using systemd. They're bringing systemd to mobile, not Linux.
@GrapheneOS @King_of_Ooo @alexia @lumi You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
The overwhelming majority of the BSD tooling that isn't systemd could be ported with a modest effort if systemd died. Note that I linked daemon supervisors earlier, because session managers and init systems are a lot easier to come by.
edit: Ah, my bad, I confused the subthread. You did ignore it and replied to the prior post.
@lispi314 @King_of_Ooo @alexia @lumi
> You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
Don't know what you're talking about. You're one of hundreds of people.
> The overwhelming majority of the BSD tooling
It has little to do with the desktop software stack. That increasingly only has an incomplete port over to BSD with a growing amount of hacks. It would just roll it back even further.
@GrapheneOS @King_of_Ooo @alexia @lumi
You know, if you're just going to avoid the question you could simply not answer that post, like you did with my mobile modem isolation question.
Don't know what you're talking about. You're one of hundreds of people.
This would be the one (started here).
It has little to do with the desktop software stack. That increasingly only has an incomplete port over to BSD with a growing amount of hacks. It would just roll it back even further.
In conjunction with the daemon supervisors? Very little would be lost that cannot be recovered with some work.
It would be somewhat tedious but hardly catastrophic or deadly, unlike the loss of upsream AOSP for every AOSP derivative.
Or Mozilla upstream for all the downstream. Which with slop is looking increasingly likely to happen.
LisPi (@[email protected])
@GrapheneOS By the way, I'm still very interested in your input on this part.I would hope that such isolation is part of the GrapheneOS safety requirements.@greenpete @bobkmertz @joe9nf
TehAppKiller@GrapheneOS @lumi @alexia No low level access for a dev = Not a Linux OS (only RIP Windows Phone™ offered that)
nieuemma@TehAppKiller @GrapheneOS @lumi @alexia I feel like all you need for a Linux OS is to be based on a Linux kernel.
Emmy 🏳️⚧️🇵🇸
Georg Weissenbacher@GrapheneOS @lumi @alexia firstly, don’t see this as an attack on GrapheneOS (it’s great what you are doing), but I believe the aim of Linux-based projects like #postmarketOS is to achieve (more) independence from the manufacuters in terms of software/driver support. Sure, ultimately this may require open-source hardware, but it’s nice to dream. I find these projects valuable, even if they aren’t quite there yet. (And yes, I know you could also just incorporate these open source drivers once they are available).
Ren@GrapheneOS @lumi @alexia I wouldn't call Android a linux distro just due to how different it's kernel has become from Linux over the years, (kinda akin to how Linux is unix-like but isn't unix) but I do agree Android is MUCH better suited to a mobile device than traditional desktop Linux. As cool as it would be to have a phone that becomes a desktop Linux device on a dock, I just have not been convinced at all by the mobile Linux space, and a degoogled Android gets a better experience with basically the same benefits
shad3@GrapheneOS Currently things are fine with Android but Goigle keep moving toward making Android more locked from software and apps. Is not this going to be a problem to what we have now? or there is a workaround?
Cassandrich@GrapheneOS @lumi @alexia I'm excited for GrapheneOS success for people it's for, but I fundamentally don't like the Android (AOSP, not even talking about Google) model of how basically anything works. Non-Android mobile OS options are what I want. Ones where I have full root, can run a small set of trusted apps from my distro just like I would on a laptop, and where everything else runs in an extremely restricted sandbox. I don't want those relationships inverted where a gigantic pile of Java code I could never understand or build or modify is the root of authority and I just have to trust that it's going to let me do what I want.
@dalias @lumi @alexia GrapheneOS has to get huge adoption and major partnerships before we can start on our much longer term goals of moving away from using a Linux-based OS as the core operating system to a more secure platform. We want to be running the current application layer part of the OS solely via virtualization eventually. We don't expect to ever make the Linux kernel and overall model it supports on top secure enough for our goals. We'll still need the AOSP-based OS for apps.