<unnamed>

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgpz4mhxue69uhhyetvv9ujuerfw36x7tnsw43qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcpr3mhxue69uhkummnw3ex2mrp0yhxx6tjvd6k6tnnwpskxegpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qq755lz

Publishing to

relay.ditto.pub

relay.damus.io

nostrelay.circum.space

relay.mostr.pub

Last Notes

2026-03-10 17:57:09 CET

- 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 17:55:25 CET

- 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 17:53:52 CET

- 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 17:52:06 CET

- 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 17:49:13 CET

- 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 16:39:19 CET

- 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 16:38:40 CET

- 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 16:37:22 CET

- 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 16:36:34 CET

- 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 16:33:52 CET

- 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 16:28:53 CET

- 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 16:03:47 CET

- 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 15:59:44 CET

- 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 15:49:31 CET

- reply

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

2026-03-10 15:40:29 CET

- 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 15:36:35 CET

- 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 15:34:25 CET

- reply

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

2026-03-10 05:04:18 CET

- reply

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

2026-03-10 02:30:02 CET

- 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-10 00:58:59 CET

- 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-10 00:19:58 CET

- 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-10 00:14:49 CET

- reply

@nprofile…4af7 @nprofile…zfu7 Can you please remove https://grapheneos.social/@[email protected]/116201618434948840?

2026-03-09 23:47:23 CET

- 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 23:45:07 CET

- 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 23:42:36 CET

- 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 23:40:49 CET

- 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 22:30:54 CET

- 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 22:29:26 CET

- 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 22:25:08 CET

- 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 22:23:31 CET

- reply

2026-03-09 22:16:40 CET

- 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 22:11:06 CET

- 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 22:11:02 CET

- reply

2026-03-09 22:08:32 CET

- 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 22:08:21 CET

- reply

2026-03-09 22:04:32 CET

- 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 22:04:18 CET

- reply

2026-03-09 22:02:18 CET

- reply

2026-03-09 19:35:00 CET

- 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 19:29:25 CET

- 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 19:25:26 CET

- 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 19:22:41 CET

- 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 19:20:08 CET

- 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 19:17:46 CET

- 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 19:15:38 CET

- 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 19:14:37 CET

- 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 19:13:37 CET

- 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 19:11:18 CET

- 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 19:10:37 CET

- 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 19:08:32 CET

- 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 19:06:13 CET

- 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 19:03:56 CET

- 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 19:03:45 CET

- 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 19:01:39 CET

- 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 19:00:34 CET

- 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 18:59:10 CET

- 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 18:57:33 CET

- 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 18:55:58 CET

- 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 18:54:25 CET

- 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 18:54:05 CET

- 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 18:52:20 CET

- 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 18:51:00 CET

- 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 18:49:02 CET

- 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 18:46:34 CET

- 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 18:44:36 CET

- 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.

2026-03-09 18:42:44 CET

- reply

@nprofile…zr8z Android's hardware-based attestation API would not cause these issues if it only had the pinning-based attestation we use as the basis for Auditor and omitted root-based attestation. The issue is having attestation roots which determine which hardware and operating systems are valid. Hardware-based attestation can be provided without any centralized authority determining which hardware and software is valid. It would still provide nearly all of what our Auditor app uses without roots.

2026-03-09 18:20:24 CET

- reply

@nprofile…7lyj Their Unified Attestation system is a proposal to ban people from using GrapheneOS while permitting using insecure operating systems from the companies working with them. Why wouldn't we have an issue with that? Even if they did give in and permit using GrapheneOS, we don't want these systems to exist. Hardware attestation should be used to protect users rather than determining OS compatibility in a way that has nothing to do with security. Banning using an OS based on this is wrong.

2026-03-09 18:17:04 CET

- reply

@nprofile…7lyj Murena and iodé relentlessly spread false claims about GrapheneOS and our team. That includes personall targeting our team with absolutely vile bullying and harassment.
Here's the founder and CEO of /e/ and Murena linking to content from a neo-nazi conspiracy site targeting our founder with blatant fabrications including links to harassment content from Kiwi Farms users:
https://archive.is/SWXPJ
https://archive.is/n4yTO
Volla is fully aware of all this but works closely with these groups.

2026-03-09 17:52:17 CET

- reply

Murena and iodé are extremely hostile towards GrapheneOS. They've spent years misleading people about it with inaccurate claims to promote their insecure products. We'll never work with them. Volla, Murena and iodé should have no say in which OS people can use on their devices.

2026-03-09 17:47:22 CET

