4 ms·

> Moxie, why haven’t you put Signal on F-Droid yet? There's no security benefit in having Signal on F-Droid instead of using https://signal.org/android/apk/ ht

by hiq 6y ago

> Moxie, why haven’t you put Signal on F-Droid yet? There's no security benefit in having Signal on F-Droid instead of using https://signal.org/android/apk/ https://signal.org/android/apk/. I don't think Signal would say much if F-Droid distributed this APK directly (instead of a recompiled version with a different signature). It's just complicated to set up, which is why (I think) nobody has done it. > But we have to trust that Moxie is running the server software he says he is. I don't understand what you're suggesting instead. There's no practical solution to this problem. > Signal doesn’t have a warrant canary Warrant canaries are legally untested. > Truly secure systems don’t require trust. Can you give an example of a truly secure system? What's your threat model?

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 ago
    A federated system design can be made to tolerate temporarily unreachable nodes. See email.
xorcist 6y ago
> There's no security benefit in having Signal on F-Droid instead of I don't know about Signal specifically but there is absolutely security benefits to hosting apks on F-Droid instead of your own home page. F-Droid supports reproducible builds, so you can actively check that their build infrastructure is not compromised. Signal seems to support some kind of reproducible builds on their own. Why that has not been integrated into the F-Droid build process I don't know. It seems like a large enough application to warrant the work. But I suspect no one has stepped up to do the work, and given that Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change.
- hiq 6y ago
  > Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change. IIRC his main arguments were really a different signature and delays in updates. Since these reasons will not exist anymore in the case of reproducible builds (the Signal app could still prompt for updates itself) from Signal being distributed on F-Droid, I don't think we can assume that Signal would not be fine with the APK distributed on F-Droid. From a quick glance, the main reason left now seems to be that Signal still relies on the Play services libraries at compile-time (not necessarily at runtime), which are proprietary and thus not acceptable for F-Droid. Signal does not want to support a fork with these libraries completely removed.

by hiq 6y ago

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 ago
  A federated system design can be made to tolerate temporarily unreachable nodes. See email.

xorcist 6y ago

> There's no security benefit in having Signal on F-Droid instead of I don't know about Signal specifically but there is absolutely security benefits to hosting apks on F-Droid instead of your own home page. F-Droid supports reproducible builds, so you can actively check that their build infrastructure is not compromised. Signal seems to support some kind of reproducible builds on their own. Why that has not been integrated into the F-Droid build process I don't know. It seems like a large enough application to warrant the work. But I suspect no one has stepped up to do the work, and given that Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change.

hiq 6y ago
> Moxie has been quite clear that Signal is not to be distributed on F-Droid, that seems not likely to change. IIRC his main arguments were really a different signature and delays in updates. Since these reasons will not exist anymore in the case of reproducible builds (the Signal app could still prompt for updates itself) from Signal being distributed on F-Droid, I don't think we can assume that Signal would not be fine with the APK distributed on F-Droid. From a quick glance, the main reason left now seems to be that Signal still relies on the Play services libraries at compile-time (not necessarily at runtime), which are proprietary and thus not acceptable for F-Droid. Signal does not want to support a fork with these libraries completely removed.