Our relationship with LibreSignal

[relyt29]

After #71 is solved, we need to come to the following decisions moving forward:

A) Do we acknowledge this repo as the source for LibreSignal, or do we tell @xmikos to create his own repo, and stop sending people with issues our way? If we acknowledge this repo as the source for LibreSignal, what level of support do we provide to people posting issues?

B) Do we start incorporating new feature requests that diverge with upstream, e.g. #40.

We should decide these issues one way or another, and then address the repo in that direction. If we decide that we still want to remain as close to upstream as possible, then we should close the offending issues, tell @xmikos to stop pointing at us for support, and start working on getting merged upstream, whatever that would take. If we decide the opposite, then we should merge #40, perhaps start working on LibreSignal features, and make it more transparent how LibreSignal releases are being made.

[SecUpwN]

If we acknowledge this repo as the source for LibreSignal, what level of support do we provide to people posting issues?

@f41c0r, should this happen, I'd like to see my already closed Issue #51 revisited. Furthermore, in conjunction with #32, I am sure many people would love to see LibreSignal be officially distributed on F-Droid without having to add yet another separate experimental repo. This also enlarges the user base.

[xmikos]

Just my two cents...

A) this repo is for now the source for LibreSignal. I have not added any feature by myself to that build yet, only presented pull request with them.

B) More features will be definitely needed in the future, for example requesting REQUEST_IGNORE_BATTERY_OPTIMIZATIONS in AndroidManifest.xml and adding code like this to app:

if (Build.VERSION.SDK_INT>Build.VERSION_CODES.LOLLIPOP_MR1) {
  String pkg=getPackageName();
  PowerManager pm=getSystemService(PowerManager.class);

  if (!pm.isIgnoringBatteryOptimizations(pkg)) {
    Intent i=
      new Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS)
        .setData(Uri.parse("package:"+pkg));

    startActivity(i);
  }
}

Without it, WebSocket fork will be unusable on Android 6.0 (because of Doze and App Standby modes - see here: Optimizing for Doze and App Standby). But Google is removing apps requesting REQUEST_IGNORE_BATTERY_OPTIMIZATIONS from Google Play (even if they shouldn't, according to this table, but nevertheless there are reports that they are removing apps that should qualify for exemption). So I think we can be sure that Open Whisper Systems will never merge this into upstream.

[SecUpwN]

But Google is removing apps requesting REQUEST_IGNORE_BATTERY_OPTIMIZATIONS from Google Play (even if they shouldn't, according to this table, but nevertheless there are reports that they are removing apps that should qualify).

I wish LibreSignal would stand up against the creepy Google dictatorship just like we do.

[Diapolo]

@xmikos I already thought about a little. What if you get push access to this repo, AFAIK this is possible, so @JavaJens could broaden development support of this fork. Also we could maintain a branch that would be easy to merge upstream for just WebSocket support etc.?

[xmikos]

I have already thought about creating independent LibreSignal repository on GitHub. Mainly because I want to implement back ZRTP key continuity check (see Issue #44 - ZRTP key continuity check removed from Signal/RedPhone). But RedPhone part of Signal is not working in WebSocket fork anyway (because it needs GCM), so I somehow postponed it.

To be fair I am also little afraid that I will not have enough free time to maintain completely independent fork just by myself. But if anyone else (who knows Java better than me, I am primarily Python developer) wants to participate, I am willing to do that.

[Diapolo]

My vote:

• I'd love to see this repo as starting point for official LibreSignal, so rename this repo to LibreSignal :)
• @xmikos Gets push access so he can merge pulls (of course after a discussion and a vote from @JavaJens or in purely experimental branches)
• work out how to handle the cases with RedPhone part (e.g. by allowing it to use GCM if available while the TextSecure part could use WebSocket or GCM - by user option as in pull https://github.com/JavaJens/TextSecure/pull/40)
• add new features and keep an easy to merge upstream branch, if Moxie comes to awareness for Google-free features ;)
• we should focus on these points and not add too much other features IMHO

Let's start the fun and get some new freedom!

[SecUpwN]

@xmikos Gets push access so he can merge pulls (of course after a discussion and a vote from @JavaJens or in purely experimental branches)

To avoid conflicts with pull requests not having been reviewed by the right people, add PullApprove!

[schachmat]

My vote:

A) @xmikos creates a separate fork for LibreSignal. B) We do not accept PRs diverging from upstream here.

My argument: This is the fork of @JavaJens and we should not impose democratic ownership decisions on someone elses "stuff". If JavaJens agrees and wants to do it, fine, but it should not be enforced by someone else. As far as I know JavaJens is not even actively using this codebase anymore and just barely keeps the life-support up for this fork by merging the upstream changes which others propose in PRs.

[xmikos]

Well, I would actually prefer if LibreSignal repository would be completely independ (and not limiting new features). JavaJens repository can stay as upstream with basic WebSocket support. My secret dream is even merging back SMS encryption from SMSSecure, but this is not too realistic ;-)

