Please add LibreSignal to f-droid #37

Closed
kakedacich opened this Issue May 4, 2016 · 465 comments

Projects

None yet
@kakedacich

Dear maintainers, I'm reading here:

#28 (comment)

that the people behind f-droid are willing to have LibreSignal distributed there.
What they're waiting for is a pull request from you (last sentence of that comment).

I hope you are already aware of this and that you'll allow everybody to get this great fork from f-droid!

Thank you

@kakedacich kakedacich changed the title from Please add the clien to f-droid to Please add LibreSignal to f-droid May 4, 2016
@mimi89999
Member

What they're waiting for is a pull request from you

There are still several important issues:

  1. The signing key for reproducible builds. If the signing key is changed, an update won't be possible. Also, who would "own" the signing key in such a case?
  2. Our relations with OWS are really bad. I'm afraid, that one day, they will ban LibreSignal from their server...
  3. Calling still doesn't work.

@LibreSignal what do you think? Should LibreSignal be moved to the main F-Droid repo?

@eighthave

I don't think it makes sense to include LibreSignal in F-Droid until you have a server to run it. They have explicitly said that the only want their own builds of Signal using their server.

@eighthave

even better, help them move to 100% free software and working without Google, so there isn't a need for the fork.

@mimi89999
Member

@eighthave

Until you have a server to run it.

Running a server costs money and I am not sure if OWS will want to federate with us.

even better, help them move to 100% free software and working without Google, so there isn't a need for the fork.

The problem is that Moxie and OWS don't want Signal to be 100% free/libre software (it is not important for them...)

@paride
paride commented May 4, 2016 edited

@eighthave They are not interested in removing the Google GCM dependencies, so unfortunately this is not possible. Moxie has been quite explicit on this point, several times.

@mimi89999:

  1. Can't the package be signed with the f-droid key, like the other packages on f-droid, and then this binary becomes the reference for LibreSignal's reproducible builds? Maybe here I'm missing something...
  2. Is is technically possible for them to ban unofficial clients? I'm not sure about this, and not even the big and evil players (Microsoft, Yahoo, Google...) ever did so. I remember Moxie asking for a client identification string to be modified on LibreSignal, and I get this as an indirect way to say "I'm OK with your client, but please let me recognize it on the server side". IMHO, if OWS bans LibreSignal at least it would be clear message to the community, and a lot of effort would be saved for better projects.
  3. I think that disabling calling altogether would be fine for the moment. Then, as there is a lot of attention on fdroid, there is a better change for it to be fixed.

This said, I understand why the inclusion on fdroid needs to be well pondered.

@paride
paride commented May 4, 2016

@mimi89999 but that is about calling the independent build Signal, and after that discussion (and legal threats) xmikos renamed it to LibreSignal (s/Signal/TextSecure). It's mostly about the trademark.

@mimi89999
Member
mimi89999 commented May 4, 2016 edited

@legovini

  1. F-Droid signing keys might get stolen or somebody from F-Droid might be forced to sign a malicious apk. If LibreSignal is added using reproducible builds, this won't be possible...

EDIT: Please read https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds#How_it_is_implemented_as_of_now

@mimi89999
Member

@legovini Let's ask @moxie0 if he is OK with LibreSignal using OWS servers.

@moxie0
moxie0 commented May 5, 2016

I'm not OK with LibreSignal using our servers, and I'm not OK with LibreSignal using the name "Signal." You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.

If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

@mimi89999
Member

@moxie0

I'm not OK with LibreSignal using the name "Signal."

LibreSignal is using the name "LibreSignal". The name "LibreSignal" contains "Signal". If you prefer, I can rename "LibreSignal", so that it doesn't contain "Signal" in the name... I can also change the icon if you want.

If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

You are receiving donations for developing Signal-Android and running the servers. I am not.

If I finance running a TextSecure server for LibreSignal, will you federate with us?
Also, I won't be able to run a RedPhone server because it is not open source.

What about other Signal forks like Signal Plus (https://play.google.com/store/apps/details?id=org.privatechats.securesms) (https://github.com/WizDom13/SignalPlus-Android) Their app name also contains "Signal" and they are also using OWS servers.

@mimi89999
Member

@xmikos @JavaJens @SecUpwN @mvdan @krt16s What do we do now?

@h-2
h-2 commented May 5, 2016

@moxie0

You're free to use our source code for whatever you would like under the terms of the license, but you're not entitled to use our name or the service that we run.

If you think running servers is difficult and expensive (you're right), ask yourself why you feel entitled for us to run them for your product.

@mimi89999

If I finance running a TextSecure server for LibreSignal, will you federate with us?
Also, I won't be able to run a RedPhone server because it is not open source.

I think these are the crucial points. Nobody wants to annoy WhisperSystems or create extra expenses or support tickets, but we do need inter-operability and interaction of the users. @moxie0 if you release the red phone server components and would agree to federate, I am sure we could gather enough resources to maintain own servers and not bother you further πŸ˜„

@moxie0
moxie0 commented May 5, 2016

If you prefer, I can rename "LibreSignal", so that it doesn't contain "Signal" in the name... I can also change the icon if you want.

Thanks, that would be great!

You are receiving donations for developing Signal-Android and running the servers. I am not.

You're capable of doing that as well, though. We're barely able to support our own apps, and having to support products outside of our control would make our lives even more difficult. If you think that collecting donations to run and maintain servers for your own project is difficult, why would you expect us to do it for you?

If I finance running a TextSecure server for LibreSignal, will you federate with us?

It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult.

What about other Signal forks like Signal Plus (https://play.google.com/store/apps/details?id=org.privatechats.securesms) (https://github.com/WizDom13/SignalPlus-Android) Their app name also contains "Signal" and they are also using OWS servers.

Yep, we're working on it.

@mimi89999
Member
mimi89999 commented May 5, 2016 edited

@moxie0
I don't think that the several LibreSignal users are a big impact on the server. Anyway, since you rely on donations, what is the difference for you if the user is using Signal-Android or another Signal fork? You don't have to specially "support" this app. It is communicating with the server the same way as Signal-Android and Signal-Desktop. (AFAIK Signal-Desktop is using WebSockets).

It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult.

Some time ago you federated with CyanogenMod. What has changed since then?
LibreSignal [server] would use the code that is in you repo and would be updated regularly. I don't understand the part "it makes changes really difficult".

@paride
paride commented May 5, 2016

@moxie on #37 (comment), I expected you to welcome LibreSignal on OWS servers because you have nothing to lose but a lot to gain. What is at stake here is the opinion and support of a big community, something that can make the difference in the future Signal. All the "freebie" PR you receive for your products do not come from people that just want to work for free.

I hope you see the difference between LibreSignal and the SignalPlus-like apps that just want to earn something using somebody else's work. I really see the space for a good cooperation here.

@mimi89999
Member

@legovini Signal Plus doesn't look bad (I didn't look yet at the entire code...). The only problem is that it is a bit outdated.

@paride
paride commented May 5, 2016

@mimi89999 my fault, I thought it was not distributed for free on the play store.

@mimi89999
Member

Signal Plus is a fork that contains many interesting features, that users asked for on the Signal-Android issue tracker, but that were never added by OWS (file transfer, wallpapers, etc.).
The issues with Signal Plus are that the app isn't 100% FOSS/FLOSS and that it requires gapps (like Signal-Android). The app is also a bit outdated, but I think that they might be open to PR.

@krt16s
krt16s commented May 5, 2016

Law is difficult, I don't know what trade/wordmarks OWS holds and what it can enforce with it. My common sense tells me that's a joke to have any such thing for a general word like "signal" in any way, but law is not common sense.

As for F-Droid: As I said, I wont be the in merging it into mainline. And even if there is a vote, I will not be in favor of it anymore. It's clear that OWS will (or might) take actions, thus leaving users out in the rain... (giving OWS yet another reason to say "see, that's why we dont support fdroid").

Let's just use XMPP/Conversations and be done...

@moxie0
moxie0 commented May 6, 2016

I don't think that the several LibreSignal users are a big impact on the server. Anyway, since you rely on donations, what is the difference for you if the user is using Signal-Android or another Signal fork?

The difference is huge; one we have control over, the other we don't. I understand that federation and defined protocols that third parties can develop clients for are great and important ideas, but unfortunately they no longer have a place in the modern world. Even less of a place for an organization the size of ours. Everyone outside the FOSS community seems to know it, but it took actually building the service for me to come to the same understanding, so I don't expect you to believe me.

I invite you to try it yourself with your own federated network of clients controlled by multiple developers, but please do not expect me to undertake that experiment for you. Again, if it sounds like a lot of work, ask yourself why you feel entitled for me to do it for you. Truly though, I wish you well in the endeavor, it's something that I'd love to be proven wrong about.

Some time ago you federated with CyanogenMod. What has changed since then?

What changed was going through that experience. It seriously degraded the UX for our users and held us back in the development process at many times. I'd estimate that all told, we lost about 6 months to a year of progress. It's something we'll probably never do again, and has fully convinced me that federated protocols are a thing of the past in this world of ours.

I hope you see the difference between LibreSignal and the SignalPlus-like apps that just want to earn something using somebody else's work. I really see the space for a good cooperation here.

If people want to use our source code to develop their own products, that's fine, so long as it's done under the terms of the license. That's the deal we're making with everyone, and I agree that it allows for possible collaboration. However, we are not running a service for other people's products, and we are not letting other people use our name in their products. Those things aren't part of the deal.

Let's just use XMPP/Conversations and be done...

You have no idea how much I would love it if you did, but the fact that you don't is sadly telling.

@krt16s
krt16s commented May 6, 2016

Let's just use XMPP/Conversations and be done...

You have no idea how much I would love it if you did, but the fact that you don't is sadly telling.

I am not involved in LibreSignal, and for my personal usage I actually am using XMPP the whole time and am pretty happy with it. My comment was directed to the LibreSignal devs. It's clear that you have other plans and other priorities. No hard feelings here, it's just when someone wants federation, no non-free blobs or whatever, Signal is not the thing to use. XMPP has quite some other problems, so if someone cares about that (more), it's not for him.

@mimi89999
Member

@moxie0
Some users that care about their device security and about the 4 essential freedoms (use CyanogenMod (I know CM isn't great either for the 4 essential freedoms...), don't flash gapps, etc.) use LibreSignal to contact users that don't know how to do that...

The difference is huge; one we have control over, the other we don't.

I don't see the huge difference. The protocol is the same. The only difference I see is that you can't directly push updates to LibreSignal users.

It's something we'll probably never do again, and has fully convinced me that federated protocols are a thing of the past in this world of ours.

What about email or XMPP? Are they a thing of the past in this world of ours?

I don't like the idea of a central server controlled by a small group of people that allows only official clients. Especially if a project claims to care about users security, privacy and freedom!

I don't even see how it would be possible for you to block Signal forks from using your servers if they keep "OWS as the "USER_AGENT".

@cjeanneret

I love the fake opensource provided by OWS : use the code, but go f*** yourself for federation, out-of-store distribution and acceptation.
Really an open mind as we want to see more and more. πŸ‘Ž

Seriously, if OWS continues that way, even libreSignal will be dropped from my devices, and no other apps from this organization will ever come back.

Currently, people seem to be wanting to help, provide resources (like servers) and are apparently just asking for federation (that was already working with CM), but all we hear are "no", and not alternative.

People that actually care for privacy just don't want to have gapps on their device. This is a basic step toward a bit more control over data and privacy.
How do you think those people will use your apps, @moxie0 ? Seriously? Locking out non-gapps-ed users is probably the worst idea you might have, since the drop of sms encryption with TextSecure (and the rebranding to signal an so on).

OWS policy just goes against real privacy, letting people with gapps, thus google services (mails, sync and so on) without the possibility to NOT let that on their phone.
That's against all logic.

Like they said: so long and thanks for all the fish.

Will follow that issue, but if LibreSignal (or whatever name it will get later) is locked out OWS servers, and no federation is possible, be sure to lose users. At least all the one that are using LibreSignal and self-build Signal. Your policy is the wrong one. And it's a shame.

C.

@mvdan
mvdan commented May 6, 2016

Whatever your take on what "the right thing" is, there is no need to get personal.

And as previously said, Signal is free software - that entitles you to the source code, and no more. Noone is in the right to demand that OWS do anything else, and that includes most of what is being said in this thread.

@paride
paride commented May 6, 2016

I agree with @mvdan and I thank @moxie0 for replying when asked by @mimi89999, providing his (OWS) point of view in a polite and useful way, bringing up some truly interesting aspects of the issue.

I can understand @cjeanneret's frustration, feeling just one step away from a truly free and secure messaging system, but this is no excuse for being rude.

@vanitasvitae
vanitasvitae commented May 6, 2016 edited

I'd find it really sad if OWS would stop LibreSignal from using their Servers. Up to this point the two projects coexisted in a nice peaceful manner. And as far as I can tell LibreSignal does not add any load to OWS servers. If a user has GApps he probably uses Signal, if he doesn't he may be using LibreSignal. That's it. Also afaict LibreSignal is not an app that generates tremendous amounts of traffic as it IS Signal with GCM removed.

Of course feel free to correct me if I'm wrong.

After all its their servers and they can do what ever they want with it, but for me there was no "real" argument against LibreSignal so far.

@mimi89999 mimi89999 added the wontfix label May 6, 2016
@mimi89999
Member

I see only 3 possibilities now:

  1. Do as @xmikos said earlier JavaJens#72 (comment) JavaJens#72 (comment)
  2. Stop LibreSignal and focus on another secure messaging app.
  3. Host our own servers, but without federation that would mean creating our own desktop and iOS client (using our own servers). That would also mean starting the user base from 0.

@LibreSignal

@kakedacich as for your original issue, it is a "wontfix".

@BlackerFlag
BlackerFlag commented May 7, 2016 edited

@mimi89999
Hi, I'm a long time lurker of this issue (ever since the infamous #127 of 2013). Now that the true colours of the situation have finally come to light, a far clearer direction is possible.

There are two great projects that instead of actively helping/supporting some of the largest bulwarks of trans-national, corporate power (Facebook Inc. & Google Inc.) actually work toward liberating computer users from the chains of proprietary software and protocols.

The first, for the desktop, is Tor Messenger[1][2], an XMPP client developed by the Tor Project and is an effort to create a security-by-design, ease-of-use XMPP client. They've ditched libpurple in exchange for a fresh codebase written in secure languages, OTR-by-default (but Axolotl/OMEMO replacing OTR is already discussed[3]) and of course torifying it all. It's already in beta and is expected to hit stable within the year[4].

And the second, for AOSP/iOS, is ChatSecure, an XMPP client developed by the Guardian Project, whom are already in active co-operation with the Tor Project, also maintaining apps like Orbot - a Tor-for-mobile and now also Orfox (currently in beta) - a Tor-Browser-for-mobile. They also make apps oriented for privacy in general, like ObscuraCam, an app that easily removes exif data from photos, for example.
ChatSecure is right now going through a huge upgrade through a co-operative merge/exchange of code with Conversations and Zom[5]. The Conversations team are the people to thank for the port of Signal's Axolotl protocol to XMPP, an implementation they named 'OMEMO'. The upcoming upgrade of ChatSecure is said to bring Axolotl/OMEMO/Olm[6], decentralised push notifications[6] and more[7] to the app.

And unlike Signal's false solution of a proprietary VoIP service, the Guardian Project is paving the way for a free/open standard in secure VoIP[8].

--[1]: Tor Messenger (initial blog post): https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily
--[2]: Tor Messenger (latest beta release): https://blog.torproject.org/blog/tor-messenger-010b6-released
--[3]: Tor Messenger OMEMO implementation: https://trac.torproject.org/projects/tor/ticket/17457
--[4]: Tor Messenger Roadmap: https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger#Roadmap
--[5]: ChatSecure, Conversations & Zom co-operation: https://chatsecure.org/blog/chatsecure-conversations-zom/
--[6]: ChatSecure Axolotl/OMEMO/Olm: https://chatsecure.org/blog/chatsecure-v32-push/
--[7]: ChatSecure public key XMPP identifiers: https://chatsecure.org/blog/using-ed25519-public-keys-as-identifiers/
--[8]: OSTel(Open Secure Telephony)/OSTN(Open Secure Telephony Network): https://ostel.co/about

Eclipse the past, usurp the future

@moxie0
moxie0 commented May 7, 2016

There are two great projects that instead of actively helping/supporting some of the largest bulwarks of trans-national, corporate power (Facebook Inc. & Google Inc.) actually work toward liberating computer users from the chains of proprietary software and protocols.

That sounds great, I hope you'll use Conversations or ChatSecure instead of Signal. The big question, however, is why doesn't everyone already do that? Guardian has been working on it for just as long or longer, with the same amount of funding or more. So why are Signal's growth, ratings, and engagement substantially higher?

You can keep mumbling XMPP over and over again like some Hare Krishna chant, but it might be worth evaluating why the entire federated IETF standards strategy has failed to get any real traction over the past decade. Most people in the church of XMPP place the blame on everyone else for not wanting to use it. Or you can blame all of us that are trying to develop something people want to use for being "a false solution." The problem is that self-perceived moral high ground alone isn't going to be the thing that makes it work any better.

I think that's why most of us are here, looking at projects like this, to begin with.

@vanitasvitae

@moxie0 You rejected the original PR of JavaJens (that added Websocket support to Signal) because of bad code quality (iirc). Are there any chances that you accept it in the future if the quality gets significantly better? That way people without GApps are at least still able to use Signal at all, even when they do not get the 4 freedoms.
Does that sound like a compromise?

@mimi89999
Member

@moxie0 @BlackerFlag

There are two great projects that instead of actively helping/supporting some of the largest bulwarks of trans-national, corporate power (Facebook Inc. & Google Inc.) actually work toward liberating computer users from the chains of proprietary software and protocols.

That sounds great, I hope you'll use Conversations or ChatSecure instead of Signal. The big question, however, is why doesn't everyone already do that? Guardian has been working on it for just as long or longer, with the same amount of funding or more. So why are Signal's growth, ratings, and engagement substantially higher?

Now ChatSecure only supports OTR.
As for Conversations, OMEMO was only added quite recently.
I think that is why.

Also, can't somebody use Conversations and Signal on a device without gapps? I know that keeping two connections with two servers for two apps has an impact on battery, but I didn't notice it...

@paride
paride commented May 7, 2016

@moxie0 trying to answer your question, I think that Signal gained way more users that the XMPP-based alternatives not because of the centralized architecture per se, but because it got two important things right:

  1. The identity of the users is their phone number. There is nothing else to exchange with anybody, nothing to chose or understand, no username, no "display name", no email, and so on. It is immediate for everybody.
  2. The user interface is simple. For example you don't have to specify a server, it just works. The fact that in Conversations you have to chose between no encryption, OTR, OpenPGP and OMEMO is already a failure on this side.

This is not to try to convince you of anything, it's just my view on the reasons for Signal's success.

@BlackerFlag
BlackerFlag commented May 7, 2016 edited

@moxie0

That sounds great, I hope you'll use Conversations or ChatSecure instead of Signal. The big question, however, is why doesn't everyone already do that? Guardian has been working on it for just as long or longer, with the same amount of funding or more. So why are Signal's growth, ratings, and engagement substantially higher?

Signal's growth, ratings, and engagement is higher due to simplifying the setup process to chat/talk fully encrypted. Tor Messenger, which you conveniently glossed over, is attempting to do this for XMPP, instead of centralising, cloudifying and sowing on proprietary protocols on a piece of "secure", "free" software like your project has done. They're going the (in my opinion) sensible route. NOT requiring an unaccountable, proprietary blob always on and phoning home (Google Play), NOT disallowing routing through secure, anonymous networks (Tor), NOT centralizing architecture, leaving control exclusively in the hands of a small group of people (OWS). I honestly see it as a stepping stone towards Ricochet, a peer-to-peer messaging app that is aiming to make servers obsolete, which is currently in experimental/alpha status (that's why I left it out in my previous post). I think that's the real solution to this whole mess.

You can keep mumbling XMPP over and over again like some Hare Krishna chant, but it might be worth evaluating why the entire federated IETF standards strategy has failed to get any real traction over the past decade.

Of course it's a bit complicated. But that's what people who want communications security are able to put up with. Your solution breaks security on several levels. What prevents Google Play from acting maliciously towards users of Signal? What re-assures users of the integrity of your unaccountable VoIP service other than your useless word? What are the benefits of requiring users to sign up with their mobile phone number instead of a unique user-name?

Or you can blame all of us that are trying to develop something people want to use for being "a false solution."

It is a False Solution since it forces unreviewable blobs of code onto the users, who, like children, are supposed to simply 'trust' daddy OWS, who's visibly having one hand in liberty (free software) and the other in propriety (support/reliance on proprietary protocols/software). I'm sorry for not ignoring the obvious and reifying your product.

The problem is that self-perceived moral high ground alone isn't going to be the thing that makes it work any better.

Neither is the ridiculous amount of trust we are supposed to grant your suspiciously divisive group.

@mimi89999
Here's Conversations on F-Droid: https://f-droid.org/repository/browse/?fdfilter=Conversations&fdid=eu.siacs.conversations

@mimi89999
Member

@BlackerFlag

Here's Conversations on F-Droid: https://f-droid.org/repository/browse/?fdfilter=Conversations&fdid=eu.siacs.conversations

I have Conversations on my Android phone.

@moxie0
Another reason for XMPP not being so popular is that iOS apps like ChatSecure can't implement Axolotl/OMEMO:

Originally we wanted to integrate Axolotl/OMEMO but we haven’t been able to acquire a license from Open Whisper Systems.

https://chatsecure.org/blog/chatsecure-v32-push/

@moxie0
moxie0 commented May 7, 2016

Now ChatSecure only supports OTR.
As for Conversations, OMEMO was only added quite recently.
I think that is why.

If the type of encryption protocol that a messenger uses is what determines its popularity, then why is Telegram so popular? Conversely, if the type of encryption protocol is what determines a messenger's popularity, why didn't XMPP clients implement something like Signal Protocol sooner? They've been around for longer than we have, have the same resources or more, have the same funding or more.

The identity of the users is their phone number. There is nothing else to exchange with anybody, nothing to chose or understand, no username, no "display name", no email, and so on. It is immediate for everybody.

Agreed! This is a huge growth engine, but it's only one of many differences. What's significant is that it's not possible to build an identity this simple in a federated landscape. That's a common theme across many of the differentiators, and since XMPP is a federated protocol, it's also pretty much stuck in time. Everyone with clients and infrastructure under their direct control can iterate into the modern world and beyond, while XMPP is stuck in the late 90s.

Of course it's a bit complicated. But that's what people who want communications security are able to put up with.

If you define "people who want communications security" as cryptonerds and free software moralists, then sure. But all the dissidents, activists, NGOs, and journalists that I've met are not willing to put up with that. It's why they use Signal.

It is a False Solution since it forces unreviewable blobs of code onto the users, who, like children, are supposed to simply 'trust' daddy OWS, who's visibly having one hand in liberty (free software) and the other in propriety (support/reliance on proprietary protocols/software). I'm sorry for not ignoring the obvious and reifying your product.

We're trying to make mass surveillance impossible for the world we live in, not a fantasy land inhabited only by cryptonerds and moralists. This is the world we live in: people do most of their communication on mobile devices running iOS or Android, use Chrome on the desktop, and expect contact discovery to be automatic in their social apps. The browser has won the desktop, iOS and Android have won mobile, and the velocity of the ecosystem is unlikely to make "distributed" communication mechanisms possible for some time.

We want to produce technology that is privacy preserving but feels just like everything else people already use, not somehow convince everyone to fundamentally change their workflow and their expectations. It'd be sweet if we lived in an alternate reality where everyone ran SailfishOS or something (and maybe this year will be the year of Linux on the desktop!), but we can't just pretend that's already the case.

What's so crazy about your perspective is that you're more committed to an ideology than building something that actually meets your needs. Don't want to run Google's Play Services because it's not Free Software? Then just write your own open source GCM implementation! Someone has even done it already. Don't want to install software from the Play Store? Build it yourself from source. It's even reproducible! Based on what you think "people who want communications security are able to put up with," that all seems pretty vanilla, but you'd prefer to moralize.

@eighthave

@moxie0 We at Guardian Project applaud your work at making crypto easier to use, but don't forget we are targeting different problems. As you said, Whisper Systems only cares about mass surveillance. We are definitely focused on targeted surveillance as well. Add in federation to the equation as an essential piece to circumvent blocking, and that makes it a lot harder to make easy-to-use software. ChatSecure works in China, which is part of the reason why we are funded, while Signal has been blocked for a while, and most devices there do not have Google on them. Federation is an important part of why ChatSecure still works in China. If you focus on the easiest part of the problem, then it becomes a lot easier to focus on a simple user experience. Focusing OWS on countries that don't block internet services, avoiding mass surveillance, and requiring Google makes your problem space a lot smaller.

And you are mistaken about the funding levels. OTF has given Whisper Systems $2.255 million https://www.opentech.fund/project/open-whisper-systems All of our Gibberbot/ChatSecure/etc. work since 2009 has received probably about $1 million (from multiple sources). The Orbot work is definitely less than $1 million. If you consider ChatSecure+Orbot as our chat app, then the funding levels are still less than Signal. And we haven't even added in any funds related to the first Whisper Systems startup or Twitter acquisition.

@mimi89999
Member

@moxie0

why didn't XMPP clients implement something like Signal Protocol sooner?

I'm asking myself the same question. Maybe because they were problems implementing it on iOS? (thinking...)

Quoting myself:

Another reason for XMPP not being so popular is that iOS apps like ChatSecure can't implement Axolotl/OMEMO:

Originally we wanted to integrate Axolotl/OMEMO but we haven’t been able to acquire a license from Open Whisper Systems.

https://chatsecure.org/blog/chatsecure-v32-push/

Also, why shouldn't you support normal users and "cryptonerds and free software moralists". "cryptonerds and free software moralists" like me would like to communicate with normal users. Signal already has a big userbase and people love Signal. That is why LibreSignal is interesting.

@moxie0
moxie0 commented May 7, 2016 edited

ChatSecure works in China, which is part of the reason why we are funded, while Signal has been blocked for a while,

Since when? Signal works fine in China, or at least I message people there on Signal pretty regularly. Looks like the registrations/minute for +86 are pretty high too.

We are definitely focused on targeted surveillance as well.

Never realized that. Out of curiosity, what about ChatSecure stops targeted attacks on an Android device?

why didn't XMPP clients implement something like Signal Protocol sooner?

I'm asking myself the same question. Maybe because they were problems implementing it on iOS? (thinking...)

It's because XMPP is stuck in time. Making any changes to a federated protocol is very difficult, which is why it still resembles the late 1990s. It's also why we'll never have usable end to end encrypted email. Services that control their own clients and infrastructure can iterate quickly, federated clients and servers can not.

"cryptonerds and free software moralists" like me would like to communicate with normal users. Signal already has a big userbase and people love Signal. That is why LibreSignal is interesting.

Sure, but if you can recognize that you want to use Signal because "normal" people use it, then I'd ask you to recognize that "normal" people use things like Signal or WhatsApp instead of XMPP for a reason. Any time you ask us to do something that makes Signal more like XMPP, you're asking us to degrade the reason you want to use Signal to begin with.

I think you can pretty easily be a cryptonerd and use Signal today without any forks. If you don't want to install Google's official Play Services on your phone, install an open source version like GsmCore instead. Problem solved, no LibreSignal required.

@vanitasvitae

If you don't want to install Google's official Play Services on your phone, install an open source version like GsmCore instead. Problem solved, no LibreSignal required.

@moxie0 So you require a "normal" user of a cheap Indian phone eg. to unlock and root his phone to install GsmCore via adb sideload to use Signal? Compare that efford to just install libresignal.
Also you forget ROMs like copperheadOS that would require gsmCore to be signed with the same key that signed the ROM itself, which would require the user to download ~30GB of Android source code, build the system himself (~4 hours depending on your computer), sign it with his key and flash both the ROM and gsmCore to his phone, after making backups etc of his old installation. And that has to be done every week for new versions of copperheadOS.

You see the gap that libresignal tries to close is much much bigger than what you make it look like.

@mimi89999
Member

@moxie0

ChatSecure works in China, which is part of the reason why we are funded, while Signal " blocked for a while,

Since when? Signal works fine in China, or at least I message people there on Signal pretty regularly. Looks like the registrations/minute for +86 are pretty high too.

@eighthave wrote "has been" not "is".

I think you can pretty easily be a cryptonerd and use Signal today without any forks. If you don't want to install Google's official Play Services on your phone, install an open source version like GsmCore instead. Problem solved, no LibreSignal required.

Signal also contains the proprietary GMS lib. I had also problems finding the source of 'org.w3c:smil:1.0.0' that is in your maven repo. Finally I added https://github.com/SilenceIM/org.w3c.dom as a git submodule in the libs folder. It is the version used in SMSSecure now called SilenceIM (a Signal fork). The problem is that the SHA of the .jar that I built doesn't correspond to the SHA that you put in build.gradle. That could mean that the code of that lib is different, but I couldn't find your source.

Any time you ask us to do something that makes Signal more like XMPP, you're asking us to degrade the reason you want to use Signal to begin with.

I think that you have problems with federation in Signal because Signal wasn't designed for federation. I think that anything without the "@" in the ID is bad for federation.

Could you also explain "Originally we wanted to integrate Axolotl/OMEMO but we haven’t been able to acquire a license from Open Whisper Systems." on https://chatsecure.org/blog/chatsecure-v32-push/ since you asked "why didn't XMPP clients implement something like Signal Protocol sooner"?

@mimi89999
Member
mimi89999 commented May 8, 2016 edited

And don't forget you need Signature Spoofing for microg to work.

@haffenloher

Signal also contains the proprietary GMS lib.
[...]
And don't forget you need Signature Spoofing for microg to work.

If these are the things that bother you, you could write an open source replacement for the GMS client library that does not enforce Google's signature on the GMS package.

@mimi89999
Member
mimi89999 commented May 8, 2016 edited

If these are the things that bother you, you could write an open source replacement for the GMS client library that does not enforce Google's signature on the GMS package.

I know that mar-v-in was working on it, so I asked him about it: microg/android_external_GmsLib#3

(The GMS lib he wrote didn't support GCM)

@SecUpwN
Member
SecUpwN commented May 8, 2016 edited

Gosh, been away a few days and this Issue is exploding! @mimi89999, would you please give me and other readers a quick round-up of the current state of this discussion? Here are some questions I have:

  • Is this discussion actually about if we should continue this app (this is an essential Issue)?
  • What are our main options now to de-confuse users?
  • How come you've set labe wontfix? We need to fix this!
  • Is there anything I can do for you to remedy this situation?
@mimi89999
Member

@SecUpwN Please read the entire discussion. It is very interesting. As for the future of LibreSignal please read #37 (comment)

@SecUpwN
Member
SecUpwN commented May 8, 2016

As for the future of LibreSignal please read #37 (comment)

That really makes me shiver. Am I right that all of that would not be the case if @moxie0 would remove the Google dependencies? I still do not get why Signal defends using these dangerous libraries..

@moxie0
moxie0 commented May 8, 2016

Any time you ask us to do something that makes Signal more like XMPP, you're asking us to degrade the reason you want to use Signal to begin with.

I think that you have problems with federation in Signal because Signal wasn't designed for federation. I think that anything without the "@" in the ID is bad for federation.

As we established earlier in the conversation, using phone numbers as identities is a strong growth engine for modern messengers. So you can pick one: federated identifiers, or a product people use. We've picked a product people use, but you're free to try a different experiment if you wish. Again, you're free to use the software we've made available under the terms of its license in that experiment, but not our name or the servers we maintain.

Could you also explain "Originally we wanted to integrate Axolotl/OMEMO but we haven’t been able to

You've been criticizing us for software dependencies that are not Free Software, and now you're criticizing us for writing software under the GPL? Which is it dude?

That really makes me shiver. Am I right that all of that would not be the case if @moxie0 would remove the Google dependencies? I still do not get why Signal defends using these dangerous libraries..

To summarize, we call an API. If you don't want to install Google's implementation of that API for whatever reason, you can install an open source implementation of that API instead. If you don't like the existing open source implementation of that API, you can write your own.

The experiment of writing software without these APIs has already been tried, and it's called XMPP clients. To the extent that you'd rather use Signal than XMPP clients,asking us to make Signal work like XMPP clients doesn't really make sense.

@vanitasvitae
vanitasvitae commented May 8, 2016 edited

Just enable users without ANY kind of GCM implementation (a libre implementation of an unfree API just makes no sense) to communicate with other Signal users by optionally targeting the websocket of your desktop app. The fact that JavaJens brought this fork to life and the devs could make it work this well demonstrates that it is indeed possible and realistic.

[Insertion]: This will have no negative impact on existing users but instead enable a lot more people to use Signal.

I think this is the main point of this discussion. Lets focus on this again instead of criticizing each others implementations/morals.

@moxie0
moxie0 commented May 8, 2016

an unfree API

What in the world is "unfree" about an API? The entire GNU subsystem was a "Free" implementation of an "unfree" API, so you're going to have to jump through some pretty revisionist history to justify that statement.

At this point I'm just going to be repeating myself, so I'm going to unsubscribe from this thread. Good luck with your projects everyone.

@vanitasvitae

@moxie0 Sorry for being inaccurate. "unfree" should read "an API that routes the users data to Google".

@mimi89999
Member

@moxie0

Could you also explain "Originally we wanted to integrate Axolotl/OMEMO but we haven’t been able to

You've been criticizing us for software dependencies that are not Free Software, and now you're criticizing us for writing software under the GPL? Which is it dude?

I read some articles saying that software under the GPL license is not allowed in the Apple App Store. Signal-iOS is under the GPL license and is was accepted in the Apple App Store. I'm really confused now.

@Pazuu
Pazuu commented May 8, 2016 edited

I think this is exactly the Point. Would it not be the perfect compromise if Signal would officially have an option f.e. to check for new messages every 20minutes (and therefor not depend on the google API)?
Then every foss nerd could compile it themselves and would not give information of any kind to google.
Thanks for your thoughts! 😊

@vanitasvitae
vanitasvitae commented May 8, 2016 edited

@Pazuu this is more or less what Libresignal is doing.

@BlackerFlag
BlackerFlag commented May 9, 2016 edited

@moxie0

Conversely, if the type of encryption protocol is what determines a messenger's popularity, why didn't XMPP clients implement something like Signal Protocol sooner? They've been around for longer than we have, have the same resources or more, have the same funding or more.

And you are mistaken about the funding levels. OTF has given Whisper Systems $2.255 million https://www.opentech.fund/project/open-whisper-systems All of our Gibberbot/ChatSecure/etc. work since 2009 has received probably about $1 million (from multiple sources). The Orbot work is definitely less than $1 million. If you consider ChatSecure+Orbot as our chat app, then the funding levels are still less than Signal. And we haven't even added in any funds related to the first Whisper Systems startup or Twitter acquisition.

This was by far the funnies exchange in this thread.

It is a False Solution since it forces unreviewable blobs of code onto the users, who, like children, are supposed to simply 'trust' daddy OWS, who's visibly having one hand in liberty (free software) and the other in propriety (support/reliance on proprietary protocols/software). I'm sorry for not ignoring the obvious and reifying your product.

We're trying to make mass surveillance impossible for the world we live in, not a fantasy land inhabited only by cryptonerds and moralists. This is the world we live in: people do most of their communication on mobile devices running iOS or Android, use Chrome on the desktop, and expect contact discovery to be automatic in their social apps. The browser has won the desktop, iOS and Android have won mobile, and the velocity of the ecosystem is unlikely to make "distributed" communication mechanisms possible for some time.

We want to produce technology that is privacy preserving but feels just like everything else people already use, not somehow convince everyone to fundamentally change their workflow and their expectations. It'd be sweet if we lived in an alternate reality where everyone ran SailfishOS or something (and maybe this year will be the year of Linux on the desktop!), but we can't just pretend that's already the case.

Hey! That's a canned response: https://news.ycombinator.com/item?id=10665789

If you don't want to install Google's implementation of that API for whatever reason

for whatever reason

You're basically jesting at this point.

Hey Dodgie, as you come in to scab their withering private properties, you must be a blast behind the closed doors of their corporate headquarters as they sit by a projector in a smoke-filled room, scrolling through your profile and laughing their fucking asses off. Clearly not a literal blast.

@BlackerFlag
BlackerFlag commented May 9, 2016 edited

So, moral of the story:

  1. "Scabbing for trans-national corporate elites and rhythmic pelvic dancing with Sergey Brin are the revolutionary tactics of the 21st century"
  2. "Cryptonerds, freetards and anonymity grandpas are icky and should be separated from the mass of the people"

-Moxie Googlespike the Shit Out of My Hardware

That's all, folks.

@vanitasvitae
vanitasvitae commented May 9, 2016 edited

Would it be a possible solution to expose the server URL in LibreSignals Settings? That way the user can enter the URL of the server he wants to use himself at runtime. It would be the users choice which server he wants to use. Is that possible?

And if the user chooses OWS server... Well its the users "fault".

@mimi89999
Member

@vanitasvitae Yes, but what would it give since there is only one TextSecure/Signal server? Don't forget that the SSL cert for the server is in the app...

@vanitasvitae

@mimi89999 Bummer, didn't know about the certificate.
Signal server code is free, so there is the possibility of other servers. If there actually ARE other servers is not the point. My idea is that LibreSignal is not responsible for users that decide on their own to use OWS' servers.

@mimi89999
Member

If LibreSignal continues using OWS servers, they might:

A. Do nothing.
B. Ban LibreSignal from the srvers.
C. Start legal actions.

My idea is that LibreSignal is not responsible for users that decide on their own to use OWS' servers.

Like a possibility to protect against C.?

@SecUpwN @xmikos What do you think?

@vanitasvitae

Like a possibility to protect against C.?

Exactly.

@pravi
pravi commented May 9, 2016

Kontalk, just needs more developers. It has phone number based identities that works like Signal, but interoperable with xmpp. I wish the LibreSignal devs joined hands with kontalk, instead of hitting their heads on OWS wall. It lacks groups and omemo right now, but that can be easily fixed by more developers.

@SecUpwN
Member
SecUpwN commented May 9, 2016

Like a possibility to protect against C.?

@mimi89999, possibly. But I really worry where all of this is heading. If OWS and especially Moxie are that keen to defend their "free" software up to the point of saying "Hey, you can copy and modify the code, but not use our servers and not use even part of the original name", it really is a turn-down. On one side we might say "we don't care, continue" - but on the other side moving on to support a friendlier platform like @Kontalk would maybe make more sense. To be honest, I'd like to hear the thoughts of @JavaJens here. I'd like to avoid that everyone is investing so much lifetime and sweat, just to find out that we have been running into a dead end. I am a bit speechless as of the "support" of @moxie0.

@mimi89999
Member

@SecUpwN
I have a feeling that we are running into a dead end. I think that abandoning LibreSignal and focussing on an other messaging app is the best solution, but lets wait for @xmikos and @JavaJens replies.

@infinity0
infinity0 commented May 9, 2016 edited

I know that @moxie0 is no longer reading this, but I just want to chime in for future readers that have the same attitude: dismissing FOSS as an "ideology" is ignorant both of software history and of its principles.

We as a community have been through many cases of "lock-in" bullshit before, and FOSS is a way to protect against that - prevent one big player from controlling technical direction simply because the non-technical mass market gave them market monopoly power, based primarily on non-technical reasons. In the long run, lock-in control results in bad technical decisions and an inferior overall product, which harms the mass market even if they don't realise it at first. The people that understand this, also understand that similar economic relationships such as centrally controlled services and APIs like GCM, also would lead to the same "lock-in" situations, even though that is not covered by the original definition of "FOSS". It is clear what people mean by "non-free API", even if that is not the best literal phrasing of it.

@pravi pravi referenced this issue in kontalk/androidclient May 9, 2016
Closed

Group chat #179

@eighthave

there are many alternative private messaging apps to work on, for those looking to work on projects that are truly free software, here's a quick list:

There is also protocol work that needs contributors, specifically to help with implementations.

  • OTR v4 protocol will include something like the Axolotl/Signal ratchet for better mobile/async support
  • (n+1)sec - https://learn.equalit.ie/wiki/Np1sec is group OTR basically, there is a C implementation, it needs to be included in apps to test it, and also implemented in other languages
@TheJJ
TheJJ commented May 9, 2016

I'd be really happy if we found a solution to make https://tox.chat/ be usable in a convenient way on mobile phones and other devices.

Using the phone number as ID will be very hard, but a true peer-to-peer messaging/calling network with working multi client support (i. e. all messages available at all authenticated devices) is the ultimate communication platform i'd say.

Maybe, to create a strong network, people could set up "relay" nodes for websocket access from mobile devices then so it's more battery saving.
I think the Tor messenger is going a similar way.

tl;dr: i'd go for a true p2p approach.

@pejakm
pejakm commented May 9, 2016

I think Kontalk is the right way to go.

@zgrimshell

@mimi89999
Member

@TheJJ

i'd go for a true p2p approach.

There is Ring, but IIRC it doesn't support FS.

@pravi
pravi commented May 9, 2016

I have used tox.im in the past and it used huge amount of data. Full p2p is possible only if you have an unlimited data plan, which is not the case in this part of the world where I live (India). So federated messaging works best, kontalk is just perfect, except for missing group feature (groups feature is in alpha and I hope it will be available soon, once its available, I can happily drop LibreSignal).

@mimi89999
Member

@pravi Don't forget that Kontalk also doesn't support FS...

@cjeanneret

@mimi89999 on its way, they are just lacking dev and people ;).

@mimi89999
Member

@eighthave

OTR v4 protocol will include something like the Axolotl/Signal ratchet for better mobile/async support

What is the difference between Axolotl/OMEMO and OTR v4?

@kaepora
kaepora commented May 9, 2016

I think @moxie0 should be more honest here.

Moxie, this isn't about you being bothered by other people using the word "Signal" as part of their name (in its own, ridiculous), or about you being bothered by federation (you've asked Telegram, of all people, to federate into your network, which I understand must be attractive due to their hundred million users.)

Why don't you give me a break and clarify your position on the Signal protocol's licensing? You have claimed to multiple open source projects that they are not allowed to publish applications on App Stores that use the Signal Protocol's four-way signed-plus-one-time-prekey handshake in combination with the Axolotl ratchet, even if they write their own implementation from scratch, because since the only existing original specification of such a protocol is your libsignal, all other implementations are, in your words, "necessarily derived work." and so cannot be re-licensed from GPLv3 for submission to App Stores (Apple, etc.) unless you give your blessing!

I challenge you to clarify this once and for all. Is the Signal Protocol specification, not the implementation, under any sort of licensing, intellectual property claim, or patent? Or is this another element in your coterie against other open source projects forking from your excellent contribution to secure messaging?

I must say, you really are the worst anarchist I've ever encountered in my life; but I'm no authority on the matter. Writing good software doesn't give you a license to bully other projects around unless they give you a WhatsApp-level payout. How about you keep your narcissism tucked in so that secure messaging in general doesn't have to suffer from it?

@haffenloher

or about you being bothered by federation (you've asked Telegram, of all people, to federate into your network, which I understand must be attractive due to their hundred million users.)

The post you link to is from 2013. Back then, Telegram did certainly not have a hundred million users (they just launched) and OWS had not yet gone through the experience of federating with CyanogenMod's Whisperpush service. They tried it and the experiment failed.

@kaepora
kaepora commented May 9, 2016 edited

The post you link to is from 2013. Back then, Telegram did certainly not have a hundred million users (they just launched) and OWS had not yet gone through the experience of federating with CyanogenMod's Whisperpush service. They tried it and the experiment failed.

Do you believe for a second that if Telegram wanted to federate today, OWS would turn down a hundred million users?

But it doesn't really matter. I am making an expression of frustration against what I perceive as plain old dishonesty from OWS. They want to release open source software but don't want anything to do with whatever that entails, not even to the point of allowing client forks to connect to the network or to allow totally independent protocol implementations to even re-use the same cryptographic constructions under a different license.

I've been aware of these little pinpricks of dishonesty from OWS for a few weeks now, and it just so happens that this issue sort of took the cake. A change of policy, and more accountability, is needed, most especially since they're the new stewards of the world's most popular encrypted secure messaging protocol.

Viber recently implemented a Signal-like protocol in their clients, but it too did not include the four-way Diffie-Hellman handshake that prevents forward secrecy weaknesses. This is because even if they had written their own protocol implementation, Moxie's claims over the idea of the Signal protocol still would have hounded them. The same is true for ChatSecure which was unable to obtain the ability to publish their own implementation of libsignal, even though it had no fork basis in the original. This is unacceptable.

Edit: I'd like to clarify that the example above regarding Viber is indeed just an example. I do not at all believe that Viber was actually approached by anyone discouraging them from implementing any particular cryptography.

@haffenloher

They want to release open source software but don't want anything to do with whatever that entails

yeah, to be honest, that's a feeling I can very well relate to

@vanitasvitae

@Kontalk Don't you also usw GCM?

@mimi89999
Member

@vanitasvitae They use GCM only in the Play Store version. Not in the F-Droid one.

@pravi
pravi commented May 9, 2016

@vanitasvitae gcm is optional in kontalk. Play store version use it, fdroid version does not.

@vanitasvitae

Ah nice! That's the way I'd like Signal to go.

@weiss
weiss commented May 9, 2016

@moxie0

using phone numbers as identities is a strong growth engine for modern messengers. So you can pick one: federated identifiers, or a product people use.

Isn't a phone number a "federated identifier"?

@zgrimshell

@weiss

Isn't a phone number a "federated identifier"?

That isn't working on Signal anymore WhisperSystems#5384

but hey, WhatsApp works and moxie already took pride on its Signal protocol usage -.-

@schiessle

I know it is a quite heated discussion. Let me start that I use Signal on a daily basis and I think it is by far the best app we have at the moment. So everything I write should be seen in the light of a big Thank You for this great app! The reasons why I think that it is the best option are:

  • How far I can tell it and what other crypto experts say, it has the best crypto protocol
  • It is Free Software (this has nothing to do with being a "free software moralists", Free Software is a pre-requirement for security)
  • It is "as easy as WhatsApp", like it or not that for example you have to use your phone number. Being like WhatsApp is a crucial point in making people consider to switch
  • It is fun to use

I also don't ask for federation. We have stuff like XMPP for this and I use both regularly. Both have their user base and use case, which are not always the same. It is not a either-or decision! I would love to see something more simple:

I think you can pretty easily be a cryptonerd and use Signal today without any forks. If you don't want to install Google's official Play Services on your phone, install an open source version like GsmCore instead. Problem solved, no LibreSignal required.

That's completely right @moxie0, but people who don't want to use Google Services don't want to compile Signal from the sources. Here you ask for something which goes against your own argument "signal should be easy to install and use". That's where other app stores like F-Droid come into play. I consider it really important to have a way to install Signal from F-Droid and I really wonder why you are that much against it? If it is about "control" you could even set up your own F-Droid repository, sign it with your keys and make sure to push updates in time.

Another point is that it would be a really great improvement if people could use something like WebSocket or just polling as a option. Many apps support it, e.g. Threema. I don't understand why you are that much against it. It doesn't cost anything but you gain new features and new users.

Both options, using it without Google Services and installing it as easy as from Google Play from a different source is not only important for "free software moralists" and "cryptonerds" but also for users who use a Android version which come without Google, e.g. CopperheadOS or a complete other operating system with Android-App compatibility. For example I'm happy that I can chat with a friend who has a Jolla phone with LibreSignal installed.

So all I, and many others, are asking for is for fairly simple stuff which wouldn't make Signal in anyway worse for other people: install it from other app stores, and have a option to use it without GCM.

@vanitasvitae

@schiesbn I agree. Also @moxie0 s argument that other app stores or distributed apks weaken security is not right. Yes, if a user installs an apk by himself he has to tick the "external sources" check box, which is a potential security problem. But what is the alternative? Not using Signal at all?

@cjeanneret

@vanitasvitae +42. You tick it, install it, untick it. Easy, in fine.
On my side, Threema is my favorite β€” unfortunately not opensource, and won't be due to the business model (had many discussions with them about that). But this one can, at least, allow to NOT use GCM with a simple, configurable polling setting.

@moxie0 please consider "polling" and "OWS f-droid repository". Think about it. Really. That would solve in a convenient and pretty way many issues…

@schiessle
schiessle commented May 10, 2016 edited

On my side, Threema is my favorite β€” unfortunately not opensource, and won't be due to the business model (had many discussions with them about that).

Completely off-topic here. But not being Free Software is a complete show-stopper for me. As said, being Free Software is a pre-requirement for security. If it is not Free Software I have to trust them the same way I would have to trust WhatsApp, etc.

I also don't buy the argument about the business model. If Threema would be Free Software they could still sell it on their web page and on the play store, Apple store, etc. Even if someone would upload a copy to F-Droid, 99% of the users would still get it from the official app stores and pay for it. Fwiw, we see something similar for the ownCloud client. Even if they fear the 1%, which I think is silly, they could change the way how people pay from "paying for the app" to "paying for the initial registration on their servers".

But enough off-topic!

@SecUpwN
Member
SecUpwN commented May 10, 2016

Hey folks, I've just received a message from Mike Kuketz from the German Kuketz IT-Security Blog who also wrote about our project. He basically said that we shall let Signal (and repectively LibreSignal) die. It is not worth the pain fiddling with all the shit Moxie Googlespike is throwing at us (and rest assured that will happen internally in his team and elsewhere on important places on the web). IT-Security geek Mike is a conviced enthusiast of Conversations - an encrypted, mobile friendly XMPP client for Android. We should take a look at that, it is also on GitHub. I am still hoping that Mike will finally register and chime in.

@paride
paride commented May 10, 2016 edited

@SecUpwN, it has been already mentioned earlier in this thread, but I think Moxie is right about this, those are projects the average user will never use. And I think that everything is about the setup process, identity (phone number), contacts discovery and simple interface. Kontalk seems a better alternating in this regard, maybe we should just focus there. It's a shame because I personally brought at least 20 persons on Signal (average users, not moralist cryptonerd punks).

@eighthave
@paride
paride commented May 10, 2016

@eighthave, Signal does not upload your contacts to a server, see the very interesting:

https://whispersystems.org/blog/contact-discovery/

@vanitasvitae

@legovini:

As far as we can determine, practical privacy preserving contact discovery remains an unsolved problem.

For RedPhone, our user base is still manageable enough (for now) to use the bloom filter technique. For TextSecure, however, we've grown beyond the size where that remains practical, so the only thing we can do is write the server such that it doesn't store the transmitted contact information, inform the user, and give them the choice of opting out.

@mimi89999
Member

@legovini

Signal does not upload your contacts to a server, see the very interesting

Look at #35

@paride
paride commented May 10, 2016

You are right, sorry.

@mimi89999
Member

I agree with @SecUpwN that we should let this project die. 😞 I think that Conversations is a good alternative. I'm using it with an XMPP server that I host on a Raspberry Pi 2. πŸ˜„ My JID is the same as my email address. πŸ˜„

@paride
paride commented May 10, 2016 edited

At this point I'm considering ditching Signal for Telegram (secret chats) to communicate with non-technical users, while I'll use ChatSecure/Conversations/Ring/whatever with my cryptonerd friends.

Telegram's server is not open source, but neither Signal's server is (at least the RedPhone part). And they don't oppose third party clients (what an absurdity, after all!):

https://telegram.org/faq#q-can-i-use-the-telegram-api

The point is finding the right compromise, and my goal is to protect myself from mass surveillance, not from targeted surveillance. This could be fair enough for me, this while keeping an eye on Kontalk.

@vanitasvitae

Perhaps a bountysource would be appropriate?

I'd support that :)

@hex-m
hex-m commented Jun 29, 2016

@f41c0r you don't have to wait for someone to allow it or do it for you. ;)

even more off-topic:
They (OWS) have their own "competitor" to bounty source but for now it does only pay per merged pull request, not for a specific feature. (see WhisperSystems/BitHub#4)

@vanitasvitae

I just opened #43 and postet a bountysource. I really hope there will be some progress on adding Websocket support to Signal now. If anyone wants to contribute feel free to do so πŸ˜ƒ
https://www.bountysource.com/issues/35722527-create-proper-pull-request-to-add-libresignal-s-websocket-support-to-ows-signal

@paride
paride commented Jul 5, 2016

@hex-m I think that whoever posts the PR that gets accepted would be able to collect both.

@vanitasvitae

Was it clever to open the issue in this repository? Can someone create a "OWS" branch which is a copy of Signals master, where the PR can be made against, so it can later be merged with Signal without problems?

@mimi89999
Member

@vanitasvitae He can clone the Signal repo and merge some code from here.

@vanitasvitae

@mimi99999 I just wasn't sure about bountysource. Can the bounty be claimed, if the PR goes to another repo? I never did something with bountysource before...

@grote
grote commented Jul 5, 2016

He can clone the Signal repo and merge some code from here.

This language assumes that the person doing this work will be male. A different language can help to create more diversity in our community. It can help non-male persons to be feel more included, respected and welcome.

@mimi89999
Member

Sorry. @grote I agree.

@pravi
pravi commented Jul 6, 2016

I usually use the plural form 'they' which is neutral.

On 2016, ΰ΄œΰ΅‚ΰ΄²ΰ΅ˆ 6 1:37:18 AM IST, Torsten Grote notifications@github.com wrote:

He can clone the Signal repo and merge some code from here.

This language assumes that the person doing this work will be male. A
different language can help to create more diversity in our community.
It can help non-male persons to be feel more included, respected and
welcome.


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#37 (comment)

@Mikaela
Mikaela commented Jul 6, 2016

I usually use the plural form 'they' which is neutral.

It*s actually known as "singular they".

@vanitasvitae

Is someone actually working on the PR? It would be embarrassing, if nothing follows this heated discussion :/

@Asara
Asara commented Jul 13, 2016

+1 for BountySource.

Is anyone working on this PR? Or is it time to ditch the Signal ecosystem all together?

Many people recommend OMEMO over XMPP but there isn't yet a compatible iOS app to communicate using OLM/OMEMO. ChatSecure claimed months ago they would release it in their next version but it doesn't seem to have progressed. For this reason I want to continue to use Signal/LibreSignal.

Thanks!

@iNPUTmice

Is anyone working on this PR?

Even if someone was working on that it is completely unclear if and when that PR would get merged

Or is it time to ditch the Signal ecosystem all together?

Using Signal is fine (even though it has almost no benefit over WhatsApp). It's the 'Libre'Signal approach that is heavily flawed. Even if you ditch GCM your meta data is still in the hands of one US based company. The meta data that flows through Google is completely negligible compared to the meta data that runs through OWS.

Many people recommend OMEMO over XMPP but there isn't yet a compatible iOS app to communicate using OLM/OMEMO. ChatSecure claimed months ago they would release it in their next version but it doesn't seem to have progressed.

It is progressing. Just because the developer isn't tweeting about it every 5 seconds doesn't mean there isn't any progress.

@pravi
pravi commented Jul 17, 2016

On 2016, ΰ΄œΰ΅‚ΰ΄²ΰ΅ˆ 17 7:03:46 PM IST, Daniel Gultsch notifications@github.com wrote:

Or is it time to ditch the Signal ecosystem all together?

Using Signal is fine (even though it has almost no benefit over
WhatsApp).

There one significant advantage - Signal client is Free Software. With WhatsApp, you have to blindly trust them on end to end encryption, with Signal, you can not only verify it independently, but with reproducible builds you can verify the binary corresponds to published source code as well.

There is smaller advantage that server is free as well. But since OWS server won't federate with other Signal servers, the advantage is not very big. It theoretically means, we can have servers outside US.

@pravi
pravi commented Jul 17, 2016

Is there anyone interested in running a Signal server outside US? The main advantage would be to break away from metadata centralization. We could later add more servers and federate among ourselves. We'll have to modify the client to connect to both servers. If both users are on the new server we should prefer that connection, if not then fallback to Signal servers. If someone is willing to code the client side, I'm volunteering to run the server side.

@mimi89999
Member

@iNPUTmice

Using Signal is fine (even though it has almost no benefit over WhatsApp). It's the 'Libre'Signal approach that is heavily flawed. Even if you ditch GCM your meta data is still in the hands of one US based company. The meta data that flows through Google is completely negligible compared to the meta data that runs through OWS.

There is the advantage, that you don't have to have the proprietary gapps running with system app privileges (if somebody fears, that they might be a backdoor or is a FOSS/FLOSS nerd.) πŸ˜„ The idea was never to really protect against metadata collection on the server, but to allow people with gappless devices to communicate with Signal users.

@mimi89999
Member

@pravi

Is there anyone interested in running a Signal server outside US? The main advantage would be to break away from metadata centralization. We could later add more servers and federate among ourselves. We'll have to modify the client to connect to both servers. If both users are on the new server we should prefer that connection, if not then fallback to Signal servers. If someone is willing to code the client side, I'm volunteering to run the server side.

What would be the advantage over XMPP + Conversation? We might as well run a secure XMPP server with good XEP support if one is needed...

@vanitasvitae

Plus we would not be bound to (Libre)Signal as client app/program

@pravi
pravi commented Jul 17, 2016

On 2016, ΰ΄œΰ΅‚ΰ΄²ΰ΅ˆ 18 12:46:16 AM IST, Michel Le Bihan notifications@github.com wrote:

@pravi
What would be the advantage over XMPP + Conversation? We might as well
run a secure XMPP server with good XEP support if one is needed...

Why did we start using Signal in the first place when we could have used xmpp+conversations?

  1. Its easy to get started for users familiar with WhatsApp. Creating an xmpp account is still a big hurdle for xmpp addition.
  2. It works like SMS/Text Message over data
  3. You can easily find contacts using your phone's addressbook
  4. For some users iOS support is important
  5. For some users crypto is important

I know the privacy advantage of xmpp+conversations, and prefer it, but its not just about my personal preference but about people I want to communicate with as well.

@mimi89999
Member

@pravi
5. Conversations has very good crypto.
4. For iOS there is chatsecure, that supports OTR. It isn't as convenient as OMEMO, but still more or less usable.
Creating a LibreSignal for iOS, that works with other servers will be really complicated. Just to give an example: Xcode (the app for developing apps for iOS) only works on OSX.

As for the rest: Your contacts probably use nicknames on Twitter/Instagram/Snapchat/some other thing. Why can't they use nicknames for IM?

@thestinger

There isn't an alternative to using the Apple Push Notification Service on iOS other than it simply not working at all in the background, and there's no way to avoid having it around. Not much point in an equivalent to LibreSignal there.

@gjedeer
gjedeer commented Jul 18, 2016
  1. Its easy to get started for users familiar with WhatsApp. Creating
    an xmpp account is still a big hurdle for xmpp addition.

With a network of non-OWS federated servers, this advantage will be gone.

.

@Mikaela
Mikaela commented Jul 18, 2016
  1. For some users iOS support is important

For some users Windows Phone, SailfishOS and Ubuntu Touch support are also important.

I believe Conversations is Android-only and OMEMO isn't supported on any other mobile platform yet even if XMPP clients probably are available for them all even if the quality (SfOS Messaging doesn't do MUCs) can vary.

@jomo
jomo commented Jul 18, 2016

This discussion has switched topic several times. Could we split it up, so we'd have an issue to discuss WebSockets in Signal and another one for a meta discussion about crypto messaging (or move the latter somewhere else entirely)?

@mimi89999 mimi89999 referenced this issue in JavaJens/TextSecure Jul 20, 2016
Open

Update to 3.16 #91

@secureemail
secureemail commented Jul 27, 2016 edited

Interesting how the conversation switched from ~"can we have WebSockets in Signal please?" to ~"maybe it's better to use ChatSecure/Conversations/Zom/.. + our own servers after all" (metadata and other issues).

And I agree, although Signal is convenient for the masses because mainly of its simplicity/convenience, the metadata issues mentioned by @iNPUTmice are there (metadata is not unimportant: "we kill based on metadata" and Signal's server are based in the USA). If we are concerned about privacy, using Signal's server is out of question (even if Signal has quite a userbase and Edward Snowden said "I use Signal every day.", doesn't mean he/they know what they are doing. WhatsApp has even more users but they know even less what they are doing privacy-wise (seems like the less users an app has the smarter they are)). So either one must be able to host its own Signal compatible servers, but is that even possible/feasible; reverse engineering the protocol necessary? Reverse engineering would be obviously annoying and @moxie0 himself said that the protocol moves along rather quickly, so RE would need to be up to date, and that's not really a solution. Or it seems to me that using Conversations, Zom (BTW: is it an un/official ChatSecure successor? code is the same up to a certain fork-date and ChatSecure's development has stopped) (BTW: it has improved usability from ChatSecure and makes it more appealing to a wider range of non-techy users -- that's a start), ChatSecure (when or if it has OMEMO) is the best solution after all, even if it's not comfortable.

Signal has their servers running because they have money input. But when running your own server be it even by a company, one has to make sure there is money to keep it running. Hopefully it's not an issue -- imagine a XMPP server which has been running for >10 years suddenly shuts down without any warning (well because mainly of money issues).

Metadata is indeed an issue, that's why there's DIME by @ladar. Unfortunately development stalled due to money (yes, again, we see that money income when running your own XMPP server may be an issue).

By best friends switched to ChatSecure when I said to please do so and explained why. They are not even techy, just my best friends. If your friends don't want to switch or additionally install it, maybe you should consider whether they are really your friends, worth it or whatever.

PS: Signal has RedPhone encrypted calls, but do Conversations, Zom or others have it? Or any alternatives that have it?

@mimi89999
Member

@secureemail

Metadata is indeed an issue, that's why there's DIME by @ ladar. Unfortunately development stalled due to money (yes, again, we see that money income when running your own XMPP server may be an issue).

Could you link me DIME?

@mimi89999
Member

Signal has RedPhone encrypted calls, but do Conversations, Zom or others have it? Or any alternatives that have it?

AFAIK CSipSimple + Ostel account is still the best solution. You might also want to try Ring.

@grote
grote commented Jul 27, 2016

And I agree, although Signal is convenient for the masses because mainly of its simplicity/convenience, the metadata issues mentioned by @iNPUTmice are there (metadata is not unimportant: "we kill based on metadata" and Signal's server are based in the USA). If we are concerned about privacy, using Signal's server is out of question

How does ChatSecure and XMPP solve this metadata problem? If you don't trust moxie to not record metadata, why do you trust all of those XMPP server administrators and their abilities to secure their servers? Isn't metadata even spread over more servers with XMPP thus increasing the risk for it to leak?

@Asara
Asara commented Jul 27, 2016

@grote: Setting up your own XMPP server that supports OMEMO isn't difficult.

Asara/Ansible@3572aa7

Not really prod-ready, but it works well enough for me.

@grote
grote commented Jul 27, 2016

Setting up your own XMPP server that supports OMEMO isn't difficult.

Yes I know. I am running a XMPP server myself. But this doesn't answer the metadata question, because I still need to trust the admins of the servers all my contacts are using, because they potentially have the metadata that relates to communication with me. AFAIK OMEMO does not hide from which JID to which other JID messages were sent when.

Also, a powerful adversary should be able to perform timing attacks even if all contacts are using their own servers.

@mimi89999
Member

@grote These are known issues with federated networks, but P2P networks have other with high impact on battery life as the worse IMHO.

@Asara
Asara commented Jul 27, 2016

@mimi89999: Is there any plan to make libresignal's websockets mechanism as a fallback for Signal? Or should we be actively abandoning this hope?

@mimi89999
Member

@Asara No plans to make the websockets PR. Sorry.

@pravi
pravi commented Jul 27, 2016

On 07/27/2016 09:09 PM, Torsten Grote wrote:

Setting up your own XMPP server that supports OMEMO isn't difficult.

Yes I know. I am running a XMPP server myself. But this doesn't answer
the metadata question, because I still need to trust the admins of the
servers all my contacts are using, because they potentially have the
metadata that relates to communication with me. AFAIK OMEMO does not
hide from which JID to which other JID messages were sent when.

The metadata is spread out, an adversary has to break all the servers to
get all your metadata. The cost and complexity (different jurisdictions)
of mass surveillance is increased by a huge amount.

You can use multiple JIDs to increase anonymity. How do an adversary
know which all JIDs belong to you? Unlike a phone number, you have much
more options to choose a JID. Add tor to the mix if you want even more
anonymity.

Also, a powerful adversary should be able to perform timing attacks even
if all contacts are using their own servers.

Use end to end encryption.

@secureemail
secureemail commented Jul 28, 2016 edited

@mimi89999 https://github.com/lavabit/libdime

Thanks, will look into CSipSimple + Ostel and Ring. Wonder why Conversations and Zom don't have it yet or whether it's planned.

@Asara Thanks for the infos.

@grote Regarding metadata: I'm not sure but as a company in the USA, isn't Moxie forced to save metadata anyway? And as nobody knows what data are collected, I don't trust them of course (even if we "knew"). You are correct, trusting other admins when using their XMPP servers is also an issue but here one has a much bigger choice of servers (in different nations, with different laws), and you can (should?) run your own server of course. But is it always better? As you say, I quote:

Isn't metadata even spread over more servers with XMPP thus increasing the risk for it to leak?

Good point. I don't know. Maybe there is no perfect solution?: Having only one server could make collecting data easier; Having accounts on different servers, well, maybe harder, but it depends of course where the servers are hosted, does one know the admins and can one trust them; and probably other points. And what about hosting your own server, and/or having accounts only on one's own server? Well, well, how do we say in Germany: ~"Questions over questions" :)

So I'm not even sure that @pravi it correct that having accounts on different servers is the best way/makes it always harder for them, or maybe there's no "best way" because it depends on some of the above points and/or other points?

Isn't it at least kind of liberating to be able to run your own server? I think so. Good point also that one is not connected with one's phone number and the ability to add Tor. These adds a healthy amount of salt to the mix, lol (still, mustn't means it's more secure).

Also, a powerful adversary should be able to perform timing attacks even
if all contacts are using their own servers.

Use end to end encryption.

I didn't mention E2EE because it was a given (OMEMO) but if it protects or helps against timing attacks, then that's great.

AFAIK OMEMO does not hide from which JID to which other JID messages were sent when.

@pravi Good to know about that what you just said. But if JID is not hidden, I wonder what else is not hidden (Wireshark probably would show it). Seems like when or if @ladar is finished with DIME, the next project he (or of course someone else) could do it to hide more metadata in XMPP.

So, @mimi89999 and others, what do you think, maybe abandon Signal after all? Or maybe some infrastructure changes could be done to improve the situation? (but here you would need to hope that Moxie is ok with implementing them) What alternatives do/would you use? Conversations, ChatSecure, its un/official? successor Zom, Ring, ... ?

@mimi89999
Member

@secureemail

what do you think, maybe abandon Signal after all?

Yes

Or maybe some infrastructure changes could be done to improve the situation?

Those would have to change completely Signal design.

What alternatives do/would you use? Conversations, ChatSecure, its un/official? successor Zom, Ring, ... ?

I am using Conversations on my Android device and Gajim on my PC running Debian (I was using Pidgin, but it doesn't support OMEMO).
I tried Ring with my friend, but it quickly ate our battery. Also last time I asked (it was several months ago) Ring encryption of messages isn't FS. 😞

@grote

But this doesn't answer the metadata question, because I still need to trust the admins of the servers all my contacts are using, because they potentially have the metadata that relates to communication with me.

They only have the metadata related to you and your contacts, that are on your server, so they have x% of what a centralized network like Signal can collect (where x is number of your contacts using that server divided by the number of all of your contacts).

AFAIK you are using Briar. Could you share your battery statistics?

Also XMPP has other useful features, that I haven't found in any P2P network/app: human readable and memorable IDs, one ID on several devices, history sync, roster sync, etc. (since I am hosting that server, I have nothing against keeping my contact list and other data there).

@secureemail
secureemail commented Jul 29, 2016 edited

@mimi89999 I like this decision because everything is better than being dependent on them and their infrastructure.

To the metadata thing: Obviously having everything on WhisperSystems's servers which are located in the USA is the worst situation. But e.g. having multiple servers in the USA isn't much better either (for new readers: read my previous post where I mention several different cases regarding this).
I agree, XMPP certainly has also advantages.

Conversations, which is one of the most promising ones, but needs to add/change some rather expected things/features which users complained about: https://www.kuketz-blog.de/conversations-sicherer-android-messenger/#comment-47489

Also mentioned there were:

@mimi89999
Member

Briar looks quite interesting. It is decentralized, but it isn't based on IP addresses (the ISP would have the metadata) nor it is based on a DHT (like torrents) (I tried Ring (based on a DHT) and it almost ate my battery).

Because Briar requires you to meet in person with your contact or to be introduced, I think, that it is for people with special needs, not for everybody. I often cross my fingers and trust my contacts' fingerprint because I need to chat with that person before we have the possibility to meet. Also, people often publish their OMEMO fingerprints on their websites, so at least there is the possibility to check against this.

@grote
grote commented Jul 30, 2016

I'm not sure but as a company in the USA, isn't Moxie forced to save metadata anyway?

I am not sure about this, but I think he stated publicly that he is not storing any metadata. Up to you to trust him or not.

I didn't mention E2EE because it was a given (OMEMO) but if it protects or helps against timing attacks, then that's great.

I don't think it does.

Briar looks quite interesting. It is decentralized, but it isn't based on IP addresses (the ISP would have the metadata) nor it is based on a DHT (like torrents) (I tried Ring (based on a DHT) and it almost ate my battery).

Yes DHT is deadly for your battery. Briar does not do this. It does not open connection to other people and relays messages all the time. It only connects to your contacts through a variety of different transports such as Tor, but also Bluetooth and WiFi which also make it work when the internet is down or has been switched off by your favorite government.

However, Briar is not ready and did not optimize battery usage, yet. It is still a lot better than Tox or Ring (both use DHT), but burns a lot more than Conversations. Once optimized, it will most likely still burn more than Conversations, but not too much actually. For example, when you use Tor for long-range data transport, it also needs to keep one connection into the Tor network open similar to Conversations needing to keep the connection to your XMPP server open.

Because Briar requires you to meet in person with your contact or to be introduced, I think, that it is for people with special needs, not for everybody. I often cross my fingers and trust my contacts' fingerprint because I need to chat with that person before we have the possibility to meet.

Actually, man-in-the-middle attacks are currently one of the biggest threat for messengers like Signal and even Conversations, because they just use TOFU and just show a warning when your keys change. Most people ignore those warnings opening the door for MITM.

Briar wants to make it difficult for people to shoot themselves in the foot easily, so that is why it put the personal verification first. But you can also get introduced to other people by trusted intermediaries and verify the identity of the introduced people later when you meet. It is also planned to provide other means of adding contacts like scanning a QR code that people publish on their website for example.

So I don't want to tell people to stop using Signal or XMPP, I just invite you to be open to whatever might come after, because the current solutions still have potential to be improved upon. For people that are interested in more details, I recently gave a presentation about exactly this: Youtube or OGG.

@mimi89999
Member

It is good to care about users' security, but at that point, I can't just test Briar with a random person in this conference TOFU based nor with my Conversations contacts, that I trusted OMEMO keys.
On top of that, it is worth mentioning, that we basically can't trust our mobile devices.

@mimi89999 mimi89999 closed this Jul 30, 2016
@secureemail
secureemail commented Jul 31, 2016 edited

because they just use TOFU and just show a warning when your keys change.

Couldn't that be easily solved by adding a setting like: "show warning and block chat to partner until approved again"? (may also make it a default setting)

On top of that, it is worth mentioning, that we basically can't trust our mobile devices.

Always good when you could provide sources and say why or which devices may come the closest to be trustable.

Recently there's this comparison going on: https://docs.google.com/spreadsheets/d/1tv5QTuoS29YwApP7i2OKe9aLrZZIwgY-f5b-d73vlI0 (unfortunately I can't see it all because I don't allow JavaScript to google.com)
And https://www.eff.org/secure-messaging-scorecard

@mimi89999
Member
@mray
mray commented Aug 19, 2016

In how far is LibreSignal dead now? What does that mean when i get my builds from fdroid.eutopia.cz with the fake google apps installed?

@xmikos
Member
xmikos commented Aug 19, 2016

@mray LibreSignal (this WebSocket-fork GitHub repository) is practically dead (on life support), so sometime in the future there will be no new builds in _experimental_ repository on fdroid.eutopia.cz. It depends on how long this GitHub repository will continue to be updated (and it is indeed possible that latest update 3.16.1 is also the last one).

But _main_ repository on fdroid.eutopia.cz is not dead at all, it is build from official Signal sources (only renamed to LibreSignal because of legal threats) and I will continue to update it in the future. So if you have microG (opensource Google Play Services alternative) installed, you will be still able to use independent builds of Signal from fdroid.eutopia.cz main repository.

@xmikos
Member
xmikos commented Aug 19, 2016 edited

@mray LibreSignal builds in both _main_ and _experimental_ fdroid.eutopia.cz repository are signed by the same key, so you can switch between them without losing app data.

Only if you want to switch from LibreSignal (WebSocket) to LibreSignal (from main repo), you have to reinstall it manually via this command:

adb install -r -d PATH_TO_APK_FILE

This is needed because builds of WebSocket-fork of LibreSignal (from experimental repo) have always higher version number than builds of LibreSignal from main repo. And Android by default doesn't allow version downgrade. But like I said app data will be preserved, you will not lose anything.

@paride
paride commented Aug 23, 2016

The "wire" app has been recently open sourced:

https://wire.com/
https://en.wikipedia.org/wiki/Wire_Swiss
https://github.com/wireapp/wire-android

I'm pretty sure it still depends on GCM, but their TOS is more reasonable than what OWS tries to enforce. From https://wire.com/legal/#apps-use-requirements:

Open Source Apps. If you choose to build an Open Source App, certain restrictions apply, as follows: a. You agree not to change the way the Open Source App connects and interacts with our servers; b. You agree not to weaken any of the security features of the Open Source App; c. You agree not to use our servers to store data for purposes other than the intended and original functionality of the Open Source App; d. You acknowledge that you are solely responsible for any and all updates to your Open Source App.

@xmikos
Member
xmikos commented Aug 23, 2016

@legovini Wow, this is great! Finally excellent opensource alternative to Signal (even with encrypted voice and video calls).

But you are right, there is GCM dependency in build.gradle, but maybe Wire is able to work without it? We will need to try it and see what happens. Or maybe they will be open to add WebSocket support (they have web-based client too).

@mimi89999
Member

Hmm... Wire looks centralized and that isn't good for metadata privacy.

Better would be to get voice and video calls in Conversations.

@xmikos
Member
xmikos commented Aug 23, 2016

@mimi89999 Yes, Wire is centralized in same way as Signal. But Signal has opensource server (at least for messages), Wire's server is proprietary (to my knowledge). On the other hand, Wire client is much more advanced and Wire company is not based in USA (and seems to have much more open policy toward independent builds of their app).

Of course Conversations or future OMEMO-based version of ChatSecure / Zom (if it added encrypted voice and video calls) would be much better privacy-wise. But I am afraid it stands no chance to get widespread adoption between common people. And it is not there yet anyway.

So if Wire could work without GCM (and that is a big if), I think it could be IMHO good interim solution.

@paride
paride commented Aug 23, 2016 edited

Would https://github.com/microg/android_external_GmsLib allow for GCM-dependent apps to be compiled without non-free dependencies, and thus included in f-droid?

(I know this solves just the licensing issue, not the privacy issue of sharing data with Google. Still, for services that are already centralized, like Signal or Wire, it could be an acceptable solution.)

Edit: I've got the answer on IRC. Building against android_external_GmsLib would allow for inclusion in f-droid with the (very well deserved) "non free network" anti-feature, unless the app also works without the Google stuff.

@ghost
ghost commented Aug 24, 2016

I've seen some comparison links here, another comparison you can find at http://secushare.org/comparison

@zarere
zarere commented Aug 26, 2016

Wire doesn't work with microG
wireapp/wire-android#10

@paride
paride commented Aug 26, 2016

@zarere it's not free software (not even open source), and its security design is not documented.

@zarere
zarere commented Aug 26, 2016

@legovini
True but at least tested here
https://www.eff.org/node/82654
even this guide is outdated already.I'm looking for the new scoreboard here
https://www.eff.org/secure-messaging-scorecard
but still no updates ;-(

@strobelm

Perhaps one should mention some bullet points to our non-German speaking
fellows:

  • it's yet another walled garden as the server part is not open source
  • their business model is unclear
  • they give the impression to operate under Swiss law but this is
    unconfirmed, probably it's rather US law
  • there is indication that a Skype founder has his finger in the pie

Am 18.09.2016 um 16:39 schrieb shellshocker:

Why you should NOT use Wire:
1.
https://www.kuketz-blog.de/wire-messenger-und-taeglich-gruesst-das-murmeltier/
2. https://www.kuketz-blog.de/wire-messenger-hintergrundinformationen/

β€”
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#37 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANhz4rud5ZhRPlfFc-F5As9ERBavujyDks5qrU0mgaJpZM4IXUsG.

Michael Strobel, M.Sc.

Technische UniversitΓ€t MΓΌnchen -- Zentrum Mathematik
Lehrstuhl fΓΌr Geometrie und Visualisierung (M10)
Boltzmannstr. 3, 85747 Garching bei MΓΌnchen
https://www-m10.ma.tum.de/bin/view/Lehrstuhl/MichaelStrobel

@xmikos
Member
xmikos commented Sep 18, 2016

@shellshocker Yes, Wire is walled garden (like Signal), but it is also better than Signal in many other ways:

  • it works without Google Play
  • it doesn't need your phone number (it works also with email based registration)
  • it is much more feature-full (video calls, etc.)
  • and most important is that they are much more friendly towards FOSS community than Open Whisper Systems (see e.g. this example as illustration from last month: https://twitter.com/kaepora/status/763015359758671873)
@strobelm

Am 18.09.2016 um 17:48 schrieb Michal Krenek (Mikos):

@shellshocker https://github.com/shellshocker Yes, Wire is walled
garden (like Signal), but it is also better than Signal in many other ways:

  • it works without Google Play
    ...

That's unfortunately not true
https://twitter.com/wire/status/765561001454530560

Michael Strobel, M.Sc.

Technische UniversitΓ€t MΓΌnchen -- Zentrum Mathematik
Lehrstuhl fΓΌr Geometrie und Visualisierung (M10)
Boltzmannstr. 3, 85747 Garching bei MΓΌnchen
https://www-m10.ma.tum.de/bin/view/Lehrstuhl/MichaelStrobel

@xmikos
Member
xmikos commented Sep 18, 2016

@strobelm According to this, it really works without Google Play services. Maybe notifications (push) will not work for now? I am still using LibreSignal (and have Wire only on device that has Google Play installed) but I am in process of switching to it.

@hakonbo Can you please tell us more about how well Wire works without GCM and if there should be full support (WebSocket) soon?

@xmikos
Member
xmikos commented Sep 18, 2016

@strobelm Also look at this:
https://twitter.com/wire/status/775616447976529920

Android privacy tip: You can use Wire without Google Play. Get APK from http://wire.com/download and enjoy. And yes, notifications will work.

@xmikos
Member
xmikos commented Sep 18, 2016 edited

@strobelm And this:
https://twitter.com/wire/status/776463685443133440

@mrbillshankly In the case that Google play services are not installed, we use websocket.

So it indeed looks like Wire does now fully work without Google Play services, even notifications (via WebSocket).

@strobelm

Thanks for the update! Perhaps one could use Wire's websocket code for
Signal.

Am 18.09.2016 um 18:48 schrieb Michal Krenek (Mikos):

@strobelm https://github.com/strobelm And this:
https://twitter.com/wire/status/776463685443133440

@mrbillshankly In the case that Google play services are not
installed, we use websocket.

So it indeed looks like Wire does now fully work withou Google Play
services, even notifications (via WebSocket).

β€”
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#37 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ANhz4jvS02xvD2zPEhWwHhFzr4yqqtNmks5qrWt7gaJpZM4IXUsG.

Michael Strobel, M.Sc.

Technische UniversitΓ€t MΓΌnchen -- Zentrum Mathematik
Lehrstuhl fΓΌr Geometrie und Visualisierung (M10)
Boltzmannstr. 3, 85747 Garching bei MΓΌnchen
https://www-m10.ma.tum.de/bin/view/Lehrstuhl/MichaelStrobel

@bootofood

Is anybody working on a wire fork that fits into the f-droid guidelines?
I think that f-droid inclusion is very important to get momentum in the FLOSS community.
@xmikos experience with Signal could be very useful here...

@petterreinholdtsen

Look like running the Signal servers have its downsides, if we are to believe this report from The Intercept, https://theintercept.com/2016/10/10/subpoena-to-encrypted-app-provider-highlights-overbroad-fbi-requests-for-information/ .

@xmikos
Member
xmikos commented Oct 10, 2016

@petterreinholdtsen Not everyone lives in the US ;-)

@smichel17 smichel17 referenced this issue in WhisperSystems/Signal-Desktop Oct 19, 2016
Closed

[PLATFORM REQUEST] Create a Signal version for Ubuntu Touch #925

@th3m
th3m commented Nov 3, 2016

"Your version of LibreSignal is outdated and will expire in 4 days"

using the 3.16.1-websocket version, i guess R.I.P. :(

@Asara
Asara commented Nov 3, 2016

Seems like it has been updated again. Thanks for that.

The only reason I am stuck using LibreSignal right now is because there is no good alternative for iOS (for my friends who have iPhones). XMPP + OMEMO is great, and once ChatSecure/ChatSecure-iOS#376 is resolved, we will have a better solution.

@strobelm
strobelm commented Nov 4, 2016
@petterreinholdtsen

[Michael Strobel]

golem.de has a report (in German) on Signal/LibreSignal and discusses
alternatives (like Wire and Conversations):

Which reminds me, are anyone working on making a Signal fork that can
talk to several servers? For example one controlled by Signal and
others controlled by other people? This way it would be possible to use
this client to talk to clients in different walled gardens?

It would make the client less depending on the good will of the Signal
developers.

Happy hacking
Petter Reinholdtsen

@xion00
xion00 commented Nov 4, 2016

I can't understand that a perfect project like that can't find more supporters. It's only some steps away from a perfect communication tool. I want to start a Crowd Funding and hope you support that. The integration into the SMS App without Gapps dependency it's the only way to blaze out other Messengers. Advanced Settings for advanced users would be fine so they can share there keys without upload their Contacts. Is the server side open source? What would it cost? Traffic and setup plus build new components I mentioned? Don't give up this nearly perfectly work. I can't see any other app offering that. Not conversations and not Surespot. What do you think about my ideas and who has the know how to make this posible?

@th3m
th3m commented Dec 20, 2016

Is anybody still using the abandoned websocket version of Libresignal? I still have it, but i feel it is a security risk to keep an app that is abandoned. What do you think?

Moved on Wire by the way and loving it.

@z4lem
z4lem commented Dec 20, 2016

Yes, I'm still using it. There was an update a few weeks ago. I will use it, as long as it's possible..

@mimi89999
Member

@th3m To this day, there isn't any vulnerability (that I know), that would be patched in upstream Signal and not LS.

@z4lem https://github.com/LibreSignal/LibreSignal/wiki/What-to-do-after-LibreSignal-was-abandoned%3F think about changing before your version expires...

@z4lem
z4lem commented Dec 20, 2016

@mimi89999 yeah, I did and it works amazing . Of course, the battery consumption is not the best but i accept it :)
If LibreSignal isn't working one day, I'll have to stop using Signal :/

@d10r
d10r commented Jan 1, 2017

I've landed here because of my astonishment of not finding the Signal App in F-Droid.
As was already mentioned, p2p may be the best solution if the downsides can be limited.
I suggest you to take a look at Status.im which in my opinion has the potential to pave the way for decentralized Apps on mobile.
The built-in messaging component is based on Whisper (not related to OWS), a component of Ethereum (also see JS API of Whisper).

According to the Status devs, the main challenges at the moment are:

  • scalability (it's not yet clear how much the concept of dark routing needs to be compromised for good scalability)
  • notifications: non-stop connection to a p2p network isn't desirable for most mobile device users, thus servers are still needed for notifications

The project is still early stage (first Alpha was release just days ago), but there's a lot of momentum (as in the Ethereum ecosystem in general).

I am not personally involved in the Status project, but closely observing it progressing.
I'm sharing this consideration because of my belief that it is indeed possible to go beyond central and proprietary infrastructure without sacrificing usability, and Status looks like it may become a key component in that journey.

@ChadSki
ChadSki commented Jan 10, 2017 edited

FYI, "Noise", a fork of Signal without the hard dependency on GCM is available in the Copperhead F-Droid repository. See here. To my knowledge they are working on getting the WebSocket changes upstreamed.

@schiessle

To my knowledge they are working on getting the WebSocket changes upstreamed.

Yes, there is already a pull request: WhisperSystems#5962

@JustAskin
JustAskin commented Jan 13, 2017 edited

Noise "lacks support for voice calls and isn’t optimized for low impact on battery life like Conversations". Might as well use Zom or any XMPP client.

I think Signal developers should prioritize enabling it on F-droid as quite a chunk of their potential user base is privacy nazis and tinfoil hatters (proudly including myself) who'd never let Google's playstore touch their device.

There's also no real VOIP FOSS substitute to Signal with everything else being amateurishly broken or difficult for my normie friends to learn. Even Wire collects your metadata. Please make Signal available to us ASAP!
Edit: Wire just changed their metadata logging policy to 72 hours https://twitter.com/wire/status/819541796493504518

@Gwend4l
Gwend4l commented Feb 1, 2017

Just want to drop by to mention that there is an app called Riot which:

  • is free software
  • exists in two versions: one on F-droid without any dependency to GCM, and one on the play store with a dependency to GCM (although it doesn't require a google account).
  • relies on an open and federated protocol called Matrix
  • provides perfect UX (in my opinion), with server side history, E2E encryption, audio/video, file sharing, designed for managing multiple devices/clients for a single user, etc. Basically what Whatsapp/Signal and others provide.
  • has a significantly increasing amount of users, although it's hard to measure since it's federated

While I am self-hosting both an XMPP server and a Matrix server, I'm personally starting to use XMPP less and less to replace everything with Matrix/Riot, as everything "just works" so well, especially on the mobile side. No more weird XMPP OTR errors or lost messages due to having multiple connected devices \o/.

@grote
grote commented Feb 1, 2017

with server side history, E2E encryption,

Aren't those mutually exclusive?

@Gwend4l
Gwend4l commented Feb 1, 2017

If I understood correctly the protocol (but I'm very far from being an expert), each sent message is encrypted for each separate device registered in a given conversation. Which means that even if it's stored on one (or several servers), a message is stored encrypted server-side, and only the client devices that were part of the conversation when the message was sent can read it. But maybe I'm wrong, I'm just a user of the whole thing.

They are using double ratchet, and there was this blog post on their encryption system: https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-encryption-security-assessment-released-and-implemented-cross-platform-on-riot-at-last/

@ara4n
ara4n commented Feb 1, 2017

@grote: the matrix e2e protocol lets you trade-off per room between replayable serverside history and privacy. the participants in the room can replace their ratchets as often as desired to "seal" history from
being decrypted by attackers; the other participants then keep a copy of the prior ratchet states if they want to re-decrypt. It's still in beta but works well other than some scenarios where the ratchet keydata sharing fails between participants, which we are working through now.

@gwend4l thanks for the enthusiasm for matrix :) heads up that whilst the e2e is in beta we make no guarantees to its privacy, but it's increasingly usable and mature. Messages are not encrypted separately for every participant in the room though; they are encrypted once per room but the sender has to make sure that all the recipients have a copy of the sender's ratchet so they can decrypt it.

(disclaimer: i'm the project lead at matrix.org)

@gsantner
gsantner commented Feb 1, 2017 edited

Why not move this over to some kind of discussion forum/group? This is all about libre and secure communication protocols, implementations and so on, but I don't think this is related to the LibreSignal project anymore.

Maybe others are also interested in such a discussion aswell. A general purpose issue on some project on GitHub isn't the right place. I read and like the conversation, but this is all offtopic to LibreSonic and to the issue itself (F-Droid).

@vanitasvitae

@gsantner That was my thought also when I read the latest posts.

@ara4n
ara4n commented Feb 1, 2017

agreed. anyone wanting to learn about Matrix is very welcome at https://riot.im/app/#/room/#matrix:matrix.org. Sorry for contributing to the OT discussion here.

@Gwend4l
Gwend4l commented Feb 1, 2017

agreed as well, and my apologies for my off-topic comment!

@ara4n sorry for my mistake above about the protocol, and thanks for the explanations! (also thanks for your work on Matrix ;))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment