Uptime monitoring dashboard for the production GrapheneOS services is available at nodeping.com/reports/status…. Alerts are also posted publicly in our #infra:grapheneos.org Matrix room when a check is added, starts failing or stops failing. It's often not really an outage.
For example, today, the TLS checks for attestation.app detected the certificate would expire in less than 15 days. This ended up being because the removal of a legacy subdomain several weeks ago broke automatic certbot removal. It can do much more advanced checks though.
At the moment, we either set the checks to use a specific location for more useful latency monitoring or we set them to roam worldwide. Here's an example of a worldwide check:
It's also a supplemental way of testing GeoDNS for the services we use it.
Since we primarily use OVH for our services, we make sure we're using non-OVH-based check locations for the non-roam checks. This is also part of why using an external service makes more sense than self-hosting and we don't send alerts to our own mail server for the same reason.
• • •
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:
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.
There are several dozen companies selling phones with GrapheneOS or forks of it. Many of these companies falsely claim to be partnered with us or working with us which isn't true. Most of these companies don't contribute back to GrapheneOS and try to get free support from us.
It's easy to install GrapheneOS with grapheneos.org/install/web and we don't expect to have a revenue stream from selling phones not specifically made to run GrapheneOS. Still, it's quite problematic for companies to claim they are supporting us when they aren't actually doing it.
An exception to the rule is @xiphcyber. They've been making donations to GrapheneOS based on a portion of each phone they sell for years.
Some of the companies building on our work are upset that we've made it easier to install GrapheneOS and gradually obsoleted their changes.
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.