What I am afraid of is like I said that I will not have enough time to actively maintain it. So my question is: does anyone here want to help with it? Preferably someone who is good at Java and who is not opposed to new features ;-) But I would be glad for any help of course!

[SecUpwN]

My secret dream is even merging back SMS encryption from SMSSecure, but this is not too realistic

I think I'm wet down below like right now! :droplet:

So my question is: does anyone here want to help with it?

Maybe some guys from @SMSSecure are willing to help here?

[mimi89999]

I think the best thing to do would be to fork this repo and do everything to get LibreSignal added to F-Droid (for example remove non-free dependencies (if any)).

What I'm afraid of is that one day moxie will ban LibreSignal from TextSecure servers.

[patcon]

:-1: from me on LibreSignal becoming more than a websockets fork

Not actively using LibreSignal, but quite possible we'll pick it up for MIA down the road. I'd be interested in keeping the diff minimal, and having a trusted member of the community sign a deterministically building APK. I'm sincerely hoping it doesn't become a dumping ground for other features OWS doesn't agree with :(

That being said, I really do appreciate that effort is being put into this fork, even if i disagree with some specific stated views :)

[h-2]

My opinion as someone who has not contributed code, yet, but followed closely (and could possibly do some advocacy):

First keep the diff minimal, approach OWS politely about Redphone-server component source and possible websocket support. If that works out somehow, prepare minimal patch and politely try to upstream. After that -- possibly -- do a fork that is only a rebrand and submit that to F-Droid.

Second If and only if the above fails, setup own infrastructure, maintain textsecure compatibility, try to reverse engineer phone cababilities, if that doesn't work, setup own phone-infrastructure (only libre2libre calling would work then). Then accept own features and possibly try to get @SMSSecure people onboard to enlarge the dev and userbase.

I would very much prefer the first option, though.

[Diapolo]

I never wanted to override @JavaJens in any way, he's the one that needs to kick of anything new that's happening in HIS repo, of course :).

I just hope to see a better maintained (e.g. the Android 6 stuff @xmikos mentioned), more transparent, WebSocket release of LibreSignal with all that's needed to get it working smoothly without GCM.

[JavaJens]

Sorry, I have been absent. I don't want to be the guy that blocks everything because I can't be too involved atm. I'd suggest to create an organization (on Github) that can track various changes and allows more people to make decisions. There reasoning is that I see this fork merely as a fork, designed for one specific purpose. Obviously it has grown and people want to see various other things happening here. So I'd suggest that we create another repo that manages a minimal diff to upstream, but also a version where new features specific to using this as a standalone can be addressed.

However in the end this is up to everybody here in what direction they feel they want to move. Again, I can't be too active right now, so I think I neither can nor should play the role it feels you want from me :wink:

[mimi89999]

@JavaJens Do you think that moxie0 could, one day, ban LibreSignal from TextSecure servers?

[JavaJens]

Of course OWS could, if they wanted to :smile: Right now we send an identifier, stating that a device is from this fork. If OWS would block this user agent, we could simply remove that. This in turn could start a cat and mouse game. But of course I have no way to assess the risk of that happening.

[mimi89999]

I know, that they have the technical possibility of doing that... My question was more about what is the possibility of this move from OWA, and also about what we could do in such a case.

[xmikos]

In worst case scenario we can make sure that requests from WebSocket fork closely mimic requests from Signal Desktop app for Chrome (which also uses WebSocket). This way OWS wouldn't be able to tell if you are using WebSocket fork of Signal for Android or their own Signal Desktop app.

[mimi89999]

They could start legal threats...

[xmikos]

That won't work, 1.) not everyone is from US juristidiction, 2.) they would completely alienate whole opensource world and make everyone suspicious about their motives, 3.) there were always third-party clients for various IM networks and not even "evil" companies like AOL sued anyone (the only case of cease & desist letters I know about is from WhatsApp and developers largely ignored them). This doesn't mean too much, but moxie would have to go completely insane to go this way...

[TheZ3ro]

(I have silently followed the project) IMHO People need a Websocket-only version of Signal (ex Text-Secure) but OWS can't support these people (that maybe are using it from Jolla, from BlackBerry, from Replicant and so on...). It's not a F-Droid problem. People want to communicate securely and cross-platform, and GCM is a big Berlin-like wall.

I think we must create an Organization to work on this and maybe maintain 2 repo, one that someday (cross fingers) will merge upstream in the GooglePlay-only-distributed repo and one that will be distributed on other platforms.

[mimi89999]

I think creating an organization is a good idea.

[SecUpwN]

I think creating an organization is a good idea.

@SMSSecure with their repo is the best example how to do it.

[mimi89999]

@xmikos Would you create an organization on GitHub?

[ton-io]

i suggest to stay as upstream with basic WebSocket support. for several reasons. But most important, security bug are most likely discovered sooner and easier to fix when you stay as upstream with basic WebSocket support

[fauno]

i just want to say i'm happy to see where this is going :)

i haven't been able to recommend textsecure/signal because of gplay and gcm requirements, but now you're solving it! keep going please!

[JavaJens]

@xmikos How do you feel about this?

[SecUpwN]

@xmikos and @JavaJens, is https://gitlab.com/fdroid/fdroiddata/merge_requests/1223 official?

[JavaJens]

I know nothing about this.

[mimi89999]

I made this PR. I didn't ask here before making it because the build is disabled, so eaven if it gets merged, the app won't be on F-Droid...

[mimi89999]

@JavaJens if you want, I can close this PR.

[JavaJens]

You don't have to ask for permission. I didn't mean to imply any judgment. Feel free to do whatever you want (as long as you stick to the upstream rules :wink:), I don't mind.

[SecUpwN]

@mimi89999, thanks for having made the PR on GitLab. Will you maintain this on a regular basis now? And does that mean that we can throw out the "experimental repo" when LibreSignal finally appears? :)

[mimi89999]

IF F-Droid accepts...

[mimi89999]

I made a new PR: https://gitlab.com/fdroid/fdroiddata/merge_requests/1229

[ddast]

Maybe I am missing something, but I thought this version still requires the proprietary play services for building. The build.gradle contains

    compile 'com.google.android.gms:play-services-gcm:8.1.0'
    compile 'com.google.android.gms:play-services-maps:8.1.0'
    compile 'com.google.android.gms:play-services-location:8.1.0'

Isn't that a dealbreaker for fdroid?

[mimi89999]

@ddast I will add the AntiFeature flag... If I remove all play dependencies the build fails.

[mimi89999]

Also: https://github.com/JavaJens/TextSecure/issues/72#issuecomment-170077997

[mimi89999]

The lines 104 and 105 in AndroidManifest are causing the problem.

Edit: It doesn't mean that removing them will fix the build...

