GrapheneOS

Open source privacy and security focused mobile OS with Android app compatibility.

Website: https://grapheneos.org/
Forum: https://discuss.grapheneos.org/
X: https://x.com/GrapheneOS
GitHub: https://github.com/GrapheneOS

Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

NIP-05 Address

grapheneos_at_grapheneos.social@momostr.pink

Profile Code

nprofile1qqst8w3u2pzlhtueh6wtfk4f78tm4mk6hg8utwg4jeg3utah5uxa07gpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslp5jg4

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1kwarc5z9lwhen05uknd2nuwhhthd4ws0cku3t9j3rchm0fcd6luslse0nj

Show more details

Last Notes

2026-05-26 03:21:51 UTC

- reply

It's already good enough for a lot of use cases and blind users can now use a fresh install of GrapheneOS without help. It's good enough to get through the setup wizard to install Google Speech Recognition & Synthesis or eSpeak NG.
It matters a lot which device you're testing on since it might be twice as fast on a Pixel 10 than a Pixel 6. It solely runs on the CPU right now and Pixels don't have a great CPU. It will benefit a lot from hardware acceleration, especially on Pixels.

2026-05-26 03:17:52 UTC

- reply

It's a different type of software and is meant to become a competitive alternative to Google Speech Recognition & Synthesis. It has a lot of room for improvement including simply not reading newlines which can waste a lot of time if the text being passed to it doesn't have the whitespace stripped down.
It doesn't use hardware acceleration yet and was trained on a AMD RX 6600 prior to obtaining an RTX 5090. It can't be expected to keep up with Google's yet but it will get better.

2026-05-26 03:03:16 UTC

- reply

No, performance was a major focus for it. It already has much lower latency than the existing options we were comparing against and there's huge room for improvement. It's the first public experimental release of the software and it has quirks to resolve including treating newlines as significant where reading newlines takes time and creates a barely audible sound. It doesn't use any form of hardware acceleration yet either. You're expecting too much from the first experimental release.

2026-05-20 18:48:33 UTC

The first public release of GrapheneOS Speech Services is now available in our App Store. After installing it, it can be activated as a text-to-speech service by tapping it in Settings > System > Language & region > Speech > Text-to-speech output > Preferred engine and approving it in the dialog.

2026-05-10 16:09:18 UTC

- reply

Services shouldn't ban people from using arbitrary hardware and operating systems in the first place. Google's security excuse is clearly bogus when they permit devices with no patches for 10 years but not a much more secure OS. It's for enforcing their monopolies via GMS licensing, that's all.

2026-05-10 16:02:27 UTC

- reply

This isn't about security or any missing functionality. GrapheneOS can be verified via hardware attestation. Google bans using GrapheneOS for Play Integrity because we don't license Google Mobile Services and conform to anti-competitive rules already found to be illegal in South Korea and elsewhere.

2026-05-10 15:54:49 UTC

- reply

reCAPTCHA Mobile Verification will currently work with sandboxed Google Play on GrapheneOS but it clearly exists to provide a way for them to start using hardware attestation on systems without it. People without an iOS or Android device will be locked out when this is required even without that.

2026-05-10 15:50:33 UTC

- reply

Instead of governments stopping Apple and Google from engaging in egregiously anti-competitive behavior, they're directly participating in locking out competition via their own services. Requiring people to have an Apple device or Google-certified Android device is anti-competition, not security.

2026-05-10 15:49:24 UTC

- reply

Governments are increasingly mandating using Apple's App Attest and Google's Play Integrity for not only their own services but also commercial services. The EU is leading the charge of making these requirements for digital payments, ID, age verification, etc. Many EU government apps require them.

2026-05-10 15:45:11 UTC

- reply

It doesn't provide a useful security feature, but it does lock out competition very well. Services requiring Apple App Attest or Google Play Integrity are primarily helping to lock in Apple and Google having a duopoly for mobile devices. Play Integrity is more relevant due to AOSP being open source.

2026-05-10 15:41:25 UTC

- reply

Play Integrity API is highly insecure and it isn't particularly hard to temporarily bypass it. There are frameworks for spoofing the software checks and leaked keys for bypassing hardware attestation can be purchased. However, bypasses are getting harder and are becoming increasingly short lived.

2026-05-10 15:37:30 UTC

- reply

Google's Play Integrity API permits devices with no security patches for 10 years. The device integrity level can be bypassed via spoofing but they can detect it quite well and block it once it starts being done at scale. The strong integrity level requires leaked keys from TEEs/SEs to bypass it.

2026-05-10 15:35:55 UTC

