GrapheneOS

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

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

NIP-05 Address

GrapheneOS@grapheneos-social.mostr.pub

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsc6v2t3

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Show more details

Last Notes

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

@nprofile…5ldk It's likely we'll support the 2027 variant of the razr ultra.

2026-03-24 05:56:39 UTC

- reply

@nprofile…xsvx 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-24 05:56:22 UTC

- reply

@nprofile…xsvx Firefox entirely lacks sandboxing on Android. Firefox has 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-24 05:52:39 UTC

- reply

@nprofile…xsvx Firefox entirely lacks sandboxing on Android. Firefox has rolled out incomplete site isolation providing protection against data being leaked via side channels through not having it in-process. It does not implement strict site isolation required to protect against more than side channels. It doesn't have sandboxing on Android so it can't protect against anything once a remote code execution exploit occurs. Complete lack of sandboxing on Android is one aspect of it being far less secure.

2026-03-22 23:20:59 UTC

- reply

@nprofile…fmlg No, these apps are going out of the way to ban using operating systems not licensing Google Mobile Services. Most apps are going to do this and users can pressure them to permit GrapheneOS which has happened successfully with a lot of these apps already. You should send them https://grapheneos.org/articles/attestation-compatibility-guide and pressure them to permit GrapheneOS. We show a notification when apps use the Play Integrity API as X does to help with this.

2026-03-22 20:29:47 UTC

- reply

@nprofile…fwu9 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 20:27:52 UTC

- reply

2026-03-22 13:55:02 UTC

- reply

@nprofile…9x99 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

@nprofile…tv8l @nprofile…qtyy @nprofile…fgrk
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

2026-03-21 14:06:21 UTC

- reply

2026-03-21 14:03:18 UTC

- reply

@nprofile…qtyy @nprofile…fgrk 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

@nprofile…qtyy @nprofile…fgrk 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

@nprofile…qtyy @nprofile…fgrk 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

@nprofile…qtyy @nprofile…fgrk 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

@nprofile…qtyy @nprofile…fgrk 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

@nprofile…g0lg 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 04:20:38 UTC

- reply

@nprofile…g0lg Yes, Pixels are going to remain supported and it will be a while before the Motorola devices launch. 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

@nprofile…7kfx 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

@nprofile…rpyy 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

@nprofile…kfh0 @nprofile…9tr7 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

@nprofile…kfh0 @nprofile…9tr7 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

@nprofile…slwy 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 16:16:17 UTC

- reply

@nprofile…lthu @nprofile…9tr7 https://grapheneos.social/@GrapheneOS/116262395412236234

2026-03-20 15:49:21 UTC

- reply

@nprofile…9tr7 @nprofile…qq64 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

@nprofile…9tr7 @nprofile…qq64 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

@nprofile…qq64 @nprofile…9tr7 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

@nprofile…qq64 @nprofile…9tr7 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

2026-03-20 14:46:05 UTC

- reply

@nprofile…ju3h 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.

2026-03-20 14:41:45 UTC

- reply

@nprofile…9tr7 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

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

@nprofile…85r0 It will be included in our next regular OS release.

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-10 16:57:09 UTC

- reply

@nprofile…hupg Why is it that you take issue with how we're defending ourselves from this but don't take issue with their inaccurate claims about GrapheneOS and harassment towards our team? Have you ever spoken out about the harassment directed towards our team? Have you ever criticized any of these companies for the objectively false claims they make about GrapheneOS and our team? Why is it that your issue is only with us for how we choose to defend ourselves and respond to these attacks?

2026-03-10 16:55:25 UTC

- reply

@nprofile…hupg These companies don't stick to falsely marketing their products. They mislead people about GrapheneOS to steer people away from it and towards their products. Their products do not provide what they claim and their claims about GrapheneOS are highly inaccurate. They haven't kept to making inaccurate claims about GrapheneOS either. Both Duval and Braxman have repeatedly engaged in absolutely vile personal attacks where they push fabrications with the clear goal of increasing harassment.

2026-03-10 16:53:52 UTC

