Android is not at the expense of either freedom or privacy. Desktop Linux OSs come at the cost of both. It would be better to direct effort to AOSP projects as it is a much better base to build from.
The Android family of operating systems and the forks made from the android open source project are all linux distributions, and linux phones.
Using desktop linux phones and trying to force that as a norm would set privacy and security back substantially.
The inverse of what you suggest, which is Android with desktop linux app compatibility, would be a huge step forward, and is already much closer than you might think.
Modern phones have substantially better VM support in the hardware than in previous models, and it is maturing at a very fast rate. We would be able to run linux VMs on Android, paired with desktop mode, with evidence for USB passthrough for an externel GPU in AOSP
There is also evidence that we will be able to put desktop linux app icons on the Android homescreen and using them in an app-like fashion.
This would use the more secure host to run the VM for the less secure OS.
No, official GrapheneOS is an ideal method to control data. As a part of this, they also provide build documentation for whatever you want to do. It is FOSS, after all.
To be clear, I am NOT advising root access. I am not contradicting myself. I am telling you it is dangerous but still telling you how it can be done in a less terrible way. To withhold that info would be senseless gatekeeping. GrapheneOS supports being built as a userdebug image but that will not stop them from telling you how bad an idea it is to use it on a production device.
GrapheneOS will not be rolling back aspects of the security model. That would be a massive step backwards for privacy and security.
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.
Most of the hardware security requirements are met by multiple lines of devices. The issue is, not all of them are met. Many have poor updates or intentionally cripple standard features for anti competitive reasons.
So no, they are not "only met on a single line of devices", in fact Samsung gets super close, but they remove yellowboot support and cripple the device if you unlock the bootloader.
Thats are improving peoples security overall by only using pixels at this time. Nothing else currently meets the hardware security requirements except pixel devices. To use subpar hardware would set the security back substantially. They are not going to compromise on security for the sake of broad device support.
Also note that Motorola Mobility has stepped up to provide the needed hardware security features. So it will expand to a subset of Motorola devices next year.
You would install your own build of GrapheneOS. Not the official images.
Its not advisable to run anything as root, at all. Or expose access to it in any form.
You can make userdebug builds to access a form of root that doesnt undermine the entire security model, in ADB. Afaik this lets you access apps internal directories but is not recommended for production devices.
You dont have the ability to guarantee you have overridden anything. The integrity of the OS cannot be verified and anything with root can lie to you that it was revoked. It does not put power in your hands.
Installing your own build does wipe the device when you unlock the bootloader, yes, but updating it with a locked bootloader does not. It would be a one time transfer if you have official images already installed.
Your paths forward are a false dichotomy. These are not the only 2 options. You can simply update your build with the changes you want.
The randomness of an app is irrelevant and apps need to jump through significantly less loops to obtain root access without your input. And even if they didnt do that, and you permitted root instead, the app can lie about you revoking it later in either case.
This is blind ideology over safety and real ownership. Root is a hacky shortcut for proper functionality, and is not a prerequisite to ownership in the slightest.
Being the administrator and being able to sidestep OS protections are not the same thing. Without root, the user is in control of what application does what and how. With root, the user is not. Root is not freedom or ownership, like many try to claim. Root is a hacky shortcut to proper functionality. You can build and sign the OS with your own keys, without undermining the security of your device, and adding whatever functionality you want with the principle of least privilege.
Its really funny because Tron, or at least Tron Legacy, is a great example of why godhood is dangerous and why a user and a program having root access is catastrophic.
> every app installed is known to the proxy since each app has a unqiue key
GrapheneOSs proxies do not collect and send any "unique keys" from apps. That is made up.
> 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.
They dont mention a proxy of RCS data because there isnt one. RCS messages do not require location data. None of the GrapheneOS proxies are related to RCS and the proxies do not know if an RCS message is received or sent.
> 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.
You did not read the FAQ at all.
> There is some vagueness regarding the RCS implementation message content. People claim Google can't read it, yet they specify they can read it in the client terms, and offer a managed RCS archiving service that works regardless of messaging client or supposed encryption. Is the RCS query proxied? Graphene does not mention it, but the simultaneous location data to use it is.
RCS is end to end encrypted on Google messages. The RCS spec also includes end to end encryption. There is no RCS proxy and RCS is handled by google messages. No other client for it exists at this time. The location data provided by SUPL is not given to apps, it is used for OS location that can be reported to apps. An app must have the location permission to have location data provided by the OS.
You seem to be greatly misunderstanding what is actually happening.
You are conflating default OS domains with google play services. Google play services is not bundled or installed by default, and is not given any kind of privileged access when it is installed. It does not handle OS domains or functionality, and GrapheneOS does not proxy its connections in any way.
As for the default domains of the OS, most are to GrapheneOS servers, not proxies. The only default OS connection that is proxied to google is remote key provisioning.
As for non-default connections, the only google proxies are widevine, for apps that use widevine, and SUPL, for location locking. SUPL can be disabled, and GOS is considering removing SUPL if network location is effective enough, or if they can host their own SUPL server viably.
GrapheneOS does not run anything through google services. Nowhere in the "terms" is this stated. GrapheneOS uses first party servers for all default OS connections.
Root access takes agency away from you and gives it to 3rd party software. It doesnt expand freedom at all, it just allows other software to abuse the user.
With a proper security model and verified boot, you can be certain you, the user, are running exactly the OS you expect to run. You can also properly revoke permissions to software and gate access as you see fit. With root, you cannot guarantee you are running what you expect and apps have to exploit much less to get root access, or just keep root access if given by the user. You cannot revoke godhood, it can just lie and say you revoked it. There is nothing enforcing any security features.
An objective and accurate assessment of the available options is not absurd, its the bare minimum.
As the userspace improves, more attacks will be (and are) directed at the kernel, the linux kernel is already really bad for security, and it is absolutely vital to keep updating due to its architectural deficiencies and constant issues.
Alternative OSs on subpar hardware do not improve privacy or security. They do the opposite. Other hardware does not provide vital hardware security features, and many OEMs do not provide yellowboot or any proper way to relock the bootloader with another OS. Verified boot is very important for security.
Note that the OEM provides firmware images, an end of life device can never be secure because it lacks critical firmware updates.
This isnt subjective, this isnt rigid, and this isnt a matter of attitude. This is fact.
Linux security is quite bad. Android tries to improve this and GrapheneOS improves it even farther than that.
Which device you need to be more secure depends on your needs and which device you put sensitive data on, but a mobile device is going to provide far better privacy and security than any desktop hardware or OS is currently capable of.
For context, GMSCompat is Google Mobile Services Compatibility. GrapheneOS installed the google play store and services as normal apps, and worked backwards to make it behave. There is no google specific sandbox, rather it uses the standard android user app sandbox. This means google is bound by the same rules, as special casing anything creates more maintenance burden and attack surface. GMSCompat is fully open source.
> "Thanks, but there's no way..."
Its reposted because the information is accurate, and misinformation regarding it is very prevalent.
> "Yes, I knew it's in a sandbox..."
Relative to MicroG, sandboxed google play is much more private, secure, and usable. I would not describe it as a privacy paradise, but MicroG does not improve upon this, and instead makes these aspects worse.
> "The sandbox still needs internet access..."
Most google libraries operate independently of google services and do not depend on them to function. FCM is an exception due to how push notifications are optimized (by using one app for the connection). MicroG does not avoid this.
> "For example, Signal will actively reach..."
You do not need to provide an identity to google. This can also be avoided with a VPN, and is not specific to google. There is the concern of metadata but Signal sends empty notifications without any identifying info. They are only used to wake the app up to fetch its own notifications.
> "So while the sandbox is definitely very useful..."
It confines google services to the same rules and restrictions as all other apps. MicroG does not. MicroG also does not avoid running unwanted software, referring to the google libraries in apps and the google code MicroG downloads.
> "Do you know what privileged context means..."
MicroG violates the security model by necessitating signature spoofing, which puts it in a position to receive data it was not intended to receive, there is also attack surface exposed by having access forbidden by the app sandbox. Sandboxed google play is bound by the same app sandbox as all other apps, and would not be any more or less capable of exploiting the device than any other app. The idea that google would try to exploit the device is nonsensical though. But granting both google and a 3rd party privileged access is still unacceptable.
> "Rather than running the unwanted proprietary (but necessary) software..."
Google play services runs in the android user app sandbox. It is not an "attempt", it is successful at doing this. MicroG being open source does not matter in regards to privacy or security. It did not change how MicroG has leaked location to apps without location permissions, it does not change how it downloads and runs google code both privileged and outside of its own APK, and it does not change how other apps are running google libraries anyway. Note that the proprietary code it downloads is not confined to the app sandbox.
> "For example, microG will replace Gmaps..."
Im unsure if you are referring to the app Google Maps, or google maps integration. GrapheneOS reroutes googlefusedlocation requests to the OS, rather than google services. You can use an app other than google maps, and apps with google map integration can simply send your location to google directly, independent of google services or MicroG.
> "It seems fairly obvious to me that less data sharing..."
Googles access to data is not limited by using MicroG, relative to sandboxed google play. And the size of proprietary code is irrelevant, that code can be anything. It can be malicious with 2 lines, or benign with 2 million. Access is what is vital, not size. Google is not permitted to "run wild", and is granted no additional access compared to any other app. Im unsure what you mean by self updating functionality, but for apps from the playstore, nearly all of them are signed with a key that google holds, and MicroG can do nothing about this. GrapheneOSs App Store is responsible for updating google play and google services, it cannot update itself.
> "What threat would sandboxed microG pose that sandboxed GMS doesn't?..."
Using MicroG necessitates GrapheneOS violate the android security model, trust a 3rd party unnecessarily, cripple 99% perfect compatibility, use code that is not near as battletested as play services, run google code as privileged, and run a software that has had serious privacy violations in the past. Not only is the base insufficient, but any finished product based on it still would not compare to GMSCompat. The logic is that GrapheneOS wants the best compatibility, the least changes to the android app sandbox, 0 privileged google components, no violations to the android security model, and no need to maintain a reimplementation when google services and store are already maintained by a huge organization.
Im not disputing the ability to use the device for many years. Using the device for a long time and the device being supported for a long time are different things.
Fairphone doesnt make their own phones, its outsourced to an ODM and Fairphone has very little input on how its designed. They havent "sourced" anything. Fairphone also stops providing kernel updates very quickly and delays userspace/driver/firmware backports for months. They delay yearly updates for years too. This doesnt even touch upon the fact they used public signing keys in the past.
It is not derogatory to say that it is e-waste out of the box, it is simply accurate. Choosing to continue using it despite how unsafe it is does not change the abysmal support it is given. A modern iPhone/android used from launch to the end of its 7 year support time, then properly recycled, would be far better for privacy, security, and for the environment. A support window that long would also provide a strong used market to continue using these devices. Cheap ODM phones with short support windows, and not benefiting from economies of scale, is a waste.