Please add LibreSignal to f-droid #37
Comments
kakedacich
changed the title
There are still several important issues:
@LibreSignal what do you think? Should LibreSignal be moved to the main F-Droid repo? |
|
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. |
|
even better, help them move to 100% free software and working without Google, so there isn't a need for the fork. |
Running a server costs money and I am not sure if OWS will want to federate with us.
The problem is that Moxie and OWS don't want Signal to be 100% free/libre software (it is not important for them...) |
|
@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.
This said, I understand why the inclusion on fdroid needs to be well pondered. |
|
@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. |
|
@legovini
EDIT: Please read https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds#How_it_is_implemented_as_of_now |
|
@legovini Let's ask @moxie0 if he is OK with LibreSignal using OWS servers. |
|
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. |
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.
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? 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. |
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 😄 |
Thanks, that would be great!
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?
It is unlikely that we will ever federate with any servers outside of our control again, it makes changes really difficult.
Yep, we're working on it. |
|
@moxie0
Some time ago you federated with CyanogenMod. What has changed since then? |
|
@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. |
|
@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. |
|
@mimi89999 my fault, I thought it was not distributed for free on the play store. |
|
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.). |
|
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... |
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.
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.
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.
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. |
|
@moxie0
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.
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". |
|
I love the fake opensource provided by OWS : use the code, but go f*** yourself for federation, out-of-store distribution and acceptation. 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. 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. 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. |
|
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. |
|
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. |
|
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. |
|
I see only 3 possibilities now:
@kakedacich as for your original issue, it is a "wontfix". |
|
@mimi89999, |
|
@akliyan They didn't remove proprietary GMS libs. |
|
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. I am sure Libresignal was forced to shutdown (by servers denial) because it is really promoting what “Signal” is pretending to promote (privacy). 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 Please just read this thread, I think nearly every other messaging app and its pros and cons was introduced already. |
|
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 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! |
|
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).
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. |
|
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.
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".
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:
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. |
|
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. |
|
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. |
|
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. |
|
Sure |
@mimi89999 regarding metadata, i would go so far and call a single server less secure than the sms-system! the 3 important things that go hand in hand for real security, are the same and will stay:
and one thing of them is pretty much nothing without the others... |
You probably haven't heard about SS7. |
|
@grote please read the whole sentence!!! (just updated the original phrasing a little bit to make in more clear.)
PS: if you are concerned about your sms-content, which everybody should (also without/before your interesting article), you should use Silence. |
|
@moxie0 This was 2 years ago but I do not get your reasoning for not supporting non GCM users? Users in China don't have Google Play installed, which means they don't get notifications until they open the app. |
|
This I also find interesting. @moxie0 I tried to talk with your support guys many times about supporting the Ubuntu Touch push server, so that users of Ubuntu Touch can get notifications for their signal-compatible App. I got turned down a few times and finally gave up. If you have a mission to proliferate the world with secure messaging, why you are restricting the access to it behind arguments of costs and support? Can I compare this to Telegram, maybe? With those guys we have an excellent relationship, we are allowed to use their servers, they send us push notifications, not a big deal. We are not allowed to use the name Telegram to not confuse with the original app, but that's fine. They also wont do support for our app, of course. We get support, and recently, they have released tdlib, a great project to make Telegram clients possible without even implementing 1 bit of their API. Telegram uses a versioned API, so that newer developments can be deployed without breaking downstream forks (immediately). You need to do the same, then its not a big deal to advance in features but still stay compatible for older apps. And don´t tell me such an API cannot be done, I have enough examples where this works well, I am a software dev myself. Maybe not for years, but at least for some months needed for downstream to catch up. We are currently discouraging people on Ubuntu Touch to use Signal because we don't see a future for it. People instead recommend Matrix. That´s rude, I know. But it´s like your argument about living in today´s world. What does this mean, that all experiences and gains of knowledge from the past are to be thrown away because "Apps"? Cmon, modern software development has come a long road. Making services closed also limits what you can achieve with them. Currently about 3 or 4 hardware vendors are working on independent phone hardware. They will have Linux flavours installed, will have no relation to Google or Android at all. Plasma Mobile is one of the bigger bets besides Ubuntu Touch. They will have apps that can be interchanged because of common packaging formats. They got their own app stores and federated push servers. We will get rid of the chains of big vendors. Shall Signal be a part of this future or not? I leave it open to you. |
|
I support this request from the perspective of the yet to be released Librem 5 Linux based cell phone from Purism. I have pre-ordered the Librem 5, and currently I have 100+ Signal contacts. I really would like to still be able to use Signal when the Librem 5 will be arrive (currently planned for April 2019). |
|
@janvlug FYI :
|
ghost
mentioned this issue
|
it's already 2020 and I'd like to contribute to that too FUCK YOU OWS!!! |
|
Sorry. I'm locking this issue. |
and others
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
The text was updated successfully, but these errors were encountered: