Developers have to go out of their way to implement triggering Play Integrity API checks in their app and then retrieve the results to check on their services. They're putting a lot of effort into banning anything not licensing Google Mobile Services. It's definitely not a security feature since it permits devices with no security updates for more than 8 years but not a far more secure OS than anything Google certifies. Google doesn't allow GrapheneOS to obtain certification and certification comes with highly anti-competitive rules which would be completely unacceptable. Their licensing system has been ruled illegal in South Korea and other countries should not only do the same but ban the Play Integrity API and other related anti-competitive features. These are not actual security features and that's an excuse for the actual purpose of enforcing their GMS licensing model including forcing including a bunch of Google apps with extremely privileged access and using their builds of many OS components shipped from the Play Store.
They don't need to do anything to support GrapheneOS. They only need to stop actively going out of the way to block it and any other alternative OS via the Play Integrity API. They put significant effort into blocking anything other than iOS or a Google Mobile Services Android stock OS certified by Google. They're not only blocking a non-stock AOSP-based operating system but rather anything other than iOS or a Google Mobile Services Android device certified by Google.
Fairphones are far from meeting the security requirements to run GrapheneOS and have chosen an incompatible path. It won't be available for their devices.
/e/ has drastically worse privacy and security from the Android Open Source Project or especially and iPhone. It's not a step up from standard AOSP. It lags many months behind on many High/Critical severity patches, years behind on overall patches and rolls back the privacy/security in a bunch of ways. It includes many invasive services.
It has many default enabled highly privileged Google services including downloading Google Play executables such as droidguard and running those with similar privileged access as they have on a Google Mobile Services OS anyway.
/e/ is the direct opposite of a privacy or security focused OS. It doesn't provide bare minimum standard privacy and security patches while setting an inaccurate Android security patch level. It lags many months behind on patches even on devices where they're the least behind. It's typically years behind on kernel, driver, firmware and major OS updates. It doesn't keep the standard privacy and security protections intact and lagging behind on OS updates means not having the current ones. It sends user data to OpenAI and other third parties without consent.
/e/ and Murena have repeatedly claimed providing strong privacy and security mainly benefits criminals and claim devices doing it are mainly used by criminals. Here's one example of many:
An iPhone is a hardened device with drastically better privacy and security than an /e/ device. It would fall under the claims from /e/ and Murena about hardened devices.
Fairphone doesn't design or make their smartphones. The devices are designed and made by a large ODM. It's entirely feasible to use a modern SoC with current generation security features and provide proper updates. Their ODM isn't doing it to cut costs.
Fairphone quickly stops providing Linux kernel updates and has months of delay for Android userspace backports along with driver/firmware backports. The delay for yearly updates typically starts at a year and gets longer as devices get older and they've always skipped the quarterly updates.
Using a modern SoC, properly configuring it, using proper signing keys (Fairphone has repeatedly used publicly available sample private keys) and providing proper updates is most of what's needed to meet the requirements. That's entirely doable by the few OEMs designing their devices in-house such as Motorola Mobility. Samsung and Google along with many of the ODMs making devices for Nothing, Fairphone, etc.
GrapheneOS is a privacy project highly focused on usability and compatibility. Privacy depends on security so it has to put a lot of work into security too and it has always been a major focus, but it's a misconception that it's all about security.
> This means they strongly advice against using other software many in their core audience are predisposed to like: Firefox, Signal, plugins for browsers, F-Droid, ect.
GrapheneOS doesn't recommend against Signal but rather it's the main recommendation for end-to-end encrypted chat from the project including via the Molly fork of Signal.
> The explanations are usually quite... blunt, and they're not exactly open for discussion (which makes sense, from a pure security perspective, those apps are indefensible).
This isn't true. GrapheneOS provides nuanced information with detailed explanations for these topics.
For security reasons, GrapheneOS uses ahead-of-time compilation for apps. The stock OS compiles the heavily used parts of the code dynamically in-memory and then does partial ahead-of-time compilation later in the background. The install-time compilation will become more asynchronous in the future so the app can be used right away.
There have been consistent problems with activating RCS, for many years. But it does work for some/many, yes.
And AFAIK they have only been desiring to build their own RCS app, and researching it, but have no concrete plans. It'll probably be extremely hard to do, given how much interaction it requires with individual telecoms, and how large the specs are and how much they change - it'll be signing up for significant dedicated eng/business/etc effort that will never decrease. Though I would very much like it if it does happen.
Personally: it worked for about a year for me, then stopped for several months, then worked for two, then I disabled it. All on the same phone, same OS install, same carrier and phone plan, and same location. No issues at all on stock Android with everything else identical which my wife uses. You can find tons of cases like this with Graphene users, RCS just doesn't work/activate/??? as well for some reason.
It's always good to be wrong about good news, then :)
I'll definitely be curious about the source code when that happens, and if it'd be reasonable to get it into a SMS-provider-like shape eventually. Particularly since Android's original PoC did that, but it was abandoned for some reason.
reply