[personal profile] mjg59
Moxie, the lead developer of the Signal secure communication application, recently blogged on the tradeoffs between providing a supportable federated service and providing a compelling application that gains significant adoption. There's a set of perfectly reasonable arguments around that that I don't want to rehash - regardless of feelings on the benefits of federation in general, there's certainly an increase in engineering cost in providing a stable intra-server protocol that still allows for addition of new features, and the person leading a project gets to make the decision about whether that's a valid tradeoff.

One voiced complaint about Signal on Android is the fact that it depends on the Google Play Services. These are a collection of proprietary functions for integrating with Google-provided services, and Signal depends on them to provide a good out of band notification protocol to allow Signal to be notified when new messages arrive, even if the phone is otherwise in a power saving state. At the time this decision was made, there were no terribly good alternatives for Android. Even now, nobody's really demonstrated a free implementation that supports several million clients and has no negative impact on battery life, so if your aim is to write a secure messaging client that will be adopted by as many people is possible, keeping this dependency is entirely rational.

On the other hand, there are users for whom the decision not to install a Google root of trust on their phone is also entirely rational. I have no especially good reason to believe that Google will ever want to do something inappropriate with my phone or data, but it's certainly possible that they'll be compelled to do so against their will. The set of people who will ever actually face this problem is probably small, but it's probably also the set of people who benefit most from Signal in the first place.

(Even ignoring the dependency on Play Services, people may not find the official client sufficient - it's very difficult to write a single piece of software that satisfies all users, whether that be down to accessibility requirements, OS support or whatever. Slack may be great, but there's still people who choose to use Hipchat)

This shouldn't be a problem. Signal is free software and anybody is free to modify it in any way they want to fit their needs, and as long as they don't break the protocol code in the process it'll carry on working with the existing Signal servers and allow communication with people who run the official client. Unfortunately, Moxie has indicated that he is not happy with forked versions of Signal using the official servers. Since Signal doesn't support federation, that means that users of forked versions will be unable to communicate with users of the official client.

This is awkward. Signal is deservedly popular. It provides strong security without being significantly more complicated than a traditional SMS client. In my social circle there's massively more users of Signal than any other security app. If I transition to a fork of Signal, I'm no longer able to securely communicate with them unless they also install the fork. If the aim is to make secure communication ubiquitous, that's kind of a problem.

Right now the choices I have for communicating with people I know are either convenient and secure but require non-free code (Signal), convenient and free but insecure (SMS) or secure and free but horribly inconvenient (gpg). Is there really no way for us to work as a community to develop something that's all three?

Re: What about conversations?

Date: 2016-05-13 06:16 am (UTC)
From: [identity profile] matej.ceplovi.cz
This argument doesn't make sense:

a) Conversation (https://github.com/siacs/Conversations/ or https://f-droid.org/repository/browse/?fdfilter=Conversation&fdid=eu.siacs.conversations) doesn’t use its own proprietary format of encryption as all the alternatives I know about but uses standard XEPs, so I have no problems to communicate with my wife between Conversation and pidgin using OTR (but Conversations supports more encryption protocols for the cipher connoisseurs). So, whatever alternatives you may suggest XMPP with Conversations (or any other XMPP client) is the widest available most open (in terms of number of independent implementations) option. Which leads to

b) you are putting question in the mutually contradictory way. Either you want the platform where all your friends are, then just switch to using whatever they use and be done with it. If you do not care about security it is Facebook chat most likely, if you do Whatsapp, I guess. If your friends are not using open protocols (i.e., with independent implementations, Signal shows us clearly that FLOSS on its doesn't matter that much), you may get some relief by using system which supports gateways (e.g., I use http://spectrum.im, but any pidgin/Adium around will suffice), but the contradiction cannot be resolved perfectly without sacrificing one or another, because the world in its constant intentional refusal to see existence of XMPP just wants to jump into one proprietary silo after another. Of course, instead of XMPP you may choose another open protocol (IRC and bitlbee), but those are usually even less widespread and with worse user-experience, not mentioning they usually have no encryption whatsoever.

Re: What about conversations?

Date: 2016-05-13 08:49 am (UTC)
From: [identity profile] matej.ceplovi.cz
... and of course Conversations is a XMPP client as any other, so it is not mutually exclusive to use encrypted plain XMPP communication with some, and chat through Spectrum (or other transports) on Facebook chat with somebody else.

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags