We've purchased grapheneos.social and it we'll be hosting an official Mastodon instance for our project accounts there in the near future.
If you follow @grapheneos@infosec.exchange right now, you'll be automatically moved over to following the new account on our instance.
fedifinder.glitch.me will scan the profiles of the people you follow on Twitter to find them on the fediverse (Mastodon). It helps you choose an instance and gives you a list of their handles to import into your new account so you can keep a lot of the people you follow there.
We'll still be posting the same content on Twitter, but not everyone will be doing that. Most of the people in the infosec community worth following have moved to the fediverse, largely to infosec.exchange, and there's much more activity/discussion in the community there.
We also have chat rooms on Matrix with our own grapheneos.org server for our services / project accounts.
Mastodon and Matrix are federated like email. You choose a provider and interact with people across providers. Can switch providers if you don't like moderation decisions, etc.
For longer-form community discussions, we have our own discussion forum at discuss.grapheneos.org.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
Google publishes the source code for their TalkBack screen reader. GrapheneOS maintains a fork of it and includes it in GrapheneOS with the help of a blind GrapheneOS user who works on their own more elaborate fork. Eventually, we'd like to include more or all of their changes.
TalkBack depends on a text-to-speech (TTS) implementation installed/configured/activated. It needs to have Direct Boot support to function before the first unlock of a profile. Google's TTS implementation supports this and can be used on GrapheneOS, but it's not open source.
We requested Direct Boot support from both prominent open source implementations:
This can't cause compatibility issues for apps from the Play Store, but there are more issues than expected with the app ecosystem outside the Play Store. Main issue is with an F-Droid repository redistributing developer builds that's not shipping 64-bit.
Android's modern app distribution mechanism system is based around split apks generated from an app bundle (aab). Code/resources specific to architectures, locales or display sizes can be split out. App repository client has to install the base apk and the required splits for it.
Split APKs can also be used for dynamic feature and asset delivery to only download portions of an app once they're needed. Play Store implementation unnecessarily tied this to Play Signing where they generate apks from the app bundle but it works fine outside the Play Store too.
We've discovered a bug on Pixel 7 and Pixel 7 Pro with hardware attestation support via the Titan M2 as part of adding Auditor support. Hardware attestation throws an error after an OS upgrade, likely due to incorrect handling of version binding updates for remote provisioning.
We've reported this issue upstream and worked around in version 62 of our Auditor app:
We previously found a similar issue with the app-generated attest key feature introduced in Android 12 and initially shipped by the Pixel 6, Pixel 6 Pro and Pixel 6a.
The previous issue we discovered was caused by a bug in the keymint (keymaster) HAL. It was fixed upstream based on our report and they gave us the updated HAL to verify the fix works. We expect it to ship in the 1st quarterly release (QPR1 aka Pixel feature drop) of Android 13.
Pixel 7 and Pixel 7 Pro have fully dropped support for 32-bit apps. We expected 7th generation Pixels to be ARMv9 devices without 32-bit app support but they dropped 32-bit app support despite remaining on ARMv8.2. Shift to ARMv9 has been pushed to next year for unknown reasons.
Play Store stopped supporting publishing apps without 64-bit support on 2019-08-01 for both new apps and app updates. It stopped serving apps without 64-bit support to 64-bit capable devices on 2021-08-01. We expect there would be little impact from dropping it from GrapheneOS.
As a small step towards dropping 32-bit app support from GrapheneOS, we're going to be moving to 64-bit only builds for Vanadium. This will substantially reduce the Vanadium build time and the size of the releases which is a substantial portion of the overall size of GrapheneOS.
We avoid bundling third party apps and services since they're never fully aligned with our approach and goals.
Once an app is included, it's difficult to remove for existing devices since users depend on it. This would result in apps being included past their best before date.
Many people wanted us to bundle Signal with GrapheneOS as the default SMS/MMS app. Signal is now dropping support for SMS/MMS. They also don't care much about keeping their dependencies patched, reducing attack surface or internal sandboxing. It would be an issue for GrapheneOS.
They've made many decisions we disagree with including replacing registration lock PIN with a sync PIN depending on SGX for security, using SGX as a replacement for the previous private contact discovery and making the secure local backup system in the Android app less useful.
Connectivity checks are one of the 4 Google services used by AOSP. We replace these 4 services with GrapheneOS services by default with toggles to disable them or use the standard Google servers. Connectivity checks are low level and are run on each network to check if it works.
Connectivity checks are a special case since they still need to detect whether each underlying network has internet access when you're using a VPN.
If you're using a VPN and want to hide that you use GrapheneOS, you should switch connectivity check toggle to Standard (Google).
We also provide a 3rd 'Disabled' option for connectivity checks. This loses support for automatically switching to a working network, handling captive portals from the OS and delaying internet-dependent scheduled jobs until the network has internet connectivity. It's your choice.