Proud to say my 'Never Went to Black Hat' award is looking very shiny right now.

We have tested running desktop Linux GUI apps before including LibreOffice. It can certainly be a thing in the future.

It's a hardened Signal fork with passphrase encryption for the message database, better notifications on devices without Google Play and support for pairing your messages to multiple devices. If you use Signal I strongly recommend it. It's available in Accrescent so there is a root of trust between GrapheneOS -> Accrescent -> Molly.

As our original announcement mentioned it is English first. We do plan to support other languages and also internationalisation of GrapheneOS in the future.

also worth mentioning FBE is a big plus compared to Full Disk Encryption (FDE) which was the legacy Android encryption and the encryption desktop OSes like Windows and Linux use. If you have the keys to decrypt the disk then it would be possible to decrypt the unallocated space in FDE since it's all one key, so you'd be relying on TRIM if you are using an SSD to prevent recovery of deleted data.

The video is very old and most Android devices didn't use disk encryption by default, so a physical extraction (image of the entire flash storage) could allow recovering deleted files from carving unallocated space. Nowadays Android uses a "file-based encryption" (FBE) where all data is encrypted with separate derived keys for each file, directory and symbolic link. Deleting the file loses the keys and recovery is impossible. If you can recover data that is deleted from an app, it means the app is caching it when it shouldn't be and it's a flaw they would need to fix. I don't recall this being an issue with Signal but if you can extract the app data before the message database is rebuilt for deleted messages then you'd be in luck. You could kill an app and prevent it cleaning up it's DB. This is something you can apply to every messenger though. Getting this data requires as much as a full filesystem extraction (FFS) to extract the application /data directory where the message databases are. Cellebrite has no extraction support for GrapheneOS according to themselves. No specification on what the most they can extract from an unlocked device is, but assume that all forensic tools get this data anyway. Molly lets you encrypt the message database with a passphrase, so it wouldn't be accessible regardless of if there was a FFS extraction and a flaw in Signal keeping the messages.

This no longer being a developer option or beta will be massive.

It is a well known brand you absolutely will have heard of. The device we will support GrapheneOS will be distributed in many countries.

As our fully local text to speech engine is deployed in GrapheneOS soon, this will be the first of hopefully many major usability advancements in GrapheneOS for the year and next. With the OEM partnership developing and later generation flagship hardware providing more of what GrapheneOS needs for features, improving usability and accessibility will help for the influx of new users we will hope to welcome. It is a good time to remind you that GrapheneOS is hiring remote developers. We have been for a while: https://grapheneos.org/hiring

This is a tablet PC with Cellebrite UFED, a mobile forensics acquisition software. Users plug a target device into it where it then will attempt to extract as much data on the device as possible. The software on the laptop is Physical Analyser which is for forensic analysis. This video is dated, and Cellebrite UFED's UI, logo and capabilities have changed a lot since the video was released. This tool is also not exclusive to UK law enforcement and there are also competitor solutions, which many countries around the world use plus the competitors. Cellebrite sell a variant of this product named Cellebrite Premium. The difference to standard UFED and Premium is that Premium comes with wider device extraction support through zero-day exploits. As described it also allows extraction of vulnerable devices that are locked. This business model is not exclusive. XRY Pro (MSAB) and GrayKey (Magnet Forensics) are other exclusive forensic tools. Cellebrite are the second-oldest of the three companies (on joining the forensics market) but are one of the most capable thanks to their funding and location. How and if these tools are able to extract your device's data depends on: - The device you are using - The installed OS and version - The lock state of the device - Configured security settings of the device - Strength of your phone's unlock credential For a locked device exploiting security vulnerabilities is required to extract data almost all of the time. There are two different device lock states on Android and iOS: After first unlock (AFU, Hot) and before first unlock (BFU, Cold). This is due to how encryption works. Modern Android and iOS encrypt all users' data by default with keys derived from the user's credentials. When a device is unlocked once, data is no longer encrypted at rest and is accessible during that boot session. When a device is BFU, all sensitive data is at rest. Data not being at rest provides more OS attack surface to exploit bypassing lock screens or other measures and access to the data without needing the original PIN/password to decrypt it. For BFU devices brute forcing is required to decrypt data first and the only data not encrypted is a minimal footprint of the OS used for unlocking the device and global OS configuration and metadata. To make extraction impossible make sure your device is powered off and you use a secure, high-entropy passphrase before seizure. GrapheneOS provides a configurable, automatic inactivity reboot feature. We also provide several other countermeasures to these tools as well. GrapheneOS locked devices as a whole is unsupported by Cellebrite. If you are an opposition activist in a high-risk country you should be concerned about potential attacks from such tools. They have been abused to target activists in numerous countries like Serbia and Jordan. https://citizenlab.ca/research/from-protest-to-peril-cellebrite-used-against-jordanian-civil-society/ https://www.amnesty.org/en/latest/news/2024/12/serbia-authorities-using-spyware-and-cellebrite-forensic-extraction-tools-to-hack-journalists-and-activists/ Despite if a business claims this use of their product like this is unauthorised, it doesn't change the fact that they will be used like this again, that they don't know about it until after it has violated someone's rights and that the security vulnerabilities remain unpatched. GrapheneOS provides an auto-reboot to put data at rest, a USB-C port control to disable data transfer or the port entirely when booted into the OS, clearing sensitive data of memory and exploit protection features.

