microG does NOT provide an open source implementation of Play services. Apps using Play services integrate the closed source Google libraries which are fully capable of contacting Google services regardless of whether Play services is present, and also do so in practice too.
The implementation of the services is also still closed source. It's only an open source middleman and the Google libraries are perfectly capable of communicating with the Google services without it. It doesn't provide better privacy or security and doesn't make Play open source.
It's not as secure as the official Play services implementation and doesn't provide comparable privacy for user data. It leaks user data across apps, doesn't properly enforce the API security model and doesn't provide comparable transport security via pinning and other measures.
It has always been possible to install microG on GrapheneOS. However, we have never been willing to make the security sacrifices necessary for it to work properly. It requires bypassing security checks in apps for the official Play services signatures without having parity.
We of course also weren't willing to integrate Play services into the OS even as an optional feature. The standard integration requires massively invasive access and privileges in the OS. It expects extensive access to internal privileged APIs and special SELinux MAC/MLS policy.
Play services is extremely problematic because it can do far more than other apps and services. It doesn't play on a level playing field. Modern Android has a great application sandbox and strong privacy and security. Play services expects to be built into the OS, bypassing that.
Sacrifices required to integrate either microG and Play services are both completely unacceptable. microG is also hardly a real alternative. It implements a tiny subset of the APIs. It's missing most of the functionality. It can't provide the broad app compatibility we needed.
GrapheneOS was founded in 2014. We've also wanted broad app compatibility. There was never previously a way for us to do that meeting our requirements.

Funding development of grapheneos.org/usage#sandboxe… has provided what we needed: a no compromises approach to Play compatibility.
Installing Play services on GrapheneOS was always possible but as a fully sandboxed app with no special access or privileges, it couldn't work at all. It would simply crash repeatedly as it tried to use the massive amount of privileged functionality that it expects from the OS.
It took us years to realize that there was a highly maintainable approach without privacy and security sacrifices: teaching Play services to work as it should have functioned in the first place. Fully sandboxed without special access/privileges like every other library/service.
Installing Play services on GrapheneOS within the user or work profile(s) of your choice provides broad compatibility with apps in those profiles using Google's libraries. It provides ZERO additional access or privileges to the Play services code in each of the apps using it.
You don't have to grant any permissions or other access to Play services in order to have broad app compatibility. You don't have to sign into a Google account, but you can do that if you want and you can use a throwaway account just like Aurora Store does for you automatically.
Our approach isn't a compromise. GrapheneOS doesn't include Play services. It doesn't offer any special access or privileges to Play services if users install apps depending on it or the Play services apps themselves. It works like any other app or service. Same rules and limits.
Implementation already provides most Play services functionality. Went from a concept to highly functional in 2 months. This is the total code size across the 3 repositories with changes:

47 files changed, 1556 insertions(+), 11 deletions(-)

Highly auditable and maintainable.
It took us 7 years of putting substantial thought into this to settle on the right approach. It's understandable that stakeholder in legacy alternatives don't see it our way yet. It's unfortunate that they've chosen to spread misinformation about our approach to this though.
We're more than happy to explain the extreme flaws with every other approach that we've considered, and why this makes the most technical sense.

If microG had any serious potential of broad app compatibility, maintainability and security we would have integrated it YEARS ago...
Bundling an existing solution is the easy path. It'd literally take 5 minutes to integrate microG.

GrapheneOS is not about taking the easy path but a proper approach able to provide our users with a high level of usability, privacy and security. Shortcuts aren't our thing.
Same reason we don't integrate F-Droid but rather are making a new app repository system able to meet the usability, privacy and security requirements needed for GrapheneOS over the long term.

We're investing in making great tech, not marketing/branding.
It's the same reason we made hardened_malloc rather than sticking to bolting on far weaker mitigations to existing malloc designs.

Often means taking longer to get there, but we eventually do. Web installer is a nice example. Is there an easier OS to install than GrapheneOS now?
Our community sees the value in our approach and GrapheneOS has a quickly growing full-time development team funded entirely by donations. No business model and no reason for one. It's not funded by grants either. Bureaucrats have never seen the value of work. We don't need them.

• • •

Missing some Tweet in this thread? You can try to force a refresh

Keep Current with GrapheneOS

GrapheneOS Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!


Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @GrapheneOS

