4 ms·

I'm the community manager for GrapheneOS. That isn't what happened, and it is very weird to not only see that on Mastodon, but also that you're going around say

I'm the community manager for GrapheneOS. That isn't what happened, and it is very weird to not only see that on Mastodon, but also that you're going around saying it in other places, too. People involved with the project you're working on have a history of making attacks on GrapheneOS, but what I mostly want to focus on is your suggestion because my goal here isn't to get in a back-and-forth with you or convince you, but rather provide context for others reading this. Our hardware requirements are not arbitrary. They are what we need in order to be able to provide usable security to people who depend on it. There's no "average security" for devices that are missing patches for known vulnerabilities for months. That's a non-starter, not something imperfect that an OEM can work on improving. Multiple OEMs have reached out to us and actually want to do the work of improving their devices so that we can use them to provide security for people. It's very weird for people to be fixated on this idea that GrapheneOS should instead be supporting devices which can't actually provide what the OS is known for. Without a secure element, a 6 digit PIN is no longer secure and can be bruteforced. What average person is using a long diceware passphrase to unlock their phone? Our device requirements are reasonable, and can be found at https://grapheneos.org/faq#future-devices https://grapheneos.org/faq#future-devices. Every time people ask us to support another device, we have to point to that explain that we cannot, because to date, no other devices meet them, and those who do purposefully go out of their way to cripple third-party OS support (Samsung chief among them). Then, we ask people which of our requirements we should drop in order to support that other device, and why people think that requirement is unreasonable. To date, we have received no convincing reply to that. You think we're chasing "perfection" but Pixels are just the best that exists right now and is extremely far from perfect. Our requirements aren't a wishlist, they're based on what is possible and reasonable today, not in the future.

WhyNotHugo 1y ago
> Without a secure element, a 6 digit PIN is no longer secure and can be bruteforced. Thanks for providing an actual example which we can use as a realistic reference. Right now such device can run OSs which ship first party spyware. If GrapheneOS supported those devices, they’d be usable with an OS without that spyware, which is a net improvement. The security issue of “a PIN can be brute-forced” exists regardless of OS.
- mbananasynergy 1y ago
  It has always been the goal of the project to provide security and privacy features while maintaining usability. People are expected to acquire a device to use GrapheneOS rather than us supporting as many devices as possible where we cannot offer the same protections. We're hoping to have a non-Pixel device that actually meets the projects requirements in the near future, potentially. Our requirements aren't exotic and OEMs are confirming that they're well within their capabilities. We'll focus on working with OEMs interested in shipping secure devices in order to expand our offerings, which should offer more choices for potential users as well.

WhyNotHugo 1y ago

> Without a secure element, a 6 digit PIN is no longer secure and can be bruteforced. Thanks for providing an actual example which we can use as a realistic reference. Right now such device can run OSs which ship first party spyware. If GrapheneOS supported those devices, they’d be usable with an OS without that spyware, which is a net improvement. The security issue of “a PIN can be brute-forced” exists regardless of OS.

mbananasynergy 1y ago
It has always been the goal of the project to provide security and privacy features while maintaining usability. People are expected to acquire a device to use GrapheneOS rather than us supporting as many devices as possible where we cannot offer the same protections. We're hoping to have a non-Pixel device that actually meets the projects requirements in the near future, potentially. Our requirements aren't exotic and OEMs are confirming that they're well within their capabilities. We'll focus on working with OEMs interested in shipping secure devices in order to expand our offerings, which should offer more choices for potential users as well.