- reply

Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit. It also bans using any other alternative. This isn't somehow specific to an AOSP-based OS. You can't avoid this by using a mobile OS based on FreeBSD instead. You'll just be more locked out.

2026-05-10 15:34:22 UTC

- reply

Control over reCAPTCHA puts Google in a position where they can require having either iOS or a certified Android device to use an enormous amount of the web. Google defines certification requirements for Android which includes forcing bundling Google Chrome, etc. It's enormously anti-competitive.

2026-05-10 15:32:04 UTC

- reply

Current media coverage for reCAPTCHA Mobile Verification misunderstands it and the impact of it. They're bringing a hardware attestation requirement to Windows, desktop Linux, OpenBSD, etc. by requiring a QR scan from a certified smartphone to pass reCAPTCHA in some cases. They could expand it more.

2026-05-10 15:26:25 UTC

- reply

Banking and government services increasingly require using a mobile app where they can use attestation to force using an Apple or Google approved device and OS. Apple's privacy pass, Google's 'cancelled' Web Environment Integrity and now reCAPTCHA Mobile Verification are bringing this to the web.

2026-05-10 15:20:30 UTC

- reply

Google's reCAPTCHA is planning an approach where they use Privacy Pass on Apple hardware, their own approach on Google Mobile Services Android devices and a QR code scanning system to require an iOS or Google certified Android device for Windows and other systems:
https://support.google.com/recaptcha/answer/16609652

2026-05-10 15:17:22 UTC

- reply

Apple's Privacy Pass brought hardware attestation to the web to help with passing captchas on their own hardware. Many people saw that as harmless since few sites would be willing to lock out non-Apple-hardware users. Apple and Google are both likely to bring broader hardware attestation to the web.

2026-05-10 15:10:07 UTC

- reply

The purpose of these systems is disallowing people from using hardware and software not approved by Apple or Google. This is wrongly presented as being a security feature. Banks and government services are the main ones adopting it but Apple and Google are encouraging every service to use it.

2026-05-10 15:08:32 UTC

- reply

Google's Play Integrity API requires hardware attestation for the strong integrity level and is gradually phasing in requiring it for the more commonly used device integrity level. Apple already has it as a requirement. Over the long term, this will increasingly lock out hardware and OS competition.

2026-05-10 15:06:36 UTC

Apple and Google are gradually expanding their use of hardware-based attestation. They're convincing a growing number of services to adopt it. Google's Play Integrity API and Apple's App Attest API are very similar. Apple brought it to the web via Privacy Pass, which Google intends on doing too.

2026-05-09 14:38:39 UTC

- reply

> You have a direct interest in keeping people on Android.
No, our goal is people moving from Android and iOS to GrapheneOS. Your claim doesn't make sense.
> your business model
GrapheneOS isn't a business and has no business model.
> So of course you're going to defend the status quo.
We're doing nothing of the kind. We've been working on this for a very long time as a freely available open source project. What's your motivation for grasping at straws trying to undermine us?

2026-05-09 14:29:01 UTC

- reply

> I'm not saying a new mobile OS alone would magically remove the Play Services requirement.
Your proposal would make things substantially worse, not better.
> But rejecting the duopoly means rejecting schemes like this reCAPTCHA requirement as well.
What you're actually doing is proposing giving up and throwing away a viable alternative.
> But let's be frank, you're a business.
No, GrapheneOS isn't a business. It's an open source project with a non-profit supporting it.

2026-05-08 23:55:59 UTC

- reply

You aren't going to avoid a requirement to have either an iOS or Google Mobile Services Android device by using a non-AOSP-based Linux distribution. How would throwing away a whole lot more compatibility with apps/services avoid that requirement? It won't.
GrapheneOS is a mobile Linux distribution. Linux doesn't mean using glibc, systemd and GNOME. Moving to drastically less private and secure desktop software wouldn't be progress. That's the opposite direction from GrapheneOS.

2026-05-06 16:05:18 UTC

- reply

The anti-tampering checks done by these are inherently insecure and most are incorrect which leads to compatibility issues with future Android versions, GrapheneOS and even OEM Android forks. The reason we had to adjust the initial call stack for secure spawning to match the standard one is because some apps insecurely try to detect tampering via method hooking by checking the call stack. We can make a similar change for their low-level checks of the data in certain memory blocks too.

2026-05-06 15:53:15 UTC

- reply

For now, you can disable secure spawning if you need to use this app on GrapheneOS. Turning it off disables it for every system process implemented with app_process including system_server and various privileged components such as the main Bluetooth process. We could provide a more granular way to disable it. We didn't anticipate anti-tampering checks causing compatibility issues and the toggle was only added as a way to test memory usage and app spawning time without it enabled.

2026-05-06 15:50:52 UTC

- reply

Various banking apps used to ban GrapheneOS because the secure spawning feature had a different initial Java call stack. We addressed this by making the call stack match for secure spawning which fixed most of the compatibility issues. There are still minor differences which are possible for apps to detect if they're checking implementation details such as low-level system properties, the address space layout or how much is initially preloaded. We plan to work around all of that too.

2026-05-06 15:47:40 UTC

- reply

Our secure spawning feature was never expected to cause any compatibility issues. We aren't aware of any legitimate compatibility issues as opposed to apps doing incorrect anti-tampering checks which make incorrect assumptions about non-stable OS implementation details. Due to these incorrect checks, these apps frequently break with new major Android OS releases. They often don't address it during Android's Developer Preview or Beta testing but rather weeks after the Stable release.

2026-05-06 15:45:18 UTC

- reply

Disabling secure spawning reverts to the standard Android Zygote-based spawning model where apps start as clones of the Zygote address space and memory. The Zygote spawning model reduces security by sharing the same state for probabilistic exploit protections including hardware memory tagging (MTE), ASLR, heap canaries, heap randomization and more. Android has a workaround to avoid weakening the security of stack canaries (SSP) but the rest can't really be worked around for it.

2026-05-06 15:38:58 UTC

- reply

This app works on GrapheneOS with the exploit protection compatibility mode disabled and secure spawning disabled. The app does incorrect anti-tampering checks which are incompatible with our secure spawning feature due to it causing small differences in the address space and properties checked by their anti-tampering. The exploit protection compatibility mode has to force enable secure spawning to disable hardened_malloc and the 48-bit address space so it has to be disabled.

2026-05-05 16:10:14 UTC

- reply

It's not unclear why you want the far less private, secure, functional and compatible closed source SailfishOS software stack over open source AOSP.
Volla, Jolla and Murena devices have drastically worse privacy and security than an iPhone. Vivaldi is recommending people move from hardware and software with very strong privacy and security protections to platforms not doing the bare minimum including not providing standard privacy/security patches and protections.

2026-05-05 16:06:57 UTC

- reply

Your claim Google is working to make GrapheneOS devices useless is untrue. If you mean the Play Integrity API, that impacts any OS regardless of whether it's based on the Android Open Source Project (AOSP).
SailfishOS and traditional desktop Linux operating systems are drastically less private and secure than AOSP. Linux doesn't mean glibc, systemd and GNOME. AOSP and GrapheneOS aren't somehow not Linux due to larger userspace differences from desktop Linux.

2026-04-22 23:51:28 UTC

Most of our users aren't active on these social media platforms and don't receive news about GrapheneOS beyond our release notes. Hundreds of thousands of people use it as a daily driver without closely following the project. We plan to reduce our dependence on these platforms.

2026-04-10 19:35:10 UTC

- reply

Here's Gaël Duval linking to harassment content on a neo-nazi conspiracy website targeting our founder with fabricated stories:
https://archive.is/SWXPJ
https://archive.is/n4yTO
This content is based around existing harassment content from another company attacking us (Copperhead). Copperhead lost their war on GrapheneOS and we're wrapping up their legal defeat, but the lies and harassment they started is still ongoing and Duval engages in it.

2026-04-10 18:01:17 UTC

- reply

The only way you're going to convince us to post less about it is putting in work to address it yourself and getting others to do that too. The only thing you'll achieve posting replies saying we shouldn't respond to these attempts to mislead people about GrapheneOS is us posting more about it as we're doing right here. You aren't going to get the result you want this way. There's a way for you to get the result you want by helping so we don't have to do as much.

2026-04-10 17:59:34 UTC

- reply

GrapheneOS will succeed based on merit. Our focus is making GrapheneOS better as it has always been. If we were left alone to do our work in peace then we wouldn't post threads debunking the attacks and would post more about other things including a lot more posts about our ongoing work. If people want that then they can help debunk the attacks so we feel much less need to do it because it's already being heavily done by others. Otherwise, we'll continue doing it.

2026-04-10 17:49:30 UTC

- reply

GrapheneOS has been enormously harmed by years of companies misleading people about it. There's a concerted effort by /e/, Murena and their supporters to mislead people into believing GrapheneOS isn't a privacy project and that they wouldn't benefit from the major privacy and security improvements it provides. @npub15r7…62av is directly peddling talking points from Gaël Duval aimed at steering people away from GrapheneOS to insecure Murena products. This isn't a minor issue.

2026-04-10 17:35:47 UTC

- reply

We aren't finished responding to it with this thread. We're going to be posting it on our forum and other social media platforms too. We're going to be responding beyond what we're already posted. We've been actively finding and archiving more cases of /e/, Murena and Gaël Duval attacking GrapheneOS by claiming it's only useful to criminals and spies which they've said directly multiple times along with often alluding to it. We have a lot more than that one video clip to use.

2026-04-10 17:30:26 UTC

- reply

You've likely already read our previous thread where we directly addressed these inaccurate claims. Here's the relevant part of the thread:
https://grapheneos.social/@GrapheneOS/116354014750484314
We're repeatedly published content addressing people inaccurately claiming GrapheneOS is a security project rather than a privacy project. He has read multiple of these threads and knows what we've said. He's saying what he did in the interview despite that. This isn't about getting any technical details wrong.
#note1ws9…4x6l

2026-04-10 17:27:28 UTC

- reply

He directly responded to the thread we published 4 days ago addressing Murena once again claiming the kind of privacy and security hardening work done by GrapheneOS and iPhones is only useful to criminals and spies. In that thread, we directly addressed these repeated inaccurate claims about the purpose, goals and approach of GrapheneOS which wrongly portray it as a security project rather than a privacy project. His claims in the interview are more than egregiously inaccurate.

2026-04-10 14:26:20 UTC

The claims made about GrapheneOS in this interview are extremely inaccurate. It heavily misrepresents the purpose of GrapheneOS and what we've worked on for years. The claim GrapheneOS is a security project rather than a privacy project is misinformation. Contacts are specifically brought up and yet our Contact Scopes feature is ignored. @fla knows GrapheneOS is a privacy project. He replied to a thread with our response to this misinformation only 4 days ago...
https://piaille.fr/@projetslibres_podcast/116379561169492214
#note1dg3…tqhl

2026-04-10 13:39:05 UTC

- reply

The claims made about GrapheneOS in this interview are extremely inaccurate. It heavily misrepresents the purpose of GrapheneOS and what we've worked on for years. The claim GrapheneOS is a security project rather than a privacy project is misinformation. Contacts are specifically brought up and yet our Contact Scopes feature is ignored. @npub15r7…62av knows GrapheneOS is a privacy project. He replied to a thread with our response to this misinformation only 4 days ago...

2026-04-09 17:09:57 UTC

- reply

GrapheneOS doesn't have a centralized push notification service integrated into the OS. If you install Signal in a profile where you haven't installed sandboxed Google Play, it will only use Signal's own servers for push.
Signal's push implementation isn't power efficient and will drain a lot more power than Google's Firebase Cloud Messaging. However, there's a fork of Signal called Molly supporting using an arbitrary push provider with efficient implementations available.

2026-03-24 09:30:04 UTC

Vanadium version 146.0.7680.164.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/146.0.7680.164.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/33474-vanadium-version-146076801640-released
#GrapheneOS #privacy #security #browser

2026-03-24 07:00:32 UTC

- reply

It's likely we'll support the 2027 variant of the razr ultra.

2026-03-24 05:56:39 UTC

- reply

Firefox entirely lacks process sandboxing on Android. Firefox rolled out incomplete site isolation providing protection against data being leaked via side channels through not having it in-process. It does not implement sandboxing site isolation required to protect against more than side channels. It doesn't have sandboxing so it can't protect against anything once a remote code execution exploit occurs. It also lacks similar JavaScript VM sandboxing and many other important protections.

2026-03-23 19:12:59 UTC

- reply

No, it's entirely possible to distribute a signed list of trusted roots and verified boot keys from one or more organizations. The proper approach to implementing a third party certification system for devices and operating systems would be directly using the Android hardware attestation API and distributing signed data for use with it. This would enable using multiple sources of that data and not being locked into it. An organization doing certification should still be neutral.

2026-03-22 22:09:40 UTC

- reply

Lenovo is a publicly traded company with 31% of the shares are owned by Legend Holdings.
Legend Holdings is a publicly traded company with 29% of the shares owned by the Chinese Academy of Sciences.
That works out to the Chinese Academy of Sciences owning around 9% of Lenovo. They're far from owning the majority of it.
We're continuing to support Pixels which are the only Android devices from a major OEM based in the US. Smaller brands are white labelled ODM phones.

2026-03-22 20:29:47 UTC

- reply

People can buy the devices without GrapheneOS and install it themselves in any region where that's an issue. Motorola devices with GrapheneOS preinstalled is something we want but it doesn't have to happen right away and doesn't need to happen everywhere for the partnership to be highly successful. Pixels are sold in 33 countries which doesn't include many countries outside North America and Europe.