11 Sep
Auditor (attestation.app/about) uses very dense QR codes for response from the Auditee device to the challenge from the Auditor device. It relies on specialized certificate chain compression with a pre-shared DEFLATE dictionary for the attestation to fit into a QR code at all.
In order to improve security of chaining trust from hardware attestation to the app, Auditor uses the very niche android:useEmbeddedDex="true" feature to disable on-device ahead-of-time compilation for the app's Kotlin/Java code. It makes the QR scanning harder on GrapheneOS.
Android uses a mix of on-device ahead-of-time (AOT) compilation and just-in-time (JIT) compilation for Java/Kotlin.

GrapheneOS disables JIT to improve security. It compensates by using full AOT compilation which results in better overall Java/Kotlin performance and battery life.
Read 5 tweets
8 Aug
GrapheneOS is just as focused on improving privacy as security. A few of the many added features:

* Sensors permission toggle
* Network permission toggle
* Wi-Fi anonymity (per-connection MAC randomization, anonymous DHCP, anonymous IPv6)

See grapheneos.org/features for more.
App sandbox on GrapheneOS also leaks significantly less data to apps. Most of our privacy improvements are under the hood and don't require user-facing interfaces.

Our improvements requiring configuration are natively integrated into the Settings app and match the standard UI.
Sensors/Network toggles are part of the standard permission UI.

Sensors toggle disables access to all sensors not covered by existing permissions and returns zeroed data.

Network toggle fully disables both direct network access and indirect via APIs requiring the permission.
Read 7 tweets
18 Jul
@GrassFedBitcoin @CalyxOS GrapheneOS is heavily focused on security enhancements making exploitation significantly harder:


Those other operating systems don't improve resistance against exploitation and won't provide more resistance against an exploit working against AOSP/stock.
@GrassFedBitcoin @CalyxOS The vast majority of remote code execution exploits are based on memory corruption bugs. Defending against those is a major focus of GrapheneOS. A lot of the bugs won't be exploitable beyond denial of service. In most cases, the exploits will need substantial changes at minimum.
@GrassFedBitcoin @CalyxOS If they specifically target GrapheneOS and put work into adjusting their exploit chains and finding new bugs as necessary, then they could certainly develop an exploit working against GrapheneOS. Costs will be higher and they'll usually need to specifically take it into account.
Read 7 tweets
18 Jul
GrapheneOS 2021.07.16.19 release: grapheneos.org/releases#2021.….

See the linked release notes for an overview of the changes since the previous release.
This release adds an experimental version of the highly anticipated feature for running Play services and friends as sandboxed apps without any special privileges.

Details are at grapheneos.org/usage#sandboxe….

Secondary user support and dynamite module compatibility is coming soon.
Once dynamite module compatibility is implemented, nearly all the APIs will be working. This doesn't work yet because it has no special SELinux MAC/MLS policy due to being in the normal app sandbox. We need to add shims on both ends sending the modules via standard file sharing.
Read 4 tweets
1 Jul
Play services compatibility layer in active development and an early prototype has the basics working.

It will allow users to install Play services as a regular app in specific profiles without granting it any special privileges. Most functionality can work with this approach.
Play services won't be bundled with the OS. It will be up to users to choose to install Play services in a profile.

It won't be part of the upcoming July security update release but there will likely be an initial experimental implementation ready for testing by the end of July.
This approach will be drastically more maintainable than attempting to reimplement the APIs. It will be much easier to port to new major OS versions and will provide much more of the functionality. It will also have all the usual security checks and component/server key pinning.
Read 5 tweets
20 Jun
Next release of GrapheneOS will finally have a fix for IPv6 privacy addresses to prevent them being used to track users not only across connections to the same network but across networks.

Future devices won't have this particular kind of issue anymore due to upstream fixes.
All of the blatant issues with Wi-Fi anonymity should be resolved now. Hardware/firmware on the supported devices has done things properly for a while but there were higher-level anonymity issues. Of course, it would be a good idea to go over everything from the bottom up again.
It won't be possible to provide the same kind of Wi-Fi anonymity on other hardware unless it goes out of the way to minimize leaked information and randomize sequence numbers, etc. in the same way.

Should be possible to properly do this on most modern Snapdragon devices though.
Read 4 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!

Follow Us on Twitter!