Our relationship with LibreSignal

[relyt29]

trafficstars

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.