2026-03-22 13:55:02 UTC

- reply

Revoking Camera, Microphone and Location access automatically is a standard Android feature via granting one-time access instead of persistent access. It revokes it 1 minute after the app isn't in the foreground anymore. The global toggles are problematic to begin with since enabling the functionality globally will allow every app which you've granted the permissions to start using those again, although at least it's only foreground access for Camera, Microphone and by default for Location.

2026-03-21 14:06:37 UTC

- reply

Heavily using Google apps and services doesn't ruin using GrapheneOS. People still get major privacy and security benefits. Migrating away from Google apps and services along with other privacy invasive services can be done over the long term. If migrating away from it is a high priority goal with willingness to be dealing with it, then it's a good idea to start out with it in a dedicated work profile or Private Space.
https://grapheneos.social/@GrapheneOS/116267529664234349
#note1up3…2yn0

2026-03-21 14:03:18 UTC

- reply

It sounds like you do want to minimize usage of Google Play, so set up a dedicated profile for it. Work profile or Private Space is most convenient since they're nested but you could also use a secondary user. Private Space is essentially a nested secondary user. Work profiles are similar but have to be managed by an device policy management app. Shelter is an open source one for local management which many people use. Private Space + work profile gives 2 nested profiles.

2026-03-21 14:01:49 UTC

- reply

You aren't ruining GrapheneOS by using sandboxed Google Play in the Owner user. They're regular sandboxed apps including in the Owner user and you can restore it back to the default of only having the Network permission granted while retaining compatibility with nearly every Play Store app. Network and Unrestricted battery mode are all it needs to provide nearly all functionality apps need. We reroute location requests to Google Play to the OS location service by default.

2026-03-21 14:00:31 UTC

- reply

Their app likely depends on Google Play for push notififications which requires giving it Unrestricted battery mode. If you want to minimize your usage of Google Play, remove it in the Owner user and set up a dedicated work profile or Private Space for it. A work profile is a good option if you want to save Private Space for the main purpose of having private apps/data which remain at rest while using the phone. Google Play is still sandboxed in Owner on GrapheneOS though.

2026-03-21 13:58:16 UTC

- reply

It doesn't matter at all that you did that if they already had your contacts anyway. You have to migrate to avoiding using them for sync if you want to avoid them having those anyway. Just get rid of it if you don't want it and make a dedicated work profile or Private Space for apps depending on Google Play if you want to keep it separate. You'll probably want apps depending on it but you don't need to give it any permissions beyond Network and it can be in another profile.

2026-03-21 13:56:44 UTC

- reply

VCF export/import should work fine. It's possible the app you used for exporting did it in a format incompatible with AOSP Contacts but you can use a different app to export/import on both ends. There are also various apps you can use for end-to-end encryption contacts sync/backup.
You didn't need to give sandboxed Google Play a bunch of permissions to use their contacts sync but it's still far less invasive than regular privileged Google Play services even with those.

2026-03-21 04:21:14 UTC

- reply

Yes, Pixels are going to remain supported and it will be a while before the Motorola devices launch. We launched experimental support for the recently launched Pixel 10a yesterday.
The initial devices with GrapheneOS support from Motorola will be 2027 flagships. We'll add support for new devices each year along with expanding to cheaper devices once those meet the requirements.

2026-03-21 02:01:36 UTC

- reply

That's what this change does.

2026-03-20 21:11:50 UTC

GmsCompatConfig version 168 released:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-168
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/33369-gmscompatconfig-version-168-released
#GrapheneOS #privacy #security #gmscompat

2026-03-20 20:42:17 UTC

GrapheneOS version 2026032000 released:
https://grapheneos.org/releases#2026032000
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/33367-grapheneos-version-2026032000-released
#GrapheneOS #privacy #security

2026-03-20 19:26:42 UTC

- reply

Pixel 6a is fully supported and works well. It's part of the oldest generation of supported devices and has an update guarantee from the OEM until at least July 2027.
Some of the laws we're referencing were already passed. It isn't going to result in any changes to GrapheneOS and it will remain available everywhere. Many other projects are making changes due to it or blocking downloads in regions passing these laws but we've determined there's no need for us to do anything.

2026-03-20 18:49:37 UTC

- reply

Pixel stock OS no longer has nearly as many changes in the monthly releases beyond the security patch backports. QPR1 and QPR3 will be smaller releases than previously and stock Pixel OS exclusive. These releases are only relevant to GrapheneOS for Pixel support. We don't need to deal with it for another device.
GrapheneOS has security preview patch access already which we didn't receive from Motorola but rather from another OEM not working on devices supporting GrapheneOS.

