[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?
Page 1 of 2 << [1] [2] >>

What about conversations?

Date: 2016-05-12 03:25 pm (UTC)
From: (Anonymous)
There is an xmpp client for android, called conversations, which at least satisfies the requirement of a negligible impact on battery.
It also has an option for end-to-end encryption.

Date: 2016-05-12 03:47 pm (UTC)
From: (Anonymous)
Not that we want an arms race here, but whether the Signal folks "like" it or not, they're not easily going to be able to stop anyone from interoperating with their servers.
From: [personal profile] mjh75
We've spent the last 1.5 years solving *exactly* this over at Matrix.org. Apologies that the below reads a bit like an ad, but the three key desirable attributes here map almost directly to what we're doing.

Convenience: glossy clients (late beta) available on web, iOS, Android such as https://vector.im with similar featureset to Slack/WhatsApp/FB Messenger etc. Interoperability with IRC, Slack and alpha bridges to things like XMPP, Lync, FB, Skype etc via libpurple.

Security: Decentralised architecture storing all conversations into a signed DAG which is replicated over all servers participating in a conversation. PERSPECTIVES for TLS cert management (not fully finished yet). Olm (https://matrix.org/git/olm) - our own independent Apache licensed C++11 implementation of the same Double Ratchet end-to-end encryption ratchet used by Signal (in late alpha)

Freedom: Built to give users the choice over which servers, services and clients they use, without sacrificing interoperability. Run your own server; run your own services; own your own data. 100% open source (Apache, for better or worse); entirely open specification with community involvement providing an open decentralised pubsub persistence building block for the web; non-profit charter; very active dev community writing all sorts of weird clients and sdks and bots and servers etc (eg weechat, pto.im, ruma.io etc :) The official Android SDK does use GCM currently by default, but can be disabled - an Fdroid distro would be *very* welcome.

So, um, sorry for the rant but we *really* think that open decentralised comms is a tractable problem and it's here today. Sure it's harder to build and maintain than a centralised service, as Moxie points out, but that is a price worth paying for maintaining independence, freedom and interoperability in our comms.
From: (Anonymous)
Tensor (https://f-droid.org/repository/browse/?fdid=io.davidar.tensor) is a Matrix client, available via F-Droid. Very welcome indeed! :)

Greg K Nicholson
From: [personal profile] mjh75
The point of Matrix, as the name implies, is to link together and decentralise conversations between different silos. I can guarantee that people you know use Matrix, given there are an ever-increasing number of networks which it links together into the resulting meta-network - for instance, all of Freenode, Moznet, W3C irc, and any other bridge you or others choose to run and expose to the wider Matrix ecosystem.

In other words, you don't have to be running a native matrix client like Vector. There are probably people you already interact with today via (say) Freenode who are bridged in via Matrix - they typically have an M- prefix on their IRC nick, although we're shortly changing to an [m] suffix.

Date: 2016-05-12 05:25 pm (UTC)
From: (Anonymous)
That sort of comment, though, is precisely why the Signal people don't want to cooperate with forks; because their wishes won't be respected and yet they still have to pay for the servers.
From: [personal profile] mjh75
I just looked at my IRC logs and it would seem that you're in #coreos on freenode, which is a channel which is exposed into Matrix as #freenode_#coreos:matrix.org (thanks to folks like M-hash accessing the channel over Matrix). Whilst you may not have directly communicated with M-hash there, it does mean that you are (very) indirectly utilising Matrix already to communicate with folks.

However, both Hangouts and IRC are obviously not end-to-end encrypted (unless you layer it on top). So if you want the convenience of communicating to bridged users, you necessarily end up exposing plaintext and metadata at the gateway. So I guess this is a scenario where the tryptic of convenience/security/freedom breaks down at the expense of security. I'd still argue that one can still achieve security in a Matrix world without significantly compromising convenience by saying "hey, M-hash, any chance you can use an E2E capable client (e.g. a native matrix client like Vector or WeeChat, or a (currently) hypothetical axolotl-compatible 3rd party client like Signal, WhatsApp, Wire etc should they ever be bridged into Matrix.). You'd then continue the conversation in an encrypted room, and achieve the trifecta :)

In terms of Hangouts: nobody's written a hangouts bridge for Matrix yet; i'm not sure why as it'd be trivial to take one of the 3rd party libraries and hook it up. We're still quite early on in the process of building out bridges ourselves, but contribs from anyone reading this would be enormously welcome!

Date: 2016-05-12 07:15 pm (UTC)
From: (Anonymous)
I'm not suggesting being needlessly adversarial. However, the whole point of software like Signal is to communicate with people, and the server software is *not* Open Source. If you build your own version from the Open Source client code, what *else* would it talk to if not the Signal servers?

Two years ago..

Date: 2016-05-12 07:17 pm (UTC)
From: [identity profile] tincho.org
Two years ago, after a day of talks at FOSDEM, some friends and I had a conversation about similar topics. It was triggered by the then new kid on the block: Telegram. I wrote a blog post (https://blog.tincho.org/posts/Telegram/) about that shortly after.

In the next few months I kept thinking about the problem of having a user-friendly, federated, secure system for RTC. Even though it went unnoticed and I did not do any real work on it, I wrote a series of posts discussing ways in which this could be done, here (https://blog.tincho.org/tags/Yakker/).

Maybe this interests somebody who has the time and resources to make it a reality.

Re: What about conversations?

Date: 2016-05-12 08:06 pm (UTC)
From: (Anonymous)
Of course my choice is XMPP & Conversations (the fdroid package without Google services), the only good enough & open solution.
From: (Anonymous)
The first person to turn down Signal probably said the same thing. If you start using it, your friends would have a reason to.
From: (Anonymous)
haevalencia@gmail.com (Hugo)

What do you think Telegram? ... I think it would fulfill quite well with many of your expectations. In my case, I made me very similar to yours questions and Signal not meet all I needed.

When I installed Telegram already had several of my contacts in it and now I have the majority. For each individual conversation I use secret chats default and even for groups there is only the possibility of chats in the cloud, do not talk issues of great secret with my teams, I also believe that in the future will be implemented something similar due to changes they have made similar applications.

In my work we use a custom client, but that does not stop to communicate with the official client or other forks available (On Android does not depend on Play Services and is optional). Finally, Telegram privacy policies and encryption system for the cloud chats give me confidence, even more than the service Signal (Metadata, location of the servers, etc.)


Date: 2016-05-12 09:21 pm (UTC)
From: (Anonymous)
There is also Ring (formerly SFLPhone), with mobile and desktop apps, however it's still in an early state. Ring supports SIP and its own protocol which is basically serverless SIP and nodes are looked up via DHT (as in torrents). Looks very interesting, is free software and uses Qt.
Also Ostel (https://guardianproject.info/apps/) is nice, multiplatfrom, free software alternative which uses SIP if I'm not mistaken.

Personally I cannot understand why new protocols are implemented when there are already SIP and XMPP, and what is lacking is good mobile apps. Current situation is horrible, with so many protocols (Skype, Whatsapp, Signal, SIP and XMPP) it's difficult to communicate. And yes, most of your friends will use Skype or WhatsApp (because it's from Facebook).

Date: 2016-05-12 09:26 pm (UTC)
From: (Anonymous)
Sorry, Ostel is actually only a service provider.

Another free mobile alternative would be Linphone (SIP based).

One more for the mix

Date: 2016-05-12 10:30 pm (UTC)
From: (Anonymous)
Let me throw another one on the mix, which I'd say fails the convenience test, for now at least. There is tox (https://tox.chat/) which seems to be promising.

Regarding signal, I tried and didn't find an explanation for why each of the many permissions is required. I guess I might need a tinfoil hat but apps that require lots of permissions always make me suspicious - mind you that I'm not implying signal is not secure or does nasty things.
From: [personal profile] mjh75
Just to make it clear: Matrix could be said to fall back to SMS, or IRC, or Slack, or whatever other bridges folks chose to run on the network. In reality, it's not so much a fallback as Matrix just providing glue between the various existing networks. And if you want E2E, you would use clients which support it, in a room where it is enabled.

However, I'm wondering if the point of this blog post was more to try to encourage Moxie into supporting 'unofficial' clients on the Signal network, or enabling federation - rather than look to other solutions. Opening up the Signal network would of course be fantastic, not least in terms of letting clients or federated servers like Matrix bridges provide interoperability to the rest of the world - and especially to E2E capable clients!
From: (Anonymous)
haevalencia@gmail.com (Hugo)

At least I trust the judgment of the Electronic Frontier Foundation to establish a code audit (external reputable company, 12 months old, security structure, etc) and that gives me the confidence to use the service.

Are you referring to other audit?


Server is open source too

Date: 2016-05-13 01:24 am (UTC)
From: (Anonymous)
I gathered from the conversation on G+ that the server is open too, so it would be possible to run an alt-Signal network. Just not convenient.

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.
Page 1 of 2 << [1] [2] >>


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