We've developed a new factory images format optimized for web installation which avoids the need for fastbootd mode and greatly reduces memory/storage usage. The new approach is compatible with 5th gen Pixels and later. It's deployed on our staging site:

Install | GrapheneOS

We'd appreciate help with testing the new web installer on our staging site. It should reduce issues caused by low quality USB connections/drivers by avoiding switching to a different mode. It should also eliminate the need to install a fastboot driver on up-to-date Windows 11. We'll wait for feedback from people using it successfully across different operating systems and devices. Sections for working around Debian, Ubuntu and Windows USB deficiencies should be unnecessary other than the legacy extended support devices so we'll likely remove those. #GrapheneOS

Vanadium version 127.0.6533.64.1 released: - enable per-site isolation for sandboxed iframes instead of per-origin isolation - avoid rare uncaught exception from attempting to load content filters from the Vanadium Config app when native code isn't loaded yet

GitHub

Releases · GrapheneOS/Vanadium

Privacy and security enhanced releases of Chromium for GrapheneOS. Vanadium provides the WebView and standard user-facing browser on GrapheneOS. It...

#GrapheneOS

Chromium has merged the WebAssembly interpreter submitted by a Microsoft Edge engineer: https://chromium-review.googlesource.com/c/v8/v8/+/5509903 Once this reaches a Chromium stable release, Vanadium will support WebAssembly by default instead of requiring turning on JS JIT via drop-down site settings. Example of a site using it is Mutiny Wallet. Chromium has a V8 Optimizer toggle for disabling the 2 optimized tiers of the Just-In-Time (JIT) compiler to greatly reduce attack surface. However, it doesn't disable baseline JIT and therefore still does dynamic native code generation. They did this to avoid breaking Wasm. In Vanadium, our JIT toggle fully disables the JIT and therefore currently loses Wasm support. An increasing number of sites are depending on Wasm with no fallback to JavaScript. Most of these sites perform perfectly fine with only the fast V8 interpreter and no JIT compilation. Vanadium has JIT compilation disabled by default as part of the security focus. This Wasm interpreter will be a nice usability improvement for sites depending on it with no fallback code since users won't need to toggle on the JIT compiler for the site unless it performs badly.

Yes!!! Yes!!! https://chromium-review.googlesource.com/c/v8/v8/+/5509903

Unplugged have doubled down on false claims about GrapheneOS security, pretending people cannot buy devices with GrapheneOS installed and pretending it's hard to install along with promoting their blatantly insecure products with false marketing.

X (formerly Twitter)

The Andres Segovia (@_AndresSegovia) on X

Long before Unplugged delivered their first phone, they were under scrutiny because of it's founders. And while people can hear from co-founder Eri...

We have an existing thread going through many of their false claims and debunking them:

X (formerly Twitter)

GrapheneOS (@GrapheneOS) on X

Unplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as high...

We also responded to their lies about GrapheneOS directly. They've read our posts and have chosen to continue peddling the same misinformation about GrapheneOS. They keep pushing the false claim that Pixels supporting using another OS makes them less secure. The reality is that it's properly implemented in a secure way without adding any significant attack surface. The bottom of the barrel MediaTek Unplugged devices have awful security. They still haven't ported to the initial release of Android 14 with Android 15 right around the corner. This means they're missing at least around a year of Moderate severity privacy/security patches and huge privacy/security improvements from the past year of Android releases. Unplugged is using an SoC from MediaTek, a company known to have poor security practices, which fares poorly against real attackers and which has a history of repeatedly shipping actual backdoors. They're trying to portray that as more trustworthy and more secure hardware. Nope. Unplugged was founded by Erik Prince, noted war criminal and illegal arms dealer. They make a point in talking about the involvement of their employees in enabling these kinds of operations:

X (formerly Twitter)

GrapheneOS (@GrapheneOS) on X

