Final

Should have said 'crypto company' instead, Fuck!!!

Binance and Chainalysis

Latest release of the App Store app for GrapheneOS used to update OS apps introduces support for delta updates through a library based on Accrescent's Ina. This should make downloading updates for apps like Vanadium much faster.

https://github.com/GrapheneOS/AppStore/releases/tag/37

We're planning on shipping our port of 10th generation Pixels to Linux 6.18 in our next official release. We'll see how that goes with much broader testing in our Alpha and Beta channels. We'll finish the port for the earlier Pixels once that's done and then we'll get everything moved over to 6.18.

Public testing via our experimental releases has been ongoing for several days now. Only a single regression has been discovered so far which was DisplayPort alternate mode no longer working and it was quickly fixed and made available in a new experimental release. It's ready for Alpha testing soon.

Had a discussion with the

team about how they could improve especially in a security and privacy standpoint. The post and article below discuss a small part of the efforts made. These provide substantial security improvements while having no added overhead or friction to the user.

If your application handles media, it's important that functionality is sandboxed and designed in a memory safe language. White Noise currently isolates image decoding in this way but now this has also been expanded to animated images as well. You can find out more below.

Memory tagging (MTE), a ARM hardware exploit protection used heavily by GrapheneOS and latest generation iPhones are now opted in the app manifest. This makes it unable to be disabled in GrapheneOS and also enables it for capable phones enrolled in Android's Advanced Protection.

The issue tracker also now tracks working on a few improvements, including adding this sandbox for other types of attachments too. I've also discussed on a improving accessibility features.

Another win for our hardware USB-C port control feature. In the highest setting, the device cannot charge unless it is powered off.

From Anthropic: "Claude wrote an exploit that let an attacker extract photos and other personal information from a stolen Android phone without unlocking it"

https://www.anthropic.com/research/discovering-vulnerabilities-with-claude

I hate talking about general security and privacy advice on social media. It's a common tactic by charlatans to make them appear trustworthy for saying basic things. But, this has to be said.

An often overlooked detail of wallet company data breaches is the collateral damage to the customer. Your compromised information can be used to target you in additional breaches, such as for phishing emails or even credential stuffing.

Everyone talks about the risk of real world harm but it's also your cyber health at stake. Never reuse your credentials and keep information you provide non-attributable where there is no consequence to do so.

If you are running a business involved in decentralised finance, whether it be as a product or accepting a mode of payment, you must understand you will have a target on your back, all the time, with threat actors who work more hours than you do and also more likely to be held unaccountable should they succeed with their goals. You have to assume you WILL get a data breach eventually. No organisation is perfect. If you aren't ready to continuously put in an effort to security, quit while you can to protect your customers.

Basic mistakes are the most overlooked, and often the most dangerous. There is never a wrong time to review your posture. Don't let your impacts be amplified by technical failures you only were able to discover after the breach happened.

0 days without a wallet company data breach.

0 days without a wallet company data breach.

Even Wikipedia appeared to get this wrong...

accused a man of destruction of evidence after he gave his screen lock duress pin to an officer during a border search.

Was not evidence, rather destruction of property to prevent seizure.

https://en.wikipedia.org/wiki/GrapheneOS

committed memory tagging (MTE) enabled in their app manifest. This means in a future version of the app, you get MTE used in a very limited scope of non-GrapheneOS Android devices. For #GrapheneOS it means the exploit protections cannot be disabled.

https://github.com/marmot-protocol/whitenoise-android/commit/9f39a21709c9ec20ff3f4d2c12e8398b88ec91ce

I was right.

DHS Said They Searched Man Who Wiped #GrapheneOS Phone for Child Abuse Material. They Lied.

https://www.404media.co/dhs-said-they-searched-man-who-wiped-grapheneos-phone-for-child-abuse-material-they-lied/

I was sent this article showing what appears to be a document by Cellebrite that was marked as confidential describing a recent Advanced Unlocks capability. The document is a few months old. This capability allegedly uses a dedicated appliance with a stated range of about 8 metres. Given the range they suspect it is to do with Bluetooth.

There is no mention of iPhones with MIE (hardware memory tagging, iPhone 17, Air and later) and it is not on the latest iOS version, which could suggest a patch.

Take a look for yourself:

https://justin.sh/blog/2026/10/cellebrite-advanced-unlocks/

