![[personal profile]](http://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59Moxie, 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?
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?
![[identity profile]](http://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
What about conversations?
Date: 2016-05-12 03:25 pm (UTC)It also has an option for end-to-end encryption.
Re: What about conversations?
Date: 2016-05-12 03:28 pm (UTC)Re: What about conversations?
Date: 2016-05-13 06:16 am (UTC)a) Conversation (https://github.com/siacs/Conversations/ or https://f-droid.org/repository/browse/?
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?
From:Re: What about conversations?
From:Re: What about conversations?
Date: 2016-05-12 08:06 pm (UTC)no subject
Date: 2016-05-12 03:47 pm (UTC)no subject
Date: 2016-05-12 05:25 pm (UTC)(no subject)
From: (Anonymous) - Date: 2016-05-12 07:15 pm (UTC) - ExpandServer is open source too
From: (Anonymous) - Date: 2016-05-13 01:24 am (UTC) - ExpandRe: Server is open source too
From: (Anonymous) - Date: 2016-05-13 07:08 pm (UTC) - Expandi think you're wrong
From: (Anonymous) - Date: 2016-05-13 09:24 am (UTC) - ExpandRe: i think you're wrong
From: (Anonymous) - Date: 2016-05-13 07:07 pm (UTC) - ExpandYes, you can pick all three, and you can do it right now.
Date: 2016-05-12 03:51 pm (UTC)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.
Re: Yes, you can pick all three, and you can do it right now.
Date: 2016-05-12 04:00 pm (UTC)Re: Yes, you can pick all three, and you can do it right now.
From:Re: Yes, you can pick all three, and you can do it right now.
From:Re: Yes, you can pick all three, and you can do it right now.
From:Re: Yes, you can pick all three, and you can do it right now.
From: (Anonymous) - Date: 2016-05-13 10:05 am (UTC) - ExpandRe: Yes, you can pick all three, and you can do it right now.
From:Re: Yes, you can pick all three, and you can do it right now.
From: (Anonymous) - Date: 2016-05-12 09:18 pm (UTC) - ExpandRe: Yes, you can pick all three, and you can do it right now.
From:Re: Yes, you can pick all three, and you can do it right now.
From: (Anonymous) - Date: 2016-05-13 01:20 am (UTC) - ExpandRe: Yes, you can pick all three, and you can do it right now.
From: (Anonymous) - Date: 2016-08-28 07:37 pm (UTC) - ExpandRe: Yes, you can pick all three, and you can do it right now.
From: (Anonymous) - Date: 2016-05-24 01:16 am (UTC) - ExpandRe: Yes, you can pick all three, and you can do it right now.
From: (Anonymous) - Date: 2016-08-28 07:31 pm (UTC) - ExpandRe: Yes, you can pick all three, and you can do it right now.
From: (Anonymous) - Date: 2016-05-12 09:00 pm (UTC) - ExpandRe: Yes, you can pick all three, and you can do it right now.
From:Re: Yes, you can pick all three, and you can do it right now.
From:Re: Yes, you can pick all three, and you can do it right now.
Date: 2016-05-12 04:19 pm (UTC)--
Greg K Nicholson
Two years ago..
Date: 2016-05-12 07:17 pm (UTC)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.
no subject
Date: 2016-05-12 09:21 pm (UTC)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).
no subject
Date: 2016-05-12 09:26 pm (UTC)Another free mobile alternative would be Linphone (SIP based).
no subject
Date: 2016-05-13 08:54 am (UTC)But thanks $DEITY we have XMPP-gateways so we can talk with all those stray souls on Facebook ;).
One more for the mix
Date: 2016-05-12 10:30 pm (UTC)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.
Re: One more for the mix
Date: 2016-05-13 12:14 pm (UTC)Literally the first search result for "signal permissions" (without the quotes) for me:
http://support.whispersystems.org/hc/en-
Re: One more for the mix
From: (Anonymous) - Date: 2016-05-14 05:01 pm (UTC) - ExpandKontalk
Date: 2016-05-13 12:50 pm (UTC)The downside there is the lack of cross platform support. It works well on Android and has a desktop client, but lacks iOS support.
Kontalk
Date: 2016-05-13 02:05 pm (UTC)Re: Kontalk
Date: 2016-05-13 02:21 pm (UTC)Re: Kontalk
From: (Anonymous) - Date: 2016-05-13 04:52 pm (UTC) - ExpandRe: Kontalk
From:Silence
Date: 2016-05-15 11:48 am (UTC)https://silence.im/
https://github.com/SilenceIM/Silence
Re: Silence
Date: 2016-05-15 04:48 pm (UTC)https://f-droid.org/repository/browse/?
Fdroid, install, launch, click yes use for default sms client, done.
When I change phones: export local backup, copy file to new phone, import,
copy backup in a secure location, delete other copies, done.
I'm surprised mjg59 did not mention it.
Re: Silence
From: (Anonymous) - Date: 2016-05-17 06:47 am (UTC) - Expandno subject
Date: 2016-05-15 06:27 pm (UTC)Really the problem is that Google has a whiz-bang service built into all Android clients, and the use of this service is tied to proprietary horseshit. Consequently all alternatives will be technically inferior (i.e. wakeups, power consumption) or require rooting a handset and so forth. It's Microsoft tier secret API leverage for competitive advantage all over again.
Spose Google's itching for an antitrust action?
no subject
Date: 2016-05-15 09:47 pm (UTC)Inasmuch as Moxie is looking for adoption, he's opting to shift out of an opsec mode in proportion to this. For people who have a *significant* need to operate out of the snooping ability of Google, then Signal is not an option: it relies on a friendly Google. This permeates everything in the ecosystem - friendly services such as Google or Apple (not neutral) are taken to be mandatory for user friendliness. It's important to understand that if you're concerned about Big Siblings, then you have to control the software; and most / all of the hardware.
This is of course in separate context from the Libre Software requirements, of course!
I'm not sure who Moxie is serving at this point in the game. Not people who have reasonable concern for a Big Sibling. Unsure who is paying his bills: Twitter, I think. My analysis would be that Signal is adequate for purpose when dealing with ordinary snooping concerns - family concerns, coffeeshop snooping, etc. For people dealing with Significant Security Concerns... not sure there are reliable options; all paths are fraught with risk.
no subject
Date: 2016-05-16 12:49 am (UTC)I don't think that it does. Signal has never been touted to thwart a adversary that's dedicated to the task of performing traffic analysis. I mean, it used to use _SMS_ to transport the cyphertext of encrypted messages. SMS! You know, that data transport mechanism that the NSA is reported to regard as "just metadata" that falls under the "business records" section of the third-party doctrine, can be retained forever, and can be sent off to Law Enforcement just because they ask nicely.
The only _official_ claim I've seen made about Signal that it protects the _contents_ of your messages from adversaries that don't have root on either or both of the conversing party's computers. This means that Signal protects you just as well from Google as it does from the NSA.
Really, if you don't trust Google enough to send securely encrypted messages through their data routing service, then why do you trust them enough to use an OS that they authored? The author of your OS has root on the computer that runs it. This is a fact. Therefore, if you don't trust the author of your OS you cannot trust the machine it runs on.
"Unsure who is paying his bills: Twitter, I think."
Twitter acquired Whisper Systems and made Marlinspike its head of cybersecurity in 2011. Marlinspike left Twitter in 2013 to found Open Whisper Systems. While it's _entirely_ possible that his small fortune made from the Twitter acquisition and paycheck from the Twitter job are still paying the bills, it's more likely that the Wikipedia article is correct and that OWS is funded by grants and donations: https://en.wikipedia.org/wiki/
OSS and the desktop/mobile
Date: 2016-05-25 07:01 pm (UTC)ChatSecure ?
Date: 2016-07-09 08:26 am (UTC)The only problem is if a communication gets disconnected, OTR is not designed for mobile communications, but the successor OMEMO is. AFAIK ChatSecure doesn't support OMEMO yet.