Wire-android: Bring the app to f-droid

[bootofood]

Please make it possible to compile the app without the non-free dependencies.
In this way it could be included in f-droid, finally beating Signal!

[someoneEsle]

Answer here: https://github.com/wireapp/wire-android/issues/5
You may as well close ^^

[bootofood]

Thanks. That issue is closed, that's why I didn't find it. Good to read that they're interested in publishing the app in f-droid, certainly a more friendly and reasonable approach than what we got for Signal.

Shouldn't a "f-droid issue" stay open until we've got it in there, complying with the inclusion policy?

[someoneEsle]

I don't know what the policy as for keeping issues open is, but it looks like something they're aware of, therefore there's no need to let the ticket open (which may be why they closed the other one). I'm pretty sure they'll remember even if this issue gets closed.
(I understand your point about leaving an issue open though, maybe they could leave the original one open as it has the official reply too)

[bjoernherbig]

Thanks guys for bringing this up again and yes, we will remember it for sure. As for closing it, we will leave this one open since there are likely to come in more requests for f-droid.

[h-2]

Out of curiosity: what are the proprietary dependencies blocking f-droid acceptance? Seems like if you already have a fallback for GCM you are almost there or not? Maybe other people could help in this process?

[paride]

@h-2 take a look here:

https://github.com/wireapp/wire-android/issues/5#issuecomment-234947466

and compiling without GCM is probably non trivial, even if there is already a fallback mechanism.

[h-2]

I am posting a 50€ bounty for someone who creates a version of the Android Wire client that fully meets F-Droid’s criteria, i.e. no proprietary dependencies. Preferably the changes would also meet upstream’s criteria for integration into the official repository, e.g. via a Flavor or build flag or something like that.

I can send the money via Paypal or WireTransfer/SEPA.

edit: timeframe: for this bounty there should be some alpha/beta version until 2017-02-01

[lipis]

💶 💵 💶 💵 💶

[grote]

The first step, before anybody can take this on would be to get rid of the custom maven repository and get those dependencies submitted to jcenter.

Currently, these libraries are affected:

• gradle-android-scala-plugin - non-upstreamed fork?
• icu4j-shrunk - non-upstreamed fork?
• robotest_2.11 - non-upstreamed fork?
• spotify-auth - non-free software?
• spotify-player - non-free software?

Having some information on these libraries would make it easier to assess the actual effort needed for a 3rd-party to take on this work.

[h-2]

Users of Signal have three months until the last version "expires" that works without PlayServices. If wire published a preliminary free software version until then, it could motivate quite a few people to switch and would definitely get some attention...
https://twitter.com/VenemaSander/status/794937272697294852
https://twitter.com/shiromarieke/status/793947755840413696

