My colleague @Final wrote the following on X: >We threat modelled that this feature could be a notable target for exploits to prevent reboots & keeping data safe when introduced in GrapheneOS. Compared to iOS, you can configure a shorter reboot time & USB-C port hardware controls prevent USB as a mode of exploit delivery. > In my adversarial opinion, blocking auto-reboot matters more than an AFU Locked extraction capability. Extraction only opens up phones seized around/after the capability exists, while the automatic reboot blocker keeps phones seized in the past more exploitable. > Magnet Forensics, the company in the article, have already discussed about the impacts the addition of automatic reboots across flagship smartphones in mobile forensics including this recent webinar. We even get a mention. https://t.co/2wAtfq3qnb > Protecting GrapheneOS against malicious use of forensic tools / 0days for unauthorised access is two parts: preventing known tools from working, and designing the OS that the window of exploitability if a capability ever emerged is as short as possible. Nothing is unhackable. > There will always be an eventual risk of an exploit day where stolen devices will be peeled open from being vulnerable after several years with no updates. This is why you use a strong entropy alphanumeric password to resist any capability of brute forcing the credentials in BFU. View quoted note →

If you have just or are planning on joining the global family of GrapheneOS users, you are doing so at a time of accelerated progress and change on a UI/UX basis. Great to have you along for the journey. #ThingsAreHappening #GrapheneOS View quoted note →

GrapheneOS Zapraiser Challenge I remember Nostr being that vibrant a Zapraiser like this wouldn't pose a problem. Your challenge if you choose to accept it is to max the Zapraiser for which I also commit to matching the donation from my own funds. On making rhe target I will send on chain to the project and provide the proofs. Good luck Nostr! View quoted note →

What is that? Another pioneering privacy feature in your class leading privacy and security focused OS? You CTRL-Clipboard. View quoted note →

Current state of play regards our continued research into possible support for 11th Gen Pixels and the MTE situation: View quoted note →

GrapheneOS continues to reveal Googles active hobbling of the ability of OEMs to protect their users in favour of market exclusivity/protection, and pushing ahead with monopolistic anti competitive abuse hand in glove with GPL violations. Read below the break for the teams detailed analysis: > Android 17 QPR1 is the first release since Android Honeycomb (3.x) adding new APIs for app developers without a release to the Android Open Source Project. The new APIs are currently exclusive to the Pixel OS and aren't available to other Android OEMs. >

API Differences between 37 and 37.1

JDiff is a Javadoc doclet which generates an HTML report of all the packages, classes, constructors, methods, and fields which have been removed, a...

> Non-Google Android OEMs and AOSP-based projects can ship yearly and QPR2 releases. There are also security backports to those releases. Security preview access is needed to ship patches without months of delay. We've had that since before our Motorola partnership via another OEM. > We already ported our code to Android 17 QPR1 since before it was released on September 15th but don't have permission to release it yet. We're working on backporting Pixel firmware, kernel drivers, userspace drivers and HALs from Android 17 QPR1 to Android 17 for now instead. > Pixel Update Bulletin for September 2026 has additional patches to standard Android platform components used by non-Pixel devices. These patches are relevant to non-Pixel devices but haven't been made available via the September 2026 Android Security Bulletin or preview patches. > Google should not be gatekeeping security patches to the standard Android platform code from Android OEMs but that's what they've started doing. Other OEMs will get these patches in December 2026 via Android 17 QPR2. We can ship them early by reverse engineering the code instead. > It would be interesting to know if Google's legal team is aware they're giving Pixels months of early access to new Android features and bug fixes including certain important security patches. Pixels being given this competitive edge over Google's OEM partners is very dubious. > Google is also once again failing to comply with our GPL source requests for weeks. We requested CD1A.260905.001.A1 sources on September 1st and were only provided access today. The kernel build IDs are the same for 17 QPR1 Beta 9 and 17 QPR1 so we have that already at least. > We could have shipped an Android 17 QPR1 update already since our port was completed. Instead, we have to deal with ongoing pain until Android 17 QPR2 is released in December 2026. This will not be an issue for Motorola since we'll have official firmware and driver code provided. > Pixels are now significantly harder to support than many other devices. One of the only advantages of Pixels is now a disadvantage instead. They're still the best fit for us due to the updates and security features but it burns time we want to spend on privacy and security work. > It will be far easier for us to support upcoming Motorola devices than Pixels. Qualcomm will hopefully expand MTE support beyond the highest end flagship SoC soon so we can expand to more than flagships. Pixel 11 didn't remove it from hardware, only firmware, so that's good news.