- reply

These companies should not have any say over which devices can be used for European banking and government apps. It will reduce competition and reduce security exactly as the Play Integrity API is already doing. The EU should ban using attestation to determine OS compatibility.

2026-03-09 17:42:27 CET

- reply

Volla, Murena and iodé sell products with atrocious security. They fail to provide important patches and protections while misleading users with inaccurate claims about privacy and security. That includes setting an inaccurate Android security patch level despite missing patches.

2026-03-09 17:37:27 CET

- reply

If banks and governments insist on checking devices for security they should define actual standards. It should be possible for any tiny project to be certified at no cost and the standards should be fairly enforced so a mainstream device without current patches is disallowed.

2026-03-09 17:24:28 CET

- reply

Hardware-based attestation has valid use cases including the Auditor app on GrapheneOS for protecting users. The way these companies are using it serves no truly useful purpose beyond giving themselves as unfair advantage while pretending it has something to do with security.

2026-03-09 17:23:25 CET

- reply

Play Integrity API should be regulated out of existence rather than making another system where companies permit their own products while disallowing others. It shouldn't be legal when Google does it and it shouldn't be legal when Volla and Murena do it either. This is wrong.

2026-03-09 17:19:18 CET

- reply

Google's Play Integrity API is a horrible system enforcing using devices officially licensing Google Mobile Services. It permits those regardless of how many years behind they are on security patches. The solution to this isn't another anti-competitive system based in Europe.

2026-03-09 17:16:18 CET

We strongly oppose the Unified Attestation initiative and call for app developers supporting privacy, security and freedom on mobile to avoid it. Companies selling phones should not be deciding which operating systems people are allowed to use for apps.
https://uattest.net/

2026-03-09 16:27:54 CET

- reply

@nprofile…y9n5 You'll need to talk to our developer soupslurpr on Matrix.

2026-03-09 16:05:50 CET

- reply

@nprofile…6uz5 @nprofile…h3m4 Many of the open source TTS implementations don't come functional out-of-the-box but rather requiring downloading and enabling a voice for them to use. A user installed TTS always needs to be activated in the TTS settings since they receive sensitive data from other apps via an OS API and it would be unsafe for them to function by default. There's meant to be a high quality TTS included in the OS which doesn't require any setup which is why we built one and are including it soon.

2026-03-09 16:04:24 CET

- reply

@nprofile…6uz5 @nprofile…h3m4 Yes, GrapheneOS has a fork of the open source TalkBack integrated into the OS. It needs a high quality default enabled text-to-speech app not requiring downloading any voice data or configuring anything. We've made one and will be included it in the OS in the near future. It does work via Sherpa TTS but you need to do more than installing a TTS implementation. You need to set up the TTS to be functional if needed and activate it in the OS TTS settings even if it shows it selected.

2026-03-09 15:49:48 CET

- reply

@nprofile…h3m4 It's possible that this already works fine, we'll need to verify that.

2026-03-09 07:45:32 CET

- reply

@nprofile…h3m4 Our SpeechServices app is at https://github.com/GrapheneOS/SpeechServices if you want to build it and try it. It should work on another OS although we haven't been testing that. We have a bunch of improvements including performance enhancements making it a better experience which are pending and that's why it hasn't been included in the OS yet since the last round of changes before the initial release in the OS hasn't been completed yet. We could include it in our App Store prior to the OS though.

2026-03-09 07:43:54 CET

- reply

@nprofile…h3m4 We likely need to add Setup Wizard integration for enabling TalkBack too which we'll get to after the TTS app is bundled.

2026-03-09 07:43:08 CET

- reply

@nprofile…h3m4 We plan to include our SpeechServices app providing text-to-speech in the OS very soon. We've had a lot of recent work caused by the release of Android 16 QPR2, upstream Chromium regressions, our Motorola partnership announcement and hiring multiple additional full time developers. Our TTS app was meant to be included in the OS already but has gotten delayed because a fair bit needs to be done to get it fully in shape for inclusion. It should be done within a week or two now.

2026-03-08 18:42:06 CET

Vanadium version 146.0.7680.65.1 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/146.0.7680.65.1
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/32895-vanadium-version-14607680651-released
#GrapheneOS #privacy #security #browser

2026-03-08 15:56:10 CET

- reply

@nprofile…gw4v @nprofile…6acr @nprofile…f62e Motorola contacted us about working together and we enthusiastically pursued it. We would do the same if Samsung wanted to work with us. Our Motorola partnership is explicitly a non-exclusive contract. There would need to be another company wanting to work with us and capable of meeting our requirements for there to be another partnership though.