2026-03-20 18:47:01 UTC

- reply

That's not how Android updates work. There was previously 1 major yearly release which was changed in 4 major quarterly releases and has been reduced down to 2 major releases per year. Those are made available to OEMs and published to the Android Open Source Project. There are monthly security backports to the major releases from the past around 3 years which are also pushed to the Android Open Source Project. Pixel stock OS is separate from what OEMs use which is the AOSP code.

2026-03-20 16:18:22 UTC

- reply

Fairphone has made it very clear they don't care about providing serious privacy or security. We aren't going to be supporting their devices or working with them. They already chose a different path incompatible with working with us.
https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

2026-03-20 15:49:21 UTC

- reply

There's a huge audience interested in having private and secure devices. Providing the bare minimum of standard privacy/security patches and important standard hardware-based defenses rules out nearly all Android devices. iPhones have much better security than the vast majority of Android devices. Out of the Android devices supporting installing another OS, the only ones with similar security protections are Pixels. People who want privacy/security mostly buy iPhones.

2026-03-20 15:26:21 UTC

- reply

GrapheneOS is a privacy and security project. It isn't elitist to have a reasonable set of hardware requirements including proper driver/firmware updates and important hardware-based security features we need to protect against widespread real world exploits. Similarly to iPhones, GrapheneOS devices are far more secure than using a traditional desktop OS. The security standards for mobile are much higher than what passes for acceptable for laptops and desktops.

2026-03-20 15:23:48 UTC

- reply

GrapheneOS is a highly usable production quality OS with broad app compatibility. It isn't a niche choice only for people who are highly committed to privacy. It's very usable as a daily driver. The vast majority of Android apps are fully functional on GrapheneOS. In practice, the only apps unavailable on GrapheneOS are a tiny subset banning using any alternate OS with the Play Integrity API or similar methods. 90% of banking apps work and 99.999% of other apps

2026-03-20 15:20:50 UTC

- reply

GrapheneOS is privacy project and privacy depends on security. We have very reasonable hardware security requirements which are listed at https://grapheneos.org/faq#future-devices. We only expect industry standard updates and security features. The only non-Pixel Android devices meeting these requirements don't allow using another OS. We're officially partnered with Motorola and they're making devices meeting these requirements with official GrapheneOS support.
https://grapheneos.social/@GrapheneOS/116159602850585685
#note1eyc…unsd

2026-03-20 14:46:05 UTC

- reply

Pixels are the only currently available devices meeting the security requirements for GrapheneOS.
GrapheneOS has an official long term partnership with Motorola and will support many of their future devices:
https://grapheneos.social/@GrapheneOS/116159602850585685
We aren't lowering our standards but rather their devices are being improved to meet our requirements. Existing devices from every non-Pixel Android OEM lack important security features and don't provide the level of driver/firmware updates we need.
#note1eyc…unsd

2026-03-20 14:41:45 UTC

- reply

GrapheneOS has an official long term partnership with Motorola and will support many of their future devices, not one. It will support multiple new Motorola devices every year. We aren't lowering our security requirements but rather their devices are being improved to meet our requirements. The reason GrapheneOS won't support their currently available devices is because those don't meet our security requirements. Currently, only Pixels meet our requirements.
https://grapheneos.social/@GrapheneOS/116159602850585685
#note1eyc…unsd

2026-03-20 11:38:02 UTC

GrapheneOS will remain usable by anyone around the world without requiring personal information, identification or an account. GrapheneOS and our services will remain available internationally. If GrapheneOS devices can't be sold in a region due to their regulations, so be it.

2026-03-20 11:22:28 UTC

- reply

It will be included in our next regular OS release.

2026-03-20 11:21:50 UTC

- reply

> The fact is Google could also go out to of their way to require a version of this that will block these apps from running on your OS.
Play Integrity API is clearly illegal and substantial progress was being made to dealing with it. Having another anti-competitive system banning using arbitrary hardware and software based in Europe will help to legitimize and spread attestation to more apps.
> Perhaps it’s time to bury the axe?
Volla is welcome to discontinue Unified Attestation.

2026-03-20 11:19:57 UTC

- reply

> Doesn’t that seem a bit farfetched?
Nothing about it is farfetched.
> You don’t want to support it, fine.
No, we don't want these companies further degrading app compatibility with arbitrary options including GrapheneOS which is what their system is going to do.
> You rather trust the whims of Google than these companies, fine.
This is an outrageous misrepresentation of our position. We've been actively fighting and succeeding against the Play Integrity API for years now.

2026-03-19 20:37:12 UTC

- reply

