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

GitHub

secure paste: add clipboard access policy and grants by inthewaves · Pull Request #435 · GrapheneOS/platform_frameworks_base

Closes GrapheneOS/os-issue-tracker#2917 Depends on: secure paste: add clipboard access settings platform_packages_apps_Settings#443 secure paste:...

View quoted note →

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.

GitHub

GitHub - cellebrite-labs/ghidra-rpc: A Ghidra agentic reverse engineering skill.

A Ghidra agentic reverse engineering skill. Contribute to cellebrite-labs/ghidra-rpc development by creating an account on GitHub.

GitHub

GitHub - cellebrite-labs/ida-bridge: Bridge between agents and IDA Pro.

Bridge between agents and IDA Pro. Contribute to cellebrite-labs/ida-bridge development by creating an account on GitHub.

GitHub

GitHub - cellebrite-labs/ida-docs: Agent skill for IDA 9.x IDAPython lookup, backed by the public Hex-Rays IDA SDK.

Agent skill for IDA 9.x IDAPython lookup, backed by the public Hex-Rays IDA SDK. - cellebrite-labs/ida-docs

GitHub

GitHub - cellebrite-labs/ida-porter: Let the agent carry your IDAPython to the next IDA version.

Let the agent carry your IDAPython to the next IDA version. - 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. View quoted note →

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. View quoted note →

Why not both?

Clicks for Pixel: More control. More screen. More you.

With real buttons, a full-screen experience, and powerful shortcuts you can type faster, see more, and take control like never before.

View quoted note →

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. View quoted note →

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. View quoted note →

Near the end of May 2026, Russia began filtering access to DataPacket IP space with an enforced domain allowlist for HTTP and TLS SNI. #GrapheneOS services aren't on the allowlist so we had to switch from DataPacket Frankfurt to Cherry Servers Amsterdam for Russia. That's now getting filtered too. We've fixed it again by using Zare London for connections from Russia instead. That's the final of our sponsored servers in Europe we can use so we'll need to fall back to Xenyth Toronto if they filter it. We're using our own IP space in Toronto so it should work unless they specifically block us. We don't think we'll be blocked directly but we're also unlikely to get placed on the allowlist. That means our services are gradually going to become inaccessible in Russia via the IP space of major cloud services. Our own IP space will still work fine and we don't host any VPN services ourselves. Our website, OS updates, app repository, connectivity checks, network time, network-based location, geocoding and other main services should work again in Russia. It's likely they'll expand to filtering Zare's IP space and then we'll have to use Toronto where we have our own non-anycast IPv4 /24. They use a domain blocklist for most of the internet and an allowlist for many VPS and dedicated server hosting providers to block access to VPN services. It's likely they'll expand to enforcing an allowlist for every major server hosting provider. That's far more aggressive than China's filtering. Our authoritative DNS is hosted via 2 anycast networks using our own ASN and IP space so it hasn't been impacted by this. It's likely we can avoid it for the rest of our services by using our own IP space. If they start filtering netcup IP space, we can make a reverse proxy to those from Toronto. If our services are blocked, connectivity checks can also be set to Standard rather than Disabled to use the Google servers. That'll keep automatic selection of networks with internet working along with automatic captive portal handling and JobSceduler not assuming every network has internet access.

We are advising people to NOT buy the 11th Generation Pixels due to removal of hardware memory tagging (MTE), a crucial security feature used in GrapheneOS since their introduction on the Pixel 8. Either use a previous generation or wait for the first Motorola devices with GrapheneOS. We have not determined what to do about this. View quoted note →

347 Linux kernel CVEs published yesterday BTW

Amazing we don't have a major open competitor to Chainalysis reactor. We have explorers, but nothing to such a level. When it comes to visualisation it seems top notch, and you need excellent visuals when doing incident reviews. Id love to have an explorer that also was bundled with aliases, (public) identifiers for addresses and so on.

I think Bitcoin Design doesn't get enough attention, so I want to give it some, as I am using it for reference myself.

Bitcoin Design

Bitcoin Design. Open-source design for bitcoin products.

Bitcoin Design is a free open-source community resource that helps designers and developers working on bitcoin-products to create better experience...

We should call software less buzzwords. Something that's 'Cypherpunk', 'sovereign' and 'freedom' actually tells me nothing about their properties.

Contrary to popculture and internet trend narratives, the majority of cyber attacks are not sophisticated. Behind some of the worst cyber attacks are what an industry worker would refer to as a common security deficiency. These are flaws that are very common and are regularly discussed. These things could be: - Delayed or no security patching - Missing second factor authentication - A misconfiguration or using a insecure configuration, whether it be crypto, application settings, etc. - Insufficient or lack of access control - Lack of due diligence or awareness from the victim - Insufficient logging or monitoring - Lack of transit or at-rest encryption Equifax, one of the worst data breaches in modern times, was thanks to them not performing security patching on Apache Struts which allowed a threat actor to exploit a known vulnerability. GTA 6 was leaked from a staff member being socially engineered. Snowden perhaps could not have done his whistleblowing if the NSA has stricter access control. The best threat actors use the easiest way in to get what they want. The big letter agencies do not jump through hoops and set up big conspiracies rather they exploit software the same way a professional researcher would try to. This also makes an operation far less attributable, because a common security deficiency could be exploited by anybody. When you regularly see coverage about North Korea ('Lazarus') compromising cryptocurrency companies or users, they are often exploiting these same easily explained weaknesses. If something is too secure, many will easily decide to find a victim that is easier to compromise. What makes them so dangerous isn't their technical capabilities rather than they have far more time and resources because they are state sponsored. They will *never* be held accountable. When you cover all of these deficiencies and more, your tech is probably more secure than 99.9% of people. Now you go from being a victim of a common attack, to something that would need to be bespoke and targeted. When working on security or privacy focused software, think long and hard about the quality of the implementation of your functions. You could have many features, but they may not be helpful if their implementation is poor. A poor implementation of a feature may introduce weaknesses compared to not having the feature introduced at all. Less can truly be more.

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 - Free Open source disk encryption with strong security for the Paranoid

VeraCrypt is free open-source disk encryption software for Windows, Mac OS X and Linux. In case an attacker forces you to reveal the password, Vera...

The decoy profile concept many have suggested for years is far more flawed than this. It wouldn't hide the presence of other profiles and would be trivially identified. Basic forensic software on a laptop would identify it without exploits. It would also make exploits far easier.

Because I am seeing discourse on the Elon app about it, see this old reply: View quoted note →