- reply

@nprofile…hupg We don't appreciate the founder and CEO of Murena repeatedly posting personal insults and libelous claims about the founder of GrapheneOS. That includes him repeatedly spreading harassment content. That includes doing things like linking to a neo-nazi conspiracy website making attacks on our founder based on fabrications.
https://archive.is/SWXPJ
https://archive.is/n4yTO
iodé is partnered with Robert Braxman who has pushed relentless fabrications about GrapheneOS to promote his products.

2026-03-10 16:52:06 UTC

- reply

@nprofile…hupg We don't appreciate Murena spending years falsely claiming GrapheneOS isn't a privacy project, isn't usable by regular people and lacks broad app compatibility. It's better at all of those things than their products, especially privacy and app compatibility. App compatibility is the main factor of usability in practice, and we're gradually working on providing a nicer out-of-the-box experience without simply bundling a bunch of third party apps with problematic approaches to privacy.

2026-03-10 16:49:13 UTC

- reply

@nprofile…zfu7 @nprofile…03zk You're continuing to lie about us and misrepresent what's actually happening. Our efforts at countering the false marketing from these groups and their recent efforts to put themselves in control of which operating systems people are allowed to use for European banking and governments apps are working out fine. Your efforts to attack us by misrepresenting what we're saying and doing along with the context for it are fruitless and not achieving anything. All you've gained is a ban.

2026-03-10 15:39:19 UTC

- reply

@nprofile…v8ld We're opposed to it on privacy grounds rather than based on whether functionality is implemented using a neutral network. We don't have a fundamental issue with using entirely local neural networks for specific tasks such as auto-brightness, text-to-speech, speech-to-text, etc. However, GrapheneOS is open source and that means any included features implemented that way need to have open source training data rather than being so called open models which are in fact closed source.

2026-03-10 15:38:40 UTC

- reply

@nprofile…v8ld We're opposed to it on privacy grounds rather than based on whether functionality is implemented using a neutral network. We don't have a fundamental issue with using a locally implemented neural network for specific tasks such as auto-brightness, text-to-speech, speech-to-text, etc. However, GrapheneOS is open source and that means any included features implemented that way need to have open source training data rather than being so called open models which are in fact closed source.

2026-03-10 15:37:22 UTC

- reply

@nprofile…v8ld GrapheneOS has no analytics or telemetry. All of the default connections are documented at https://grapheneos.org/faq#default-connections. It doesn't include any kind of AI assistant and we would be strongly opposed to including any functionality based on those kinds of cloud services.
We're fine with having local implementations of features such as text-to-speech, speech-to-text and others which are not invasive, do not use a cloud service and do not persistently store data based on the inputs.

2026-03-10 15:36:34 UTC

- reply

@nprofile…v8ld GrapheneOS has no analytics or telemetry. All of the default connections are documented at https://grapheneos.org/faq#future-devices. It doesn't include any kind of AI assistant and we would be strongly opposed to including any functionality based on those kinds of cloud services.
We're fine with having local implementations of features such as text-to-speech, speech-to-text and others which are not invasive, do not use a cloud service and do not persistently store data based on the inputs.

2026-03-10 15:33:52 UTC

- reply

@nprofile…9d69 @nprofile…x6j3 We aren't part of a shared community and we're not on the same side. Volla, Murena and iodé trying to put themselves in the position of being the ones choosing which operating systems people are allowed to run on their devices is wrong. It's not a solution to the Play Integrity API but rather a new problem we'll be fighting against too. We aren't going to allow either Google or Volla to erode app compatibility with GrapheneOS without facing opposition and consequences.

2026-03-10 15:28:53 UTC

- reply

@nprofile…hupg It's not legitimate. The companies involved in it have atrocious security for their devices. They've created a system to permit using their own products while forbidding others. It's inherently not going to be neutral or fair. GrapheneOS isn't simply not going to participate but is going to actively fight against it. We're determining the best way to do that and one approach under consideration is a library banning any OS including Unified Attestation which we'll promote apps using.

2026-03-10 15:03:47 UTC

- reply

@nprofile…zfu7 @nprofile…4af7 There haven't been any internal power struggles and people engaging in years of extreme harassment and libel towards our founder and other team members is not simply personal insults. You're repeatedly misrepresenting what's happening and downplaying it. If you're not going to do basic research into what's happening and has been happening in the past then you're not in a position to leave any informed responses or advice. You're taking away from GrapheneOS development right now.

2026-03-10 14:59:44 UTC

- reply

@nprofile…4af7 @nprofile…zfu7 No, that's not good enough and you're continuing to repeat false narratives about GrapheneOS and our team from Rossmann including in this latest reply.
https://mastodon.social/@neogoth/116201618304737460
https://mastodon.social/@neogoth/116201913550793871
Please remove both of these posts and we can both move on from this misunderstanding.

2026-03-10 14:49:31 UTC

- reply

@nprofile…48fk No, and we have no plans to ever make one.

2026-03-10 14:40:29 UTC

- reply

@nprofile…zfu7 They've waged a war against GrapheneOS and our team for years. No amount of misrepresentations from you about the situation and what we've said/done is going to change reality. The real enemies of GrapheneOS are the people trying to harm GrapheneOS and our team. Apple has done nothing to try to harm GrapheneOS. Apple makes products with substance behind their privacy and security claims. We wish Apple didn't have such an aversion to giving credit to others but it's not an attack on us.

2026-03-10 14:36:35 UTC

- reply

@nprofile…zfu7 We post factual information about the falsely marketed products from companies attacking GrapheneOS in response to their attacks. You're misrepresenting the situation and what we said. It's the opposite of supporting a project you use which is provided to you entirely for free.

2026-03-10 14:34:25 UTC

- reply

@nprofile…jdyl That sounds like a hardware issue rather than something we can address. Try turning it off completely.

2026-03-10 04:04:18 UTC

- reply

@nprofile…l29u @nprofile…6vp6 Neither is preferable if both ban using GrapheneOS...

2026-03-10 01:30:02 UTC

- reply

@nprofile…94hx It's another way for apps to forbid using arbitrary operating systems and instead only allow specific ones. In Google's case via the Play Integrity API that means permitting only operating systems licensing Google Mobile Services. That includes mostly insecure devices failing to provide patches. In this case it's a way to allow a specific set of operating systems developed in Europe which are failing to provide basic privacy/security patches and protections. It's actually anti-security.

2026-03-09 23:58:59 UTC

- reply

@nprofile…vnlz We were actively engaging with the European Commission and others about it and this is going to seriously interfere with it. We don't want any companies or governments to be choosing which operating systems are allowed. It's a horrible idea and it puts us in a position where even if GrapheneOS is allowed then these companies or governments have leverage to make arbitrary demands. They can make anti-privacy and anti-security demands where not complying means losing app compatibility.

2026-03-09 23:19:58 UTC

- reply

@nprofile…avn4 These companies are among the last people who should be in charge of deciding which operating systems people should be allowed to use which shouldn't even be under consideration in the first place. We've posted a response to this:
https://grapheneos.social/@GrapheneOS/116200110686604617

2026-03-09 23:14:49 UTC

- reply

@nprofile…4af7 @nprofile…zfu7 Can you please remove https://grapheneos.social/@neogoth@mastodon.social/116201618434948840?

2026-03-09 22:47:23 UTC

- reply

@nprofile…4af7 @nprofile…zfu7 Claims that anyone had their work suspended on GrapheneOS or left the project is false. The massive amount of harassment directed towards our project and particularly our founder resulted in a major drop in productivity and another developer had to take over doing code review and leading the development team. Spinning someone not being able to do their job anymore due to how much they were being harassed into that story is ridiculous. You should stop listening to the perpetrators.

2026-03-09 22:45:07 UTC

- reply

@nprofile…4af7 @nprofile…zfu7 That video consists of targeting someone with bullying based on fabricating a false narrative about them and pushing tropes from the harassment/doxxing site where Rossmann is a member. Rossmann rants about people he dislikes on Kiwi Farms knowing they'll target thise people because they support him. Rossmann similarly knew the result of his incredibly dishonest video would be harassment and his phony justifications are thoroughly disproven at this point.
https://kiwifarms.st/members/larossmann.132201/

2026-03-09 22:42:36 UTC

- reply

@nprofile…4af7 @nprofile…zfu7 That's an outrageously inaccurate story. Rossmann engaged in months of bullying towards the founder of GrapheneOS both privately and publicly. He also supported Henry Fisher's public bullying campaign based around fabrications. There's nothing polite about the toxicity he engaged in towards us. After swatting attacks from Henry Fisher's community targeting the founder of GrapheneOS, Rossmann live streamed himself trolling him and then followed it up making a video out of it.

2026-03-09 22:40:49 UTC

- reply

@nprofile…zfu7 They've been spreading misinformation about GrapheneOS and making personal attacks on our team for years. They were doing it long before we were regularly publicly defending ourselves from it. Debunking their attacks and providing accurate information isn't remotely in the same class as what they're doing. Each time people push these false narratives about GrapheneOS and make disingenuous claims about the ongoing situation, we'll defend ourselves that much harder against these attacks.

2026-03-09 21:30:54 UTC

- reply

@nprofile…htxq @nprofile…drz2 No, your understanding is not correct. We want apps to start implementing proper server side security protections instead of using obfuscation and weak anti-tampering systems such as this to try to stop people looking at their code and experimenting with their services to find vulnerabilities. Apps shouldn't be enforcing using only specific operating systems. They're welcome to warn people about having an insecure OS but shouldn't be ban users from using what they want to use.

2026-03-09 21:29:26 UTC

- reply

@nprofile…82h9 Our community should help us much more than they do with the attacks being perpetrated against GrapheneOS and our team. If that was happening then it wouldn't be causing nearly as much harm and we wouldn't talk about it as much as we wouldn't feel nearly as much pressing need to provide an alternative to their inaccurate and misleading claims.

2026-03-09 21:25:08 UTC

- reply

@nprofile…82h9 We've posted accurate information debunking their attacks and addressing their false marketing. We've continued posting it because of continued attacks on GrapheneOS and our team. That's absolutely not stooping to their level. There's no reason for us to tolerate someone engaging in such blatant misrepresentations and lies about our project and team. You're going to achieve the direct opposite of silencing us. There's no reason for you to continue contacting us beyond trolling.

2026-03-09 21:23:31 UTC

- reply

2026-03-09 21:16:40 UTC

- reply

@nprofile…8w6d You can do those things on a phone using a web browser too. On the other hand, a lot of functionality is exclusive to mobile apps from banks and governments which are increasingly locking out users from using anything but operating systems approved based on the business models of companies involved in mobile phones. Whether someone can use a device to run a banking app shouldn't be determined based on a decision from either Google or Volla/Murena/iodé. These companies have no place in it.

2026-03-09 21:11:06 UTC

- reply

@nprofile…82h9 Here's the founder and CEO of /e/ and Murena linking to harassment content from a neo-nazi conspiracy site targeting our founder with fabrications:
https://archive.is/SWXPJ
https://archive.is/n4yTO
Their founder and CEO has regularly engaged in vile personal attacks on our including spreading harassment content directly from Kiwi Farms.
Debunking lies about GrapheneOS and our team along with providing accurate information countering their false marketing isn't what you claim it is.

2026-03-09 21:11:02 UTC

- reply

2026-03-09 21:08:32 UTC

- reply

@nprofile…82h9 Their products aren't at all what they claim but rather have poor privacy and atrocious security. They feel very threatened by GrapheneOS. Murena and iodé have engaged in many years of attacks on GrapheneOS including personal attacks on our team. They've engaged in absolutely vile fabrications and bullying aimed at directing harassment towards our team. Their communities have relentlessly targeted our team with harassment. You're pushing a false narrative about what's happening.

2026-03-09 21:08:21 UTC

- reply

