Skip to content
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

GCM support in LibreSignal (websocket) #30

Open
anarcat opened this issue Apr 8, 2016 · 18 comments
Open

GCM support in LibreSignal (websocket) #30

anarcat opened this issue Apr 8, 2016 · 18 comments
Assignees
Labels

Comments

@anarcat
Copy link

anarcat commented Apr 8, 2016

Currently, Signal and LibreSignal (Websocket) require GCM for voice calls to function properly. In fact, as things stand, voice calls do not work in the websocket fork at all (see #10). This is because it is deliberately built without GCM support, because those are proprietary libraries.

One way to fix phone calls is to fix the server and the client to use Websocket, this is tracked in #29. This issue is about letting the Websocket fork still use GCM for voice calls, either through MicroG's GCM support or Google Play Services, or through its own library.

It is unclear if this is contrary to the goals of this project. I believe it would still be interesting to support this as an option, maybe off by default, to better serve the users.

Forked off #10 for clarity.

@mimi89999
Copy link

I think that a FOSS library for GCM could be included in LibreSignal. Then JavaJens#40 would be merged with WebSocket as default. The only missing part is a FOSS library for GCM.

@xmikos
Copy link
Member

xmikos commented Apr 8, 2016

@mimi89999 I am not sure what to do, maybe there could be experimental microG branch of LibreSignal.

But I am not going to implement it myself, it will be really a lot of work... if someone is interested in it, they can start by creating their own FOSS GCM library project for inclusion into apps without being dependent on microG framework (it will be useful for a lot of projects, not just LibreSignal)...

(moved from #10)

@mimi89999
Copy link

But I am not going to implement it myself, it will be really a lot of work...

I agree. I would prefer to fix voice calls the #29 way, but to do that some minimum cooperation from OWS if needed...

@mimi89999
Copy link

@xmikos

if someone is interested in it, they can start by creating their own FOSS GCM library project for inclusion into apps without being dependent on microG framework (it will be useful for a lot of projects, not just LibreSignal)...

For this to work, the code of that library would have to be similar or almost identical to the Google proprietary library code. I'm afraid that Google won't like this...

@mimi89999
Copy link

@xmikos
Copy link
Member

xmikos commented Apr 8, 2016

@mimi89999 You are free to reimplement API like you want, Google can't say anything against it.

EDIT: Well, they has been attacked by Oracle for reimplementing Java API in Android, so they will be against themselves ;-)

@xmikos
Copy link
Member

xmikos commented Apr 9, 2016

If android_external_GmsLib would be extended to support GCM by @mar-v-in, I think we should definitely integrate it. But there should be option to enable it in preferences which IMHO should be disabled by default. We can add some alert dialog informing users that they need to enable it if they want to be able to use voice calls.

@mimi89999
Copy link

#30 (comment)

@xmikos
Copy link
Member

xmikos commented Apr 9, 2016

Yes, I would just need to add some alert dialog. And if it would be disabled by default (which it should be), registration procedure must be initiated when first turning it on.

@mimi89999
Copy link

@xmikos Could you login to Freenode IRC?

@mimi89999
Copy link

@xmikos I wanted to send you an email, but Gmail is rejecting my emails. 😢

@relyt29
Copy link

relyt29 commented Apr 19, 2016

Hey all,

I want to remind you guys that I looked into this a while back and decided it was not a good idea, for privacy reasons. Basically it boils down to - even if the phone has an open source GCM implementation, its still sending tons of unnecessary info in the background round the clock to Google servers for almost no reason. I consider that a violation of my privacy so I didn't chase down the rabbit hole any further.

Here's a link to some of the research I did looking into the topic

@mimi89999
Copy link

@f41c0r Some time ago I was against adding GCM support in LibreSignal. Now I think, that GCM support can be added if:

  1. The lib is 100% FOSS
  2. It's disabled by default

@mimi89999
Copy link

Probably adding GCM support in LibreSignal is the only way of making calling work...
If you want, you can ask OWS to open source the RedPhone server and to implement WebSocket support in the RedPhone server.

@mimi89999
Copy link

I would also prefer to solve the calling issue the #29 way, but to do that some minimum cooperation/help from OWS side is needed.

@psivesely
Copy link

psivesely commented May 14, 2016

If you want, you can ask OWS to open source the RedPhone server and to implement WebSocket support in the RedPhone server.

To be totally honest with you, I think it's abundantly clear upstream does not want to cooperate with this project and if anything, the more they get bugged and harrangued, the more likely they are to actually put in the effort to try to boot LibreSignal users off their servers.

... Just my 2¢ here...

I think you should recognize you're building a free software app to communicate with a proprietary server and a walled garden environment and that's not going to change. Don't get me wrong, I really appreciate you doing so (it's invaluable to me to be able to have e2e encrypted communications w/ Signal's large user base), however, if you're looking to create/work with/support/etc. a decentralized, fully liberated communications app/platform/system, know it ain't happening here.

So granted you are building a free software app to communicate with a proprietary server and a walled garden environment, it makes sense to recognize your effort as such and at least try to support full compatibility with the upstream infrastructure. You're not doing users some noble service by saving them from a free software GCM implementation, which sends minimal data to Google which can be spoofed/hardcoded with generic values to preserve privacy anyway (see https://github.com/microg/android_packages_apps_GmsCore/blob/master/play-services-core/src/main/java/org/microg/gms/gcm/RegisterRequest.java#L58).

I haven't looked much into metadata concerns with Signal to be honest, so writing this out of ignore: the metadata attack that seems most feasible given the huge amount of data that passes through the Signal server is a "confirmation attack" that two people were talking, and I'm sure our regional carriers can be compelled/ are willing even more so than Google to divulge the data necessary for these confirmation attacks.

So, maybe this is not the exact appropriate place for all these concerns, but on this topic you should consider changing your name. Not just because Moxie asked, but also because LibreSignal is a misnomer in that it gives a false sense to something that will never be liberated in the sense you and I would like it to be. Sure, if you want to take a stringent interpretation of the FSF's 4 freedoms, you can say it's libre, but I think that's sometimes a limited scope from which to consider what libre, freedom means and there are many shades between "pure freedom" and "pure authoritarianism," however you shall like to think about those terms.

So sorry if this is derailing the issue some; while from a technical standpoint these issues are unrelated, from a reasoning standpoint they are related.

@mimi89999
Copy link

I definitely don't want to continue LibreSignal. I will only do that for a very brief period of time, so that users have the time to migrate.

@psivesely
Copy link

Fair enough :-P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants