Amber

theglobeandmail.com/canada/a… is a very fair and balanced article. They did proper research and talked to experts. That's entirely unlike nearly all of the coverage by the media in Spain, France, Germany and the Netherlands. In the few cases we were asked for our perspective, nearly nothing we said was included. They acted as sycophants for the state and did not challenge or verify their claims. Why is it that nearly all the western European news coverage is sycophantic?

There's a major state sponsored misinformation and smear campaign towards GrapheneOS in the Netherlands and Germany. The misinformation campaign includes unsubstantiated security claims not holding up to scrutiny to scare people away from it. They're also heavily misrepresenting who uses it overall. These smear campaigns conflate GrapheneOS with forks and modifications of it sold by shady companies. Those usually include a device management app to remotely manage the devices of their customers as if they're employees. These are largely not GrapheneOS devices or have preinstalled malware apps. A common tactic being used in these smear campaigns is to make unsubstantiated and outright false claims about the capabilities of forensic data extraction tools. They misrepresent how they get into devices. They want to scare people into using far less secure devices which are easier to exploit. France, Germany, Spain and the Netherlands are becoming increasingly authoritarian surveillance states with an ongoing crackdown against privacy. It's happening throughout the whole EU and it's likely both secure devices and end-to-end encryption without backdoors are going to end up outlawed. There are a bunch of companies based in the EU selling phones with drastically worse privacy and security than an iPhone including Jolla, Volla, Murena and iodé. These products are effectively backdoored by not providing standard privacy and security patches/protections while misleading users. France and other EU countries are actively cracking down on legitimate privacy and security projects while supporting unsafe products within their control. These products make it far easier to remotely exploit devices and also to bypass encryption to extract data. They're phony privacy products. Each of the companies we've listed have participated in the misinformation and smear campaigns against GrapheneOS. Jolla spent years working closely with Putin's regime. Volla, Murena and iodé are building an EU Play Integrity API. None provides the crucial standard privacy patches/protections. Murena is directly assisting with state anti-privacy campaigns smearing highly private and secure devices as mainly benefiting criminals. They've repeatedly falsely claimed GrapheneOS is mainly used by criminals. Here are 2 of many examples: teapawt.org/GrapheneOS/status/2040… clubic.com/actualite-604786-… GrapheneOS, end-to-end encrypted messaging apps, Monero and other projects are being targeted with state and corporate propaganda and anti-privacy laws. Meanwhile, the same governments heavily fund and support phony privacy projects clearly downgrading privacy and security compared to an iPhone. GrapheneOS is only an initial target for these state actors and their sycophants in corporate news organizations. Apple heavily works on protecting users against exploits too. It would be much harder to convince the public that an iPhone is for criminals so they're starting with open source.

Our port of the 10th generation Pixels to the Linux 6.18 GKI LTS branch has been through a day of public testing by a couple dozen users. There are no known issues remaining anymore. We're going to continue heavily reviewing the commits and looking for more unhandled API changes.

Yahoo is still blocking emails from our newly assigned IPv4 space (206.220.120.0/22). It's likely they're behind on updating their database of allocated IP space. It was already published via arin.net/resources/guide/ipv… and other providers have been accepting it for 2 weeks already.

Secure paste has been merged into GrapheneOS to provide a replacement for focused apps being able to read the clipboard: github.com/GrapheneOS/platfo…

Android has USB data and a large number of USB drivers available including while locked. Plug in a mouse, keyboard, external drive or other USB accessory and you'll see that's the case. When Android says charging-only, it means not allowing file transfer. teapawt.org/linuxuser1996/status/2…

This paper is inaccurate slop. It makes a large number of clearly inaccurate claims about GrapheneOS and presents results which are verifiably false. It's filled with nonsense which appears AI generated. > The Clone Strikes Back: Efficient Vulnerable Code Detection in Custom Android-based Systems The authors wrongly believe GrapheneOS has diverged from the Android Open Source Project (AOSP). The starting point for GrapheneOS is the latest stable release of AOSP with all of the AOSP security backport commits applied. Our changes to AOSP repositories are maintained as cleanly rebased patches. Our AOSP changes are reviewed and improved on an ongoing basis. It's not only the code being improved but also commit structure. We're always preparing for porting to the next stable release. It's handled as if our AOSP changes are being prepared for submission to the project for the first time. We start fresh with each stable release of AOSP. All our changes are ported to the new source tree. There's no merging process but rather porting and submitting the changes to the new source tree. Major changes are often required including entirely rewriting certain features for the new release. This entire paper is based around a misconception. The authors wrongly believe we need to identify and incorporate all of the upstream changes into GrapheneOS. It's our changes we need to make sure to fully and correctly port to each new release of AOSP, not the other way around as they believe. The authors should have seen that each of releases has all of our changes to AOSP repositories cleanly rebased on top of the latest stable release. We do make substantial changes to AOSP but it can all be reviewed as a set of patches applied on top of the latest AOSP release with zero merge commits. Android Security Bulletins are a list privacy and security patches backported to older releases of the OS. These aren't the privacy and security fixes made in the development branch but rather incomplete backports. Far more fixes made in the development branch and the approach is often different. Android's development branch can do major refactoring and rewrites. It can make privacy and security improvements requiring substantial changes to the code. It can fix weaknesses requiring backwards incompatible changes. The backports don't even attempt to cover Low and Moderate severity patches. The authors of the paper took the diffs from the Android Security Bulletins and created tooling to look for the changes made by those diffs being missing. They present the findings where they manually confirmed lines of code don't appear to be present as if those are missing patches in GrapheneOS. They should have easily figured out GrapheneOS releases are based on the latest AOSP release. They should have used their tooling on AOSP itself as a control. They would have gotten the same results for AOSP and GrapheneOS if they used versions from the same date. Instead, they're misleading people. If they checked the latest AOSP release at the time, they would have seen there's no actual difference in what their tooling finds between AOSP and GrapheneOS. The code they identified as not present in GrapheneOS wasn't in the latest AOSP release at the time. It also doesn't show anything is wrong. Many of the security issues fixed by Android for older releases aren't present in recent releases due to rewrites and changes to the code. Fixes in the development branch are often difficult to backport with major changes or entirely different approaches being needed. Backports are their own thing. It's common for the initial attempt at fixing a privacy and security issue to be incomplete or incorrect. These changes sometimes even introduce new vulnerabilities. There are often multiple rounds of partial fixes. Truly fixing it often requires major changes or rewrites impractical to backport. This paper is built around an incorrect understanding of how GrapheneOS is based on AOSP and Android's security patches. All of the patches included in Android at the time were shipped by GrapheneOS. If any of what they found was an actual issue, which is doubtful, then it was missing in AOSP too. Aside from the incorrect premise and methodology, the paper is filled with many other inaccurate claims about GrapheneOS. Look at this example: > For instance, GrapheneOS eliminates unnecessary background processes and applies exploit-hardening techniques to reduce CPU and battery usage. Did a human truly write that sentence? We aren't aware of any background processes we've eliminated compared to AOSP. Our exploit protections certainly don't reduce CPU, memory or battery usage. We do take great care to minimize the overhead and provide toggles for features with a substantial cost. The paper is filled with statements which sound reasonable to non-experts but are nonsense. We wouldn't be surprised if most of the paper and code was LLM generated. There are many strong signs of it and it's hard to believe humans wrote all of this. We think it should be investigated further. There are 4 authors listed for this. The person listed 3rd is a Senior Research Scientist in the Platforms Security and Privacy team at Google. It's published as part of the 2026 IEEE 11th European Symposium on Security and Privacy (EuroS&P). What happened here? computer.org/csdl/proceeding… Google published Android as an open source project and it succeeded based on it. For years, they've been engaging in illegal anti-competitive tactics to gain control over what was an open platform supposedly governed by a group of companies rather than Google. That includes the Play Integrity API. Play Integrity API is pushed based on the false premise that it's a security feature. In reality, it's a core pillar of an illegal anti-competitive business model and clearly harms security. It bans GrapheneOS despite it being far more secure than anything they certify including far better patching. This paper pushes Google's false narrative of alternatives to Google certified Android not providing standard patches and protections. A Google researcher being directly involved as an author is scandalous. The claims made by the paper about GrapheneOS are clearly false and it needs to be retracted. The paper links to a GitHub repository with code, data and a copy of the paper. It's strange they apparently never thought to run this against the AOSP release which the GrapheneOS release they tested was based on. There are 0 differences in most of the relevant code... github.com/Demeter2025/Andro…

In response to recent suggestions mentioning it: > If you need plausible deniability, you must not use VeraCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism. veracrypt.io/en/Wear-Levelin…