New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Please add LibreSignal to f-droid #37

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

Comments

Projects
None yet
@kakedacich

kakedacich commented May 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 4, 2016

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?

Member

mimi89999 commented May 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@eighthave

eighthave May 4, 2016

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 commented May 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@eighthave

eighthave May 4, 2016

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

eighthave commented May 4, 2016

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

@mimi89999

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 4, 2016

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

Member

mimi89999 commented May 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@paride

paride May 4, 2016

@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 commented May 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@paride

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

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 4, 2016

Member

@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

Member

mimi89999 commented May 4, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 4, 2016

Member

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

Member

mimi89999 commented May 4, 2016

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

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

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

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 5, 2016

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.

Member

mimi89999 commented May 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 5, 2016

Member

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

Member

mimi89999 commented May 5, 2016

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

@h-2

This comment has been minimized.

Show comment
Hide comment
@h-2

h-2 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 😄

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

This comment has been minimized.

Show comment
Hide comment
@moxie0

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

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 5, 2016

Member

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

Member

mimi89999 commented May 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@paride

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

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 5, 2016

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.

Member

mimi89999 commented May 5, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@paride

paride May 5, 2016

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

paride commented May 5, 2016

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

@mimi89999

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 5, 2016

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.

Member

mimi89999 commented May 5, 2016

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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

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

ghost 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

This comment has been minimized.

Show comment
Hide comment
@moxie0

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

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.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

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

ghost 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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 6, 2016

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

Member

mimi89999 commented May 6, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@cjeanneret

cjeanneret May 6, 2016

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.

cjeanneret commented May 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mvdan

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

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

This comment has been minimized.

Show comment
Hide comment
@paride

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

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

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae May 6, 2016

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.

vanitasvitae commented May 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 6, 2016

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

Member

mimi89999 commented May 6, 2016

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

This comment has been minimized.

Show comment
Hide comment
@BlackerFlag

BlackerFlag May 7, 2016

@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

BlackerFlag commented May 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@moxie0

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

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

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae May 7, 2016

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

vanitasvitae commented May 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 7, 2016

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

Member

mimi89999 commented May 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@paride

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

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

This comment has been minimized.

Show comment
Hide comment
@BlackerFlag

BlackerFlag May 7, 2016

@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

BlackerFlag commented May 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 7, 2016

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/

Member

mimi89999 commented May 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@moxie0

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

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

This comment has been minimized.

Show comment
Hide comment
@eighthave

eighthave May 7, 2016

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

eighthave commented May 7, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 May 7, 2016

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.

Member

mimi89999 commented May 7, 2016

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

@th3m

This comment has been minimized.

Show comment
Hide comment
@th3m

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

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

This comment has been minimized.

Show comment
Hide comment
@z4lem

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

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 Dec 20, 2016

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

Member

mimi89999 commented Dec 20, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@z4lem

z4lem 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 :/

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

This comment has been minimized.

Show comment
Hide comment
@d10r

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

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

This comment has been minimized.

Show comment
Hide comment
@ChadSki

ChadSki Jan 10, 2017

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.

ChadSki commented Jan 10, 2017

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

This comment has been minimized.

Show comment
Hide comment
@schiessle

schiessle Jan 11, 2017

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

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

schiessle commented Jan 11, 2017

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

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

@JustAskin

This comment has been minimized.

Show comment
Hide comment
@JustAskin

JustAskin Jan 13, 2017

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

JustAskin commented Jan 13, 2017

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

@Ezwen

This comment has been minimized.

Show comment
Hide comment
@Ezwen

Ezwen 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/.

Ezwen 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

This comment has been minimized.

Show comment
Hide comment
@grote

grote Feb 1, 2017

with server side history, E2E encryption,

Aren't those mutually exclusive?

grote commented Feb 1, 2017

with server side history, E2E encryption,

Aren't those mutually exclusive?

@Ezwen

This comment has been minimized.

Show comment
Hide comment
@Ezwen

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

Ezwen 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

This comment has been minimized.

Show comment
Hide comment
@ara4n

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

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

This comment has been minimized.

Show comment
Hide comment
@gsantner

gsantner Feb 1, 2017

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

gsantner commented Feb 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Feb 1, 2017

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

vanitasvitae commented Feb 1, 2017

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

@ara4n

This comment has been minimized.

Show comment
Hide comment
@ara4n

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

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.

@Ezwen

This comment has been minimized.

Show comment
Hide comment
@Ezwen

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

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

@PeskyFactoids

This comment has been minimized.

Show comment
Hide comment
@PeskyFactoids

PeskyFactoids Mar 8, 2017

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

PeskyFactoids commented Mar 8, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 Mar 8, 2017

Member

@PeskyFactoids

VoLTE -- Voice over LTE?

Member

mimi89999 commented Mar 8, 2017

@PeskyFactoids

VoLTE -- Voice over LTE?

@akliyan

This comment has been minimized.

Show comment
Hide comment
@akliyan

akliyan Mar 26, 2017

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

akliyan commented Mar 26, 2017

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

@mimi89999

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 Mar 27, 2017

Member

@akliyan They didn't remove proprietary GMS libs.

Member

mimi89999 commented Mar 27, 2017

@akliyan They didn't remove proprietary GMS libs.

@akliyan

This comment has been minimized.

Show comment
Hide comment
@akliyan

akliyan Mar 27, 2017

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

akliyan commented Mar 27, 2017

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

This comment has been minimized.

Show comment
Hide comment
@vanitasvitae

vanitasvitae Mar 27, 2017

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

vanitasvitae commented Mar 27, 2017

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

@hackel

This comment has been minimized.

Show comment
Hide comment
@hackel

hackel Jun 15, 2017

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.

hackel commented Jun 15, 2017

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

This comment has been minimized.

Show comment
Hide comment
@victoroldschool

victoroldschool Jul 2, 2017

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!

victoroldschool commented Jul 2, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Aug 25, 2017

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 commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Aug 25, 2017

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.

SafwatHalaby commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 Aug 25, 2017

Member

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.

Member

mimi89999 commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Aug 25, 2017

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 commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SafwatHalaby

SafwatHalaby Aug 25, 2017

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.

SafwatHalaby commented Aug 25, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mimi89999

mimi89999 Aug 25, 2017

Member

Sure

Member

mimi89999 commented Aug 25, 2017

Sure

@DJCrashdummy

This comment has been minimized.

Show comment
Hide comment
@DJCrashdummy

DJCrashdummy Dec 6, 2017

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

DJCrashdummy commented Dec 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@grote

grote Dec 6, 2017

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

You probably haven't heard about SS7.

grote commented Dec 6, 2017

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

You probably haven't heard about SS7.

@DJCrashdummy

This comment has been minimized.

Show comment
Hide comment
@DJCrashdummy

DJCrashdummy Dec 6, 2017

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

DJCrashdummy commented Dec 6, 2017

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

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