Does anyone prefer CalyxOS over GrapheneOS or LineageOS?
Graphene is honestly ahead on the security and privacy front. MicroG requires very strong privileges and weakens the comprehensive privsep you'd otherwise have; GrapheneOS offers sandboxed play services with the standard SELinux policies for unprivileged Android software.
GrapheneOS also has hardened_malloc, which seems to have the best design for malloc hardening out of any alternatives I'm aware of.
On the userspace side, Graphene uses several of its own apps. One is Vanadium for its webview and browser; it's a hardened fork of Chromium. Check the patchset; it's got a bunch of security improvements and cross-pollenates with Bromite. The most interesting feature they've been working on is per-site JIT toggles.
The list goes on. Few other OSes come close.
Now, if you want to tinker with your phone at the expense of security, Lineage is actually a great option. It has a big community of tweakers and ricers who root their phones and come up with some cool experiments. It also supports a wider variety of devices, including devices abandoned by their manufacturers. Don't expect security updates, though.
I'd pick Calyx over privacy grounds not Graphene. (I totally agree that Graphene beats anyone on security grounds by miles, and depending on your threat model, security could be related to your privacy)
> MicroG requires very strong privileges and weakens the comprehensive privsep you'd otherwise have
If we're speaking of FAKE_SIGNATURE.... No it doesn't? If implemented properly (I don't know how Calyx do it, but I know I do), only apps in firmware are allowed to use FAKE_SIGNATURE, and if you build your firmware with only microg that has FAKE_SIGNATURE, then only microg can fake signature. Also it can fake exactly one signature, which is Google's. It's probably possible to make that patch better, if some people gives us reasons it is a flaw.
Really, please tell me in which threat model does using microg hinders security, maybe we can find a fix. So far, I've never heard any.
> GrapheneOS offers sandboxed play services with the standard SELinux policies for unprivileged Android software.
With regards to privacy, I take unprotected opensource software over Google trackware no matter the sandboxes you put under it. Windows has a better sandboxing model than Linux, yet I feel much better doing random apt installs, than downloading random Windows apps.
Yes, I'm very exaggerating the comparison, but still. My point is that the comment I'm answering touts the sandboxed Google Play Services. You can't tout it *and* say it's privacy preserving, it's a XOR.
> you can't tout it *and say it's privacy preserving.
Why? Sandboxed Play Services has no special privileges on GrapheneOS and thus has the same level of access as any other app. How can it invade your privacy if you don't explicitly give it access to private information?
Going to simply interpret this as unhelpful sarcasm.
> My point is that the comment I'm answering touts the sandboxed Google Play Services.
Sandboxed Google Play isn't included in GrapheneOS. Users can choose to install apps which include Google's libraries and use the Google Play SDK. Regardless of whether people use sandboxed Google Play or microG, they're using the Google Play code inside each app using it. The whole point of sandboxed Google Play is that users can optionally choose to install Play services and the Play Store in the user/work profile(s) of their choice with it receiving ZERO additional access or privileges compared to the Google libraries / Play SDK within each app using it. GrapheneOS does not include Google Play and has no special sandbox for Google Play. It includes a compatibility layer for users to run it in the full, strictest API 32 app sandbox with all the standard GrapheneOS enhancements. It does not receive any special access or privileges. It can't do anything the Google libraries within apps can't already do themselves. The Sandboxed Google Play compatibility layer also includes the ability to redirect APIs like location services to the OS implementation. By default, location services are redirected to the OS implementation, so users don't need to give Location access to Play services. Of course, if users grant Location to apps using Google Play, they're trusting the app and all the included libraries, and any app using Google Play is using Google Play libraries.
You can see for yourself that the full featured Google Maps app completely works without Google Play, and that their Ads SDK and other libraries work without it. Their libraries can do everything that sandboxed Google Play can do on their own without it. That's the whole point. Google Play is not required to contact Google services. Apps can do that on their own, and Google's libraries within those apps are fully capable of doing it. They largely choose not to implement fallbacks for features, but in some cases they clearly do as you can see from Google Maps and the Ads SDK. Only apps using the Lite variant of the Ads SDK need Google Play services for it to work. And again, sandboxed Google Play is not included in GrapheneOS. CalyxOS includes microG as part of the OS and encourages using it through the setup wizard. That uses Google's proprietary services and code. The Play code in each app is not replaced. It has a bunch of serious privacy and security issues from not implementing all the expected security checks, in some cases because microG is ideologically against enforcing the security model for things like location services.
CalyxOS doesn't simply include microG with users encouraged to use it. They use Google services by default, with no way to turn them off. They significantly roll back the security model of the OS. They recently went almost 4 months without shipping the browser or Android security updates, including multiple vulnerabilities caught being exploited in the wild and announced as such in bulletins. How are users supposed to get privacy and security from an OS which lacks consistent security updates and has no problem rolling back or bypassing the standard OS privacy and security model? It isn't simply not a hardened OS. It's a dangerously insecure one.
I think it is helpful to convey the emotion that goes through me when I read such a remark.
> It includes a compatibility layer for users to run it in the full, strictest API 32 app sandbox with all the standard GrapheneOS enhancements.
How does it handle Doze? In original Android, no app is allowed to keep a TCP connection open forever. And without that, FCM is useless. Also I believe that having Google Play Services running permanently has an impact (more on that later in this comment)
> You can see for yourself that the full featured Google Maps app completely works without Google Play, and that their Ads SDK and other libraries work without it.
That's an interesting point, thanks, I'll probably spend some time exploring those things. That Google garden does such things doesn't really surprise me.
> Only apps using the Lite variant of the Ads SDK need Google Play services for it to work.
From the description of Lite Ads SDK, it sounds like something that every app developer should want, yet it looks like Google is down-publicizing it a lot, so noone actually use it, nice workaround from Google, thanks for the info.
I see you're focusing your whole speech on Ads SDK. Does it mean only the ads SDK has this behavior?
My personal use of microg is for apps I trust (mostly opensource, or where I'm a paying customer), which work (much) better with cloud messaging. (I have to admit, I trust those apps enough to know they don't have ads, but not enough to trust they don't have ads sdk). So I do believe that for my usecase, microg gives me a much better privacy than Play Services, because most apps won't contain the infinite list of trackers Google Play Services include. But if you have proofs of otherwise, please do enlighten me, you're more knowledgable than me on SDKs.
FWIW, I have one metric (a rather stupid one, I agree) which is IMO showing that there is a huge difference: the data transferred and the battery usage. I have an order of magnitude difference in data transferred, and I get at least 3 times more battery life in suspend. Which IMO definitely highlights the fact that Google Play Services running permanently has its own privacy impacts, even when giving them minimal permissions.
> CalyxOS doesn't simply include microG with users encouraged to use it. They use Google services by default, with no way to turn them off.
"Google services" are 100MB+ proprietary code, sending god knows what to Google. CalyxOS doesn't have 100MB+ proprietary code, with microg you exactly know which data is sent. And actually if I'm not mistaken, microg doesn't do google registration or cloud messaging by default, so I don't think it does any Google connection by default? I'm not exactly sure there. I'm sure cloud messaging is disabled by default though, so no permanent connection
> They recently went almost 4 months without shipping the browser or Android security updates, including multiple vulnerabilities caught being exploited in the wild and announced as such in bulletins.
Just like the biggest (or maybe second or third, I don't really track that) corporation in the world on their flagship, while they are 50000 times smaller? But anyway, you're right: again, I said that on security grounds, I'd always pick GrapheneOS, and that the relation between privacy and security is pretty complicated, and I understand that some privacy threat models requires stronger security than trust.
---------------- Edit: Removed this part which is no longer relevant.
> They significantly roll back the security model of the OS.
I'm guessing you're speaking of microg implementation when you say "roll back the security model". I'm curious why you didn't answer to the comment where I ask to point out precisely how that roll backs the security model.
Play Services requires its battery optimization to be set to unrestricted for FCM to work reliably. Other apps keeping a persistent background connection (e.g. Signal w/out Play Services) require the same thing, so this is not specific to Play Services
> FWIW, I have one metric (a rather stupid one, I agree)
Why do you bring it up then? The amount or frequency of data transfer has zero indication of negative privacy impact. What private data could possibly be sent since Play Services doesn't have any privileged access on GrapheneOS?
> "Google services" are 100MB+ proprietary code, sending god knows what to Google
See my above comment.
> I'm guessing you're speaking of microg implementation when you say "roll back the security model".
He has already stated how microG allows signature spoofing which directly directly breaks the Android security model. But CalyxOS breaks the security model further: it also includes the F-Droid and Aurora privileged extensions which give the corresponding apps special privileges to install apps without user interaction. The proper way to do this (without breaking the security model) is to use the Android 12 API for unprivileged, unattended updates.
> Just like the biggest (or maybe second or third, I don't really track that) corporation in the world on their flagship, while they are 50000 times smaller?
It's not okay to stop shipping security updates for 4 months just because someone else is doing it. GrapheneOS shipped those updates with a team of only 5 developers. If CalyxOS cared at all about security and privacy, they would at a bare minimum meet the latest Android patch level and not break the Android security model.
CalyxOS is substantially less private than GrapheneOS, not just less secure. You seem to be claiming this entirely based on CalyxOS including microG rather than the sandboxed Google Play compatibility layer. Sandboxed Google Play is not part of GrapheneOS. It doesn't ship with it, and unlike on CalyxOS, there isn't a setup wizard page encouraging you to use Google services. CalyxOS uses Google services even without microG and you can't turn it off. Your claims really don't make sense. Sandboxed Google Play compatibility layer is an optional feature users can choose to use, and it uses exactly the same sandbox used for the apps themselves including the apps people want to use with it. Those apps include Google's libraries including the Play SDK. You're relying on exactly the same sandbox for the client-side part of Play services as Play services has containing it. That's actually not entirely the full story since Play services is API 32 and always has the best available sandbox, while many apps have a lower API level and get a somewhat weaken sandbox, like API < 28 not having a per-app instance of the untrusted_app domain.
GrapheneOS has a bunch of added privacy features, not simply security features. This page is a list of features added on top of AOSP 12.1: https://grapheneos.org/features. It does not list features implemented by GrapheneOS upstream that are present in AOSP 12.1 since those are no longer features differentiating it.
Privacy depends on security, and CalyxOS recently went 4 months without shipping the Chromium and Android security updates. How is that supposed to be private? They also covered up how bad it was and wouldn't admit to how much was missing. They've consistently done that. They've covered up security vulnerabilities in their code. They denied there were leaks in their "firewall" app toggles and are still pretending as if there aren't leaks even though those were explained to them in the past and they're well aware their approach doesn't work properly.
> If we're speaking of FAKE_SIGNATURE.... No it doesn't? If implemented properly (I don't know how Calyx do it, but I know I do), only apps in firmware are allowed to use FAKE_SIGNATURE, and if you build your firmware with only microg that has FAKE_SIGNATURE, then only microg can fake signature. Also it can fake exactly one signature, which is Google's. It's probably possible to make that patch better, if some people gives us reasons it is a flaw.
Except that microG is missing security checks and the full security model, and by doing this you're directly bypassing a security check.
> Really, please tell me in which threat model does using microg hinders security, maybe we can find a fix. So far, I've never heard any.
Projects spreading libel about security researchers lose the privilege of getting vulnerabilities reported to them and patches made for them. microG has a bunch of blatantly missing security checks and based on what you're saying it should be no problem for others to find and fix those. Also, how are you going to add all kinds of cross-app signature checks, pinning and parts of the missing security model to an app ideologically opposed to some of these things?
> With regards to privacy, I take unprotected opensource software over Google trackware no matter the sandboxes you put under it. Windows has a better sandboxing model than Linux, yet I feel much better doing random apt installs, than downloading random Windows apps.
microG still uses proprietary Google services and the proprietary Google libraries are still included and being used by every app using it. People can see for themselves that Google Maps entirely works without Play services other than compass calibration, and that the Ads SDK works fine without Play services. microG is open source middleware sitting between closed source libraries and services. CalyxOS includes the privileged Google eSIM apps by default which give Google your IMEI, with no warning about that.
GrapheneOS does not use Google services by default. CalyxOS uses Google services by default with no off switch even without microG and has privileged Google services in the OS.
We've always heavily restricted as well.
https://calyxos.org/docs/tech/microg-details/
> Really, please tell me in which threat model does using microg hinders security, maybe we can find a fix. So far, I've never heard any.
I keep asking the same to anyone bringing this up. We'd be happy to even submit patches to microG for any issues found and reported.
For the binary blobs, but for the opensource components all supported builds are current on monthly android security patches. (well, in review for probably a few days on April: https://review.lineageos.org/q/topic:R_asb_2022-04 )
LineageOS maintainers also pull android servicing branch back to cm14.1 tree too if you wanted to try your hand at building on a previously supported device.
Unfortunately as you can see from these posts, there's a lot of in-fighting between developers and users, it's detrimental to everyone involved and drives away users, supporters, and other developers who would contribute but don't want to get involved in it.
Regardless of all the garbage surrounding these projects, the technical work behind GrapheneOS speaks for itself and is how I ended up selecting it vs the other options.