Currently, 90% of European banking apps can be used on GrapheneOS including many supporting tap-to-pay without Google Pay. Unified Attestation will reduce the compatibility of these apps. Each app adopting it would stop working on GrapheneOS and many other systems. It's the opposite of how you're portraying it. It's a system to reduce the compatibility of these apps with arbitrary systems to instead only permit using products from Volla and other participants in the cartel.

2026-03-19 20:35:17 UTC

- reply

Unified Attestation is entirely built on top of the standard Android hardware attestation service. The sole purpose it serves is to centralize control over what's allowed to be use. It exists so that the companies involved can convince apps to adopt their own API for verifying devices where they permit their own products while forbidding everything else. It has no legitimate purpose over using standard Android hardware attestation API which is fully usable outside Android too.

2026-03-19 20:33:31 UTC

- reply

You appear to be confusing Jolla and Volla with each other. Those are completely different companies. Jolla's partnership and ownership by the Russia government from 2015 through 2023 is well documented public information. What do you expect to be proven about something which was very openly acknowledged by them? Their bankruptcy restructing in 2023 got rid of Russia's ownership of Jolla but doesn't change that it's a largely closed source OS which was developed with that regime.

2026-03-19 20:30:49 UTC

- reply

No, GrapheneOS is a privacy project. It's focused on privacy above everything else. Privacy depends on security.
Privacy does not mean specifically avoiding Google services while using more privacy invasive services. Your reasoning for why Curve isn't a private option is extremely wrong. It's not the reliance on Google Play services which makes it bad for privacy.
You're presenting statements from an account not belonging to GrapheneOS or any of our team members as from us...

2026-03-19 20:28:00 UTC

- reply

> It’s obvious to me that GOS is not really about de-googling, but rather to harden the security of Android.
GrapheneOS is a privacy project. It's focused on privacy above everything else. Privacy depends on security.
You're presenting posts from an account which doesn't belong to GrapheneOS or any of our team members as if it's from us...
> Where I find it a bit discomfortable is the constant accusations that others are scammers/lying.
They should stop doing it.

2026-03-18 23:25:07 UTC

Vanadium version 146.0.7680.153.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/146.0.7680.153.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/33290-vanadium-version-146076801530-released
#GrapheneOS #privacy #security #browser

2026-03-18 23:24:45 UTC

- reply

It's nearly certain that it's a Volla employee and we have a good idea of exactly who it is too since we've seen their posted on LinkedIn and communicated with them. We know their writing style from LinkedIn. They had non-public information about when they contacted us.
https://mastodon.social/@vollaficationist/116250746129876535
#note1q28…5d0q

2026-03-18 21:55:19 UTC

- reply

That's the same service as archive.ph. They have a bunch of separate proxies with different TLDs.

2026-03-18 20:48:45 UTC

- reply

There's no need for this Unified Attestation API as a layer on top of Android hardware attestation. There's no need for having a single centralized source of what's allowed. Apps can choose which sources of what's allowed they want to use with the Android hardware attestation API already. Each OS can release a signed list of their verified boot keys and multiple orgs can collect those with ongoing checks. Companies selling devices and operating systems shouldn't control it.

2026-03-18 20:47:07 UTC

- reply

Apps insisting on checking the device and OS can already use the hardware attestation API. It doesn't require querying a service about what's allowed, they can decide themselves. It's entirely possible for an actually neutral organization to implement reasonable standards with ongoing checks for those without delaying OS releases where the standard hardware attestation API is used with signed lists of allowed roots and verified boot keys they release. That would enable multiple orgs.

2026-03-18 20:39:35 UTC

- reply

GrapheneOS provides far better app compatibility than they do and that's not going to change. They're not going to be successful at pushing this system. They've already massively shot themselves in the foot with their sockpuppet account posting conspiracy theories that we supposedly aren't actually based in Canada but rather are some branch of the US state.

2026-03-18 20:24:05 UTC

- reply

Why do you accept several European companies making a system which permits using their products but not GrapheneOS? GrapheneOS will not participate or comply with their demands so it won't be allowed. That means they'll be permitting their products with poor security while not permitting a far more secure option. It's not legitimate for a group of companies to come together to make a system permitting the products of the companies participating and not alternatives. That's not legal.

2026-03-18 20:08:08 UTC

- reply

Pinning-based attestation is a useful security feature for protecting users and has little potential for abuse to prevent competition and enforce authoritarian laws. Root-based attestation is what causes those problems. Root-based attestation has poor security since it depends on none of the TEE/SE implementations getting exploited with their keys extracted. Not much of a security feature when any leaked key can be used to bypass it.