It would make sense that Cellebrite would choose to have capabilities like this one under development. When devices increase their security against physical attacks, the exploit developers will move towards a path of least resistance to exploit other components or circumvent the security measures that prevent the extraction, as we see with their automatic reboot cancelling exploits for iPhones. Since forensics labs contain devices in isolation to prevent network access and remote wiping, it is possible to make simulated / dummy network environments inside those containers where advanced labs can attempt exploit delivery without the risks.

The full document is available on request so it needs to be looked at further. While I do not intend to make discussion threads on this site regularly I think this is in a public interest.

Latest #GrapheneOS update moves the launcher grid options and icon sizes to the Stock OS. You should have an extra row for the apps at the top you didn't have before.

This is the new #GrapheneOS boot animation in the latest release available now. It's generated frame-by-frame using a script. It has a minimum 3.5s total runtime for the intro including a small pause. The rest of the animation gets interrupted once the device is booted to avoid any delay so there can't be an outro.

Interesting new software from the Ibis Paint guys. Extremely fast office suite.

https://github.com/ibisjp/ibis-office

Updaters: have you noticed it? 👀

You should see an OS performance increase in our latest update. In upcoming releases there will be much more too including a way to possibly decrease memory usage from our secure app spawning feature.

Well it looks like I have Mythos 5.1 now. Sweet.

Android 17 QPR1 was released for Pixels on September 15. It has a regression in the Pixel kernel driver tree causing stuttering, lag and outright freezes under memory pressure. It impacts #GrapheneOS too since we updated the firmware/drivers but now we fixed it ourselves.

Google is taking increasingly long to implement and ship fixes for major issues in Android. We're having to expand our workload to include handling basic updates, testing and quality control for the entire operating system. We have rapidly growing resources and we'll handle it.

Pixel 11 series received a bug fix release near the start of September 2026 with the 2026-09-01 patch level. That update wasn't Android 17 QPR1 and also doesn't include the September 2026 Pixel firmware/driver security patches. Perhaps they noticed this issue and cancelled it.

Standard Android and Pixel updates have a severe issue with delays. It usually takes 2-3 months for Google to ship fixes for both severe regressions and security issues. They often get the issues fixed in days but the release engineering and testing process is completely broken.

Major Android releases including Android 17 QPR1 go through a long public testing period. It typically takes Google at least around 4 to 6 weeks to ship fixes for even the most severe issues. They either cancel the release (Pixel 11) or ship a broken release (everything else).

Here's our fix for the awful Android 17 QPR1 regression causing lag, stuttering and freezes:

https://gitlab.com/grapheneos/kernel_pixel_6.6/-/commit/ed5a9b87d99b45618fa55b3d6b53094cbd784b9f

It's so severe that it's causing processes to be killed for stalls. It's unclear when Google will ship a fix for the issue. December 2026 wouldn't be a surprise.

Due to this major Android 17 QPR1 regression, we've been looking into reducing memory usage. We found a way to eliminate most extra memory use from our secure spawning feature without any significant downsides. We'll try to get that huge improvement shipped before November 2026.

Big number that I don't care to count anymore vulnerabilities in Debian just update your OS or whatever

https://lwn.net/Articles/1097401

Bitcoin Racing x #GrapheneOS: BMW M3

Lifelong 'Grand Theft Auto' fan excited to play the first 'Grand Theft Auto' game released in his lifetime

Our massive overhaul of the AOSP Messaging app has reached the Stable channel in our App Store after 3 releases. It's well on the way to becoming our own high quality #GrapheneOS Messaging app instead. There are still parts of the interface to overhaul including widgets and important features to add.

Full support for RCS with all of the additional features it brings including proper group chats, media, opt-in read receipts and much more is going to be the largest project. We'll also be adding RCS end-to-end encryption via Messaging Layer Security (MLS) compatible with Google Messages and iOS.

RCS support will be provided via an optional dependency on sandboxed Google Play for activation. In the longer term, we plan to make a fully standalone implementation requiring the carrier to support it. We probably won't make an alternate implementation of using Google's own system for this.

Finishing the user interface overhaul, resolving many minor issues and adding important features including search are going to be the priority before getting to RCS. In the meantime, Google Messages is already fully supported on GrapheneOS including RCS with E2EE via MLS:

https://grapheneos.org/usage#rcs

Side of Burritos released a video demonstrating a malicious app with no added permissions compared to stock Android collecting clipboard data automatically. Our new clipboard control features in GrapheneOS protects such a thing from happening.

DID YOU JUST SURF THE BLOODY INTERNET WITHOUT PAYING YOUR "BBC LICENSE" MATE 💂‍♀️

https://inews.co.uk/news/bbc-licence-fee-could-scrapped-for-internet-charge-4782353

This update adds on many bug fixes and significantly improves the performance of our overhauled default SMS / MMS messaging app, most notably, large conversations (tested to 80k texts) now open 350x faster than before (~0.10 seconds from over 35 seconds).

There are many security what-ifs that can be solved by answering "POCs or GTFO" by the way.

The

app transition to Kotlin and Jetpack Compose is really good. It's such a smooth, fast messenger. Even more so when I expect most apps relating to Nostr or BTC to be quite sluggish. There is a significant leap in usability for apps that are designed for a platform's native language and libraries.

Get free pentesting by designing your new web app frontend with Bootstrap 1.0 so it looks old and unmaintained

Now in Stable.

Become Ungovernable

You can now control the clipboard access of applications individually in #GrapheneOS. This makes apps only able to see data if the user manually pasted it, with exception of the clipboard item originating from the same app attempting to paste.

You can go into Settings -> Security and Privacy in Owner to control clipboard access globally.

You can also go into individual applications in any profile to control that individual app's access.

Secure paste has been merged into #GrapheneOS to provide a replacement for focused apps being able to read the clipboard:

https://github.com/GrapheneOS/platform_frameworks_base/pull/435

When it comes to open source software, the corporates funded with state money who want to find vulnerabilities in your software for their advantage are often far more qualified, resourceful and committed to their objectives than the limited project developers are.

You must be more cautious about having both a secure design and a secure implementation of the design of your software at the earliest possible stage of software development. This increases the time and effort to discover a vulnerability or can close out entire classes of vulnerabilities. We have seen how massive projects are weighted down from development standards of the late 90s and 00s that makes them have thousands of CVEs every release.

https://www.phoronix.com/news/Linux-Kernel-CVEs-Nearly-2000

Check out some of the open-source AI tooling from Cellebrite to improve their workflows and automate in researching mobile device vulnerabilities.

https://github.com/cellebrite-labs/ghidra-rpc

https://github.com/cellebrite-labs/ida-bridge

https://github.com/cellebrite-labs/ida-docs

https://github.com/cellebrite-labs/ida-porter

You can have opinions on the issues of LLMs (and I have several), but that comes with having to accept an adversary is accelerating how to harm you with that technology.

The overhauled #GrapheneOS Messaging app is available in our App Store via the Alpha channel.

Our new app development team worked on this for months. It's now a far better app with much higher quality code. We'll make a new release based on feedback soon.

We're going to be overhauling or replacing most AOSP apps in the near future: Calculator, Clock, Contacts, Gallery, Keyboard and Phone.

The apps we created will be overhauled too. PDF Viewer is done and Camera is next. Camera and PDF Viewer will be getting many new features too.

It's a massive overhaul and may need a few releases to reach the Stable channel. We're working on a version 14 release fixing issues with the predictive back animation, tapping contacts not always showing the right SIM with dual SIM and some outdated icons/colors we missed.

Messaging will be overhauled even more. We plan to add RCS support with Messaging Layer Security (MLS). That will provide E2EE with contacts using Google Messages or iOS. RCS with MLS can already be used on GrapheneOS via Google Messages but we want to avoid people needing it.

#GrapheneOS messaging, our new redesign of the SMS/MMS messaging app, is now available in the GrapheneOS App Store in Alpha channel.

This is the first of many replacements of default apps we aim to work for. Check it out!!

We're currently making a new OS release to resolve a volume bar UI regression caused by an upstream Android security preview patch found in Alpha. We've also fixed a Private Space UI issue.

The major Messaging app release we've been working on for months has been slightly delayed to after we make the OS release. Hope you'll like it!

Why not both?

https://www.clicks.tech/products/clicks-for-google-pixel

We've developed a secure paste feature replacing traditional clipboard APIs in #GrapheneOS. Users will be able to take away clipboard access from apps to use this instead. It integrates into the standard selection toolbar, input methods, accessibility services and keyboard shortcuts. We plan to get it merged soon.

A small subset of apps including those written in Flutter implement their own text selection toolbar. We've worked around this by adding a Paste button to the default keyboard. We'll be replacing AOSP Keyboard with a much better keyboard and will carry over adding this feature to the new one too.

Android only permits the currently focused app and keyboard to read the clipboard. However, sensitive data often lingers around in the clipboard for a while and privacy invasive apps can read it. Android shows a notice for apps reading clipboard content set by other apps but by then it's too late.

Our approach is replacing the inherently problematic API-based clipboard access approach used by both desktop and mobile operating systems. It's another overhaul of the privacy model for apps similar to our Contact Scopes and Storage Scopes features. We have many of these privacy features planned.

We're well into the process of converting the Messaging app included in #GrapheneOS into a modern app. We'll be making a new release later today with a completely overhauled user interface written in Android Compose. We've made a massive amount of other improvements and bug fixes beyond that too.

In the longer term, we plan to add support for RCS including support for the standard end-to-end encryption (E2EE) via Messaging Layer Security (MLS). Currently, RCS including E2EE is available on GrapheneOS via Google Messages. We want to avoid the need to use Google Messages for RCS eventually.

RCS on Android is currently implemented with code across the OS, Google Messages and Google Play services. Our plan is to start by making an equivalent to the portion in Google Messages. It would initially require sandboxed Google Play for RCS activation, etc. but we plan to implement that too..

RCS isn't an open platform in practice. It isn't even as open as SMS/MMS. It heavily depends on proprietary Google and carrier infrastructure in practice. We can start by replicating Google's approach and then we can work on only using carrier services for carriers where it's actually supported.

We're also going to be overhauling or fully replacing the rest of the AOSP apps in the near future. AOSP Gallery is incredibly outdated and is being entirely replaced. AOSP Keyboard may be similar. We recently hired a bunch of new people and will be hiring more so our progress will be accelerating.

In the past, our focus was nearly entirely on the base OS rather than bundled apps with alternatives available. We've heavily ramped up the resources we're investing into the bundled apps. We'll also be scaling up our work on the base OS too. More donations will enable us to hire even more people.

Latest GrapheneOS release implements automatic call recording.

We've been testing performance of MTE on the Pixel 11 using the Android 17 QPR2 Beta 4 release adding back firmware support for it. MTE in asymmetric mode only has around 5% overhead in the standard benchmarks and other tests we've done. That's more than good enough but we've done limited tests.

Android 17 QPR2 Beta 4 on the Pixel 11 force disables MTE for the OS from the firmware. Using it requires ignoring the arm64.nomte parameter being passed to the kernel. It still isn't clear why they're making the feature unavailable. SVE was also force disabled in Android 17 but not in QPR2 Beta 4.

Our initial testing indicates performance isn't substantially worse. The overhead may be higher but there was an incremental CPU performance with the Pixel 11 which should more than make up for it. However, MTE is unavailable with stable firmware and we're bypassing firmware disabling it for QPR2.

Multiple Google engineers we've contacted have said they aren't able to give us any information about this so we're left doing reverse engineering and relying on leaks. The leaks do not seem reliable and do not match what we see. Our concern is that MTE may actually be broken due to CPU errata.

We have good news about the Pixel 11. It still has at least bare minimum support for MTE at a hardware level. We think they removed most of the hardware acceleration from the CPU cache to save money. They ruined the performance so it ended up being fully disabled in firmware. It may still be usable.

Android 17 QPR2 Beta 4 was released on August 28th. It's the first Beta release with Pixel 11 support. MTE support is still completely disabled in the OS and arm64.nomte is unconditionally passed by the firmware to the kernel. The good news is the firmware itself had MTE support added back to it.

It's possible to enable reserving the tag memory for MTE via fastboot oem mte on, boot a non-stock kernel ignoring arm64.nomte and use MTE. We're in the process of determining whether it's fully functional and the performance characteristics. It's likely disabled due to performance being ruined.

We expect performance must be quite bad for Google to have decided to entirely strip out support for it in not only the software but also the firmware so that no would could even try to use it before Android 17 QPR2 Beta 4. That's a very strange thing to do. It's at least added back to firmware now.

We reached out to multiple people at Google asking about the MTE situation on the Pixel 11 prior to making our original thread and didn't receive any responses. We still don't know what's wrong with MTE on the Pixel 11. It isn't clear if there are serious CPU errata or it simply performs very badly.

If the issue is simply that MTE performance is poor, then we can support the Pixel 11 in #GrapheneOS with the major caveat that it will be a significant performance downgrade. Aside from MTE, Google downgraded the Pixel 11 series GPU compared to the Pixel 10 series in addition to reducing RAM for base Pro models.

Google has been increasingly silent in response to any communications since dropping Pixel support from AOSP with Android 16 in June 2025. They could have told us MTE performance was significantly reduced so they disabled it at launch but will add it back to firmware for QPR2. That's still unclear.

Android 17 QPR2 Beta 4 releases for the Pixel 11 series were only uploaded around 10 hours ago rather than with the initial release on August 28th so this hasn't been available for very long. It wasn't missed by us or people who looked into it after our initial thread but rather wasn't out yet.