Here's an example of a "counterterrorism operation" by a U.S.-allied Western government targeting political opponents with NSO exploits: https://t...

That doesn't imply competence, but explains the lack of ethics. They're trying to present themselves as if they were leaders in the field and switched sides, but they never were and simply want money. Unplugged is an affinity scam in the same vein as the Freedom Phone. Unplugged has built their product out of open source projects, but without complying with the licenses from projects like DivestOS and while trying to harm open source. Claiming to be in the process of replacing some of the code they were caught stealing doesn't change much...

Accrescent app store documentation and website have been updated to reflect the collaboration with #GrapheneOS. If using Accrescent before this, the recommended method to verify Accrescent is to install it from the GrapheneOS App Store. This approach chains the signing verification of Accrescent to GrapheneOS itself, which can then be chained to a hardware-backed root of trust through the GrapheneOS verified boot and Auditor app. You can learn more about the Accrescent security modeling here:

Accrescent

Accrescent

Notable features of Accrescent distinguishing it from other stores.

For Signal users: Outside of just the security benefits for using Molly we discuss a lot about, you should also use it if you don't use Google Play Services, as the non-FCM push notifications in the original Signal app drains a lot of battery. Molly FOSS has a much more efficient implementation of non-FCM push notifications and doesn't drain battery. You can find Molly FOSS on the Accrescent app store (available in GrapheneOS Apps app) or from the project site.

Molly

Molly is an improved Signal app for Android

EXCLUSIVE: Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024. 404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current. Here's the Cellebrite Premium 7.69.5 Android Support Matrix from July 2024 for Pixels. They're still unable to exploit locked #GrapheneOS devices unless they're missing patches from 2022. A locked GrapheneOS device also automatically gets back to BFU from AFU after 18h by default.

We published the Cellebrite Premium documentation from April 2024 in May 2024. Our thread properly explained the info in the tables including their inability to exploit Pixel 6 or later secure element and only partially bypass it on iPhone 12 or later at that current period of time. Cellebrite was a few months behind on supporting the latest iOS versions. It's common for them to fall a few months behind for the latest iOS and quarterly/yearly Android releases. They've had April, May, June and July to advance further. It's wrong to assume capabilities didn't change for the later iPhones. 404media published an article about the leaked documentation this week but it doesn't go into depth analyzing the leaked information as we did, but it didn't make any major errors. Many news publications are now writing highly inaccurate articles about it following that coverage. The detailed Android table showing the same info as iPhones for Pixels wasn't included in the article. Other news publications appear to be ignoring the leaked docs and our thread linked by 404media with more detail. They're only paraphrasing that article and making assumptions. The person who shared it with 404media is one of our community members. We regularly get sent this kind of information. In the case of XRY from MSAB, we were able to report several Android vulnerabilities based on their docs which are now fixed on Pixels but not elsewhere yet. We received Cellebrite's April 2024 Android and iOS support documents in April and from another source in May before publishing it. Someone else shared those and more documents on our forum. It didn't help us improve GrapheneOS, but it's good to know what we're doing is currently working. It would be a lot more helpful if people leaked the current code for Cellebrite, Graykey and XRY to us. We'll report all of the Android vulnerabilities they use whether or not they can be used against GrapheneOS. We can also make suggestions on how to fix vulnerability classes. In April, Pixels added a reset attack mitigation feature based on our proposal ruling out the class of vulnerability being used by XRY. In June, Pixels added support for wipe-without-reboot based on our proposal to prevent device admin app wiping bypass being used by XRY. In Cellebrite's docs, they show they can extract the iOS lock method from memory on an After First Unlock device after exploiting it, so the opt-in data classes for keeping data at rest when locked don't really work. XRY used a similar issue in their now blocked Android exploit. #GrapheneOS zero-on-free features appear to stop that data from being kept around after unlock. However, it would be nice to know what's being kept around. It's not the password since they have to brute force so it must be the initial scrypt-derived key or one of the hashes of it.