Signal-android: Permission to distribute Signal or a renamed fork on F-Droid

Created on 27 Aug 2020  路  3Comments  路  Source: signalapp/Signal-Android

Sorry to file this as a bug report -- after my original bug report was closed, as suggested there I posted on the Signal User Community forums and filed a pull request in May 2020, but haven't received a response and don't know how else to reliably get in contact with the team.

As per the User Community discussion, I have written some patches to Signal that stub out Google Play Services, Firebase Cloud Messaging and Machine Learning code, so Signal can build and run without these libraries, connecting via WebSocket. I mentioned this on the F-Droid forums and users were receptive to the idea of distributing a Signal build there that meets their FOSS requirements, however this has never worked out in the past; the last time this was mentioned Greyson indicated signing builds would be a holdup.

So, which approach would the Signal team prefer?

  1. Signal merges some of these patches and removes Google/Firebase code from the Website APK release. The hard part would be finding a replacement Machine Vision library for facial recognition; a Maps patch using OpenStreetMap is already in the pull request list. Signal could sign builds, F-Droid could build them reproducibly, and list Signal's own signed builds in its catalogue if they match. Signal gets more users on official builds and F-Droid users get an easy download and update experience. This would also benefit MicroG and perhaps Huawei users who can have trouble with Google connections.
  2. Allow F-Droid to list a forked and renamed client based on these patches e.g. how they distribute Fennec instead of Firefox. Users are made aware it's unofficial and might break. It'll likely miss a few features e.g. facial recognition. I'd advocate for keeping build expiry, so in the event updates stop, legacy clients won't persist beyond a couple of months. They build from source + patches and sign themselves. Should still be a net win for everyone.

In any case, could Signal please merge the patch to remove a few unnecessary calls to GMS APIs? They're all one-line tweaks (usually using Signal's existing Util library code e.g. hex conversion) and that would make maintenance easier! I've signed the CLA; the best source is the latest branch on my GitHub with -FOSS in the name (currently 4.69.6.0-FOSS). Thanks :).

Most helpful comment

Hey there! Just some background on the website release: it was never intended to be completely free of any Google Play dependencies -- instead, all our builds have a fallback such that during registration, if we detect there's no Play Services, we will fallback to using a websocket for notifications. Using FCM for notification delivery still provides the most reliable user experience and is something we'd prefer to use if the user has Play Services available on their device.

Concerning F-Droid, we already providing an auto-updating APK directly from our site, and we really don't want forked versions of the app maintained by other parties connecting to our servers. Not only could the users using the forked version have a subpar experience, but the people they're talking to (using official clients) could also have a subpar experience (for example, an official client could try to send a new kind of message that the fork, having fallen out of date, doesn't support). I know you say you'd advocate for a build expiry, but you know how things go. Of course you have our full support if you'd like to fork Signal, name it something else, and use your own servers.

I think the rest of the discussion can happen on #9644. Thanks!

All 3 comments

If it was up to me I would simply remove all ML code and features. Face recognition is not secure anyway as a picture could be used to trick it (I never tried Signal so I don't know what the ML is used for besides that)

Hey there! Just some background on the website release: it was never intended to be completely free of any Google Play dependencies -- instead, all our builds have a fallback such that during registration, if we detect there's no Play Services, we will fallback to using a websocket for notifications. Using FCM for notification delivery still provides the most reliable user experience and is something we'd prefer to use if the user has Play Services available on their device.

Concerning F-Droid, we already providing an auto-updating APK directly from our site, and we really don't want forked versions of the app maintained by other parties connecting to our servers. Not only could the users using the forked version have a subpar experience, but the people they're talking to (using official clients) could also have a subpar experience (for example, an official client could try to send a new kind of message that the fork, having fallen out of date, doesn't support). I know you say you'd advocate for a build expiry, but you know how things go. Of course you have our full support if you'd like to fork Signal, name it something else, and use your own servers.

I think the rest of the discussion can happen on #9644. Thanks!

Hi @greyson-signal , I've force-pushed the patch in the pull request to just the utility function removal, thanks if you can merge that for now.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jult picture jult  路  3Comments

notthematrix picture notthematrix  路  3Comments

Dyras picture Dyras  路  3Comments

hiredgunhouse picture hiredgunhouse  路  3Comments

McLoo picture McLoo  路  3Comments