[SecUpwN]

What this repository lacks is a clear statement from @JavaJens and @xmikos of what should happen with it. Right now, opinions of users are drifting heavily apart between pro and contra renaming it to LibreSignal and making it become more than just a WebSocket supported fork. We need a clear outline and some soothing words from the official maintainers so that the userbase won't be split and yet another "fork of the fork of the fork" is being created. One real LibreSignal project with more support, an official F-Droid distribution and a clear outline and maintainance to make privacy geeks happy would rock!

@xmikos and @JavaJens, please sit down and really discuss this internally and make sure to find some solution that takes into account that privacy geeks like me would love LibreSignal to be officially appear on F-Droid (means all Google shit as mentioned in https://github.com/JavaJens/TextSecure/issues/72#issuecomment-187602687 has to be removed entirely) and that Moxie will highly likely kick LibreSignal to use their servers at some point of time when it becomes too popular. How do I know? Posts on the official Signal repo with mentions about LibreSignal do get modified so that LibreSignal does not even get linked to. While I do understand that they do not want to promote forks of their app on their own repo, it seems some sort of censorship exists there. I also never got the point why Signal sticks to proprietary Google libraries in the first place (as mentioned in the German article Android: Signal ohne Google Cloud Messaging). We've even tried to contact Edward Snowden via Twitter about this, but never received a reply. Judge for yourselves, privacy monkeys.

[fauno]

and that Moxie will highly likely kick LibreSignal to use their servers at some point of time when it becomes too popular.

what kind of resources are required to run a signal server for the community? do we need the sms registration process?

:D

[SecUpwN]

what kind of resources are required to run a signal server for the community? do we need the sms registration process?

@fauno, see How can I host my own server, which redirects to this unofficial Google group. Stunning. :(

[schachmat]

@SecUpwN: I wrote a comment with some questions on the imho one-sided blog post which never got answered by the author. For reasons to "stick" to GCM see https://github.com/JavaJens/TextSecure/issues/22#issuecomment-136520499.

[fauno]

"Security: PWNED" notifications@github.com writes:

what kind of resources are required to run a signal server for the community? do we need the sms registration process?

@fauno, see How can I host my own server, which redirects to this unofficial Google group. Stunning. :(

how hard would it be to write a signal server then :P

http://lainventoria.com.ar/

[SecUpwN]

how hard would it be to write a signal server then :P

We should wait how this discussion turns out, then open a fresh Issue for moving to our own server.

[fauno]

"Security: PWNED" notifications@github.com writes:

how hard would it be to write a signal server then :P We should wait how this discussion turns out, then open a fresh Issue for moving to our own server.

of course, i can collaborate on setting it up too :)

http://lainventoria.com.ar/

[ton-io]

maybe iam wrong but isnt GCM like apple's push notifications? its just being used to let the users device connect to a specific servers. there is actualy no data being transfered to google other then checkin to that specific server, in this case the signal to the whisper systems server.... My understanding is that google only knows your connecting to a specific server and will never see what data is being transfered to the users device. dont het me wrong i dont want to see this project end in any way. i happly using the websocket version on my blackberry, offcourse i have my reasons of using a blackberry instead of an android device :). so will many of you guys if not al have there reason for not using google services. but please stay as close to the original version from signal as possible. the less likely we will upset moxie/whisper systems, in the end they did a create job with signal for with we might consinder showing a little respect. Dont forget they are also the persons not just keeping the servers up and running but also paying for it.

again to get me wrong i still think this websocket version needs to stay available for the people without google services.

[fauno]

ton-io notifications@github.com writes:

maybe iam wrong but isnt GCM like apple's push notifications? its just being used to let the u

i don't know what it does, since it requires to install a 100mb (iirc) apk on my phone that demands access to everything :P

[mimi89999]

@ddast The problem is that if I sed -i '/com.google.android.gms:play-services/d' build.gradle, the build fails :disappointed: