Please add LibreSignal to f-droid

[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

[mimi89999]

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]

@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]

@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.

[mimi89999]

https://cloud.githubusercontent.com/assets/1433926/9705240/83886c9c-54be-11e5-867a-458f24bf9b6a.png

[paride]

@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]

@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]

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

[moxie0]

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]

@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]

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

[h-2]

@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]

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]

@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]

@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]

@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]

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

[mimi89999]

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]

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]

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]

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]

@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]

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]

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]

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]

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]

@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]

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]

@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]

@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]

@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]

@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]

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]

@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]

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]

@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]

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]

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]

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]

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

[SecUpwN]

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]

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]

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]

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]

@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]

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]

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

[BlackerFlag]

@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]

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]

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]

@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...

[zarere]

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

[zarere]

This also looks promising
http://www.apkmirror.com/apk/wickr-inc/wickr/wickr-2-6-4-1-release/wickr-2-6-4-1-android-apk-download/#description

I saw it in 6-th episode of Mr.Robot :-)

[paride]

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

[zarere]

@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 ;-(

[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/

[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]

@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]

@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]

@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]

@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]

@petterreinholdtsen Not everyone lives in the US ;-)

[th3m]

"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]

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]

golem.de has a report (in German) on Signal/LibreSignal and discusses alternatives (like Wire and Conversations): http://www.golem.de/news/verschluesselung-signal-verschluesselung-ohne-googles-play-dienste-nutzen-1611-124246.html

[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]

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]

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]

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]

@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]

@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]

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]

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]

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]

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]

with server side history, E2E encryption,

Aren't those mutually exclusive?

[Gwend4l]

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]

@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]

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]

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]

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 ;))

[PeskyFactoids]

@moxie0 🤣

[ May 7, 2016] since XMPP is a federated protocol, it's also pretty much stuck in time
XMPP is stuck in the late 90s.

cough VoLTE: SIP & XMPP & stuff

Is VoLTE stuck in time also? 🗡

It's why they use Signal

Yes, intellectual sloth is rampant.

Don't want to run Google's Play Services because it's not Free Software?

Nope. It is the bothersome Privacy Rape: people or their privacy are not profit chattel.

@eighthave 🎆

[May 7, 2016] Federation is an important part of why ChatSecure still works in China

Federation is necessary for success.

@mimi89999

"cryptonerds and free software moralists" like me would like to communicate with normal users

yes, without suffering legacy sms texting or worse. Talk about being stuck in time!

@JustAskin

[Jan 13] no real VOIP FOSS .. everything else being amateurishly broken

That is extremely not-true. Pair f/oss voip client with open registration free SIP provider. SIP 2 SIP calls are free. Add zRTP or sRTP as needed.

or difficult for my normie friends to learn.

F---book is a hurdle to learn. If they can F---book they can these other tools with fewer steps or the same signup 'hurdle'.

@Gwend4l @BLeQuerrec

[Feb 1] Matrix/Riot, as everything "just works" so well,
matrix e2e protocol lets you trade-off per room between replayable serverside history and privacy

VoLTE favors XMPP. It just works. It is ubiquitous. XMPP use is becoming inescapable ;P

Our good friend Ben Franklin had something to say about trading security and privacy.

[mimi89999]

@PeskyFactoids

VoLTE -- Voice over LTE?

[akliyan]

@mimi89999,
what about Noise is it not similar to Libresignal? Any difference ?
https://github.com/copperhead/Noise

[mimi89999]

@akliyan They didn't remove proprietary GMS libs.

[akliyan]

It seems that pseudo privacy oriented apps like signal are not any better than popular mass surveillance tools owned by secret services such as Facebook/Whatsapp, except that for the first the agenda is somewhat hidden.
https://www.youtube.com/watch?v=vmre4SeWunk

I am sure Libresignal was forced to shutdown (by servers denial) because it is really promoting what “Signal” is pretending to promote (privacy).
If Moxie and Whisper Systems guys are really interested in community privacy, why should they be rude against improvements brought by “Libresignal” while allowing other forks on their servers, just because they serve, in someway, their hidden agenda ?

It is sad to see this project hit the wall, and I hope someday it will revive. In the meantime, I’m looking for better alternative and would like to welcome suggestions from experts like “Libresignal” promoters.

I am thinking about “Kontalk” but I don’t know much about its “pros” and “cons”. Does it really do what it says it does?

Thanks

[vanitasvitae]

@akliyan Please just read this thread, I think nearly every other messaging app and its pros and cons was introduced already.

[hackel]

Wow, moxie0 just sounds sounds like a giant cunt. Anyone who uses a binary compiled release of Signal from the Google Play Store for security is a fucking idiot.

[victoroldschool]

I had to register just to agree with the above few posters. I've been following this project since before it came out. Moxie had stalled on removing Google Dependencies for YEARS. When an alternative came out that achieved just that - he destroyed it. Absolute shame about LibreSignal. They would have ended up becoming the preferred choice for many, as it was able to achieve what Moxie has simply refused to do. LibreSignal demonstrated that the numerous claims Moxie made about things "not being possible" or "wouldn't work", was nothing more than lies.

Eliminating TRUE encryption (SMS based encryption was/is the pinnacle of secure communications) in favor of a vastly less secure option running through data. Wonder why that happened.... it probably actually WORKED, and if that's the case, it would not be 'permitted' in his country. Cough - LavaBit.

LibreSignal was already a "more secure" option without the Google dependency, and instead of taking ideas from the project and incorporating it into Signal, he had it killed. How does that make sense from a security or open source view? They made the product more secure - and you never adopted any of the changes they made, and go as far as to criticize and flame the developer... Hmmmmmm.

Everyone needs to be aware that this does not protect your data from anything. It might make you "feel better" but security is not the#1 issue. Follow all the discussions over the years here on Github - notice any "trends"? :P

Anyways, we have removed Signal from all 500+ of our clients and have started reaching out to others who also have lots of clients, encouraging them to do the same. No point in using it.

If you want secure SMS (remember signal doesn't actually do encrypted 'sms') - there are better alternatives that are more complicated to setup. But once they are initially setup, they work amazing.

This has reached the point of becoming absolutely ridiculous. People been concerned about the same things for YEARS - and it will never be addressed. How can security be of utmost importance to you, when it's been the "same old" problems that have been discussed for YEARS.

Moxie, you shoot down literally EVERY person that has contributed something "substantial" over the years. EVERY TIME. It's almost like the goal is to keep the app "functional" but not offer "too much" in the way of encryption.

But then again.... I'm sure if you didn't "comply" with the wishes of the state (seeing as you're an American company), you would be in prison right now. So I do understand where you're coming from.

Please everyone, look closely at the case of "LavaBit" - and look what happened to the owner of the company that refused to hand over SSL keys in order to break their encryption. This happened in 2013, and things have only gotten MUCH WORSE. Wondering why Moxie is a free citizen, especially if his service actually WORKS? Anyone else in his position has been "cut down".

Please folks, follow your "gut". If it don't feel right - there's usually a reason. In this case, all you need to do is read through various github discussions and forum posts to get a better sense of the picture.

Good luck!

[SafwatHalaby]

Signal now works without Play Store / Play Services, and APKS are available directly from their website. This makes LibreSignal redundant (and an F-droid download to some extent).

Wow, moxie0 just sounds sounds like a giant cunt. Anyone who uses a binary compiled release of Signal from the Google Play Store for security is a fucking idiot.

I'm no expert but I believe Playstore APKs must be signed by the developer himself. So it might be a bit more secure than you think.

[SafwatHalaby]

As an off-topic offshoot, please calm down people. There is no need to resort to offensive language, non factual information, and even borderline conspiracy theories just because Websockets / independent apk took some time. Experts agree Signal is secure.

SMS based encryption was/is the pinnacle of secure communications

No. Metadata can be more dangerous than the data. Although message bodies are secure, SMS metadata cannot be encrypted. This was the prime motive for moving away from it. It offered a superficial form of security.

"SMS and MMS are a security disaster. They leak all possible metadata 100% of the time".

Wow, moxie0 just sounds sounds like a giant cunt. Anyone who uses a binary compiled release of Signal from the Google Play Store for security is a fucking idiot.

https://signal.org/android/apk/

https://android.stackexchange.com/questions/75279/does-the-play-store-app-verify-the-apks

https://developer.android.com/studio/publish/app-signing.html

Notably:

Every app must use the same certificate throughout its lifespan in order for users to be able to install new versions as updates to the app. For more about the benefits of using the same certificate for all your apps throughout their lifespans, see Signing Considerations below.

The certificate is controlled by moxie. Meaning Google cannot MITM, at least not through the normal Play Store app distribution mechanism. (I am not qualified to say for sure that the firmware / some code can bypass the checks)

Edit: minor rephrasing and more links.

[mimi89999]

Having a single server isn't much safer then SMS actually. Even if OWS isn't storing metadata, NSA/FBI could either find a way to backdoor it and to make it leak all metadata or they could take the servers and run them (as they did in many cases) collecting metadata...

A single server is a single point of failure.

[SafwatHalaby]

I'm only saying that "SMS based encryption was/is the pinnacle of secure communications" is a false statement. Different setups have different trade-offs and threat models. SMS is not a holy grail and has its flaws, and so does the server model. The developers decided that the flaws of the SMS model outweigh the flaws of the server model.

[SafwatHalaby]

I'd blind guess that one consideration was: A server is a theoretical single point of failure, but many carriers are proven to be compromised nodes.

[mimi89999]

Sure

[DJCrashdummy]

Having a single server isn't much safer then SMS actually.

@mimi89999 regarding metadata, i would go so far and call a single server less secure than the sms-system!
because with "infiltrating" one server NSA/FBI can collect the metadata of all possible users in the whole world; but with sms it is not that easy because of the different carriers in every single country...

---

the 3 important things that go hand in hand for real security, are the same and will stay:

• cryptography
• open source
• federation/decentralism

and one thing of them is pretty much nothing without the others...

[grote]

i would go so far and call a single server less secure than sms!

You probably haven't heard about SS7.

[DJCrashdummy]

@grote please read the whole sentence!!! (just updated the original phrasing a little bit to make in more clear.)

regarding METADATA, i would go so far and call a single server less secure than the sms-system!

PS: if you are concerned about your sms-content, which everybody should (also without/before your interesting article), you should use Silence.