Build your own keyboard. That's all. You won't regret it

Accrescent is an early alpha app store made by a sole developer. It is designed for security and privacy. The application has a hardcoded key that checks for a cryptographically signed app repository. If the repository is compromised, it would not be able to deliver anything malicious due to them not having access to the cryptographic keys to sign new repository metadata. The metadata is downgrade protected with a minimum version pinned to the app to prevent old repositories being used. In the signed repo metadata, the application ID, signing key hash, and minimum expected version for each app are available. This ensures a legitimate app install and prevents first installing an insecure outdated version. View quoted note →

Android applications are cryptographically signed by the developer of the application when they are packaged. When you install an application, the signing certificate is pinned by the operating system and trusted on first use (TOFU). This prevents an app with the same app ID (domain.company.application) having a different certificate be installed. This has a few benefits: - You ensure updates are only able to be delivered by the same entity, providing the signing certificates isn't compromised. - An app can't be tampered with since it will require being re-signed. - You can use the hash of the certificates as a form of app / developer verification. Outside of signing, apps are also protected by downgrade protections to prevent downgrade attacks. A limitation with TOFU is that it doesn't verify it an app is legitimate, only that it is different from the original install. App stores provide far more verification on an application being listed and are more likely to assure you getting a legitimate app than getting a random APK file off the internet. AppVerifier is an app by one of our app developers that lets you check the signing certificate hashes of an app. You can compare the signing hash with one the developer publishes with your own install to validate you have an authentic package. #GrapheneOS will eventually add this as a UI feature (e.g. in the install dialog) in the later future to not necessitate having an additional app. This information is heavily used to verify apps in an Alpha build app store called Accrescent which we'd like other app store apps to follow the model of. I will explain further about the workings of it later. Other app stores like F-Droid and recently Google Play compile the apps and/or sign them. The former only allowing own signings certificates if there is reproducible builds (a minimal amount). This is problematic, as it adds an additional trusted party. Apps should be exclusively signed by developers as a compromise of a shared signing certificate means a pwn of every app using that certificate. It also makes updates impossible should the apps be exited from the app store or if you want to get from another source. It is even more telling as F-Droid builds apps on extremely old infrastructure that missed features from processors added in the late 2000s - early 2010s.

One of our full time devs are working their resources on building our own text-to-speech and speech-to-text integration for GrapheneOS. None of the available apps are suitable for inclusion. None are modern enough aside from Sherpa and it has issues including high latency making it unsuitable for use with TalkBack. Our own implementation is going to be significantly better.

Worth noting, we have early access to upstream security patches ready for December. We also can get the early access to Android 16 QPR1 since it isn't in AOSP, but by the time we do this we'd probably have access to 16 QPR2. QPR1 comes in coming weeks. The issue is that the code is embargoed until released to AOSP. Only binaries can be released. We are looking at potentially making a separate binary-only stream of GrapheneOS with these early releases and features, but the audience here likely won't find it interesting since it isn't open source. It's purpose would be for reverse engineering purposes so devs can reverse engineer, make patches and other code from decompiling builds. I would assume most users wouldn't be using this version as their main operating system. View quoted note →

Regarding the recent situation with Proton Mail, I have nothing to comment that I haven't said countless times already. I would need to understand more context about what the users they suspended did, which is in the clouds of social media conflict right now. It is abnormal to suspend a researcher, so I personally would like to see a more formal response from Proton on their justifications -- especially since accounts were reinstated after the matter went public. In the meantime, let us go through a refresher your need-to-know on encrypted email providers. If you are aware already on how Proton Mail works technically and as a business, it should be of no surprise to know the following: - Email is not end-to-end encrypted. Proton Mail encrypts received emails from external domains when they arrive unencrypted. The only encryption is in the transit between the two email providers, NOT the individual users. In theory, a service provider could be legally compelled to intercept email traffic and keep the readable copy as they arrive. Only Proton to Proton emails are end-to-end encrypted. - "Zero-access encryption" is NOT "end-to-end encryption". - Providers suspend accounts on their own due diligence. Should be no surprise companies suspend accounts from reporting from sources like CERTs, ISACs, anti-spam registries etc. If an email provider can't read the mailbox, then this or email contents being reported is the most information they get. Don't act shocked when they aren't on your side. - Don't think irrationally: Removal of service is not at all related to information disclosure. Certain information you provide to the service cannot be encrypted in a way that is unreadable to the service, for example, email account recovery information. It wouldn't be possible to restore accounts using information they don't know. Understand what information you provide to a service provider. Overall: Don't use email for personal highly sensitive communications you believe could be disrupted by a service provider. If there is no way around this, encrypt the email contents and attachments yourself and leave a generic non-sensitive subject line so neither providers can read it. The same applies to self-hosting your own email. Use end-to-end encrypted messaging apps for communication. Keep emails for accounts. Mail providers with mailbox encryption like Proton and Tuta provide encryption as a protection mechanism against data breaches. Using such services are a reasonable choice for someone who needs an email provider with a focus on account security and requiring only the minimum amount of information required to function. But, they are not an opsec silver bullet.

#GrapheneOS version 2025091000 released. This release provides the entire October 2025 security patches EARLY. We are also packing Android 16 QPR1 backports as we wait for AOSP releases. We are also fixing a vulnerability the Linux kernel refuses to fix. • full 2025-10-01 security patch level • partially backport Android 16 QPR1 Pixel userspace device support: RIL, eSIM, TPU and NeuralNetworks (deprecated) • kernel (6.1): roll back recent upstream Android GKI dma-buf changes due to a few MTE crash reports • kernel (6.1, 6.6, 6.12): disable unused memory hotplug support • kernel (6.1, 6.6, 6.12): fix linear region randomization by dropping memory hotplug support (see the Project Zero issue where the upstream Linux maintainers decided not to fix the issue) • kernel (6.1): update to latest GKI LTS branch revision • kernel (6.6): update to latest GKI LTS branch revision • kernel (6.12): update to latest GKI LTS branch revision including update to 6.12.45 • Vanadium: update to version 140.0.7339.123.0 Information on vulnerability:

Project Zero

Releases | GrapheneOS

For #GrapheneOS users concerned on a full Android 16 QPR1 release. Android Authority has reported the source code for Android 16 QPR1 in AOSP will be released 'In the coming weeks':

Android Authority

Android 16 QPR1’s source code is nowhere to be found, but Google swears it’s coming

Google has yet to release the source code for Android 16 QPR1, sparking fears about the company's commitment to AOSP.

This delay is unprecedented. This information matches our own sources and communications. The general consensus is it SHOULD be released, but for some reason it hasn't been.

re: Apple Memory Integrity Enforcement Pixels have provided hardware memory tagging (MTE) support since the Pixel 8. GrapheneOS deployed it in production around a month after the launch of the Pixel 8 and we use it for the kernel and nearly the entire base OS. We use it for some third party apps and users can opt-in to using it for all. There have been multiple revisions of ARM MTE. FEAT_MTE4 (Enhanced Memory Tagging Extension) is the 4th generation of ARM MTE improvements, not the beginning of it. The baseline feature was already a game changer for defending devices. The improvements will make their way to devices providing it. Being able to leak data via side channels is a known issue with modern CPUs with many rounds of issues being discovered and addressed. ARM has been working on fully resolving it for MTE itself. Apple CPUs have had much more severe issues with side channels than Cortex, so it's a strange jab by them. Unlike iPhone users, #GrapheneOS users have been well protected by attacks from Cellebrite and other exploit development companies.

GrapheneOS Discussion Forum

Cellebrite Premium July 2024 documentation - GrapheneOS Discussion Forum

GrapheneOS discussion forum

Apple talks a big game but consistently fails to protect their users against broadly deployed exploits used at a large scale. ARM shipped MTE support multiple years before Apple in their Cortex cores. Yes, it was discovered to have a side channel usable by local attackers. This doesn't ruin it. MTE only has 4 bit tags which is a bigger weakness than the side channel. MTE still paves the way for stronger future features. Apple has far more severe side channels in their hardware which leak user data. It's strange to portray leaking tags as a severe issue ruining a feature when they've consistently downplayed the impact of endless side channels vulnerabilities directly leaking sensitive user data on iPhones and Macs.