The post says: We've built our own text-to-speech system with an initial English language model we trained ourselves with fully open source data. It will be added to our App Store soon and then included in GrapheneOS as a default enabled TTS backend once some more improvements are made to it. We're going to build our own speech-to-text implementation to go along with this too. We're starting with an English model for both but we can add other languages which have high quality training data available. English and Mandarin have by far the most training data available. Existing implementations of text-to-speech and speech-to-text didn't meet our functionality or usability requirements. We want at least very high quality, low latency and robust implementations of both for English included in the OS. It will help make GrapheneOS more accessible. Our full time developer working on this already built their own Transcribro app for on-device speech-to-text available in the Accrescent app store. For GrapheneOS itself, we want actual open source implementations of these features rather than OpenAI's phony open source though. Whisper is actually closed source. Open weights is another way of saying permissively licensed closed source. Our implementation of both text-to-speech and speech-to-text will be actual open source which means people can actually fork it and add/change/remove training data, etc.

You may have been aware of my posts about TTS / SST. Heres more info:

#GrapheneOS version 2026010800 released. • raise declared patch level to 2026-01-05 which has been provided since we moved to Android 16 QPR2 in December due to Pixels shipping CVE-2025-54957 in December • re-enable the system keyboard at boot if it's disabled • switch to the system keyboard when device boots to the Safe Mode • add "Reboot to Safe Mode" power menu button in Before First Unlock state to make Safe Mode much more discoverable for working around app issues such as a broken third party keyboard • add workaround for upstream UsageStatsDatabase OOM system_server crash • add workaround for upstream WindowContext.finalize() system_server crash • disable buggy upstream disable_frozen_process_wakelocks feature causing system_server crashes for some users • Sandboxed Google Play compatibility layer: fix phenotype flags not working in Play services clients • Sandboxed Google Play compatibility layer: add MEDIA_CONTENT_CONTROL as a requested permission for Android Auto as part of our toggles for it to avoid needing to grant the far more invasive notification access permission • Sandboxed Google Play compatibility layer: extend opt-in Android Auto Bluetooth support to allow A2dpService.setConnectionPolicy() to fix Bluetooth functionality (previously worked around with a GmsCompatConfig update avoiding a crash) • switch to new upstream PackageInstallerUI implementation added in Android 16 QPR2 and port our changes to it • update SQLite to 3.50.6 LTS release • add an extra layer of USB port protection on 10th gen Pixels based on upstream functionality to replace our USB gadget control which was causing compatibility issues with the Pixel 10 USB drivers • allow SystemUI to access NFC service on 10th gen Pixels to fix the NFC quick tile • disable the upstream Android USB data protection feature since it conflicts with our more advanced approach and causes issues • issue CHARGING_ONLY_IMMEDIATE port control command in more cases • fix an issue in our infrastructure for spoofing permission self-checks breaking automatically reading SMS one-time codes for certain apps • add workaround for upstream KeySetManagerService system_server crash causing a user to be stuck on an old OS version due to it causing a boot failure when booting a the new OS version after updating • wipe DPM partition on 10th gen Pixels as part of installation as we do on earlier Pixels since it's always meant to be zeroed on production devices • Settings: disable indexing of the unsupported "Parental controls" setting which is not currently available in AOSP • Settings: disable redundant indexing of widgets on lockscreen contents which is already indexed another way • skip all pseudo kernel crash reports caused by device reboot to avoid various false positive crash reports • Vanadium: update to version 143.0.7499.192.0 All of the Android 16 security patches from the current January 2026, February 2026, March 2026, April 2026, May 2026 and June 2026 Android Security Bulletins are included in the 2026010801 security preview release. List of additional fixed CVEs: • High: CVE-2025-32348, CVE-2025-48561, CVE-2025-48615, CVE-2025-48630, CVE-2025-48641, CVE-2025-48642, CVE-2025-48644, CVE-2025-48645, CVE-2025-48646, CVE-2025-48649, CVE-2025-48652, CVE-2025-48653, CVE-2026-0014, CVE-2026-0015, CVE-2026-0016, CVE-2026-0017, CVE-2026-0018, CVE-2026-0020, CVE-2026-0021, CVE-2026-0022, CVE-2026-0023, CVE-2026-0024, CVE-2026-0025 https://grapheneos.org/releases#2026010800