(Note that Free Software server source and federation #237 would be really cool, but totally unrelated to this issue as Signal didn't provide these either)

[darkbluelight]

Referencing https://github.com/wireapp/wire-android/issues/233#issuecomment-253722552
@bjoernherbig count one more request for f-droid from a Signal user (with quite some friends using Signal...) willing to change to Wire! I'm really looking forward to it. Especially as the GCM free WebSocket Signal for f-droid is very likely to be discontinued :(

[bgermann]

The bintray maven repository wire-android/third-party that @grote mentioned is not the only one that is in use and not allowed by f-droid. There are some more by wire (wire-android/releases, wire-android/snapshots), which can be built from the github sources, and a Localytics repo.

The Localytics library seems to be BSD licensed, but I cannot find the corresponding source. I guess this tracking library would have to be removed for f-droid anyway.

I have not checked all build scripts. Maybe there are some other Maven repositories not allowed by f-droid.

For the mentioned third-party libraries I have found the following:

• gradle-android-scala-plugin - non-upstreamed fork, can be imported via jitpack.
• icu4j-shrunk - can be replaced by standard icu4j.
• robotest_2.11 - There is a newer incompatible version available on standard repos. But you can use a jitpack build on v0.7.

[h-2]

So it seems it is mostly about making the spotify stuff and localytics optional, the rest is just infrastructural cleanup?

[bgermann]

@wireswiss in app/opensource.txt you list Spotify Authentication Library and Spotify Player Library as Apache 2.0 licensed. While this is true for a newer Authentication Library than the Beta version you link with, the Spotify Player Library is subject to Spotify Developer Terms of Use rather than any open source license.

You also list Localytics SDK in that file, but it is not open sourced as well. I guess it is redistributable under the Localytics Terms of Service.

I suggest you remove the lines from app/opensource.txt and mention the proprietary dependencies at README

[grote]

I would also be nice if you could clarify whether you would accept a PR that introduces a new gradle flavor that builds the app without these non-free dependencies.

[hakonbo]

Hi all,

We are looking into creating an F-Droid flavour, but it's a side project and will take a bit of time. Would be great if you want to contribute.
Spotify/Localytics libs are included in the sync engine project as well, so we need a new flavour of that one as well.
@bgermann Thanks for checking the licences, I think that file might be a bit outdated, I'll see if we can get it updated.

[ghost]

Why was it closed? I think it's still not published in F-Droid.

So what's next on the agenda to make it publishable on F-Droid?

Edit: sorry! @someoneEsle is right. I saw the closed badge of #411 and thought it was for this issue.
When I asked for the status, sure I did read the message from @hakonbo but didn't got it, why it seemed like the work on this issue stopped.

[grote]

@bastoGrande the issue is still open and the current status has been posted right above your message.

[someoneEsle]

@grote when @bastoGrande asked "why was it closed" I think he was talking about the PR introducing free build types: https://github.com/wireapp/wire-android/issues/411

[varac]

Looking forward to an fdroid package! Please continue with your efforts!

[TomSea]

Yes. Please make wire as an fdroid package. Thanks!!!

[h-2]

I am posting a 50€ bounty for someone who creates a version of the Android Wire client that fully meets F-Droid’s criteria, i.e. no proprietary dependencies. Preferably the changes would also meet upstream’s criteria for integration into the official repository, e.g. via a Flavor or build flag or something like that.

I can send the money via Paypal or WireTransfer/SEPA.

edit: timeframe: for this bounty there should be some alpha/beta version until 2017-02-01

Signal now works well with Websockets and is available as APK, but not in F-Droid so I am renewing this pledge until 2017-07-01!

[fungs]

Yes, I'm also waiting for Wire to get fully open (FDroid build support) before I can convince my contacts to switch from Signal/LibreSignal to Wire. It would be nice for all of us who do not use Google apps on our phones.

[mxmehl]

I am posting a 50€ bounty for someone who creates a version of the Android Wire client that fully meets F-Droid’s criteria, i.e. no proprietary dependencies. Preferably the changes would also meet upstream’s criteria for integration into the official repository, e.g. via a Flavor or build flag or something like that.

Signal now works well with Websockets and is available as APK, but not in F-Droid so I am renewing this pledge until 2017-07-01!

I add another 50€ to @h-2's pledge, same timeframe and same conditions.

It would be awesome to have Wire in F-Droid!

[Larx]

Just for the record, wire works fine with MicroG. As thus a non-free dependency is seamless replacable by a free drop-in, I don't know how FDroid's stance is.

[fungs]

@Larx: AFAIK FDoid allows non-free dependencies but marks them as anti-features. Nonetheless, many build on FDroid have such dependencies removed. I'm not sure if MicroG can be incorporated as a replacement at compile time or if it needs a modified OS with signature spoofing enabled (I believe the latter). Wire doesn't need GCM/MicroG at all, if the Websocket fallback method is used.

[Larx]

I have a modified ROM (signature spoofing) for MicroG. Otherwise, Wire runs as downloaded (even the PlayStore version), no modification at all, and get its notifications through "GCM". IMHO (but I'm no purist) this makes me "Google-free" enough, but I guess the FDroid guys have other restraints.

[eighthave]

F-Droid requires apps be free software and be built from source.
Including Google's proprietary GMS libraries makes Wire non-free
software. If Google made those Android libraries free software, we
could include Wire as it is right now.

[bgermann]

That is not true. The proprietary Localytics dependency would have to be patched out additionally.

From f-droid Inclusion Policy about Play Services/MicroG:

We cannot build apps using Google's proprietary "play-services". Please talk to upstream about an untainted build flavor (either using microg or removing non-free deps completely).

[Larx]

I don't want to spam this thread, just wanted to point out that Wire is already completely usable without the Google packages on the device.

[bgermann]

@Larx Even if it is usable without Google packages on the device, the Google dependencies are still needed for the compilation. For a free version those dependencies would have to be removed or replaced by MicroG.

[bgermann]

I had a look at the MicroG libraries. The play-services-base, play-services-location and play-services-gcm dependencies could be replaced by the MicroG libraries, but as of now there are no replacements for firebase-messaging (maybe Google will free this one) and play-services-maps (only API version 1).

[grote]

play-services-maps (only API version 1).

Did you look into whether Lost could be a free replacement here?

[grote]

Sorry not Lost, but there's also osmdroid and maps libraries by Mapzen and Mapbox which should be compatible.

[bgermann]

The MicroG lib uses osmdroid under the hood. Upstream does not support V2 either. There is a feature request for Mapzen. I do not see hints for Mapbox supporting any version of the Google API.

So there seems to be no trivial solution. Maybe the V2 calls can be replaced by V1 calls easily and then MicroG/osmdroid can be used.

[Mis012]

MicroG supports maps api v2, I think. It's just not written correctly somewhere.

[bgermann]

It is only partially supported. I requested wire's missing API calls.

[Mis012]

oh I see. Maybe someone from here could help with that? For example a callback may be relatively easy thing to implement?

[h-2]

@Mis012 Can we move discussion about MicroG to a different thread? It won't help bring it to F-Droid...

[ghost]

It's very important for dataprivacy reasons to get Wire on F-Droid.
Please publish your app there. :)
What is the current status?

[colans]

If you really want to be using F-Driod, you should consider switching to https://riot.im/.

The MicroG issue here is related to a similar one in that queue: https://github.com/vector-im/riot-android/issues/994.

[ghost]

colans:
If you really want to be using F-Driod, you should consider switching to https://riot.im/.

Why the hell?!? unhelpful!
We want use wire and not matrix! We are here in the wire github repo and not in riot.im.

---

Back to topic, please bring your app to F-Droid, it's:

1. the only googlefree way to use wire (the version from website includes google (gcm))
2. compfortable (to update) for useres without PlayStore

Thank you guys for your great work!! :)

[ghost]

Take an example on Tutanota.

One of our aims with Tutanota is to offer a secure alternative to mainstream mail services like Gmail and Yahoo that spy on their users.

To fully leave Google behind, we as the Tutanota developers have yet to do our share: Right now the Android app relies on Google's GCM for push notifications. That's why it is so important for us to publish the Tutanota app on F-Droid.

So are there positiv news for us?

https://tutanota.com/blog/posts/secure-mail-open-source

[bgermann]

the new Android app will finally come without any ties to Google services

So no. unhelpful!

[ghost]

Freeze?

[strypey]

Mapzen has shut down, so their Lost API etc may not be a replacement for Google location services, but Mapzen posted this guide to some alternatives: https://mapzen.com/blog/migration

[mnemi]

It looks like Tutanota was able to overcome the GCM issue and release their app on f-droid. Maybe this will be helpful to Wire? https://f-droid.org/en/2018/09/03/replacing-gcm-in-tutanota.html

[fungs]

@mnemi, the last paragraph is very true: there should be an open standard for push notification and everybody should pick a trusted provider for him or herself, reducing the number of active connections and controlling the flow of data.

AFAIK GCM is not the main issue for bringing Wire to FDroid as it has a working websocket implementation which could be selected at compile time.

[selurvedu]

Wire always worked just fine without GCM. See my short report in #1833.

[fungs]

@selurvedu: The question is whether it can be built from sources using the fdroid tool chain without google requirements.

[tuxayo]

About FCM (ex GCM) see #1903

[trymeouteh]

Is this still in the works. I would like to have Wire on my LineageOS devices.

[fungs]

As for #5 which was closed I think there is no clear communication whether the Wire team wants to support the open source community by bringing Wire to FDroid. Also, its seems that the organization lacks policies and/or resources to classify and handle these kinds of requests. All I can see is users communicating with each other but no statement, assignment or prioritization whatsoever.

For me it looks like the Wire company has entirely shifted towards providing a business tool while ignoring its principal open source philosophy and community.

[JavaZauber]

This ticket is open while #5 has been closed. This seems wrong to me.
The devs said something along the line of "yeah we are aware" and then closed the original ticket.

Also, I don't think that google location API really holds this ticket back. I'm an android dev and I've already worked with the various location APIs in the android ecosystem before. I've written down technical details on how to perform open source location tracking here: https://github.com/wireapp/wire-android/issues/5#issuecomment-511189256.
Since it's really easy to pull off maybe the open source community really is not important for Wire Swiss GmbH.

[EdaNano]

Let's ask again :)
Hi Wire developers, is this issue, three years after it was opened, still in your TODO list? And is it getting near the exit point on this list? Should we F-Droid users still hope ;)
Thank you :)

[tuxayo]

In the hope to move this forward a bounty has been started for the removal of the non-libre FCM dependency: https://github.com/wireapp/wire-android/issues/1903#issuecomment-552118691

[Gardosen]

Hey Everyone,

i am currently cleaning up this issues board and i stumbled across this long ongoing discussion.
i fully understand this request and started investigating about decisions, actions taken and things in the past related to this request by talking to colleagues.

i will continue this investigation and sync up with my team members in the Android Team to be able to give a clear and final answer about if it will ever be possible to make this F-droid support possible.

Kind regards
Marco from the Android Team

[Gardosen]

Update Week 10(2nd of March): I closed two tickets, related to this topic, so we have one ticket as the source of truth about it.

OpenPush will be discussed internally this week.

Kind regards
Marco from the Android team

[genodeftest]

In theory, the rfc2822 F-Droid repo should contain the Wire APKs. However, the download link broke because Wire's version numbering changed (bug report). It would be nice if you could fix that.

[12people]

@Gardosen How did the internal discussion go? Any plans on incorporating OpenPush?

[android10]

@12people and the rest, sorry for the late reply. At the time being there are no plans to address this. Unfortunately we are suffering from other issues that are higher priority. In any case, we will keep you posted if anything changes in the mid term.

Thanks for the patience.

[genodeftest]

You may just add the rfc2822 F-Droid repo to F-Droid, it also ships the Wire app. The issues I mentioned a few weeks back have been fixed.

[zabbal]

You may just add the rfc2822 F-Droid repo to F-Droid

No you can't:

The APKs are unaltered and hence still signed by the app developers.

So the Wire installed from that repo will still rely on proprietary FCM and won't work for lots of phones. The point of this ticket is not to automate manual .apk download step, it's to uplift Wire to the same code quality standards which are used by other secure chat apps in f-droid.org repos, like Telegram for example.

[zabbal]

On a positive side, with the introduction of E2E to Riot and other Matrix clients this issue might become obsolete in a foreseeable future :)

[stephenjudge]

I understand @zabbal point, however it doesn't look like Wire will ever buy in a position to replace the FCM dependcy and to be fair to Wire, they have pivoted aware from being a consumer client and are now focused on corportate solutions, so bring Wire to the F-Droid Repository is not going to be a very high priority for them.

If they cannot replace their FCM dependecy, then I would suggest that the best middle ground solution would be for them to host their own F-Droid Repository using the F-Droid Repomaker https://f-droid.org/en/repomaker/. This allows them to be in control of how their app is distrubted using the F-Droid app, rather than relying on third-party repositories like rfc2822 or Izzy's Repo.

[colans]

On a positive side, with the introduction of E2E to Riot and other Matrix clients this issue might become obsolete in a foreseeable future :)

Just to add more perspective to that thought, I've been using Riot.im/Matrix.org for a couple of years now, having dumped Wire a while ago (mostly due to https://github.com/wireapp/wire/issues/160). E2EE was in the Matrix protocol before, but the UX recently got better (yesterday, in fact).

[strypey]

@stephenjudge

Wire ... have pivoted aware from being a consumer client and are now focused on corportate solutions

This is a red herring. If a corporate user chooses Wire over a proprietary chat app (eg WhatsApp or whatever Goggle calls their "enterprise" chat apps these days), it's because they care about security. Therefore they are just as likely as anyone to want a client that meets the requirements for inclusion in the F-Droid repo. With E2EE now being on by default in Riot, If Wire don't prioritize F-Droid inclusion, and rolling out support for server<>server federation (see https://github.com/wireapp/wire/issues/160#issuecomment-582012258 ), they might find the corporate users they want as customers starting to use Matrix via Modular.im instead.

[2011]

Just to add a comment to this thread so I can find it again...

The about page on the web site states "We put security and privacy first..." I don't see how Wire can make that claim (regarding privacy, not security) when Google gets a timeline of all received messages (via FCM) for the Android app, and would likely have no problem determining the identities of two or more people (all using Android) communicating with each other (in a real-time text chat, for example).

[tuxayo]

have no problem determining the identities of two or more people (all using Android) communicating with each other (in a real-time text chat, for example).

I'm not sure how much users&messages traffic are needed to make such an attack impractical. That would be interesting to explore. IMHO, not much. I don't know how much of the 1.000.000+ install have daily activity but seeing only the GCM traffic should be terrible mess to match to user.
Responding quickly to the other is also important to help the attack.
And it's only for the receiver that gets a GCM push which makes matching harder.

[strypey]

@tuxayo

I'm not sure how much users&messages traffic are needed to make such an attack impractical.

Doesn't that rather depend on the nature of the attack? What @2011 is saying is that GCM is leaking metadata. Let's not forget that fomer government spooks have made public comments about killing people based on metadata. While that's unlikely to be part of the threat model for a corporate client, it seems wise for Wire engineers to do everything they possibly can to reduce the amount of metadata that Wire leaks.

[codedust]

More importantly, the closed-source libraries to use GCM need to be included in the Wire apk. This ruins the high mark of confidence of the Wire app not being able to bypass e2ee that is introduced by releasing the source code of the app. Only if the app can be build without any proprietary Google library, full trust in the app can be established.

[zabbal]

https://github.com/threema-ch/threema-android - given the recent news on Threema going Free (as in Freedom) way I think this issue can be closed once threema appears on f-droid.org

[grote]

Does not look like Threema is (fully) Free Software though: https://github.com/threema-ch/threema-android/blob/main/app/build.gradle#L384-L392

So it won't appear in F-Droid anytime soon.

[zabbal]

Given that this issue will soon meet half-decade jubilaum, I'm prepared to use more relaxed definition of "soon" in this case.