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
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.
@scien We've partially addressed the state reset issues by having a strict rule of a single shared admin account across our rooms responsible for setting power levels, permissions, settings, etc. without moderators able to change them. The account is hosted on grapheneos.org. We require all moderators to be on matrix.org or grapheneos.org, although we'd prefer having them all on grapheneos.org but we need people on matrix.org due to it being the main source of abuse and federation often lagging.
@scien We do not ever set our rooms invite-only anymore, even during large raids, because if the room state resets back to an earlier state where it was invite-only it ends up dropping all the users who joined without invites since then in a way that bricks the room in their clients until they clear state. People think they got banned, etc. It happens all the time in other rooms. We notice it and remake them quickly now. We also have some other rules, and hopefully we avoid it going forward.
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.
@scien There is no absolute privacy, and people really should stop proposing signal. It's a centralized service in the US, so your metadata (who to whom, how much data, what time, what IP address, which client.…) will be recorded and monitored. Signal is better than WhatsApp, but not that much. @GrapheneOS
Gonzalo🐧 🇨🇱@GrapheneOS what about XMPP?
@g0nz4 It's not a good private messaging system either XMPP + OMEMO is not quite as problematic as Matrix.
Kevin Karhan 
@GrapheneOS personally I'll stick wirh #XMPP+#OMEMO & #PGP/MIME since that works and is secure - including 100% #SelfCustody of all the keys!
@kkarhan PGP/MIME is an extremely flawed way of doing encrypted messaging lacking forward secrecy and robust implementations. It should be avoided.
XMPP + OMEMO is not the worst choice but not one of the better choices either.
None of the end-to-end encrypted messaging apps we're referring to lack self custody of the encryption keys or they wouldn't be E2EE.
@GrapheneOS I have a different assessment, as both #PGG/MIME & #XMPP+#OMEMO have a robust ecosystem of apps and services that support both of them, are self-hosting capable and just work over @torproject / #Tor, #I2P and #VPN without fuss, including hosting the server as an #OnionService.
If i.e. @signalapp / #Signal would actually care, they'd force all traffic on Tor and stop demanding #PII like #PhoneNumbers which in an increasing number of juristictions can't be acquired anonymously by legal means...
vPurple@GrapheneOS Could you post a link to that forum post or whatever that is?