- MobileCoin rollout was pretty poorly done and communicated, regardless of the team’s intent. Withholding server source for a year to conceal MobileCoin development really didn’t attract any goodwill, either.
- Phone numbers being required is a bummer. I know that there’s work being done to remove this requirement, and I know that there are valid UX reasons to require phone numbers, but still not desirable for a secure messenger.
- The lack of federation is a valid critique. Moxie has defended this position at length in writing, but I found Matrix’s rebuttal (also a good read) more convincing.
Things I wish were substantiated more strongly:
> The reason the US government hasn't tried to block or hinder Signal, is because it's satisfied with the amount of information Signal can provide to it.
I found this unconvincing; this is a pretty big leap to make without more evidence. (Good counterexamples are all of the Signal alternatives mentioned in TFA.) I also don’t think it’s accurate to say the USG hasn’t tried to block or hinder Signal or E2EE messaging in general.
This reasoning would also disqualify Tor, which the author cites as a technology used in one of the Signal alternatives.
> Signals database [has] Message senders and recipients (via phone number identifiers)
Doesn’t Sealed Sender mean this isn’t the case? To their credit, the author mentions this a couple paragraphs after. I didn’t find that analysis consistent.
It would have been more persuasive to directly address Signal’s blog posts on collected data released in subpoenas (https://signal.org/bigbrother/central-california-grand-jury/ - maybe I missed it) and the zero-trust model of the protocol itself. Reflections on trusting trust, and all that.
I believe it's far more likely that the US government does like signal is the same reason as Tor. It's not about data collection (though technically possible it requires essentially destroying the trust in the service to achieve), it's about providing a tool useful for foreign dissidents and regime change that aligns to US interests.
Signal and Tor are statecraft and espionage tools not surveillance honeypots (though they both could become the latter through extreme means). This value far outweighs the ability to gather even more data when everyone is already surrendering huge amounts anyway.
>Signal also notably isn't self-hostable: there's no way to run your own signal server, and control your data. Marlinspike ruthlessly shuts down anyone attempting to build alternate clients or servers that could communicate with the main one.
That is perfectly wrong. As a maintainer of https://axolotl.chat, a third-party signal client initially built for Ubuntu Touch but which runs on almost everything now, I can tell you that our client is speaking without any problems to the official Signal servers, and also that the code of the server is available and is running fine, we used it to test our code.
I hadn’t heard of this, cool that it exists. How many people work on it and use it? I see one maintainer on GitHub making all the issues and PRs. But I could be mistaken.
Signal has been historically very anti-third party clients.
The first thing I saw on the github page is a screenshot talking about a shooting, maybe it's a quote from something? I'm unsure but letting you know it's rather offputting.
I couldn't find what the signup process is like, it says it doesn't require creating an account on the official Signal app but I assume you still need to use a phone number?
Throughout this page, the author fluidly shifts between conspiracy theories (that the CIA may be controlling Signal), opinions (that for a messaging platform to be good it must be self-hostable), and misdirection (NSLs exist, but it’s noteworthy that if you use a non-US company, the USG doesn’t need a warrant at all to compromise and extract data).
Moxie has been pretty clear about the problem Signal is trying to solve: radically upgrading the security of messaging for the masses. I’d say he’s clearly accomplished that: for the average human, migrating from SMS / email / etc to Signal or WhatsApp will immediately make their communications an order of magnitude more secure.
People get very emotional about this. So, maybe instead of it being “signal” it was instead: “closed chat app”.
I have an issue with closed chat app. My issue is that it’s closed, but often pretends to be secure.
I can’t be sure it is secure, because they pay lip service to open source, they also integrate another Foreign (to me) companies binary SDK which is also not open source.
They’re also a closed system, meaning that they have direct network effects and have been hostile to third party implementations of clients.
The protocol is documented (somewhat homegrown, more like an evolution of something existing), and the server is “open”, but it’s not possible to actually use these things.
The politics of the founder are sometimes in question. They’re also foreign to me and have had brushes with their nations law enforcement. Whether I can trust them shouldn’t be my concern- if the service were open it would not be.
So, I personally don’t believe in it.
I would _rather_ have a small collection of TLS irc servers or zulip servers, because lots of small targets is better than a big centralised one; Better than that is matrix which is properly federated.
Tell me though, was I talking about signal, whatsapp or telegram?
They all suffer the same problems and people like to bicker about their personal favourite; forgetting that you shouldn’t be throwing in to this kind closed ecosystem with its stupid network effects.
>In April 2021, signal outraged the open-source community by going a whole year without publishing their server code updates.
So? We have no way to be sure what is actually running on the server. In an end to end encrypted system, if the server can degrade security then you are doing it wrong.
We should make a distinction between the server tampering with message content and message metadata. Message content is protected by well-scrutinized and auditable client code. However, there's nothing stopping a malicious server from logging a bunch of extra metadata on top of what they claim to log, which would be very interesting for nation states. And the extra-metadata scenario is the one being criticized, I think.
If you trust Intel SGX (or other secure enclaves) it is theoretically possible for the server to attest to the client that a particular hash of code is running. (Typically the reverse process is used, to attest to a server that a client is running whatever DRM code the company wants.)
Signal already uses SGX to implement contact search [1]. The actual algorithm is performed in plaintext in the enclave.
Now, you might counter that SGX is full of holes, and I would agree with you.
Who cares? I can't audit the Signal servers. Signal can't realistically be completely sure the servers weren't tampered with - they're not funded to run bomb proof, spy proof, supply-chain secure data centers.
This is why we have E2E messaging and we accept the risk profile that entails - there is no better solution.
Any server can at least log both data and metadata. Any server could at least monitor and alert.
I wonder if there is a theoretical way to use ecryption to somehow prove that a message was only handled the way it was claimed? Seems impossible on the face of it but I've only given it one minutes thought yet.
Could you for instance have a hypervizor that does not know anything about the comms, and the client supplies something encrypted that causes a server to be created on the spot, do the comms work, and go away, and all the hypervizor knows is that it ran a process for a while? And the encrypted thing the client submits is not just an envelope and message but also essentially it's own decryption and verification code, such that the client can verify that the server is running the code it submitted, which of course included no copying.
Indeed, DHTs in generally are pretty hard on phones, even laptops. Even a few dozen packets a minute can use a fair bit of battery.
Seems like a DHT service running on a Raspberry Pi (on wall power), ddwrt router, maybe a plugin for "Home assistant" (an open source Siri/Google home like widget) would allow a phone to get the advantages of a DHT, without chewing through expensive mobile batteries or bandwidth.
Right, but seems like that's complicated enough to prevent mass adoption, also not particularly secure from traffic analysis. A p2p client could potentially have e2e encryption, be pretty much turn key, find all clients globally, and be traffic analysis resistant. Ideally as easy to use as signal.
Agreed with article, but for ordinary users I would have much easier to understand reasons why I ditched Signal some time ago after years of use:
1. It's unreliable, if you switch between mobile network and WiFi connection it takes way long time for Signal to register to change to send/receive the messages, while Whatsapp has no such problem and send message almost instantly.
2. Devs ignore users, I waited years for file picker being able to provide such BASIC feature as selecting multiple pictures at once, for years you have to select pictures one by one, Signal devs remind of Firefox devs, zero interest in fixing basic things.
3. It's unreliable poorly operated service, I remember when Signal went down and it took almost whole night in US until someone in US woke up and fixed it, I was for hours without working service.
4. The last drop was when they started ti push on users some PIN code nobody asked for taking 1/3 of the screen until you created it, for some users full screen nag. Then I decided to move me and my wife and both of my parents from Signal, so good luck with such crappy service (I know they soon backpedalled from this stupid decision but it was already way too late for us and they lost at least 4 users).
5. It's user hostile - there is no way knowing long pressing Send button allows you to force send message as SMS to Signal user, there was no introduction at first launch explaining this to user, each and every user have to go to Google and search how to do this. I assume also there is no automatic SMS fallback for Signal messages which are not sent/delivered within specific time frame.
6. There is no 3rd party app allowed, so you are stuck with one option whether you like it or not despite their "open source" claims.
All these happened before it became hype and fashionable to be on Signal, so maybe it's different now, but these are basic things ordinary users care about who don't even really care all that much about privacy and other stuff.
If you want to use alternative service you better use Element (Matrix), it doesn't require phone number, it doesn't rely on one American controlled server.
The average users mainly cares if their friends are on it. As it stands most people use either iMessage, WhatsApp or FBs Messenger in the west and WeChat in the east.
Signal had at Jan 1st 2021 around 40 mln users. WhatsApp had 2 bln. FBs Messenger had 1.2 bln.
Between Jan 1st 2021 and Augst 1st 2021, Signal also lost around 60% DAUs
Kind'of hard to use a messaging app, no matter how feature rich it is, when you have nobody to message.
Well of course that's the most important one, which goes even without saying, I was just working with (my real life) scenario when you are able to convince someone and then they have to deal with inferior service.
There were 2 things I liked about Signal, shared photos had much higher resolution than compress Whatsapp mess and I didn't need extra app for SMS, I couldn't really care less about privacy, since it's no more private than half of the other messengers.
Yes, the criticisms are generally valid. However, if the only proposed alternatives are Matrix, XMPP, Briar and Jitsi then Signal is still the best messenger. Of course those alternatives are great but for 99% of the people they are way too complicated.
I think what Signal should do, is set up additional multiple servers in the EU and maybe add some kind of noise messages to make it harder to analyze the meta-data/social-graph.
People/Groups/Firms who need more security should probably switch to Matrix.
- MobileCoin rollout was pretty poorly done and communicated, regardless of the team’s intent. Withholding server source for a year to conceal MobileCoin development really didn’t attract any goodwill, either.
- Phone numbers being required is a bummer. I know that there’s work being done to remove this requirement, and I know that there are valid UX reasons to require phone numbers, but still not desirable for a secure messenger.
- The lack of federation is a valid critique. Moxie has defended this position at length in writing, but I found Matrix’s rebuttal (also a good read) more convincing.
Things I wish were substantiated more strongly:
> The reason the US government hasn't tried to block or hinder Signal, is because it's satisfied with the amount of information Signal can provide to it.
I found this unconvincing; this is a pretty big leap to make without more evidence. (Good counterexamples are all of the Signal alternatives mentioned in TFA.) I also don’t think it’s accurate to say the USG hasn’t tried to block or hinder Signal or E2EE messaging in general.
This reasoning would also disqualify Tor, which the author cites as a technology used in one of the Signal alternatives.
> Signals database [has] Message senders and recipients (via phone number identifiers)
Doesn’t Sealed Sender mean this isn’t the case? To their credit, the author mentions this a couple paragraphs after. I didn’t find that analysis consistent.
It would have been more persuasive to directly address Signal’s blog posts on collected data released in subpoenas (https://signal.org/bigbrother/central-california-grand-jury/ - maybe I missed it) and the zero-trust model of the protocol itself. Reflections on trusting trust, and all that.
And more, but this is most of it.