GrapheneOSUnplugged are a recent entry in the crowded space of selling insecure hardware with significantly worse privacy and security than an iPhone as highly private and secure. Bottom of the barrel MediaTek device with outdated AOSP is worse than status quo. All marketing, no substance.
As part of marketing their products, Unplugged are spreading unsubstantiated spin and misinformation about GrapheneOS and the much more secure hardware we target. We've been aware of it for a while but chose not to respond to it until they began doing it in direct response to us.
GrapheneOS is a hardened OS built on the latest release of the Android Open Source Project rather than older releases with inferior privacy/security and incomplete privacy/security patches. We substantially improve privacy/security with our changes rather than making it worse.
The work we do in GrapheneOS is highly regarded by privacy and security researchers. We've made major upstream contributions to the Android Open Source Project, Linux kernel and other projects, both through submitting privacy/security improvements and reporting vulnerabilities.
We've also reported numerous vulnerabilities in hardware/firmware along with making multiple suggestions for new features which were implemented for Pixels. They're the only devices meeting our security requirements (https://grapheneos.org/faq#future-devices). We target them because of security.
Pixels have first class alternate OS support, which does not come at the expense of security. Support for installing an alternate OS is implemented securely as part of best in class boot chain and secure element security for Android devices. Supporting it has benefited security.
Unplugged has claimed open source and support for alternate operating systems reduces security. Pixel security has benefited from many external security researchers along with contributions from GrapheneOS because of it. They'll benefit more as they publish more firmware sources.
GrapheneOS not only leverages the same hardware-based security features as the OS but implements major hardware-based features unavailable elsewhere.
Hardware memory tagging for production hardening is an exclusive GrapheneOS feature with a best-in-class implementation.
Our USB-C port and pogo pins control feature does hardware-level attack surface reduction with code written for the drivers on each device:
https://grapheneos.org/features#usb-c-port-and-pogo-pins-control
Our Auditor app leverages the pinning-based hardware attestation available on Pixels based on our proposal for it.
Many of our other features are hardware-based, and some of these exist because of features we proposals or helped to secure against weaknesses.
In April, Pixels shipped reset attack protection for firmware based on our proposal, which is not available on other Android devices.
That reset attack protection blocks real world attacks by forensic data extraction companies, which we reported to Android. In April, Pixels also shipped a mitigation against interrupted factory resets used by those companies based on our report, not yet available on non-Pixels.
In June, Android 14 QPR3 was released with a hardware-based OS feature fully blocking interrupting factory resets. This was based on our initial proposal we made as part of our reports of active exploits in January, similar to the reset attack protection shipped in April.
Unplugged uses an older Android release. They do not have this AOSP patch. Their hardware is missing many standard security features including these recent 2 improvements shipped on Pixels. Their hardware doesn't even close to meeting our list of security standards even on paper.
Unplugged has tried to misrepresent these improvements and falsely claimed they're uniquely relevant to Pixels due to alternate OS support. That's not true. Their device is missing these and many other security features, and is not more secure due to lacking alternate OS support.
Unplugged has tried to spread fear, uncertainty and doubt about the hardware we support despite it being much more secure and trustworthy. MediaTek does not have a good security reputation and has repeatedly shipped real backdoors unlike the unsubstantiated claims from Unplugged.
Unplugged was founded by Erik Prince, the same person who founded Blackwater. Erik and others involved in UP are deeply tied to human rights abuses and surveillance around the world. Best case scenario is they're simply grifting like the Freedom Phone. Worst case is much worse.
Our initial response to someone asking about them is here, where we were avoided saying more than necessary:
https://x.com/GrapheneOS/status/1804551479484645421
Unplugged followed up with spin and misinformation about GrapheneOS, which we debunked, and then they doubled down on doing even more of it.
GrapheneOS (@GrapheneOS) on X
@PiereChangstein @weare_unplugged Where do they make any claim about GrapheneOS? It's an ARMv8.2 MediaTek Dimensity 1200 SoC device running a non-hardened fork of the Android Open Source Project. The hardware/firmware doesn't come close to meeting our security requirements, and it's not a hardened OS.
Since they posted huge tweets, we replied with our own huge tweets with inline quotes of everything they wrote for ease of understanding:
1/2:
GrapheneOS (@GrapheneOS) on X
@weare_unplugged @PiereChangstein > Our goal was to create a phone where privacy is convenient. Flashing GrapheneOS, however, is not something most consumers can do easily. GrapheneOS is very easy to install via https://t.co/29OBsAOaiI and many companies around the world are selling devices with the OS
GrapheneOS (@GrapheneOS) on X
@weare_unplugged @PiereChangstein > Here are our responses to continue the conversation. What you've done is push more spin and misrepresentations about an open source project to promote your insecure product marketed based on false privacy and security claims. > Let's agree to disagree. While the web installer
Unplugged in also infringing on the open source licensing multiple projects including DivestOS where they ripped off their AV from without attribution. They even still use DivestOS servers without permission. SkewedZeppelin is lead developer of DivestOS (URLs are in alt text):
Their messaging service is simply Matrix. Matrix is not a good private messaging system because it doesn't encrypt any metadata or even emoji reactions, and all that metadata is stored on each server for each room: room members, power levels, time/size/sender of messages, etc.
Scien@GrapheneOS I think it's a little harsh to call it "not a good private messaging system". There are precious few messaging services to the standard of Matrix or above that have wide capabillities that come close to many non-private, proprietary messengers.
And the few that tick those boxes have huge difficulties irt self-hosting. And afaik none of them have the variety of clients Matrix has, either.
But perhaps I'n being unfair. Maybe it's more accurate to say that Matrix is a good protocol, but not yet satisfactory as an *absolutely* private messenger.
If *absolutely* private is the goal I would be inclined to suggest something else like Briar or Signal - this much is true.
But I think it's plenty servicable for most peoples' - even tech-interested peoples' - standards of privacy in its current state.
@scien There are much bigger issues than what we described there for privacy and beyond that. Matrix has massive issues as a protocol not related to privacy too. Our public, non-E2EE rooms have repeatedly gotten bricked over the years due to state resolution bugs in the protocol and implementations which are still largely unresolved. Rooms accumulate more and more state events. The whole thing is also extremely vulnerable to abuse with very weak / non-existent anti-abuse and moderation tools.
@scien Briar is very poor choice for communication over the internet. Signal is a great option and there are other apps with good privacy and security beyond that. Matrix protocol and clients are very far from that being the case, and have even bigger non-privacy-related issues going largely unsolved too.
@GrapheneOS I see. That's rather unfortunate. I guess I simply give Matrix quite a bit of slack because of how increasingly transfomative it is as a protocol. There's even government contracts involving it.
I hope these problems get resolved as the protocol evolves, but until if/when that comes true, I can see why more rock-solid services like Signal are preferred.
About cryptography issues: https://gist.github.com/soatok/8aef6f67fec9c702f510ee24d19ef92b
About other protocol issues, relevant to why our rooms and others have often gotten bricked: https://telegra.ph/why-not-matrix-08-07
We've learned how to stop our rooms getting bricked for the most part but we've only followed our rules for that for the 4th time we recreated the main room and the 3rd for offtopic after the previous chain state reset incidents. We experienced it in several other rooms but not as recently so we expect those to break.
@GrapheneOS Wow. That's so much worse than I expected. Particularly # 11 of the second link is so laughably unconscionable as a part of basic spec design - it's the type of thing I'd forsee as problematic when I was just starting to learn to code.
And on the security side that simple confidentially break issue is absurd. Wtf.
I had no idea the issues ran this deep, let alone so ludicrously incompetent.
Worse still is the intrinsic problems of the DAG-based system listed there. Not much you can conceptually do about a lot of that without rewriting the basis of the protocol till it's practically a new one.
Well shit. I don't suppose you know of any other batteries-included messaging protocol that's relatively easy to self-host?
@scien Matrix tried to do better than XMPP by having the rooms decentralized where they aren't hosted on any particular server, so they need their complex state resolution system based on a form of consensus between servers. You can try joining the same large rooms across a few servers and you'll often find the user list, etc. is not the same across them. The inconsistencies can be quite a bit larger than that. Eventually, things start going very wrong and it starts resetting to old state.
LisPi@GrapheneOS @scien Sounds like the expectations were nowhere near pessimistic enough during the design of the protocol.
This is not stuff with no known solutions.
This is not stuff with no known solutions.