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.
Detun3d@GrapheneOS
What do you suggest with same features?
What do you suggest with same features?
Orca 🌻 | 🎀 | 🪁 | 🏴🏳️⚧️@tuneintodetuned @GrapheneOS
For now only Signal is capable of metadata encryption, they literally can't pull any user information other than two UNIX timestamps from servers. However they have problems selfhosting.
* SimpleX claimed so, too. But I wasn't able to make it work at all so I'm suspicious.
For now only Signal is capable of metadata encryption, they literally can't pull any user information other than two UNIX timestamps from servers. However they have problems selfhosting.
* SimpleX claimed so, too. But I wasn't able to make it work at all so I'm suspicious.
@Orca @GrapheneOS Signal won't cut it for me. SimpleX is amazing but it's not accessible enough yet.
datenritter 
@Orca @GrapheneOS @tuneintodetuned Metadata cannot be encrypted. You're mixing things up. Emoji-reactions are not metadata but content.
Oversimplified: Metadata is network data. Required to be readable so a service does work.
Best way to reduce metadata is reduce the network surface, i.e. use a decentralized service. That's why Matrix is better.
All this bizarre reasoning against Matrix. It's getting suspicious tbh. Even though there might be smaller technical details still to fix, centralized services just can't compete.
Also, screw emojis. 😅
@datenritter @GrapheneOS @tuneintodetuned
Metadata is network data.In the context of chat apps, metadata is who you're talking to, when the exchange happens, how long a message it would likely be, and to some extent, what your account is like (like nickname, profile pic and account description).Emoji-reactions are not metadata but content.Best way to reduce metadata is reduce the network surface, i.e. use a decentralized service. That's why Matrix is better.If so, Matrix would be (and is) worse, because the amount of data you can drag from a Matrix server is everything but encrypted chat's content* (except reaction emojis, because it's chat content as you mentioned it), and most people just join matrix.org without hesitation (which means in most cases just dump the db of matrix.org would be enough to figure out most of the connections between users, just like how the ATT metadata leak will impact users that do not use ATT's service). Have you tried login to your account without verifying your client? That amount of data is the amount of data about you that anyone w/ physical/logical access (former being server farm sunpoena, latter being server attacked by adversarials) can extract from the server database.* Some of this maybe due to design or architectural problems as federated services needs some metadata being visible to keep things running.All this bizarre reasoning against Matrix. It's getting suspicious tbh.It is just what it is, it doesn't matter whether you like it or not. You can freely doubt my motive or say I'm shilling for Signal as you like, though I have my doubt if they'll pay me anymore after the last time I criticized them for not caring enough about their desktop client security XD
Also, whether you like emoji or not doesn't matter. If you provide a function in your marketed "encrypted chat app" without telling everyone "well ackthually this part of chat data is not encrypted at all lmao" you are the baddies, because in the end of the day there will be people who use it. You wanna be cool, fine, but "emoji is cringe so those who use emoji can die in data breaches because fuck emojis" is not how products are made. Simple enough? 😉
(That and reaction data is, apparently, not necessary in server federation)
Nicknames/IDs are technically routing information, so we're talking about the same here.
You can't really get rid of this kind of information without messing up your service. (Let's not theorize about random IDs or onion routing here, please.)
You cannot magically "encrypt" it, without making it useless.
A centralized service will have all this data from all it's users, a single server from a decentralized/federated won't. There is no metadata where there is no communication.
The "some matrix server has my metadata" story is misleading.
Do matrix servers pull all metadata from each other? No.
If and only if you communicate with someone on another server, that server will have *some* information.
That's just how networks work. Nothing special.
Compare that to the "who, when, where, how much"-info Signal has. And the "who" in that list refers to real people, because, erm, phone number. 😳
(I like emojis. But minor problems like emoji reactions are out of scope.)
@datenritter @GrapheneOS @tuneintodetuned
Apology for my the last message. I was a little emotional while replying to your last message. 
Also Signal doesn't send a remote user its user profile (nick, pfp, bio) until a message request is approved. It's on device rather than on server, as designed by the protocol (so the server does not know this). Also partnering with the fact they added option to use username instead of showing phone number, the number used to register Signal is not actually linked to the specific account.
You see... those things we took for granted (like "centralized server knows everything") isn't necessaily true. With carefully designed protocols many of the problems can be mitigated.some matrix server has my metadataYes, some metadata, but if most of the accounts are on a single server, the benefits of "decentralization" begins to decrease. But Element dev team are still using poor (as in bad taste, subjective) UI/UX decisions to sway new users to join matrix.org server, which is worrying to me. It's a bit like mastodon's m.s/o problem, two servers having absolute majority of users and most of the data, while mastodon android client is still pushing more people to them.
https://web.archive.org/web/20210728141141/https://serpentsec.1337.cx/matrix
https://web.archive.org/web/20210724054202/https://snippets.serpentsec.1337.cx/matrix-metadata-leaks
Technology preview: Sealed sender for Signal
In addition to the end-to-end encryption that protects every Signal message, the Signal service is designed to minimize the data that is retained about Signal users. By design, it does not store a record of your contacts, social graph, conversation list, location, user avatar, user profile name, ...
@Orca Well… I'd expect the phone number to be connected to the account and an IP-address during registration, maybe not by Signal itself but by some three-letter agency. Why is it required in the frst place? Other services don't need it, but it is a 100% perfect personal identifier.
Also, it doesn't matter if a decentralized service has a big main instance. It's still better than a service which is centralized by design - and hosted in the US.
Many "mitigation" methods are nerd porn, but don't mean much in reality. All CIA and NSA have to do is to tell Moxie he's gonna record/copy them metadataz and lie about it or else. You can't check the integrity of their code or their servers.
Decentralization reduces risks and attack surfaces.
@Orca Thanks for the links though. I see only minor problems. E.g. someone in a room can see who else is in the room. Well… that's by design, maybe? Most messengers display join/leave events and memberships on purpose. SimpleX hides this AFAIK.
@GrapheneOS @tuneintodetuned
@GrapheneOS @tuneintodetuned