2026-03-09 21:04:32 UTC

- reply

@nprofile…tq8l No, your understanding is not correct. We want apps to start implementing proper server side security protections instead of using obfuscation and weak anti-tampering systems such as this to try to stop people looking at their code and experimenting with their services to find vulnerabilities. Apps shouldn't be enforcing using only specific operating systems. They're welcome to warn people about having an insecure OS but shouldn't be banning users from using what they want to use.

2026-03-09 21:04:18 UTC

- reply

2026-03-09 21:02:18 UTC

- reply

2026-03-09 18:35:00 UTC

- reply

Having a European version of the Play Integrity which permits people to use insecure products from specific European companies participating in it while disallowing using arbitrary hardware or software is the opposite of a solution. It's more of the same anti-competitive garbage.

2026-03-09 18:29:25 UTC

- reply

There's no legitimate purpose for either Play Integrity or Unified Attestation to exist. Both will inherently fail to uphold even basic security standards since otherwise their own products wouldn't be allowed. Root-based attestation is also inherently not a secure approach.

2026-03-09 18:25:26 UTC

- reply

@nprofile…pljj @nprofile…7lyj It's inherently security theatre because neither companies and governments aren't willing to ban using the majority of Android phones which is what would happen if even basic security standards such as keeping up with High and Critical severity patches from AOSP and the SoC / radio vendors was enforced. Instead, they're disallowing people having the freedom to use their hardware or OS of choice while not enforcing even basic security standards. They're disallowing better security.

2026-03-09 18:22:41 UTC

- reply

@nprofile…dj2z @nprofile…pgqq Yesterday, a contributor to Ubuntu Touch posted a whole bunch of extraordinarily inaccurate claims about GrapheneOS on X in a malicious attempt to cause harm to our project. Many of the claims are quite clearly fabrications rather than simply being misinformed. We debunked this here:
https://x.com/GrapheneOS/status/2030402535463506069
Murena, iodé and Ubuntu Touch have been attacking GrapheneOS for a long time with misrepresentations and false claims including personal attacks on our team.

2026-03-09 18:20:08 UTC

- reply

@nprofile…dj2z @nprofile…pgqq Jolla has spent years attacking GrapheneOS and other projects based on the Android Open Source Project. They portray their non-open-source OS as somehow being an open alternative. They plaster EU flags everywhere and market it as having European values and yet they closely partnered with Putin's Russian government in 2015. They ended up with a huge portion of Jolla owned by Russia and only got rid of Russia's ownership in 2024. Are these their European values?

2026-03-09 18:17:46 UTC

- reply

@nprofile…dj2z @nprofile…pgqq SailfishOS doesn't provide anything close to bare minimum privacy and security patches. It lacks many important standard privacy and security protections. Their Android compatibility layer completely breaks the Android security model and sandboxing. Putting a weaker and incomplete sandbox around the overall compatibility system isn't a substitute for the standard security model, not to mention that it's super outdated and not getting basic patches itself.

2026-03-09 18:15:38 UTC

- reply

@nprofile…dj2z @nprofile…pgqq SailfishOS has very poor privacy and atrocious security. The portions of the OS they make themselves are largely closed source. It's a massive regression from the privacy and especially security of the Android Open Source Project even without the major GrapheneOS improvements. It's strange it's marketed based on using open source as the foundation when they don't open source most of what they actually made themselves. Android Open Source Project is a complete OS.

2026-03-09 18:14:37 UTC

- reply

@nprofile…dj2z @nprofile…pgqq You're mistaken about any of those being competitors to GrapheneOS. SailfishOS and Ubuntu Touch are the direct opposite of privacy and security hardened operating systems. They're far less private and secure than the Android Open Source Project or even LineageOS. They're going in the direct opposite direction of GrapheneOS from AOSP by combining the issues of low-end Android devices with a much less private and secure software stack. They're not in the same space.

2026-03-09 18:13:37 UTC

- reply

@nprofile…dj2z @nprofile…pgqq @nprofile…7fmw You're mistaken about any of those being competitors to GrapheneOS. SailfishOS and Ubuntu Touch are the direct opposite of privacy and security hardened operating systems. They're far less private and secure than the Android Open Source Project or even LineageOS. They're going in the direct opposite direction of GrapheneOS from AOSP by combining the issues of low-end Android devices with a much less private and secure desktop software stack.

2026-03-09 18:11:18 UTC

- reply

@nprofile…zr8z Disallowing people using GrapheneOS is anti-security and that's exactly what apps using either the Play Integrity API or Unified Attestation API are going to be doing. Both are going to be allowing extremely insecure options without basic patches and protections but yet not permitting a hardened OS with much better security. As far as we're concerned the whole approach is both fraudulent and violates antitrust law. Fighting Google's influence is hard but fighting this won't be hard.

2026-03-09 18:10:37 UTC

- reply

@nprofile…zr8z Disallowing people using GrapheneOS is anti-security and that's exactly what apps using either the Play Integrity API or Unified Attestation API are going to be doing. Both are going to be allowing extremely insecure options without basic patches and protections but yet not permitting a hardened OS with much better security. As far as we're concerned the whole thing is fraudulent and illegal for anti-competitive reasons.

2026-03-09 18:08:32 UTC

- reply

@nprofile…zr8z Most of the companies using attestation want root-based attestation. They primarily want to use it to control which hardware and software people can use. Useful hardware-based attestation can be provided without enabling apps to do this. It can also be useful without being available to user installed apps but it's not harmful for it to be available to user installed apps if it doesn't provide a root-based system that's inherently anti-competitive. It's even actually very anti-security.

2026-03-09 18:06:13 UTC

- reply

@nprofile…zr8z As an example, pretend that one of the 2 devices is compromised and the attacker stops allowing security patches. This would be visible in the attestation metadata and the attacker wouldn't be able to fake it without an early boot chain or secure element exploit. It could similarly provide more than it does today such as warning if the device hasn't been rebooted for a certain amount of time. This would all work fine without root-based attestation. Our Auditor app provides this stuff.

2026-03-09 18:03:56 UTC

- reply

@nprofile…zr8z Yes, and the attestation metadata includes certain information set by the OS developers such as the patch level for the OS. As an example of how this can be used, consider 2 people talking to each other on Signal who both want it to be a highly secure conversation. There could be a way to opt-in to sending each other attestations as part of the verification. It could then enforce that it's the same devices talking to each other and that the patch level continues to be updated, etc.

2026-03-09 18:03:45 UTC

- reply

@nprofile…zr8z Yes, and the attestation metadata includes information set by the OS developers such as the patch level for the OS. As an example of how this can be used, consider 2 people talking to each other on Signal who both want it to be a highly secure conversation. There could be a way to opt-in to sending each other attestations as part of the verification. It could then enforce that it's the same devices talking to each other and that the patch level continues to be updated, etc.

2026-03-09 18:01:39 UTC

- reply

@nprofile…zr8z The pinning-based approach was implemented so that you can verify the initial chain based on the root by enabling attestation for the attest key itself but it doesn't have to be used that way. It can be used to solely provide pinning-based attestation. Our Auditor app uses both but we don't consider root-based attestation to have much value. Any exploit of any TEE or secure element on any Android device that's certified can be used to get keys chaining to a root. It's not a secure system.

2026-03-09 18:00:34 UTC

- reply

@nprofile…zr8z These attest keys are meant to be pinned after the initial use and then used to enforce that subsequent attestations have trust chained from the initial verification. As long as the initial key was securely generated in the TEE or secure element and those have not been compromised with exploits then compromised apps or a compromised OS cannot fake the data. It chains trust from an initial starting point and does not limit which hardware or software can be used, the root approach does.

2026-03-09 17:59:10 UTC

- reply

@nprofile…zr8z Root-based attestation is done by verifying certificates up to a root of trust which is a Google certificate authority for Google Mobile Services devices. The Android hardware attestation API is in fact not inherently biased towards Google itself but rather their documentation and open source sample libraries hard-wire their roots as the only ones which should be checked.
Android supports apps generating attest keys in the hardware keystore to use for signing attestations instead.

