11–20 of 32 posts
What could Signal do to prove they aren't a honeypot? I have no idea if they are or not, but it'd be a disaster if they are. Or maybe not. I suppose people might just shrug it off like the NSA. sigh.
That doesn't solve the intermediary servers, but if it's e2e encrypted that only matters for metadata.
- 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.
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.
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.
>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.
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.
What could Signal do to prove they aren't a honeypot? I have no idea if they are or not, but it'd be a disaster if they are. Or maybe not. I suppose people might just shrug it off like the NSA. sigh.
Deterministic binaries? (I forget the correct term) Then just compile yourself from source, and compare to the apk you install. That doesn't solve the intermediary servers, but if it's e2e encrypted that only matters for metadata.
>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 te…
Signal has been historically very anti-third party clients.
>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 th…
This is why we have E2E messaging and we accept the risk profile that entails - there is no better solution.
Things I agree with: - 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 no…
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.
Messaging is so low bandwidth I'm surprised there's not an E2E p2p chat client that uses a DHT to find all the other clients.
However mobile messaging apps have trouble maintaining even a single TCP connection (even with optimizations like XEP-0352).