The absolute hysterics over on the Fediverse...

GM Nostr-nam

As Freeborns OH has the issue some others may have noticed it too. The official project response follows: Google and carriers deployed changes to RCS which have been breaking it for many users on the stock OS including with certain carriers and in whole countries. The changes appear to have specifically impacted GrapheneOS users too. It's not related to our September 8th update. We're working on it. You can find many recent threads about people having issues with RCS in Google Messages while using a stock OS with Google Mobile Services. There are articles about how some carriers and countries no longer have it. It still works for most people but the changes definitely regressed compatibility. GrapheneOS users were impacted by these recent changes much more than other users. We don't know why yet but we're working on determining that and restoring compatibility with Google Messages for people who use it. We'll try to get compatibility with the new way it functions implemented very soon. View quoted note →

April release of the Pixel boot chain firmware includes fixes for 2 vulnerabilities reported by GrapheneOS which are being actively exploited in the wild by forensic companies:

Android Open Source Project

Pixel Update Bulletin—April 2024 | Security | Android Open Source Project

Android Open Source Project

Android security acknowledgements | Security | Android Open Source Project

These are assigned CVE-2024-29745 and CVE-2024-29748. source.android.com Android Security Acknowledgements | Android Open Source Project CVE-2024-29745 refers to a vulnerability in the fastboot firmware used to support unlocking/flashing/locking. Forensic companies are rebooting devices in After First Unlock state into fastboot mode on Pixels and other devices to exploit vulnerabilities there and then dump memory. We proposed zeroing memory in firmware when rebooting to fastboot mode to wipe out the whole class of attacks. They implemented this by zeroing memory when booting fastboot mode. USB is only enabled by fastboot mode after zeroing the memory is completed, blocking these attacks. GrapheneOS already implemented defenses against this attack before we became aware of it. After becoming aware of this attack against Pixels running the stock OS, we improved our existing defenses and added new ones alongside reporting the firmware weaknesses to get those fixed. CVE-2024-29748 refers to a vulnerability providing the ability to interrupt a factory reset triggered by a device admin app. It appears they've implemented a partial solution in firmware. See

X (formerly Twitter)

GrapheneOS (@GrapheneOS) on X

Google is publicly working on a fix for the factory reset vulnerability we reported: https://t.co/WaNX85FAUr Currently, apps using device admin A...

about ongoing work we spotted on wipe-without-reboot support. Google is publicly working on a fix for the factory reset vulnerability we reported: https://android-review.googlesource.com/c/platform/frameworks/base/+/3008138 Currently, apps using device admin API to wipe do not provide any security against a local attacker since you can interrupt them. Forensic companies are aware of this. Show more GrapheneOS has been working on a duress PIN/password feature for a while, and as part of that we already implemented our own wipe-without-reboot system. We care a lot about doing things properly and the way this was done in existing apps and operating systems was highly insecure.

When you level up your coffee game and the homebrew matches, note for note, the experience from the roastery. ☕💯😋 #DialedIn

GrapheneOS Current Android QPR2 Bluetooth Compatibility statement: Due to mainline modules, the Stock Pixel OS is currently using a much older release of the Bluetooth module than the current release in the Android Open Source Project without current security patches. We believe this is the reason for remaining issues not occurring for stock. The remaining compatibility issues with a small number of devices such as the past couple generations of Galaxy Watch hardware appear to be the consequence of the March security patches and other changes in QPR2. There's a solid chance the Bluetooth devices are what's buggy. GrapheneOS is on Bluetooth module version 990090000 from the Android 14 QPR2 release. Stock Pixel OS is still using 341313030, without tags available for that. Needs to be addressed even if simply by tagging the older Bluetooth module release being separately built/shipped.