2026-03-08 07:13:32 CET

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

2026-03-06 22:40:08 CET

Vanadium version 146.0.7680.65.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/146.0.7680.65.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/32825-vanadium-version-14607680650-released
#GrapheneOS #privacy #security #browser

2026-03-05 18:52:30 CET

- reply

@nprofile…43nz It has to start with those because they'll be the first meeting our update and security feature requirements. Lower end devices can gradually be supported as the improved updates and security features trickle down to those.

2026-03-05 15:50:46 CET

quasselkopf.de is a single user Mastodon where the sole user is heavily using an LLM to generate posts. They're using AI generated concern trolling to annoy and harass people.
Here's an example of them bothering someone else with AI generated replies:
https://quasselkopf.de/@kranzkrone/116176600327746998
Here's where they began doing it towards us:
https://quasselkopf.de/@kranzkrone/116176504616907351
We posted a constructive reply with useful information so they doubled down on trolling. We called it out and got targeted with abuse.
#fediblock

2026-03-05 13:24:55 CET

- reply

@nprofile…2ert No, only future devices meeting our update and security requirements will be supported. It will start with their next generation of flagship devices and then trickle down as the lower end devices improve to meet the requirements. The initial support will likely be for the 2027 equivalents of the Motorola Signature (2026), Motorola razr fold (2026) and Motorola razr ultra (2026).

2026-03-05 13:22:08 CET

- reply

@nprofile…07gq Those hardware details aren't up to us but for future devices we could gain more influence. It's still going to be unlikely we could get them to make such a substantial change with major tradeoffs for their regular devices. It's more realistic to be able to get more hardware security features added to future versions of the devices after the initial 2027 generation. It can keep getting better with time.

2026-03-05 03:11:08 CET

- reply

@nprofile…2ert No, only future devices meeting our security requirements starting with ones launching in 2027.

2026-03-04 16:45:51 CET

- reply

@nprofile…lqhl Pixel Camera supports RAW DNG and has more aggressive HDR+ for the regular photo mode. The main benefit would be that it has a stabilization UI to help with Night mode by having you hold the camera more steady but it works around the camera moving around regardless. We plan to add support for RAW DNG and various other features but it hasn't been one of our priorities partly since Pixel Camera can be used by people who want it to get the best that's available.

2026-03-04 16:43:50 CET

- reply

@nprofile…lqhl Don't generally recommend using wait for focus lock. You should just take a bunch of pictures instead. In practice, the use highest photo resolution toggle won't make a difference on Pixels yet since they always output images based on pixel binning even when asking for the full image sensor resolution. It would only make a difference when heavily zooming into the image or heavily cropping it but it would be nice if they added the necessary support to the camera hardware/HAL stack.

2026-03-04 08:36:35 CET

- reply

@nprofile…xpz3 @nprofile…0qar AOSP has support for flip and fold devices. We only need to do a small amount of special work for the Fold variants of Pixels.

2026-03-04 08:21:40 CET

- reply

@nprofile…0qar What do you think about the moto razr ultra? We can realistically support their 2027 flip device.

2026-03-04 08:20:40 CET

- reply

@nprofile…lqhl It has Night mode if you want to capture a lot more data in a way that looks as if it was brighter out than it actually was. You can also use Pixel Camera on GrapheneOS too which has extra features especially on Pro devices. Don't have particular recommendations beyond that.

2026-03-04 08:19:09 CET

- reply

@nprofile…n0uw @nprofile…wgun We're making the operating system, not them. We aren't concerned about whatever they decide to do in their own OS where they want to integrate GrapheneOS features.

2026-03-04 04:17:23 CET

- reply

@nprofile…n0uw @nprofile…wgun There's no reason GrapheneOS for Motorola devices would be less open source than GrapheneOS for Pixels especially with the direction Pixels have headed away from gradually open sourcing more and more of the firmware and userspace driver support to providing increasingly less of it to where it's becoming the same as supporting non-Pixel devices without OEM help. Pixels will be way harder to support than the planned devices.

2026-03-04 04:16:04 CET

- reply

@nprofile…n0uw @nprofile…wgun It has been a goal for a long time to get OEMs on board implementing the requirements for GrapheneOS, helping us with support for their devices and ideally making substantial contributions to GrapheneOS. Finally having this isn't a change in direction but rather the existing direction achieving something we've worked towards for a long time. If you want to keep using Pixels then you can keep using Pixels.