update for nostr clients without edits: 'unlocked' changed to 'locked'

Worth noting stock Android also added 'Advanced Protection' which does similar, but still the same as Lockdown Mode where it does less than what GrapheneOS does, many of which is part of GrapheneOS *by default*.

Most of what makes GrapheneOS secure is set up by default. Many of the features are simply additions for people with greater needs and are described on the site page. Advanced Data Protection is related to iCloud, not the iPhone device or iOS. If you aren't storing data on iCloud it is mostly irrelevant but still useful to enable. Keep in mind your iCloud emails are not encrypted with ADP too. iCloud data is also not all Apple Account data. Some countries have also blocked ADP, including the United Kingdom. GrapheneOS doesn't have a cloud service like that, so it is moot. A new GrapheneOS device only connects to update servers (to deliver device updates), a network time service and a blank connectivity check page for captive portals, most of which are configurable. A better and fairer comparison would be Lockdown Mode, which is a feature in iOS that lightly hardens the OS against exploits. Most of what iOS does in Lockdown Mode is also what GrapheneOS does but better: - Lockdown Mode disables JS JIT (Just in Time compilation) for web browsing. Vanadium in GrapheneOS does too. - Lockdown Mode prevents wired USB connections when locked, GrapheneOS does and also via hardware, including turning the USB port off in OS mode. - FaceTime and iMessage improvements are moot as GrapheneOS doesn't bundle a messaging service. This would be dependent on the service you used. Most messaging apps give options to block unknown contacts, link previews and more. Most iPhones are also behind on exploit protections except for the iPhone 17 and later which introduced memory tagging (which they affectionately call Memory Integrity Enforcement). Pixel 8 and later provided memory tagging for GrapheneOS years prior. iPhone 17 with Lockdown Mode and ADP is the best choice for anyone not willing to use GrapheneOS. A great real world example of the security difference is capabilities provided by Cellebrite, a digital forensics company that leverages zero-days to extract data from devices. Cellebrite can extract data from most unlocked iPhones and stock OS Pixels, but they can't touch Pixel 6 and later with GrapheneOS right now. (Note, this iOS extraction slide is old and has newer devices / OS version support by now) https://arstechnica.com/gadgets/2025/10/leaker-reveals-which-pixels-are-vulnerable-to-cellebrite-phone-hacking/