7 ms·
The benefit of running Signal on F-Droid is its secure update mechanism. Do you really think a homebrewed self-update mechanism is superior to the battle teste
by SignalNotSecure 6y ago
The benefit of running Signal on F-Droid is its secure update mechanism.
Do you really think a homebrewed self-update mechanism is superior to the battle tested F-Droid?
Moxie has a complete stranglehold on the Signal system. You are completely at his mercy for all decisions affecting the platform
See:
https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165 https://github.com/LibreSignal/LibreSignal/issues/37#issueco...
The solution is federation, like email has always been.
There are a couple of ways to solve this problem, which can be used in tandem. We can stop Signal from knowing when we’re talking to each other by using peer-to-peer chats. This has some significant drawbacks, namely that both users have to be online at the same time for their messages to be delivered to each other. You can still fall back to peer-to-server-to-peer when one peer is offline, however. But this isn’t the most important of the two solutions.
The most important change is federation. Federated services are like email, in that Alice can send an email from gmail.com to Bob’s yahoo.com address. I should be able to stand up a Signal server, on my own hardware where I am in control of the logs, and communicate freely with other Signal servers, including Open Whisper’s servers. This distributes the security risks across hundreds of operators in many countries with various data extradition laws. This turns what would today be easy for the United States government to break and makes it much, much more difficult. Federation would also open the possibility for bridging the gap with several other open source secure chat platforms to all talk on the same federated network - which would spurn competition and be a great move for users of all chat platforms.
Moxie forbids you from distributing branded builds of the Signal app, and if you rebrand he forbids you from using the official Open Whisper servers. Because his servers don’t federate, that means that users of Signal forks cannot talk to Signal users. This is a truly genius move. No fork of Signal4 to date has ever gained any traction, and never will, because you can’t talk to any Signal users with them. In fact, there are no third-party applications which can interact with Signal users in any way. Moxie can write as many blog posts which appeal to wispy ideals and “moving ecosystems” as he wants5, but those are all really convenient excuses for an argument which allows him to design systems which serve his own interests
- hiq 6y ago> Do you really think a homebrewed self-update mechanism is superior to the battle tested F-Droid? I don't think it makes a practical difference. > both users have to be online at the same time for their messages to be delivered to each other Not only online but one has to be directly reachable, e.g. ping $IP works. With mobile connections it's rarely the case. > on my own hardware where I am in control of the logs That still means the users of your server trust you, you've just moved the problem. It only solves the problem for you as a user. > This distributes the security risks across hundreds of operators in many countries with various data extradition laws. I don't understand this argument: if a piece of (meta)data goes through one server and you think it's bad because this server can monitor this piece of data, then having multiple servers with various levels of accountability is arguably worse. > those are all really convenient excuses for an argument which allows him to design systems which serve his own interests You are still not discussing why his reasons are bad according to you, so it's hard for people that have found the blog post convincing to change their mind. I'm also curious as to which interests you're referring to, especially when we're talking about a non-profit that develop FOSS software.
- SignalNotSecure 6y agoA federated system design can be made to tolerate temporarily unreachable nodes. See email.