> What's wrong with the upcoming partnership with Motorola where they work with grapheneos to get it suppported, but it's not preloaded?
It's definitely planned for GrapheneOS to be sold preinstalled on devices, but it will also be possible to buy devices without it and install it yourself with our web installer. The details need to be worked out. The focus is currently meeting the requirements and porting GrapheneOS to the devices.
AOSP is a Linux-based mobile OS. It runs fine on top of standard Linux kernels without downstream changes. Getting rid of the need for closed source userspace drivers for components like a modern Mali GPU can be done with AOSP and will benefit the most people that way. AOSP if many companies and others band together to do it. It could also happen due to government intervention due to Google's antitrust law violations, but that could be done poorly in a way that harms open source.
Privacy depends on privacy patches/protections and on security patches/protections. They do the opposite of taking it seriously from the hardware through the software.
None has anything close to the privacy or security of AOSP or iOS. Librem 5 is the direct opposite of hardware prioritizing privacy and security. It doesn't provide basic firmware updates, uses a bunch of extremely low security components and brings the awful privacy and security of a desktop OS to mobile on top of that. It's the opposite of how you're describing it. Purism's devices also aren't open source as they claim but rather are closed source hardware with closed source firmware. They only pretend it's open hardware and firmware by not shipping the closed source firmware with the OS, which leaves users without crucial privacy/security protections. The components don't have proper updates available regardless due to their hardware choices but they don't ship what is available and prevented doing it for some components.
> They target devices made with the intent of running linux, but also have a few ports to android devices.
AOSP is a Linux distribution. Linux doesn't mean glibc, systemd, GNU coreutils and GNOME. If you mean GNU/Linux or bringing systemd to mobile then that's what you should say.
There isn't a standard Linux distribution. Those operating systems have drastically worse security than a decent server distribution or the mainstream mobile Linux. Traditional Linux distributions don't have a standard set of core components or configuration so system administrators are assembling their own OS and the differences in security are vast. It's extremely rare to deploy anything close to the level of iOS and AOSP security but it's an entirely different environment on a server. Running a few server applications in weak sandboxes is far different than using a bunch of apps including an enormously complex web browser with a GPU, cellular, Wi-Fi, Bluetooth, NFC, etc. There's also no serious attempt by almost anyone to defend Linux servers and desktops against physical attacks with the disk encryption only even attempting to provide protection for data before the encryption passphrase is entered, not after.
Those ports of desktop Linux to mobile don't have a proper privacy/security model for running applications. They don't have anything close to modern exploit protections or hardware-based security features crucial to protect against increasingly sophisticated and widespread exploits. AOSP is a Linux distribution with drastically improved privacy and security compared to a traditional desktop Linux traditional. GrapheneOS starts from there and improves privacy and security much further.
System administrators of a traditional Linux distribution assemble their own OS out of their package and configuration choices. There isn't a well defined standard base OS. That's part of what makes it the traditional approach and is inherently incompatible with the privacy and security approach of AOSP or iOS in many ways.
Linux distributions use different implementations of init systems, shells, command-line tools and nearly everything else. Ubuntu uses glibc, systemd and Rust uutils coreutils. Alpine uses OpenRC, Musl and BusyBox as the defaults. Debian uses glibc, systemd and GNU coreutils as the defaults but supports other choices of init system. Each has their own variants of the projects they each package with different versions, patches compile-time configuration and default runtime configuration.
Using systemd, Bash, etc. on an OS Debian is a choice for the system administrator rather than the OS being defined that way. Even if people swap out major components for ones which aren't officially supported, it's not generally regarded as not using the distribution anymore. It's a far different approach than defining a standard base OS, developing that together as a whole with user installed packages and configuration changes are solely on top of that.
The higher up you go in the software stack, the more different things are across operating systems. The Debian installations across different machines are a vastly different OS with far different components and configuration. There are default sets of packages and configurations but not a standard base OS shared across each machine. Swapping out components and changing the configuration isn't making it not Debian and is pretty much required.
A huge portion of server Linux uses musl and BusyBox due to Alpine.
Embedded Linux has always heavily used different software stacks. Android wasn't much different in that regard on mobile. Android runs fine on standard Linux kernels without any mandatory downstream changes. It was never the only distribution making changes to the kernel regardless.
> Usability-wise, they are no match for Android and iOS—or even versions of them from five years ago.
They're also no match for the privacy or security of iOS or AOSP. They're bringing the lack of privacy/security model and protections on desktop operating systems and hardware to mobile. It's a massive regression for privacy and security despite being marketed in the opposite way.
> Waydroid is a container-based approach to boot a full Android system on regular GNU/Linux systems running Wayland based desktop environments (like PureOS).
No, it's only a partially working form of Android with the privacy/security model largely disabled and poor app compatibility. Waydroid is based on an ancient release of Android and disables the SELinux-based privacy/security model. It doesn't contain apps from each other and has far less protection for the Linux kernel from the apps. It has poor app compatibility and isn't a good approach to running Android in another OS. ChromeOS made a proper better Android container not losing the privacy/security model but migrated to using hardware accelerated virtual machines. It makes a lot more sense to use a VM since current era smartphone hardware fully supports it.
> PureOS also provides convergence via Phosh. Convergence means here that the same app can be used on a phone and on a big screen, the GUI adjusts to the available screen size.
Android Open Source Project has a desktop mode. It has a hardware-based virtualization layer for running desktop Linux applications too including GPU acceleration support.
> Phosh aims to provide a daily-usable, robust and easy to use graphical user environment for mobile devices running mainline Linux.
Android runs fine on mainline Linux. It doesn't require special kernels. That's tied to specific hardware rather than Android.
PureOS has far worse privacy and drastically worse security compared to iOS or AOSP. It's bringing the traditional atrocious privacy and security of desktops to mobile. Librem 5 also combines that with extraordinarily insecure hardware missing basic firmware updates and security protections. As a whole, these make it drastically easier to exploit devices. That includes going back to disk encryption which doesn't work for the average user due to them not using a strong passphrase and not protecting against data extraction with physical access unless the device is turned off.
These operating systems aren't compatible with most of the apps and services people want to use. It's going to become much worse. The compatibility layers several provide have extremely poor compatibility combined with disabling the Android security model and app sandbox. Apps running in those compatibility layers are much less contained with less isolation from the Linux kernel, not more.
Aside from that, many people care about privacy and security. Each of those operating systems is far less private and drastically less secure than the Android Open Source Project. None has a truly complete and working app sandbox or permission model. None uses modern exploit protections. None has serious hardware-based encryption features needed to protect against data extraction. They're not serious alternatives to an iPhone from a privacy and security perspective as an AOSP-based OS on decent hardware can be.
> but in case we don't manage to push back on this
It's a warning that's being added to Google Mobile Services operating systems. It doesn't negatively impact other operating systems based on the Android Open Source Project.
> various actual linux OSes for mobile
Linux doesn't mean GNU/Linux or systemd/Linux. It doesn't at all imply using glibc, systemd, GNU coreutils, Bash, GNOME, etc. Distributions using different userspace components including several of the ones you've listed are still Linux Android-based operating systems including AOSP and GrapheneOS are Linux distributions. Alpine doesn't use glibc and SailfishOS has a lot of their own mix of open and closed source software. Using a typical desktop Linux userspace stack isn't what makes it Linux and there's also not a lot of consistency in what's used on desktops regardless. A Linux distribution not using musl, glibc, GNU coreutils, etc. is still Linux.
> There are many more linux mobile OSes, but as far as I know these are the main ones. There might also be some inaccuracies on this post, I tested some of these a long time ago, and I never actually run the last 2.
AOSP-based mobile operating systems are Linux distributions.
> These operating systems aren't compatible with most of the apps and services people want to use.
Exactly this.
If I can't run WeChat, Venmo, my brokerage app, WhatsApp, etc. it's a non-starter for me. I might as well not have a phone, because these apps are pretty much the only reason I carry around a phone.
"Apps running in those compatibility layers are much less contained with less isolation from the Linux kernel, not more."
Being isolated a little bit more from the kernal offers an illusion of privacy meanwhile where you are, what you have installed, your photos and friends are available to other apps at a much higher level. I understand being able to slow down a nation state actor is important but most privacy concerns for average people happen at the OS level not the kernel.
This claim is false. Isolation and protection from the kernel is vital and it is already targeted for exploitation, and will be targeted even more as time goes on. Properly updating the kernel and improving its isolation and security is the bare minimum for even below average users, not just for high threat models. The claims you are making are unsubstantiated.
GrapheneOS has an official partnership with Motorola Mobility which is improving their next generation devices to meet our requirements and helping us port GrapheneOS to those. GrapheneOS will be officially supported on those devices with Motorola Mobility providing us with the stripped down hardware support code we need to support their devices with proper firmware/driver/HAL updates.
A bunch of companies are already selling devices with GrapheneOS installed. Those companies can start buying the future Motorola devices supported by GrapheneOS and doing the same thing with those which they already do with Pixels. Motorola can also specifically sell devices to other companies to sell with GrapheneOS with official support from Motorola.
> prohibiting OEMs from making or partnering with "non Google approved" OSes
It has been challenged in court and ruled to be illegal in South Korea and elsewhere. Regardless, it's only an inconvenience and can be worked around. Even if Motorola can't sell devices with GrapheneOS in many countries themselves, those can still be sold by other companies and Motorola can sell devices to those companies at wholesale rates where they can match the price of the non-GrapheneOS devices. Other than Google, most OEMs aren't directly selling most of their devices anyway.
> every app installed is known to the proxy since each app has a unqiue key
No such proxy exists in GrapheneOS. GrapheneOS does not intercept or proxy connections made by Google apps or other apps.
GrapheneOS doesn't include Google Mobile Services. Sandboxed Google Play is not part of GrapheneOS. Users can choose to install Google Play services, Google Play Store and other Google apps on GrapheneOS. Unlike a standard GMS Android device, those are installed as regular sandboxed apps with no special access. The feature provided by GrapheneOS is a compatibility layer coercing those to run as regular sandboxed apps if installed by users. It doesn't involve intercepting or proxying any connections.
> location data is proxied
Location request rerouting is an entirely local feature of the sandboxed Google Play compatibility layer. By default, it replaces the Google Play location library used by many apps with another implementation using the local OS location service instead of the local Google Play location service. This isn't intercepting or proxying connections.
Google Play has an optional network-based location service that's opt-out for a GMS Android OS although it's opt-in for sandboxed Google Play and people would also need to grant the required permissions to Play services which aren't normally needed.
GrapheneOS has an opt-in network-based location using Apple's service either directly or via a proxy. We'll also eventually have our own service with offline database download support as another option. We have to build our own database to use for this first.
You're misunderstand what location request rerouting means. It reroutes apps which normally request location from Play services to ask the regular Android location API for it instead. This doesn't involve servers other than optional network-based location for apps which support using the network or fused providers. Network-based location is opt-in for GrapheneOS.
> They mention no proxy of RCS data, but in theory, an RCS message requires location data. So, the proxy knows when a message is sent and received, at a minimum.
GrapheneOS doesn't proxy things in the way you claim in the first place. It doesn't proxy any connections involving carriers and doesn't proxy any connections made by Google apps. It doesn't come with Google apps and those would need to be installed by users.
> So, based purely on the FAQ, if you use the sandboxed services and enable RCS, Graphene knows every app you install and has your location data, but they erase it after a couple of weeks.
This is all completely untrue. GrapheneOS doesn't include with sandboxed Google Play. Sandboxed Google Play compatibility doesn't make any connections to GrapheneOS servers. It doesn't proxy anything through our servers. RCS via Google Messages doesn't involve our servers either.
You're misunderstanding our approach to all of these things. Location request rerouting means replacing the local Play services location API for apps using it with the OS location API. That means asking the OS for location rather than Play services. That isn't a connection to a server. It means that by default, apps using the Play services location SDK will work without Play services needing to be granted Location access based on the OS satellite-based location. If users enable network-based location for the OS location service then it will work for apps normally using the Google Play network or fused location providers. It's an entirely local compatibility layer as with the whole rest of it. Sandboxed Google Play compatibility layer has 0 connections to our servers and there's no reason it would need to connect to our servers.
> Graphene proxies all the Google services connection. They take over the connections that would go to Google. They then, supposedly, only forward the ones you wish.
GrapheneOS doesn't include Google Play services. Unlike LineageOS, GrapheneOS replaces all of the standard Android Open Source Project (AOSP) connections with our own servers. Also unlike LineageOS, GrapheneOS adds toggles for these connections providing a way to disable the ones which didn't already have a way to do it. See https://eylenburg.github.io/android_comparison.htm for a comparison across AOSP-based operating systems covering what's done with most of the standard AOSP connections. It doesn't cover everything such as the Certificate Transparency (CT) log list downloads added in Android 16 which are now used by default for enforcing CT for apps targeting Android 17.
> Graphene proxies what would go to Google on regular Android.
GrapheneOS doesn't include Google Play services. It has a compatibility layer enabling running Google Mobile Services apps including Google Play services and Google Play Store as regular sandboxed apps, but it doesn't come with those. Users can choose to install those in specific profiles.
> I am getting downvotes on this, but that is how their Google Play sandbox works. It is proxied on their server, not your phone.
>
> A non-Google copy of your Google pointed traffic is made. That is a fact. It is identifiable to you or they could not individually forward this or that. That is a fact.
GrapheneOS doesn't include sandboxed Google Play. It does not come with it. It's possible to install those apps on GrapheneOS and it provides a compatibility layer to make it work. The compatibility layer doesn't involve proxying anything to our servers.
> Extricating from Google is the answer. Not relating your RCS chats et al through a third party then to Google then to that third party and back to you.
No such thing exists in GrapheneOS. It doesn't include any Google apps and doesn't proxy any of the connections made by Google apps elsewhere if people install them.
GrapheneOS has low-level support for RCS but doesn't have an RCS app yet since the only one for Android which exists in practice anymore is Google Messages and Google apps aren't included in GrapheneOS. Google Messages can be installed by users on GrapheneOS and set as the SMS/MMS/RCS app instead of using our fork of AOSP Messaging but that's definitely not a default. We'll have our own RCS implementation in the future in our fork of AOSP MEssaging.
> They wrote an article on it a while back.
No, and it's definitely not how sandboxed Google Play works for people who choose to install it.
It sounds like you're misunderstanding what our sandboxed Google Play compatibility layer handles location requests made to Play services. For users who install sandboxed Google Play on GrapheneOS, our compatibility layer redirects apps requesting location from Play services to request it from the OS instead. This doesn't involve making any connections, it happens locally on the default. By default, only GNSS (satellite-based location) with A-GNSS (SUPL and PSDS) is used. GNSS is a receive-only system. We add toggles for configuring SUPL and PSDS with choices between GrapheneOS, Google or Off. PSDS are static database downloads covering the whole world so that's just another form of update download. We also add a toggle for opting into our network-based location implementation which uses Apple's service either directly or via a proxy. You seem to be confusing our location request redirection with intercepting connections and running those through our services which isn't what it involves at all. Our location request redirection avoids needing to grant Location access to Play services by making it use the standard Android OS location service instead as many apps already do. There's a toggle for this in case someone actually wants to use Google's location service with their network-based location instead of Apple such as if the Apple data for their area is awful.
> Graphene with Google Services is like calling up an Intel Agency and signing up to use them as your VPN.
GrapheneOS doesn't include Google Mobile Services, and our sandboxed Google Play compatibility layer doesn't work that way at all.
> Without Google Services, it is a way to degoogle a phone with an SD card slot and 3.5mm phone jack if Motorola continues on track, but I would prefer regular Lineage support than Graphene for that purpose in case the middle man aspect expands to non-Google Services apps later.
There's no such man-in-the-middle system in GrapheneOS as you claim. LineageOS does not replace the Google servers for all of the standard AOSP services as we do and doesn't provide similar settings to control all of those. GrapheneOS does not intercept/redirect Google services used by Google apps as you claim. It doesn't come with Google apps as you're describing either.
> I want straight no-google android with the chipset drivers so that calls and sms/mms messages work without Google getting a copy of every message sent and received, and I want it on phones with sd card slots and 3.5mm headphone ports.
GrapheneOS only includes support for using SMS/MMS via the carrier. There's no involvement from Google unless Google is your carrier or your carrier is using GCP to host their servers or something similar. Using Google's RCS services would require that you go out of the way to install Google Messages after first going out of the way to install sandboxed Google Play followed by setting Google Messages as your carrier-based messaging app and granting the required permissions to use RCS (Phone permission for Google Messages and Play services along with the ICC authentication toggle in the sandboxed Google Play settings).
You're talking about it as if us supporting installing these apps as regular sandboxed apps somehow makes that the default approach. That's not how any of this is supported at all. You have to go out of your way to install sandboxed Google Play or especially Google Messages. Those don't come with GrapheneOS.
GrapheneOS does not include Google Mobile Services or Google Messages. It does not intercept or proxy connections made by Google apps installed by users. None of that is part of how it works.
It's definitely planned for GrapheneOS to be sold preinstalled on devices, but it will also be possible to buy devices without it and install it yourself with our web installer. The details need to be worked out. The focus is currently meeting the requirements and porting GrapheneOS to the devices.
reply