2026-03-18 20:06:30 UTC

- reply

Being able to take away compatibility with banking and government apps based on a system imposing arbitrary rules with certification required for each release is authoritarian. Regardless of the motivation for building this kind of system, the end result is a powerful tool for a police state. Root-based attestation is inherently anti-competitive and primarily useful for controlling people rather than protecting people.

2026-03-18 20:05:05 UTC

- reply

Attestation enables them to enforce it. Otherwise, people can import devices not complying with the rules they place on devices sold within Europe. Banning people from using devices from elsewhere is far more extreme and oppressive so that's a lot less likely. It's also far harder to enforce and if things have gotten that bad then many people are going to be unintentionally breaking oppressive laws regardless.

2026-03-18 19:55:13 UTC

- reply

If companies insist on permitting only certain devices and operating to be used then the system should be one that's distributed around the world with multiple neutral organizations not tied to the companies making devices or governments. However, delaying updates for certification is inherently anti-security. It would be impossible to quickly ship security patches without breaking compatibility with many important apps.

2026-03-18 19:53:30 UTC

- reply

It has everything to do with a centralized attestation system. Once this system starts being adopted, the EU can require it for banking/government apps as they began the process of doing with the Play Integrity API. They can then hijack it and begin enforcing their own requirements such including disallowing encryption without backdoors. There should be no organization in charge of which devices and operating systems are allowed.

2026-03-18 19:51:16 UTC

- reply

We made the mistake of using Wayback Machine to keep archives of attacks on the GrapheneOS project and companies engaging in blatant scamming. It backfired when they removed the archives upon request. We've been using archive.today for years to keep archives due to not trusting Wayback Machine to preserve what we archive with it. It's quite bad if that's lost and there isn't an alternative to it.

2026-03-18 19:46:37 UTC

- reply

We're open to suggestions on a better archiving site since there are some complaints about the one we've been using. archive.org has repeatedly removed archives upon request by companies covering up what they've done to GrapheneOS so their service isn't acceptable.

2026-03-18 19:44:04 UTC

- reply

Do you have any alternative to use instead? archive.org will remove content upon request and we'd have archives we created deleted upon request from the companies which then subsequently denied it ever happened and have convinced a lot of their supporters it never did.

2026-03-18 19:35:17 UTC

- reply

Here's an archive preserving all of the posts from this account clearly run Volla:
https://archive.ph/LhddH
It has the whole history of how it was used to promote it pretending to be a supporter with inaccurate marketing to the current outrageous conspiracy theory attacks.

2026-03-18 18:21:32 UTC

- reply

We'll put our support behind a ban on root-based attestation as long as pinning-based attestation is still allowed. Pinning-based attestation doesn't have the same issues with being used to restrict competition and user choice. Our Auditor app is primarily based around pinning-based attestation with little faith put in the initial root-based attestation. A single leaked key from the least secure devices can be used to bypass root-based attestation. It's absolutely not a serious security feature.

2026-03-18 18:19:18 UTC

- reply

GrapheneOS will fight against attempts by the Canadian government to take control over what people are allowed to use on their devices rather than building a system to enable it. Volla is building a system governments will be able to use to control which hardware and software people are allowed to use. The only usage of attestation should be to protect users as our Auditor app does, not to control what they can use as a growing subset of banking and government apps are doing. That should stop.

2026-03-18 18:16:14 UTC

- reply

GrapheneOS exists for the purpose of creating highly private and secure devices which are highly usable and compatible with all of the apps people want to use. GrapheneOS doesn't exist to provide a Canadian smartphone OS and eventually hardware. It's based in Canada because it was a pragmatic decision and we believe it's currently a better location for privacy projects than the US or EU. If that significantly changes, we're open to creating a non-profit elsewhere and moving our operations there.

2026-03-18 18:10:40 UTC

- reply

GrapheneOS is based in Canada but we don't promote it based around it being based in Canada. We're willing to move our non-profit and operations elsewhere in the future if Canada ever passes laws incompatible with our goals. It's based in Canada because it was practical rather than as a core value or approach of GrapheneOS. If Canada goes down the same path as the EU and starts passing laws we cannot accept, then we'll leave Canada rather than ruining GrapheneOS. They won't do that with the EU.

2026-03-18 18:08:44 UTC

- reply

These companies MUST NOT be allowed to successfully seize control over the compatibility of European banking/government apps with mobile devices via Unified Attestation. These companies have a view of privacy based around protecting people from Google and the US government rather than privacy from corporations and governments as a whole. They even market themselves as providing so-called digital sovereignty by giving European governments access and control instead of the American government.