GrapheneOS is well into the migration to Android 12. Many unexpected issues have cropped up and progress is going much slower than anticipated.
It's a better time than ever to start working on the project since so much work needs to be done over the next few weeks in many areas.
Starting with making a development build of Android 12 GrapheneOS for the emulator via grapheneos.org/build is the best way to start. Most of the work can be done in the emulator.
Since there aren't official releases of Android 12 yet, building for devices has extra steps.
Temporary instructions on using android-prepare-vendor with the Android 12 Beta 5 releases has been added to grapheneos.org/build#extracti…. Our recommendation is to start with the emulator target. We also haven't yet finished initial device support for all of the supported devices yet.
Device support still needs to be completed and many of the significant features still need to be ported to Android 12.
Certain features such as using full ahead-of-time compilation to fully replace the Android Runtime JIT and exec-based spawning have proven difficult to port.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
GrapheneOS developers/moderators are being impersonated across different platforms (Matrix, Telegram, Reddit) as part of the attacks on the project.
They're copying our display names, avatars and usernames. Make sure to confirm it's one of our accounts and not someone malicious.
This is one of the tactics being used to cause harm to GrapheneOS. See github.com/bromite/bromit… for a particularly damaging past incident where they impersonated Bromite's developer.
Happening more frequently now and multiple developers/moderators are being targeted this way.
People have fallen for this trick repeatedly and a lot of harm has been caused with it. It's not going to keep working for them when they're doing it so frequently.
It's unfortunate CalyxOS/Techlore have encouraged their communities to engage in these relentless attacks on us...
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.
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.
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.
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.
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.
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.