2026-03-09 17:57:33 UTC

- reply

@nprofile…zr8z We don't support using attestation to disallow using hardware or operating systems. We do support having hardware attestation for providing protection against device compromise. The issue is that the features provided can be used to disallow using devices instead of only protecting against compromise and notifying users if something is wrong. Apps notifying users their OS is missing security patches or lacks security features would be fine but we don't agree with banning using it..

2026-03-09 17:55:58 UTC

- reply

@nprofile…zr8z Apps wouldn't be able to disallow using operating systems via the hardware attestation API if it only supported pinning-based security and didn't have support for chaining up to a root. It's chaining up to a root which enables trusting only Google's root or specific roots permitted for specific alternate hardware. Similarly, there's the fact that they differentiate green and yellow where green trusts every OS approved by the root CA party vs. yellow requiring allowlisting fingerprints.

2026-03-09 17:54:25 UTC

- reply

@nprofile…zr8z Apps don't use the hardware-based attestation API directly in practice by rather using a service like the Play Integrity API choosing what's allowed. Unified Attestation is a group which wants to use hardware-based attestation to choose what's allowed themselves. We don't think hardware-based attestation should be used to choose which operating systems are allowed and also don't agree with this specific group of companies selling insecure products adding vendor lock-in for themselves.

2026-03-09 17:54:05 UTC

- reply

@nprofile…zr8z Apps don't use the hardware-based attestation API directly in practice by rather using a service like the Play Integrity API choosing what's allowed. Unified Attestation is a group which wants to use hardware-based attestation to choose what's allowed themselves. We don't think hardware-based attestation should be used to choose which operating systems are allowed and also don't agree with this specific group we know are selling insecure products adding vendor lock-in for themselves.

2026-03-09 17:52:20 UTC

- reply

@nprofile…zr8z The problem with the Android attestation API is that the documentation and libraries treat Google as the only root of trust and it's also inherently biased towards stock operating systems since it can verify those by simply checking for the green state instead of needing to allowlist keys for the yellow state. Even if apps used hardware-based attestation instead of the Play Integrity API, many wouldn't permit GrapheneOS and they'd still be limiting what people can use if they did allow it.

2026-03-09 17:51:00 UTC

- reply

@nprofile…zr8z GrapheneOS supports the Android hardware-based attestation API. The API itself is a neutral approach which can support arbitrary roots of trust, non-stock operating systems verified based on verified boot key fingerprint and also has pinning-based attestation based on a proposal we made to Google before they stopped collaborating with us. Pinning-based attestation can be used with or without chaining up to a root for bootstrapping trust. It could exist without root-based attestation.

2026-03-09 17:49:02 UTC

- reply

@nprofile…zr8z Root-based attestation is can be used to bootstrap pinning-based approach to bootstrap initial trust in a weak way that's vulnerable to leaked keys and trusts a bunch of different parties which is what we do in our Auditor app. The real security model it uses is a Trust On First Use model to provide secure attestation going forward. The problem is Google or this new group declaring themselves as arbiters of what's allowed and using a root CA to allow only business partners.

2026-03-09 17:46:34 UTC

- reply

@nprofile…zr8z Apps should be able to use pinning-based attestation but root-based attestation as it exists today is inherently anti-competitive and anti-security. It locks people into using less secure hardware and software. The approaches should be differentiated. Any device can provide pinning-based attestation support including software emulation of it if they don't support the security features. Apps can use it with no loss of choice or privacy. Attestation roots are the abusive part.

2026-03-09 17:44:36 UTC

- reply

@nprofile…zr8z We support hardware-based attestation based on pinning for protecting users against attacks. Root-based attestation has extremely weak security due to depending on the entire ecosystem of devices not having vulnerabilities enabling leaking keys chaining up to the root. Pinning-based attestation can be used as a very strong security feature. Check out our Auditor app. It does use the root-based attestation for first verification but it would provide most of what it does without it.