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

Request: Google Play signed download alternative #127

Closed
countrygeek opened this Issue Feb 9, 2013 · 150 comments

Comments

Projects
None yet
@countrygeek

countrygeek commented Feb 9, 2013

I was about to suggest this before reading the infamous issue 53. It is sad to see that FDroid and WhisperSystems could not work together, I truly enjoy both projects. Needless to say a google alternative is required - google more and more frequently involves itself in privacy violations. I am opening this ticket in hopes that an alternative of some sort is made.

Possibilities:

  1. WhisperSystems creates it's own official FDroid repository, as did GuardianProject:
    https://guardianproject.info/2012/03/15/our-new-f-droid-app-repository/

  2. WhisperSystems provides an APK somewhere out there for people to download with simple instructions on how to verify it's not been tampered with.

In the event this is not done users not wanting Google will have to compile it from source, which although can be done, is a major inconvenience especially to newbies. Just for reference, there seems to be a large interest in migrating away from google. e,g, the NoGAPPS project:
http://forum.xda-developers.com/showthread.php?s=a7bf27eb98e3bcefb7e58fb46d09710b&t=1715375

I hope you all come up with a resolution. Thanks and keep up the great work! :)

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Feb 9, 2013

Member

Hey @countrygeek, let me provide a little color on why I've been reluctant to distribute APKs outside of Google Play.

First, I'm concerned primarily with the security of our users, and am interested in targeting a demographic that does not know what a checksum or signature is. You might call them "newbies," but personally I think we're doing a good job if these are the bulk of our users.

It may be an unpopular opinion, but I think the two worst security moves that an average user can make are rooting their device, or ticking the "allow 3rd party APKs" box in Android's settings. As bad as Google is, I believe that these actions make users susceptible to something that is much worse.

We are reluctant to distribute raw APKs for a few additional reasons:

  1. No upgrade channel. Timely and automatic updates are perhaps the most effective security feature we could ask for, and not having them would be a real blow for the project.

  2. No app scanning. The nice thing about market is the server-side APK scanning and signature validation they do. If you start distributing APKs around the internet, it's a reversion back to the PC security model and all of the malware problems that came with it.

  3. No crash reporting. We are able to react very quickly to crash bugs through exception reports.

  4. No stats. We are largely dependent on Play for knowing how many users we have, what types of devices they're running, and what version of Android they have. This allows us to make decisions about where to prioritize development and which platforms we should be supporting.

  5. Avoiding Play alone is not a privacy win. Many people seem to be under the impression that avoiding Play prevents their device from phoning home to Google, but that's not the case. On 2.2+, if you have the GSF on your device, it will phone home whether you have a Play account registered or not.

So that's where we are. I believe that the decision not to distribute prebuilt APKs achieves the following balance:

  1. It does not encourage the average user to tick "allow 3rd party APKs" in Android settings.

  2. It allows "power" users who can appropriately manage the risks to install TextSecure without Play by building from source.

The thesis essentially being, if you aren't able to build TextSecure from source, you probably aren't capable of managing the risks associated with 3rd party sources.

Member

moxie0 commented Feb 9, 2013

Hey @countrygeek, let me provide a little color on why I've been reluctant to distribute APKs outside of Google Play.

First, I'm concerned primarily with the security of our users, and am interested in targeting a demographic that does not know what a checksum or signature is. You might call them "newbies," but personally I think we're doing a good job if these are the bulk of our users.

It may be an unpopular opinion, but I think the two worst security moves that an average user can make are rooting their device, or ticking the "allow 3rd party APKs" box in Android's settings. As bad as Google is, I believe that these actions make users susceptible to something that is much worse.

We are reluctant to distribute raw APKs for a few additional reasons:

  1. No upgrade channel. Timely and automatic updates are perhaps the most effective security feature we could ask for, and not having them would be a real blow for the project.

  2. No app scanning. The nice thing about market is the server-side APK scanning and signature validation they do. If you start distributing APKs around the internet, it's a reversion back to the PC security model and all of the malware problems that came with it.

  3. No crash reporting. We are able to react very quickly to crash bugs through exception reports.

  4. No stats. We are largely dependent on Play for knowing how many users we have, what types of devices they're running, and what version of Android they have. This allows us to make decisions about where to prioritize development and which platforms we should be supporting.

  5. Avoiding Play alone is not a privacy win. Many people seem to be under the impression that avoiding Play prevents their device from phoning home to Google, but that's not the case. On 2.2+, if you have the GSF on your device, it will phone home whether you have a Play account registered or not.

So that's where we are. I believe that the decision not to distribute prebuilt APKs achieves the following balance:

  1. It does not encourage the average user to tick "allow 3rd party APKs" in Android settings.

  2. It allows "power" users who can appropriately manage the risks to install TextSecure without Play by building from source.

The thesis essentially being, if you aren't able to build TextSecure from source, you probably aren't capable of managing the risks associated with 3rd party sources.

@jamesbeebop

This comment has been minimized.

Show comment
Hide comment
@jamesbeebop

jamesbeebop Feb 9, 2013

FWIW I appreciate this posture. The usefulness of this app increases for me every time a friend or family member installs it ... most of whom aren't power users.

jamesbeebop commented Feb 9, 2013

FWIW I appreciate this posture. The usefulness of this app increases for me every time a friend or family member installs it ... most of whom aren't power users.

@countrygeek

This comment has been minimized.

Show comment
Hide comment
@countrygeek

countrygeek Feb 9, 2013

@moxie0 Thanks for clarifying, it does help me better understand your thoughts on it.

However, I have some possibilities for what you mentioned.

  1. No Upgrade Channel. Most Debian-based distros suffer the same, which is why they made PPA's. Further reason to offer a repository of your own which is only available via HTTPS and synced as soon as a build is made. It can be GPG signed for powerusers who are unable to compile the tool everytime a new build is made. This can be due to a number of reasons, slow connections or unreliable and censored connections while trying to download the entire Android SDK.

Don't forget the people in Arab Spring. A quick download of an APK from a trusted party vs. an entire tool-chain when Google Play is blocked is more practical.

  1. No App Scanning - Agreed. Although Google does a fairly poor job as well, plenty of active malware is inside the market. The best defense a regular user can do is watch their Permissions and install an Anti-Virus. "Powerusers" could install PermissionBlocking software and firewall their applications, as well as hash check them and check their GPG signatures.

  2. No Crash Reporting - I think Mozilla's Fennec project did an excellent job of this -
    https://wiki.mozilla.org/Mobile/Fennec
    They use their own crash reporter which doesn't require Google to function.

  3. Stats - understandable, but I think users would prefer to opt-in to sharing statistical information. e.g. Cynanogen Mod asks if this "OK" before sharing. Google only asks if it's OK to share a crash report, the rest is fair game.

  4. Definitely Agree, Google controls many facets of the phone - Oh and let's not forget CarrierIQ. That's why NoGAPPS and Replicant Project is definitely something to watch long-term.
    http://replicant.us

I believe, as rightly communicated in your other tool, Convergence.io - there must also be decentralization in layers of security. If Google has complete central control, and if they ever become compromised the entire network and users are then compromised; additionally, if it fails or is blocked it becomes impossible to access. That's why there needs to be fallback nodes/mirrors whatever you want to call them.

Outside the scope of this project, I think there should be a repository which is peer-reviewed for security, as well having an established WebOfTrust, perhaps P2P based, that doesn't require users to uncheck "3rd party apps" and is open-source.

FDroid for example (as soon as more security measures are in place) could become the official repository on Replicant devices. Then users would not have to uncheck 3rd party apps. That's when tools like this should be included in the repository and updated regularly, as well as being system apps in ROMs. It would also need to regularly pull commits and updates like Arch so there was no delay that puts users at risk.
But that's for hopeful dreaming - until then we have we have.

countrygeek commented Feb 9, 2013

@moxie0 Thanks for clarifying, it does help me better understand your thoughts on it.

However, I have some possibilities for what you mentioned.

  1. No Upgrade Channel. Most Debian-based distros suffer the same, which is why they made PPA's. Further reason to offer a repository of your own which is only available via HTTPS and synced as soon as a build is made. It can be GPG signed for powerusers who are unable to compile the tool everytime a new build is made. This can be due to a number of reasons, slow connections or unreliable and censored connections while trying to download the entire Android SDK.

Don't forget the people in Arab Spring. A quick download of an APK from a trusted party vs. an entire tool-chain when Google Play is blocked is more practical.

  1. No App Scanning - Agreed. Although Google does a fairly poor job as well, plenty of active malware is inside the market. The best defense a regular user can do is watch their Permissions and install an Anti-Virus. "Powerusers" could install PermissionBlocking software and firewall their applications, as well as hash check them and check their GPG signatures.

  2. No Crash Reporting - I think Mozilla's Fennec project did an excellent job of this -
    https://wiki.mozilla.org/Mobile/Fennec
    They use their own crash reporter which doesn't require Google to function.

  3. Stats - understandable, but I think users would prefer to opt-in to sharing statistical information. e.g. Cynanogen Mod asks if this "OK" before sharing. Google only asks if it's OK to share a crash report, the rest is fair game.

  4. Definitely Agree, Google controls many facets of the phone - Oh and let's not forget CarrierIQ. That's why NoGAPPS and Replicant Project is definitely something to watch long-term.
    http://replicant.us

I believe, as rightly communicated in your other tool, Convergence.io - there must also be decentralization in layers of security. If Google has complete central control, and if they ever become compromised the entire network and users are then compromised; additionally, if it fails or is blocked it becomes impossible to access. That's why there needs to be fallback nodes/mirrors whatever you want to call them.

Outside the scope of this project, I think there should be a repository which is peer-reviewed for security, as well having an established WebOfTrust, perhaps P2P based, that doesn't require users to uncheck "3rd party apps" and is open-source.

FDroid for example (as soon as more security measures are in place) could become the official repository on Replicant devices. Then users would not have to uncheck 3rd party apps. That's when tools like this should be included in the repository and updated regularly, as well as being system apps in ROMs. It would also need to regularly pull commits and updates like Arch so there was no delay that puts users at risk.
But that's for hopeful dreaming - until then we have we have.

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Feb 9, 2013

Member
  1. No Upgrade Channel. Most Debian-based distros suffer the same, which is why they made PPA's. Further
    reason to offer a repository of your own which is only available via HTTPS and synced as soon as a build is
    made. It can be GPG signed for powerusers who are unable to compile the tool everytime a new build is made.
    This can be due to a number of reasons, slow connections or unreliable and censored connections while trying to
    download the entire Android SDK.

Generally speaking, comparisons to the PC world are not going to resonate with me. The security model for desktops (unix-based and windows-based) is completely broken, and I think the mobile environment should be a chance to rectify our past sins, not copy them.

The current situation is that it's not (rightly!) possible for a 3rd party app to automatically install an APK. This fundamentally prevents auto-updates from being a reality outside of Play.

Don't forget the people in Arab Spring. A quick download of an APK from a trusted party vs. an entire tool-chain
when Google Play is blocked is more practical.

Unfortunately, circumvention problems extend beyond the download. RedPhone depends on GCM, and soon TextSecure likely will as well. My sense is that other projects are better positioned to deal with circumvention in the general case.

  1. No App Scanning - Agreed. Although Google does a fairly poor job as well, plenty of active malware is inside
    the market. The best defense a regular user can do is watch their Permissions and install an Anti-Virus.
    "Powerusers" could install PermissionBlocking software and firewall their applications, as well as hash check
    them and check their GPG signatures.

Actually, the malware incidence inside of the Play Store is exceptionally low. Compare it to desktop malware, and it's nonexistent. The bulk of mobile malware (drudged up by AV companies to justify their existence) has been in 3rd party app stores and random drive-by downloads. And the problem with depending on mobile AV is that mobile AV is a complete joke, even more so than desktop AV. These apps have no system integration, so they literally can't do anything other than look at a 3rd party APK at install time. It's quite easy to evade any signature detection and then simply disable the AV app. This is already happening.

Again, I feel like we should be desperately trying to avoid what we inherited with the desktop paradigm, rather than reproducing it.

  1. No Crash Reporting - I think Mozilla's Fennec project did an excellent job of this -
    https://wiki.mozilla.org/Mobile/Fennec
    They use their own crash reporter which doesn't require Google to function.

A good crash reporting solution is essentially a product in itself. There are entire companies built around mobile crash reporting, but as far as I've seen, none of them are as good as the default Play reporting. To ask that I develop and maintain my own is a big ask. I can't emphasize how important this is to the project.

  1. Stats - understandable, but I think users would prefer to opt-in to sharing statistical information. e.g.
    Cynanogen Mod asks if this "OK" before sharing. Google only asks if it's OK to share a crash report, the rest is
    fair game.

Build me a high quality stats reporting solution with a nice web interface that displays graphs and trends of time. Then manage the server side hosting for me, and I'll use it. =)

I believe, as rightly communicated in your other tool, Convergence.io - there must also be decentralization in
layers of security. If Google has complete central control, and if they ever become compromised the entire
network and users are then compromised; additionally, if it fails or is blocked it becomes impossible to access.
That's why there needs to be fallback nodes/mirrors whatever you want to call them.

This is actually how the Play Store works right now. Google does not have complete control over all updates: I sign all APKs with my own code signing key that is kept offline. These signatures are enforced by the PackageManagerService on each user's device, not by the Play Store itself. The mechanics are very similar to TACK (http://tack.io), which is what we're currently advocating for the TLS world.

This is in huge contrast to how the bulk of apps on fdroid are distributed. Most are not signed by the developers, but by fdroid itself, with keys that they keep online. I believe this is a dangerous situation, and is one of the primary reasons (along with having to enable 3rd party sources) that I don't recommend using fdroid.

Member

moxie0 commented Feb 9, 2013

  1. No Upgrade Channel. Most Debian-based distros suffer the same, which is why they made PPA's. Further
    reason to offer a repository of your own which is only available via HTTPS and synced as soon as a build is
    made. It can be GPG signed for powerusers who are unable to compile the tool everytime a new build is made.
    This can be due to a number of reasons, slow connections or unreliable and censored connections while trying to
    download the entire Android SDK.

Generally speaking, comparisons to the PC world are not going to resonate with me. The security model for desktops (unix-based and windows-based) is completely broken, and I think the mobile environment should be a chance to rectify our past sins, not copy them.

The current situation is that it's not (rightly!) possible for a 3rd party app to automatically install an APK. This fundamentally prevents auto-updates from being a reality outside of Play.

Don't forget the people in Arab Spring. A quick download of an APK from a trusted party vs. an entire tool-chain
when Google Play is blocked is more practical.

Unfortunately, circumvention problems extend beyond the download. RedPhone depends on GCM, and soon TextSecure likely will as well. My sense is that other projects are better positioned to deal with circumvention in the general case.

  1. No App Scanning - Agreed. Although Google does a fairly poor job as well, plenty of active malware is inside
    the market. The best defense a regular user can do is watch their Permissions and install an Anti-Virus.
    "Powerusers" could install PermissionBlocking software and firewall their applications, as well as hash check
    them and check their GPG signatures.

Actually, the malware incidence inside of the Play Store is exceptionally low. Compare it to desktop malware, and it's nonexistent. The bulk of mobile malware (drudged up by AV companies to justify their existence) has been in 3rd party app stores and random drive-by downloads. And the problem with depending on mobile AV is that mobile AV is a complete joke, even more so than desktop AV. These apps have no system integration, so they literally can't do anything other than look at a 3rd party APK at install time. It's quite easy to evade any signature detection and then simply disable the AV app. This is already happening.

Again, I feel like we should be desperately trying to avoid what we inherited with the desktop paradigm, rather than reproducing it.

  1. No Crash Reporting - I think Mozilla's Fennec project did an excellent job of this -
    https://wiki.mozilla.org/Mobile/Fennec
    They use their own crash reporter which doesn't require Google to function.

A good crash reporting solution is essentially a product in itself. There are entire companies built around mobile crash reporting, but as far as I've seen, none of them are as good as the default Play reporting. To ask that I develop and maintain my own is a big ask. I can't emphasize how important this is to the project.

  1. Stats - understandable, but I think users would prefer to opt-in to sharing statistical information. e.g.
    Cynanogen Mod asks if this "OK" before sharing. Google only asks if it's OK to share a crash report, the rest is
    fair game.

Build me a high quality stats reporting solution with a nice web interface that displays graphs and trends of time. Then manage the server side hosting for me, and I'll use it. =)

I believe, as rightly communicated in your other tool, Convergence.io - there must also be decentralization in
layers of security. If Google has complete central control, and if they ever become compromised the entire
network and users are then compromised; additionally, if it fails or is blocked it becomes impossible to access.
That's why there needs to be fallback nodes/mirrors whatever you want to call them.

This is actually how the Play Store works right now. Google does not have complete control over all updates: I sign all APKs with my own code signing key that is kept offline. These signatures are enforced by the PackageManagerService on each user's device, not by the Play Store itself. The mechanics are very similar to TACK (http://tack.io), which is what we're currently advocating for the TLS world.

This is in huge contrast to how the bulk of apps on fdroid are distributed. Most are not signed by the developers, but by fdroid itself, with keys that they keep online. I believe this is a dangerous situation, and is one of the primary reasons (along with having to enable 3rd party sources) that I don't recommend using fdroid.

@Argafal

This comment has been minimized.

Show comment
Hide comment
@Argafal

Argafal Feb 12, 2013

I am happy to see this issue discussed here and i would like to add another user requesting this app to be available from outside Google Play. I do not use Google Play since I do not wish to bundle my phone with a Google account. I do see your reasoning in why you are reluctant to support anything else, but I think you should reconsider this, at least for alternatives that actually care about security and open source software. I fully agree that decentralization is a vital requirement for secure designs and that monopolies should be avoided. History shows many examples.

For my daily use I use fdroid exclusively, since I see the need for a trustworthy source of applications and an update mechanism. Fdroid provides this for me at the level that I require. Yes, some details could be improved (such as statistics), but I think it's very much a step in the right direction. I do believe the fdroid folks are in general very open to suggestions.

I very much wish I could get the most recent TextSecure through fdroid as well rather than having the choice between running a version older than Methusalem or building from source. Avoiding the former should be in your very own interest as the author of the app. The latter requires me to constantly monitor for updates and bugs and is manual work which I wish I could avoid. Since most of my friends and family use cyanogenmod and fdroid as well I am very reluctant to suggest them to upgrade to TextSecure, since that would put me in the apk maintainer position.

For these reason I would greatly appreciate to see TextSecure back in fdroid, and I would very much hope you reconsider your position on this.

Argafal commented Feb 12, 2013

I am happy to see this issue discussed here and i would like to add another user requesting this app to be available from outside Google Play. I do not use Google Play since I do not wish to bundle my phone with a Google account. I do see your reasoning in why you are reluctant to support anything else, but I think you should reconsider this, at least for alternatives that actually care about security and open source software. I fully agree that decentralization is a vital requirement for secure designs and that monopolies should be avoided. History shows many examples.

For my daily use I use fdroid exclusively, since I see the need for a trustworthy source of applications and an update mechanism. Fdroid provides this for me at the level that I require. Yes, some details could be improved (such as statistics), but I think it's very much a step in the right direction. I do believe the fdroid folks are in general very open to suggestions.

I very much wish I could get the most recent TextSecure through fdroid as well rather than having the choice between running a version older than Methusalem or building from source. Avoiding the former should be in your very own interest as the author of the app. The latter requires me to constantly monitor for updates and bugs and is manual work which I wish I could avoid. Since most of my friends and family use cyanogenmod and fdroid as well I am very reluctant to suggest them to upgrade to TextSecure, since that would put me in the apk maintainer position.

For these reason I would greatly appreciate to see TextSecure back in fdroid, and I would very much hope you reconsider your position on this.

@mvdan

This comment has been minimized.

Show comment
Hide comment
@mvdan

mvdan Feb 12, 2013

@moxie0 Might I give my five cents here?

I've gone through all the discussions on this, and this is my overall conclusion: Your concern here seems to be the safety of your users. You don't want them ignoring the availability of newer versions, or downloading APK's from sources that don't provide you with use/device statistics. Is that correct?

Now, here's my point of view - What about the users who do not want to use Google Play and do not want to follow your advice? Surely you can consider that as harmful to them - but that's their problem, not yours. And the amount of people who use F-Droid is in no way comparable to the amount of people who use Google Play.

Moreover, I would certainly not think that by keeping F-Droid from packaging your software you are getting more installs on Google Play. Most of the people who use it would never consider using Google, thus you're just making life harder for these people. Nor are you winning anything by that prohibition.

Please do tell me if I understood anything the wrong way. I just started packaging for F-Droid as a hobby, and I'd like to package your software in the following days. Hopefully there won't be a problem with that.

mvdan commented Feb 12, 2013

@moxie0 Might I give my five cents here?

I've gone through all the discussions on this, and this is my overall conclusion: Your concern here seems to be the safety of your users. You don't want them ignoring the availability of newer versions, or downloading APK's from sources that don't provide you with use/device statistics. Is that correct?

Now, here's my point of view - What about the users who do not want to use Google Play and do not want to follow your advice? Surely you can consider that as harmful to them - but that's their problem, not yours. And the amount of people who use F-Droid is in no way comparable to the amount of people who use Google Play.

Moreover, I would certainly not think that by keeping F-Droid from packaging your software you are getting more installs on Google Play. Most of the people who use it would never consider using Google, thus you're just making life harder for these people. Nor are you winning anything by that prohibition.

Please do tell me if I understood anything the wrong way. I just started packaging for F-Droid as a hobby, and I'd like to package your software in the following days. Hopefully there won't be a problem with that.

@Argafal

This comment has been minimized.

Show comment
Hide comment
@Argafal

Argafal Feb 12, 2013

mvdan, thanks for adding this. Indeed I would never consider using Google Play, that was the point I was trying to make. I build it myself until I find an alternative way of getting the app in a recent version. Unfortunately my grandma can't do that (building it herself) so she can't use it. ;)

Argafal commented Feb 12, 2013

mvdan, thanks for adding this. Indeed I would never consider using Google Play, that was the point I was trying to make. I build it myself until I find an alternative way of getting the app in a recent version. Unfortunately my grandma can't do that (building it herself) so she can't use it. ;)

@dalb8

This comment has been minimized.

Show comment
Hide comment
@dalb8

dalb8 Feb 12, 2013

If the app uses GCM will it be usable without Google Play?

F-Droid admin does not keep the keystore online: how could one come to that conclusion?

He signs the apks, thus we know if updates are also signed by him; I don't see why this fact should upset the whole idea of sharing software as set out in the GNU GPL.

dalb8 commented Feb 12, 2013

If the app uses GCM will it be usable without Google Play?

F-Droid admin does not keep the keystore online: how could one come to that conclusion?

He signs the apks, thus we know if updates are also signed by him; I don't see why this fact should upset the whole idea of sharing software as set out in the GNU GPL.

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Feb 12, 2013

Member

@Argafal

I am happy to see this issue discussed here and i would like to add another user requesting this app to be
available from outside Google Play. I do not use Google Play since I do not wish to bundle my phone with a
Google account. I do see your reasoning in why you are reluctant to support anything else, but I think you should
reconsider this, at least for alternatives that actually care about security and open source software. I fully agree
that decentralization is a vital requirement for secure designs and that monopolies should be avoided. History
shows many examples.

But I'm reluctant to distribute APKs outside of the Play Store precisely because I care about the security of TextSecure users.

Additionally, many folks seem to think that not adding a Google account to their device is a privacy win, when that's rarely the case. If your device has GSF installed, the privacy implications are the same whether you have a Google account associated or not.

For my daily use I use fdroid exclusively, since I see the need for a trustworthy source of applications and an
update mechanism. Fdroid provides this for me at the level that I require. Yes, some details could be improved
(such as statistics), but I think it's very much a step in the right direction. I do believe the fdroid folks are in
general very open to suggestions.

It's not just statistics. The problem is the security model. The bulk of applications distributed through fdroid are signed by keys that belong to the fdroid maintainers, and which are kept online. This means that the fdroid maintainers themselves, or any attackers who compromise fdroid, are capable of pushing malware to your device.

This is a huge contrast to Google Play, where every app is signed by keys that belong to the app's developers. Google, or attackers who compromise Google, are not capable of pushing rogue updates.

I very much wish I could get the most recent TextSecure through fdroid as well rather than having the choice
between running a version older than Methusalem or building from source. Avoiding the former should be in your
very own interest as the author of the app. The latter requires me to constantly monitor for updates and bugs and
is manual work which I wish I could avoid. Since most of my friends and family use cyanogenmod and fdroid as
well I am very reluctant to suggest them to upgrade to TextSecure, since that would put me in the apk maintainer
position.

Again, I know that this is probably an unpopular opinion, but if you've set your "less technical" friends and family up with cyanogenmod and fdroid, I believe that you've very seriously compromised their security. Both cyanogen and fdroid seriously compromise the security gains that we've made in the mobile environment and are a reversion back to the desktop security model:

  1. Cyanogen runs things as root, completely circumventing the development of a fine grained permissions system. They've also made a number of tradeoffs that further weaken its security.

  2. In order for your friends to run fdroid, they've had to tick "allow 3rd party sources," which is probably the single most effective malware prevention mechanism for less savvy users.

It's exactly this (setting less technical users up with things like fdroid) that I am afraid of.

For you, compiling and installing from source once a week is literally three commands: git pull && ant release && adb install -r bin/TextSecure-release.apk. For your friends who are not technically capable of doing this, I believe that this means they aren't savvy enough to tick "allow 3rd party sources" responsibly.

I totally agree that 3rd party app store alternatives seem cool, but until they're done securely and correctly, I'd prefer not to participate.

Member

moxie0 commented Feb 12, 2013

@Argafal

I am happy to see this issue discussed here and i would like to add another user requesting this app to be
available from outside Google Play. I do not use Google Play since I do not wish to bundle my phone with a
Google account. I do see your reasoning in why you are reluctant to support anything else, but I think you should
reconsider this, at least for alternatives that actually care about security and open source software. I fully agree
that decentralization is a vital requirement for secure designs and that monopolies should be avoided. History
shows many examples.

But I'm reluctant to distribute APKs outside of the Play Store precisely because I care about the security of TextSecure users.

Additionally, many folks seem to think that not adding a Google account to their device is a privacy win, when that's rarely the case. If your device has GSF installed, the privacy implications are the same whether you have a Google account associated or not.

For my daily use I use fdroid exclusively, since I see the need for a trustworthy source of applications and an
update mechanism. Fdroid provides this for me at the level that I require. Yes, some details could be improved
(such as statistics), but I think it's very much a step in the right direction. I do believe the fdroid folks are in
general very open to suggestions.

It's not just statistics. The problem is the security model. The bulk of applications distributed through fdroid are signed by keys that belong to the fdroid maintainers, and which are kept online. This means that the fdroid maintainers themselves, or any attackers who compromise fdroid, are capable of pushing malware to your device.

This is a huge contrast to Google Play, where every app is signed by keys that belong to the app's developers. Google, or attackers who compromise Google, are not capable of pushing rogue updates.

I very much wish I could get the most recent TextSecure through fdroid as well rather than having the choice
between running a version older than Methusalem or building from source. Avoiding the former should be in your
very own interest as the author of the app. The latter requires me to constantly monitor for updates and bugs and
is manual work which I wish I could avoid. Since most of my friends and family use cyanogenmod and fdroid as
well I am very reluctant to suggest them to upgrade to TextSecure, since that would put me in the apk maintainer
position.

Again, I know that this is probably an unpopular opinion, but if you've set your "less technical" friends and family up with cyanogenmod and fdroid, I believe that you've very seriously compromised their security. Both cyanogen and fdroid seriously compromise the security gains that we've made in the mobile environment and are a reversion back to the desktop security model:

  1. Cyanogen runs things as root, completely circumventing the development of a fine grained permissions system. They've also made a number of tradeoffs that further weaken its security.

  2. In order for your friends to run fdroid, they've had to tick "allow 3rd party sources," which is probably the single most effective malware prevention mechanism for less savvy users.

It's exactly this (setting less technical users up with things like fdroid) that I am afraid of.

For you, compiling and installing from source once a week is literally three commands: git pull && ant release && adb install -r bin/TextSecure-release.apk. For your friends who are not technically capable of doing this, I believe that this means they aren't savvy enough to tick "allow 3rd party sources" responsibly.

I totally agree that 3rd party app store alternatives seem cool, but until they're done securely and correctly, I'd prefer not to participate.

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Feb 12, 2013

Member

@mvdan

Now, here's my point of view - What about the users who do not want to use Google Play and do not want to
follow your advice? Surely you can consider that as harmful to them - but that's their problem, not yours. And the
amount of people who use F-Droid is in no way comparable to the amount of people who use Google Play.

Moreover, I would certainly not think that by keeping F-Droid from packaging your software you are getting more
installs on Google Play. Most of the people who use it would never consider using Google, thus you're just
making life harder for these people. Nor are you winning anything by that prohibition.

I can't willingly participate in something that I believe is a bad idea. I can't sign and distribute packages through fdroid, because I believe that fdroid is harmful, and I don't want to endorse harmful activity.

I understand that many of the people commenting here probably understand how insecure fdroid is, but value a full OSS stack more than the security of their device. That's fine, but I think anyone that completely understands the risks is also completely capable of building TextSecure from source themselves. It's the people that don't understand the risks that I'm worried about.

Please do tell me if I understood anything the wrong way. I just started packaging for F-Droid as a hobby, and I'd
like to package your software in the following days. Hopefully there won't be a problem with that.

It's my preference that you don't. I spend a lot of time on this project, and I'm certain that having APKs floating around which are signed by someone else will inevitably cause problems for me in the future.

I realize that everyone here likely has their own projects that they spend their time on, but before jumping straight to the high-level decisions for the direction of this project, I would recommend that people who are interested in this project's direction start by committing a little bit of code here first, in order to get a feeling for this codebase and its challenges.

Member

moxie0 commented Feb 12, 2013

@mvdan

Now, here's my point of view - What about the users who do not want to use Google Play and do not want to
follow your advice? Surely you can consider that as harmful to them - but that's their problem, not yours. And the
amount of people who use F-Droid is in no way comparable to the amount of people who use Google Play.

Moreover, I would certainly not think that by keeping F-Droid from packaging your software you are getting more
installs on Google Play. Most of the people who use it would never consider using Google, thus you're just
making life harder for these people. Nor are you winning anything by that prohibition.

I can't willingly participate in something that I believe is a bad idea. I can't sign and distribute packages through fdroid, because I believe that fdroid is harmful, and I don't want to endorse harmful activity.

I understand that many of the people commenting here probably understand how insecure fdroid is, but value a full OSS stack more than the security of their device. That's fine, but I think anyone that completely understands the risks is also completely capable of building TextSecure from source themselves. It's the people that don't understand the risks that I'm worried about.

Please do tell me if I understood anything the wrong way. I just started packaging for F-Droid as a hobby, and I'd
like to package your software in the following days. Hopefully there won't be a problem with that.

It's my preference that you don't. I spend a lot of time on this project, and I'm certain that having APKs floating around which are signed by someone else will inevitably cause problems for me in the future.

I realize that everyone here likely has their own projects that they spend their time on, but before jumping straight to the high-level decisions for the direction of this project, I would recommend that people who are interested in this project's direction start by committing a little bit of code here first, in order to get a feeling for this codebase and its challenges.

@mvdan

This comment has been minimized.

Show comment
Hide comment
@mvdan

mvdan Feb 12, 2013

@moxie0

You're not being asked to participate in F-Droid, nor are you needed to sign or distribute any packages for it.

And, as much as security seems to be quite subjective, I would not say F-Droid is insecure. Like @dalb8 stated, no keys are online, and the default downloads are through SSL. I see no big insecurity here. Even if there was, that's the risk the user is willing to take once he installs F-Droid and accepts the terms of service. Much like with CM - we are not bringing malware to the masses.

I see it is your preference that we don't package it. But I don't understand the reason. We can always add something like the following to the description:

Please make sure that you're running the latest upstream version before submitting any bug reports.

Would that suffice? It has been said before that you "forbid" us from packaging it, but that's not what I understood. You'd rather not have people install it from non-Google sources, but we can still package it as-is without a problem.

mvdan commented Feb 12, 2013

@moxie0

You're not being asked to participate in F-Droid, nor are you needed to sign or distribute any packages for it.

And, as much as security seems to be quite subjective, I would not say F-Droid is insecure. Like @dalb8 stated, no keys are online, and the default downloads are through SSL. I see no big insecurity here. Even if there was, that's the risk the user is willing to take once he installs F-Droid and accepts the terms of service. Much like with CM - we are not bringing malware to the masses.

I see it is your preference that we don't package it. But I don't understand the reason. We can always add something like the following to the description:

Please make sure that you're running the latest upstream version before submitting any bug reports.

Would that suffice? It has been said before that you "forbid" us from packaging it, but that's not what I understood. You'd rather not have people install it from non-Google sources, but we can still package it as-is without a problem.

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Feb 12, 2013

Member

It's my preference that you don't. I would also reiterate that it might behoove you to commit even a single line of code before you jump straight to signing your own releases. =)

Member

moxie0 commented Feb 12, 2013

It's my preference that you don't. I would also reiterate that it might behoove you to commit even a single line of code before you jump straight to signing your own releases. =)

@mvdan

This comment has been minimized.

Show comment
Hide comment
@mvdan

mvdan Feb 12, 2013

It's my preference that you don't. I would also reiterate that it might behoove you to commit even a single line of code before you jump straight to signing your own releases. =)

Although you might be right, I have never done any serious Java. Still getting started with C++. Perhaps someone else would be of some use to you. But so far all I've been doing is packaging.

mvdan commented Feb 12, 2013

It's my preference that you don't. I would also reiterate that it might behoove you to commit even a single line of code before you jump straight to signing your own releases. =)

Although you might be right, I have never done any serious Java. Still getting started with C++. Perhaps someone else would be of some use to you. But so far all I've been doing is packaging.

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Feb 12, 2013

Member

The only secret is to begin. Pick one of the open issues, start working on it, and you'll figure it out as you go.

Member

moxie0 commented Feb 12, 2013

The only secret is to begin. Pick one of the open issues, start working on it, and you'll figure it out as you go.

@tedks

This comment has been minimized.

Show comment
Hide comment
@tedks

tedks Feb 12, 2013

@moxie0 -- As one of the former users of TextSecure via fdroid, and someone who values libre software and security, I'd like to say that I appreciate your points, and feel pretty good about my decision to keep using TextSecure as deployed by the Play store.

However, I'd still prefer to use fdroid for as many apps as I can, and I'd also like to have some sense of security when using it.

As a compromise, do you think you could outline, either on fdroid's bug tracker or here, exactly what would need to be fixed in fdroid before you'd consider allowing TextSecure on it? Then, the people who want TextSecure in fdroid can fix those bugs, or work towards fixing them. Either way, everyone benefits: you get a definitive end to these issues, and fdroid gets more secure.

As an FSF member, free software advocate, fdroid user, etc., I hope that if Moxie does this, it ends this discussion until those bugs are resolved. Moxie is the maintainer of a free software package; he's under no obligation to do even more work than he already has for our benefit; forcing him to repeat himself on bug reports like these is to no one's benefit.

(At least one of the things mentioned in this thread is not necessarily an issue: there are some packages in fdroid that have packages signed by the maintainers, including the Firefox build, I believe.)

tedks commented Feb 12, 2013

@moxie0 -- As one of the former users of TextSecure via fdroid, and someone who values libre software and security, I'd like to say that I appreciate your points, and feel pretty good about my decision to keep using TextSecure as deployed by the Play store.

However, I'd still prefer to use fdroid for as many apps as I can, and I'd also like to have some sense of security when using it.

As a compromise, do you think you could outline, either on fdroid's bug tracker or here, exactly what would need to be fixed in fdroid before you'd consider allowing TextSecure on it? Then, the people who want TextSecure in fdroid can fix those bugs, or work towards fixing them. Either way, everyone benefits: you get a definitive end to these issues, and fdroid gets more secure.

As an FSF member, free software advocate, fdroid user, etc., I hope that if Moxie does this, it ends this discussion until those bugs are resolved. Moxie is the maintainer of a free software package; he's under no obligation to do even more work than he already has for our benefit; forcing him to repeat himself on bug reports like these is to no one's benefit.

(At least one of the things mentioned in this thread is not necessarily an issue: there are some packages in fdroid that have packages signed by the maintainers, including the Firefox build, I believe.)

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Jul 30, 2013

Member

This is the current list of things that we need before we can distribute an APK outside of the Play Store. Any help completing these missing pieces would certainly be appreciated:

  • A built in crash reporting solution with a web interface that allows us to visualize crashes and sort by app version, device type, etc. This is essential for producing stable software.
  • A built in statistics gathering solution with a web interface that allows us to visualize aggregate numbers on device type, android version, and carriers for our users. This has been crucial in shaping support and development direction.
  • A built in auto-update solution. Fully automatic upgrades won't be possible outside of Play Store, but we at least need something that will annoy the hell out of users until they upgrade. This is necessary for ensuring that new security features and bug fixes can be propagated quickly.
  • A build system that allows us to easily turn these features on and off for Play and non-Play builds. Gradle should make this easier.
Member

moxie0 commented Jul 30, 2013

This is the current list of things that we need before we can distribute an APK outside of the Play Store. Any help completing these missing pieces would certainly be appreciated:

  • A built in crash reporting solution with a web interface that allows us to visualize crashes and sort by app version, device type, etc. This is essential for producing stable software.
  • A built in statistics gathering solution with a web interface that allows us to visualize aggregate numbers on device type, android version, and carriers for our users. This has been crucial in shaping support and development direction.
  • A built in auto-update solution. Fully automatic upgrades won't be possible outside of Play Store, but we at least need something that will annoy the hell out of users until they upgrade. This is necessary for ensuring that new security features and bug fixes can be propagated quickly.
  • A build system that allows us to easily turn these features on and off for Play and non-Play builds. Gradle should make this easier.
@michalzxc

This comment has been minimized.

Show comment
Hide comment
@michalzxc

michalzxc Aug 18, 2013

"1) Cyanogen runs things as root, completely circumventing the development of a fine grained permissions system. They've also made a number of tradeoffs that further weaken its security."

Sniffing phone communication, like motorola did?
http://www.beneaththewaves.net/Projects/Motorola_Is_Listening.html?source=hn

Or maybe you think about Trojans like Carrier iQ?
http://gizmodo.com/5864220/what-is-carrier-iq

Closed source (official) ROMs doesn't have weak security, there are completely compromised. Full of malware, trojans and backdoors.

  1. In order for your friends to run fdroid, they've had to tick "allow 3rd party sources," which is probably the single most effective malware prevention mechanism for less savvy users.

If you have your official OEM ROM, you don't have to install any malware, you have all out of the box

michalzxc commented Aug 18, 2013

"1) Cyanogen runs things as root, completely circumventing the development of a fine grained permissions system. They've also made a number of tradeoffs that further weaken its security."

Sniffing phone communication, like motorola did?
http://www.beneaththewaves.net/Projects/Motorola_Is_Listening.html?source=hn

Or maybe you think about Trojans like Carrier iQ?
http://gizmodo.com/5864220/what-is-carrier-iq

Closed source (official) ROMs doesn't have weak security, there are completely compromised. Full of malware, trojans and backdoors.

  1. In order for your friends to run fdroid, they've had to tick "allow 3rd party sources," which is probably the single most effective malware prevention mechanism for less savvy users.

If you have your official OEM ROM, you don't have to install any malware, you have all out of the box

@KaitoKito

This comment has been minimized.

Show comment
Hide comment
@KaitoKito

KaitoKito Aug 29, 2013

I've read the whole conversation and I don't understand something : if someone want textsecure but don't want to use a google account and has better thing to do than learn how to compile an android software, he can either download a very very very old version or take an .apk compiled by someone on internet without knowing if the .apk he's downloading has been compromised or no. Do you really prefer these two insecure option for your users instead of releasing an official binary, compiled by your hands, right here ?

Also I don't understand why the fact of not knowing how to compile a source code make you not enough responsible to untick the "third party app". I know many guys who know how to program and compile codes but they still can't avoid stupid viruses on Internet and next to them some people who can't even read a source code but are enough intelligent to know which app is good and safe for them. Your argument is invalid.

"I spend a lot of time on this project, and I'm certain that having APKs floating around which are signed by someone else will inevitably cause problems for me in the future." If you really think this the most intelligent thing to do is to compile and sign yourself the .apk who will floating on internet. don't give the time to creepy black hats to do it before you.

KaitoKito commented Aug 29, 2013

I've read the whole conversation and I don't understand something : if someone want textsecure but don't want to use a google account and has better thing to do than learn how to compile an android software, he can either download a very very very old version or take an .apk compiled by someone on internet without knowing if the .apk he's downloading has been compromised or no. Do you really prefer these two insecure option for your users instead of releasing an official binary, compiled by your hands, right here ?

Also I don't understand why the fact of not knowing how to compile a source code make you not enough responsible to untick the "third party app". I know many guys who know how to program and compile codes but they still can't avoid stupid viruses on Internet and next to them some people who can't even read a source code but are enough intelligent to know which app is good and safe for them. Your argument is invalid.

"I spend a lot of time on this project, and I'm certain that having APKs floating around which are signed by someone else will inevitably cause problems for me in the future." If you really think this the most intelligent thing to do is to compile and sign yourself the .apk who will floating on internet. don't give the time to creepy black hats to do it before you.

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Aug 29, 2013

Member

@KaitoKito If you look at the number of open issues we have right now, we're substantially behind where we'd like to be in terms of providing support. We're at a place where raising our support load by even 1% would be really overwhelming, and my sense is that an official non-Play APK release without the 4 prerequisites I list above would have that impact.

So I'd love to get a non-Play APK distribution channel going, but we need to do some work in order to make that happen smoothly. If this is something you're interested in seeing, the best thing you can do to help is to take on some of the work listed here: #127 (comment)

Member

moxie0 commented Aug 29, 2013

@KaitoKito If you look at the number of open issues we have right now, we're substantially behind where we'd like to be in terms of providing support. We're at a place where raising our support load by even 1% would be really overwhelming, and my sense is that an official non-Play APK release without the 4 prerequisites I list above would have that impact.

So I'd love to get a non-Play APK distribution channel going, but we need to do some work in order to make that happen smoothly. If this is something you're interested in seeing, the best thing you can do to help is to take on some of the work listed here: #127 (comment)

@dalb8

This comment has been minimized.

Show comment
Hide comment
@dalb8

dalb8 Aug 29, 2013

Too true: anybody can be careless, even clever people. However, I don't think it's fair to portray compiling apps as difficult. Some are, but not this one — give it a try!

dalb8 commented Aug 29, 2013

Too true: anybody can be careless, even clever people. However, I don't think it's fair to portray compiling apps as difficult. Some are, but not this one — give it a try!

@zak333

This comment has been minimized.

Show comment
Hide comment
@zak333

zak333 Oct 16, 2013

Hello moxie,

thank you for your discussion about this issue. There are many other developers out there, who close such issues very fast, avoiding the opinions and preferences of other users.

I recognize you think the "security model for desktops (unix-based and windows-based) is completely broken" and "believe that fdroid is harmful, and [you] don't want to endorse harmful activity."

As I understand it, your sense of security lies in the use of Google Play in combination with the deactivation of the ability to install 3rd party applications. The ability to create, sign and upload your app to the Playstore yourself gives you alone the full control of it. Nobody else should be able to provide any other (probably compromised) version of your app.

Although I can understand the positive implications of this, I nevertheless strongly want to disagree with this perspective. First: It's condition is to trust two involved parties.

  1. Google
    I do not know, what Google really does. Its main purpose of existence is the processing of data, our data. It can keep track of our phones, our contacts, our communication, our preferences, what apps we use when and how often and who knows what else. I do not allege Google to use this data against us (yet?) (maybe undeliberately?), but I simply do not want to create any account with Google just to be able to install some few apps I would like to use. And as you can see, there are many other users who think alike.
    I do not know if Google modifies your created package in some way, too. It may be unlikely, but I cannot be absolute sure they don't either. Who programmed the key-verification routines and how do they really work with all those Google Apps?
    In the end, if I would want to install something from Google Play, I will have to give Google my trust.
  2. (Please don't take this personally) You
    I do not believe you have any bad interests when providing us your software. (And I am of course grateful you provide it at all!) But the fact is, the way I see it now, you are the only one involved in creating this package, and I therefore need to trust you alone with it. It could be very easy for you to patch every version just before you compile it and add a few lines. No one would ever know. Maybe in a year or so, someone sends you a generous check, if you would be so nice to add some specific code. Maybe someone hacks your server/workstation and uploads a new version under your name. Again: I don't think this will happen and you are probably trustworthy, but in the end, the trust in you alone is mandatory.

Now, it is of course essential, that security is not possible without the trust to anybody. So second: The problem with your concept is, that we - the users - do not have the choice who we trust. If we want to install the app, we are forced to trust you with packaging and to trust Google with providing it.
(I leave the option to compile the source ourselves, because that is not the issue here. I believe the issue is to provide users an easy and secure concept of installing and using applications.)

If however, other people in an open community become involved in the distribution of applications and this distribution is transparent and replicable, the possibility of compromised software gets lower.

Why is that so?
a) The chances, that several people at once have malevolent intentions is lower. If only one person is involved, he/she can do whatever he/she wants without anybody else noticing.
b) If someone does something wrong (either intentionally or accidentally), there is a good chance that someone else recognizes this.
c) In case of a bigger project like F-Droid (or take Debian for example to mention one of your "faulty desktop security models"), the impact of something bad would fall back on the whole project. It is unlikely that people will risk losing their trust by risking something bad with a few apps/programs.

And finally, I cannot emphasize enough the most important thing I believe security should have: The freedom of choice! If I think Google is untrustworthy, I should have the possibility to get my app elsewhere. If I believe F-Droid sucks, I should be able to get the apk from maybe another distributor or on the webpage of the author. If I believe, even this apk is compromised, I should have the possibility of compiling it myself.
The attitude of someone who pursues the open policy of providing his software to other people using different channels raises in my opinion the credibility of that person and the project.

If people however need to trust one single instance, it gives this instance great power about them. And we all know: With great power comes great responsibility.
Unfortunately there were often times in the past, were great power was misused at some point sooner or later.

And in the end, security remains entirely with the user. If he does not care or understand what it means (or what kind of security he desires), not your and not my concept will completely help him.

By the way:
a) The "demographic that does not know what a checksum or signature is" will probably use Google Play either way.
b) The users who do not want to create a Google account will probably still not create one just to use your app.
c) It is very likely that someone will start a fork or create a new app instead. So your concern about the security of the users of your app may be honorable, but you will not really help them by restricting your software that way.

P.S.: I installed Cyanogenmod on my device and cannot find any GSF. If I am missing it I would be interested in how my device may still phone home to Google.

zak333 commented Oct 16, 2013

Hello moxie,

thank you for your discussion about this issue. There are many other developers out there, who close such issues very fast, avoiding the opinions and preferences of other users.

I recognize you think the "security model for desktops (unix-based and windows-based) is completely broken" and "believe that fdroid is harmful, and [you] don't want to endorse harmful activity."

As I understand it, your sense of security lies in the use of Google Play in combination with the deactivation of the ability to install 3rd party applications. The ability to create, sign and upload your app to the Playstore yourself gives you alone the full control of it. Nobody else should be able to provide any other (probably compromised) version of your app.

Although I can understand the positive implications of this, I nevertheless strongly want to disagree with this perspective. First: It's condition is to trust two involved parties.

  1. Google
    I do not know, what Google really does. Its main purpose of existence is the processing of data, our data. It can keep track of our phones, our contacts, our communication, our preferences, what apps we use when and how often and who knows what else. I do not allege Google to use this data against us (yet?) (maybe undeliberately?), but I simply do not want to create any account with Google just to be able to install some few apps I would like to use. And as you can see, there are many other users who think alike.
    I do not know if Google modifies your created package in some way, too. It may be unlikely, but I cannot be absolute sure they don't either. Who programmed the key-verification routines and how do they really work with all those Google Apps?
    In the end, if I would want to install something from Google Play, I will have to give Google my trust.
  2. (Please don't take this personally) You
    I do not believe you have any bad interests when providing us your software. (And I am of course grateful you provide it at all!) But the fact is, the way I see it now, you are the only one involved in creating this package, and I therefore need to trust you alone with it. It could be very easy for you to patch every version just before you compile it and add a few lines. No one would ever know. Maybe in a year or so, someone sends you a generous check, if you would be so nice to add some specific code. Maybe someone hacks your server/workstation and uploads a new version under your name. Again: I don't think this will happen and you are probably trustworthy, but in the end, the trust in you alone is mandatory.

Now, it is of course essential, that security is not possible without the trust to anybody. So second: The problem with your concept is, that we - the users - do not have the choice who we trust. If we want to install the app, we are forced to trust you with packaging and to trust Google with providing it.
(I leave the option to compile the source ourselves, because that is not the issue here. I believe the issue is to provide users an easy and secure concept of installing and using applications.)

If however, other people in an open community become involved in the distribution of applications and this distribution is transparent and replicable, the possibility of compromised software gets lower.

Why is that so?
a) The chances, that several people at once have malevolent intentions is lower. If only one person is involved, he/she can do whatever he/she wants without anybody else noticing.
b) If someone does something wrong (either intentionally or accidentally), there is a good chance that someone else recognizes this.
c) In case of a bigger project like F-Droid (or take Debian for example to mention one of your "faulty desktop security models"), the impact of something bad would fall back on the whole project. It is unlikely that people will risk losing their trust by risking something bad with a few apps/programs.

And finally, I cannot emphasize enough the most important thing I believe security should have: The freedom of choice! If I think Google is untrustworthy, I should have the possibility to get my app elsewhere. If I believe F-Droid sucks, I should be able to get the apk from maybe another distributor or on the webpage of the author. If I believe, even this apk is compromised, I should have the possibility of compiling it myself.
The attitude of someone who pursues the open policy of providing his software to other people using different channels raises in my opinion the credibility of that person and the project.

If people however need to trust one single instance, it gives this instance great power about them. And we all know: With great power comes great responsibility.
Unfortunately there were often times in the past, were great power was misused at some point sooner or later.

And in the end, security remains entirely with the user. If he does not care or understand what it means (or what kind of security he desires), not your and not my concept will completely help him.

By the way:
a) The "demographic that does not know what a checksum or signature is" will probably use Google Play either way.
b) The users who do not want to create a Google account will probably still not create one just to use your app.
c) It is very likely that someone will start a fork or create a new app instead. So your concern about the security of the users of your app may be honorable, but you will not really help them by restricting your software that way.

P.S.: I installed Cyanogenmod on my device and cannot find any GSF. If I am missing it I would be interested in how my device may still phone home to Google.

@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Oct 16, 2013

Member

@zak333:

I do not know if Google modifies your created package in some way, too. It may be unlikely, but I cannot be absolute sure they don't either. Who programmed the key-verification routines and how do they really work with all those Google Apps?

You can be absolutely sure. PackageManagerService is OSS, so you (or anyone) can audit the code.

(Please don't take this personally) You
I do not believe you have any bad interests when providing us your software. (And I am of course grateful you provide it at all!) But the fact is, the way I see it now, you are the only one involved in creating this package, and I therefore need to trust you alone with it. It could be very easy for you to patch every version just before you compile it and add a few lines. No one would ever know. Maybe in a year or so, someone sends you a generous check, if you would be so nice to add some specific code. Maybe someone hacks your server/workstation and uploads a new version under your name. Again: I don't think this will happen and you are probably trustworthy, but in the end, the trust in you alone is mandatory.

If you don't trust the packager, I think your only option is to build it yourself. Fortunately, we've gone to great lengths to ensure that this can be done by typing a single command: gradle build

If you're concerned about trusting me to package the source, I'm not sure why you would be less concerned about someone random at F-Droid packaging the source. At least my signing keys aren't online!

And finally, I cannot emphasize enough the most important thing I believe security should have: The freedom of choice! If I think Google is untrustworthy, I should have the possibility to get my app elsewhere.

You don't have to convince me. I would love to distribute an APK outside of Play. Above, I've outlined the four missing pieces we need in order to do that. If this is something that you are interested in seeing happen, all it takes is helping us get those done.

Member

moxie0 commented Oct 16, 2013

@zak333:

I do not know if Google modifies your created package in some way, too. It may be unlikely, but I cannot be absolute sure they don't either. Who programmed the key-verification routines and how do they really work with all those Google Apps?

You can be absolutely sure. PackageManagerService is OSS, so you (or anyone) can audit the code.

(Please don't take this personally) You
I do not believe you have any bad interests when providing us your software. (And I am of course grateful you provide it at all!) But the fact is, the way I see it now, you are the only one involved in creating this package, and I therefore need to trust you alone with it. It could be very easy for you to patch every version just before you compile it and add a few lines. No one would ever know. Maybe in a year or so, someone sends you a generous check, if you would be so nice to add some specific code. Maybe someone hacks your server/workstation and uploads a new version under your name. Again: I don't think this will happen and you are probably trustworthy, but in the end, the trust in you alone is mandatory.

If you don't trust the packager, I think your only option is to build it yourself. Fortunately, we've gone to great lengths to ensure that this can be done by typing a single command: gradle build

If you're concerned about trusting me to package the source, I'm not sure why you would be less concerned about someone random at F-Droid packaging the source. At least my signing keys aren't online!

And finally, I cannot emphasize enough the most important thing I believe security should have: The freedom of choice! If I think Google is untrustworthy, I should have the possibility to get my app elsewhere.

You don't have to convince me. I would love to distribute an APK outside of Play. Above, I've outlined the four missing pieces we need in order to do that. If this is something that you are interested in seeing happen, all it takes is helping us get those done.

@mvdan

This comment has been minimized.

Show comment
Hide comment
@mvdan

mvdan Oct 16, 2013

If you're concerned about trusting me to package the source, I'm not sure why you would be less concerned about someone random at F-Droid packaging the source. At least my signing keys aren't online!

Just two quick comments:

  • You can be less concerned because the whole build process is public, verbose and reproducible by anyone.
  • Our keys are not online. Where did you get that?

mvdan commented Oct 16, 2013

If you're concerned about trusting me to package the source, I'm not sure why you would be less concerned about someone random at F-Droid packaging the source. At least my signing keys aren't online!

Just two quick comments:

  • You can be less concerned because the whole build process is public, verbose and reproducible by anyone.
  • Our keys are not online. Where did you get that?
@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Oct 16, 2013

Member

You can be less concerned because the whole build process is public, verbose and reproducible by anyone.

As it is for me. If that's not good enough somehow, I don't see how someone else building it is any different.

Our keys are not online. Where did you get that?

So every time any one of your packages needs to be updated, someone hand carries the source to an airgapped machine, plugs in the HSM with the key specific to that app, runs the build, and carries the signed APK back over to the networked machine? How do you scale that process across all of the apps you distribute? How do you physically store all of your HSMs?

Member

moxie0 commented Oct 16, 2013

You can be less concerned because the whole build process is public, verbose and reproducible by anyone.

As it is for me. If that's not good enough somehow, I don't see how someone else building it is any different.

Our keys are not online. Where did you get that?

So every time any one of your packages needs to be updated, someone hand carries the source to an airgapped machine, plugs in the HSM with the key specific to that app, runs the build, and carries the signed APK back over to the networked machine? How do you scale that process across all of the apps you distribute? How do you physically store all of your HSMs?

@mvdan

This comment has been minimized.

Show comment
Hide comment
@mvdan

mvdan Oct 16, 2013

As it is for me. If that's not good enough somehow, I don't see how someone else building it is any different.

I'm not saying that our method is any better than yours or anyone else's. I'm just saying that argueing that it is less secure doesn't make sense either (edit: as far as I know or have been told)

So every time any one of your packages needs to be updated, someone hand carries the source to an airgapped machine, plugs in the HSM with the key specific to that app, runs the build, and carries the signed APK back over to the networked machine? How do you scale that process across all of the apps you distribute? How do you physically store all of your HSMs?

The process is similar to what you say. There is the web server holding the site and the repo over http and https, and there's a machine without any kind of remote access that holds the keys and runs the builds. All of this is to be done separately for each repo, in fact a single fdroiddata dir can only handle a single repo. Repos should never share their keys with any other repo, at least we won't do that with the main repo.

How do we physically store the sensible data? I don't have access to said machine (only one person does), so I'm guessing it is stored in a secure place in an encrypted file system. But that's only a guess following what I would do.

Just to clarify, the building machine uses ssh to provide the hosting machine with the apks, the icons, the index, etc. This is all public if you check the fdroidserver python source.

mvdan commented Oct 16, 2013

As it is for me. If that's not good enough somehow, I don't see how someone else building it is any different.

I'm not saying that our method is any better than yours or anyone else's. I'm just saying that argueing that it is less secure doesn't make sense either (edit: as far as I know or have been told)

So every time any one of your packages needs to be updated, someone hand carries the source to an airgapped machine, plugs in the HSM with the key specific to that app, runs the build, and carries the signed APK back over to the networked machine? How do you scale that process across all of the apps you distribute? How do you physically store all of your HSMs?

The process is similar to what you say. There is the web server holding the site and the repo over http and https, and there's a machine without any kind of remote access that holds the keys and runs the builds. All of this is to be done separately for each repo, in fact a single fdroiddata dir can only handle a single repo. Repos should never share their keys with any other repo, at least we won't do that with the main repo.

How do we physically store the sensible data? I don't have access to said machine (only one person does), so I'm guessing it is stored in a secure place in an encrypted file system. But that's only a guess following what I would do.

Just to clarify, the building machine uses ssh to provide the hosting machine with the apks, the icons, the index, etc. This is all public if you check the fdroidserver python source.

@dalb8

This comment has been minimized.

Show comment
Hide comment
@dalb8

dalb8 Oct 16, 2013

My understanding is that the keys are offline only in the sense that the machine doesn't accept incoming internet traffic. The encrypted keys are stored on the same machine as the builds which are done in a VM.

Theoretically, it allows for bit-for-bit reproducible builds, which would allow anybody to verify that an apk was built as described, negating the need for HSMs and such.

dalb8 commented Oct 16, 2013

My understanding is that the keys are offline only in the sense that the machine doesn't accept incoming internet traffic. The encrypted keys are stored on the same machine as the builds which are done in a VM.

Theoretically, it allows for bit-for-bit reproducible builds, which would allow anybody to verify that an apk was built as described, negating the need for HSMs and such.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Aug 24, 2014

Contributor

@countrygeek Do you have a Linux box? Then you could build it by yourself (it's not too complicated). Pls. contact me by mail if you need help (your github account has no e-mail address connected for direct feedback).

Contributor

Wikinaut commented Aug 24, 2014

@countrygeek Do you have a Linux box? Then you could build it by yourself (it's not too complicated). Pls. contact me by mail if you need help (your github account has no e-mail address connected for direct feedback).

@agrajaghh

This comment has been minimized.

Show comment
Hide comment
@agrajaghh

agrajaghh Aug 24, 2014

Contributor

@countrygeek Without gapps you can't use push messages, you'll be only able to send encrypted and unencrypted SMS

Contributor

agrajaghh commented Aug 24, 2014

@countrygeek Without gapps you can't use push messages, you'll be only able to send encrypted and unencrypted SMS

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Aug 24, 2014

Contributor

@agrajaghh @countrygeek You can use TextSecure without having an Google Play account. For some reasons, I can use my self-built version on all my phones and tablets without any problem.

My devices however have Google Play Store installed, but as said, without an associated account ‒ the devices are not running CyanogenMod.

Contributor

Wikinaut commented Aug 24, 2014

@agrajaghh @countrygeek You can use TextSecure without having an Google Play account. For some reasons, I can use my self-built version on all my phones and tablets without any problem.

My devices however have Google Play Store installed, but as said, without an associated account ‒ the devices are not running CyanogenMod.

@agrajaghh

This comment has been minimized.

Show comment
Hide comment
@agrajaghh

agrajaghh Aug 24, 2014

Contributor

I think you don't need an google play account, but you need the google play services to be installed for push messages...

Contributor

agrajaghh commented Aug 24, 2014

I think you don't need an google play account, but you need the google play services to be installed for push messages...

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Aug 24, 2014

Contributor

@agrajaghh wrote

I think you don't need an google play account, but you need the google play services to be installed for push messages...

@countrygeek : yes

Contributor

Wikinaut commented Aug 24, 2014

@agrajaghh wrote

I think you don't need an google play account, but you need the google play services to be installed for push messages...

@countrygeek : yes

@generalmanager

This comment has been minimized.

Show comment
Hide comment
@generalmanager

generalmanager Aug 24, 2014

Currently TS doesn't work without gapps because it uses GCM as a push network. Take a look at #1000 to monitor the progress on websockets.

On 24. August 2014 15:47:06 MESZ, countrygeek notifications@github.com wrote:

Would anyone mind posting the latest version of TextSecure? I'm
currently running cynanogen without gapps and didn't feel like
installing them to upgrade. Thanks!


Reply to this email directly or view it on GitHub:
#127 (comment)

generalmanager commented Aug 24, 2014

Currently TS doesn't work without gapps because it uses GCM as a push network. Take a look at #1000 to monitor the progress on websockets.

On 24. August 2014 15:47:06 MESZ, countrygeek notifications@github.com wrote:

Would anyone mind posting the latest version of TextSecure? I'm
currently running cynanogen without gapps and didn't feel like
installing them to upgrade. Thanks!


Reply to this email directly or view it on GitHub:
#127 (comment)

@patcon

This comment has been minimized.

Show comment
Hide comment
@patcon

patcon Aug 24, 2014

Thanks for the pointer on that thread @generalmanager :)

@countrygeek While it's not particularly helpful here, I find this helpful for getting apk's for essentials not yet on F-Droid. (You can install with adb install /path/to/app.apk if you have USB debugging set up.)

http://apps.evozi.com/apk-downloader/

patcon commented Aug 24, 2014

Thanks for the pointer on that thread @generalmanager :)

@countrygeek While it's not particularly helpful here, I find this helpful for getting apk's for essentials not yet on F-Droid. (You can install with adb install /path/to/app.apk if you have USB debugging set up.)

http://apps.evozi.com/apk-downloader/

@countrygeek

This comment has been minimized.

Show comment
Hide comment
@countrygeek

countrygeek Aug 24, 2014

@patcon : Thanks, I actually had tried using that but the site was down - appears up again now. It's definately the easiest way, vs. trying to get the ADT bundle up and running just to run TextSecure without Gapps. I have an unlimited data plan so I don't care about SMS charges. :)

countrygeek commented Aug 24, 2014

@patcon : Thanks, I actually had tried using that but the site was down - appears up again now. It's definately the easiest way, vs. trying to get the ADT bundle up and running just to run TextSecure without Gapps. I have an unlimited data plan so I don't care about SMS charges. :)

@Zeriuno

This comment has been minimized.

Show comment
Hide comment
@Zeriuno

Zeriuno Aug 25, 2014

I find it worrying that, to escape Google surveillance and profiling,
some are ready to install an apk downloaded from a service that don't
really offer security garantuees and that could compromise your device.

I think it really calls for a priority revision.

Find a way to do a checksum at least!

Zeriuno commented Aug 25, 2014

I find it worrying that, to escape Google surveillance and profiling,
some are ready to install an apk downloaded from a service that don't
really offer security garantuees and that could compromise your device.

I think it really calls for a priority revision.

Find a way to do a checksum at least!

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Aug 25, 2014

Contributor

@Zeriuno this could be done by @moxie on the release page https://github.com/WhisperSystems/TextSecure/releases see this → example https://github.com/schildbach/bitcoin-wallet/releases

Moxie could simply additionally publish ‒ parallel to the publication in Google Play Store ‒ the release apks and their corresponding signature files in the TextSecure https://github.com/WhisperSystems/TextSecure/releases page. Currently, there is only the source code. But there's no room for discussion, because AFAIK, he wants a secure channel for automatic updates, and only Google Play Store can do.

Contributor

Wikinaut commented Aug 25, 2014

@Zeriuno this could be done by @moxie on the release page https://github.com/WhisperSystems/TextSecure/releases see this → example https://github.com/schildbach/bitcoin-wallet/releases

Moxie could simply additionally publish ‒ parallel to the publication in Google Play Store ‒ the release apks and their corresponding signature files in the TextSecure https://github.com/WhisperSystems/TextSecure/releases page. Currently, there is only the source code. But there's no room for discussion, because AFAIK, he wants a secure channel for automatic updates, and only Google Play Store can do.

@Wikinaut

This comment has been minimized.

Show comment
Hide comment
@Wikinaut

Wikinaut Aug 25, 2014

Contributor

@Zeriuno I published checksums for versions < 2.0.8 on my TextSecure Wiki page https://github.com/Wikinaut/TextSecure/wiki/History-of-changes

This not-so-well-known gpg command/option lists all avaliable message digests:
gpg --print-md "*" org.thoughtcrime.securesms.apk

Contributor

Wikinaut commented Aug 25, 2014

@Zeriuno I published checksums for versions < 2.0.8 on my TextSecure Wiki page https://github.com/Wikinaut/TextSecure/wiki/History-of-changes

This not-so-well-known gpg command/option lists all avaliable message digests:
gpg --print-md "*" org.thoughtcrime.securesms.apk

@Zeriuno

This comment has been minimized.

Show comment
Hide comment
@Zeriuno

Zeriuno commented Aug 26, 2014

@Wikinaut: good!

@CHEF-KOCH

This comment has been minimized.

Show comment
Hide comment
@CHEF-KOCH

CHEF-KOCH Sep 10, 2014

I also vote for an F-Droid repo and a alternative direct link which provide sha1 and gpg. To publish it on the github release page would be also an interesting idea, we generally should as less as possible from google.

CHEF-KOCH commented Sep 10, 2014

I also vote for an F-Droid repo and a alternative direct link which provide sha1 and gpg. To publish it on the github release page would be also an interesting idea, we generally should as less as possible from google.

@cyl-us

This comment has been minimized.

Show comment
Hide comment
@cyl-us

cyl-us Oct 24, 2014

Where there is no transparency, there cannot be any hope of either security or privacy. Seeing a privacy application depend on nonfree software to function is therefor a very sad thing to me, as its dependences undermine its purpose. A system is only as secure/private as its least secure/private component, so anything that has Google Play Services installed is already compromised.

You also mention that a user has to enable third-party application installation to install outside the Google Play Store. While I'm not sure it will sway you, it's worth noting that for us Replicant users, we have to have that box unchecked to install anything outside of F-Droid's repository, meaning that by not offering it on F-Droid, you require us to enable third-party application installation.

cyl-us commented Oct 24, 2014

Where there is no transparency, there cannot be any hope of either security or privacy. Seeing a privacy application depend on nonfree software to function is therefor a very sad thing to me, as its dependences undermine its purpose. A system is only as secure/private as its least secure/private component, so anything that has Google Play Services installed is already compromised.

You also mention that a user has to enable third-party application installation to install outside the Google Play Store. While I'm not sure it will sway you, it's worth noting that for us Replicant users, we have to have that box unchecked to install anything outside of F-Droid's repository, meaning that by not offering it on F-Droid, you require us to enable third-party application installation.

@SecUpwN

This comment has been minimized.

Show comment
Hide comment
@SecUpwN

SecUpwN Nov 2, 2014

@jtrig, maybe it's time to move on to more open alternatives like Tinfoil-SMS?

SecUpwN commented Nov 2, 2014

@jtrig, maybe it's time to move on to more open alternatives like Tinfoil-SMS?

@rdsqc22

This comment has been minimized.

Show comment
Hide comment
@rdsqc22

rdsqc22 Nov 2, 2014

@SecUpwN No, because that's also not on Fdroid. Google Play only, so it's no better.

rdsqc22 commented Nov 2, 2014

@SecUpwN No, because that's also not on Fdroid. Google Play only, so it's no better.

@SecUpwN

This comment has been minimized.

Show comment
Hide comment
@SecUpwN

SecUpwN Nov 2, 2014

@rdsqc22, the developer of that App is extremely open to open source. Feel free to open up an Issue on his GitHub for that, I am sure this App will be available there sooner than you think.

SecUpwN commented Nov 2, 2014

@rdsqc22, the developer of that App is extremely open to open source. Feel free to open up an Issue on his GitHub for that, I am sure this App will be available there sooner than you think.

@rdsqc22

This comment has been minimized.

Show comment
Hide comment
@rdsqc22

rdsqc22 Nov 2, 2014

@SecUpwN It looks like it used to be on Fdroid, but then got removed because the developer started using non-free binary blobs. https://f-droid.org/wiki/page/com.tinfoil.sms

rdsqc22 commented Nov 2, 2014

@SecUpwN It looks like it used to be on Fdroid, but then got removed because the developer started using non-free binary blobs. https://f-droid.org/wiki/page/com.tinfoil.sms

@justjanne

This comment has been minimized.

Show comment
Hide comment
@justjanne

justjanne Jan 9, 2015

Source, what is still limiting progress with this issue?

  • F-Droid allows nonfree apps, but will display a bold warning against them I seem to be mistaken here, but this still holds: (And TextSecure is implementing sockets instead of GCM anyway),
  • F-Droid now allows to distribute a developer-signed version of the app, if the build is reproducable by their build server,
  • F-Droid now allows installation of apps without enabling third-party support

In other words, every single of @moxie0’s complaints has been fixed, so why is this still not happening?

justjanne commented Jan 9, 2015

Source, what is still limiting progress with this issue?

  • F-Droid allows nonfree apps, but will display a bold warning against them I seem to be mistaken here, but this still holds: (And TextSecure is implementing sockets instead of GCM anyway),
  • F-Droid now allows to distribute a developer-signed version of the app, if the build is reproducable by their build server,
  • F-Droid now allows installation of apps without enabling third-party support

In other words, every single of @moxie0’s complaints has been fixed, so why is this still not happening?

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Jan 9, 2015

Contributor

In other words, every single of @moxie0’s complaints has been fixed, so why is this still not happening?

Maybe just because no-one told him yet ;-)

I guess distributing TextSecure on F-Droid while Google Play Services are still required for it to run doesn't make too much sense. You could check out #1000 resp. the fork at https://github.com/JavaJens/TextSecure to help with that.

Contributor

fwalch commented Jan 9, 2015

In other words, every single of @moxie0’s complaints has been fixed, so why is this still not happening?

Maybe just because no-one told him yet ;-)

I guess distributing TextSecure on F-Droid while Google Play Services are still required for it to run doesn't make too much sense. You could check out #1000 resp. the fork at https://github.com/JavaJens/TextSecure to help with that.

@haffenloher

This comment has been minimized.

Show comment
Hide comment
@haffenloher

haffenloher Jan 9, 2015

Contributor

F-Droid now allows to distribute a developer-signed version of the app, if the build is reproducable by their build server

Interesting. Could you point me to some information / docs on how this is supposed to work?

In other words, every single of moxie0’s complaints has been fixed

I don't think there is a solution for automated crash reporting without Google Play yet.

Contributor

haffenloher commented Jan 9, 2015

F-Droid now allows to distribute a developer-signed version of the app, if the build is reproducable by their build server

Interesting. Could you point me to some information / docs on how this is supposed to work?

In other words, every single of moxie0’s complaints has been fixed

I don't think there is a solution for automated crash reporting without Google Play yet.

@fwalch

This comment has been minimized.

Show comment
Hide comment
@fwalch

fwalch Jan 9, 2015

Contributor

@brumsoel See https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds. For background on reproducible builds in general, see e.g. this talk at the 31C3 (slides on this page).

Contributor

fwalch commented Jan 9, 2015

@brumsoel See https://f-droid.org/wiki/page/Deterministic,_Reproducible_Builds. For background on reproducible builds in general, see e.g. this talk at the 31C3 (slides on this page).

@eighthave

This comment has been minimized.

Show comment
Hide comment
@eighthave

eighthave Jan 9, 2015

Contributor

The reproducible build stuff is quite new and still a bit raw, but it does work. I'm happy to help get TextSecure integrated using this process for anyone who wants to take it on.

As for automated crash reporting without Google Play, you can use ACRA then choose which backend you want it to upload to.

Contributor

eighthave commented Jan 9, 2015

The reproducible build stuff is quite new and still a bit raw, but it does work. I'm happy to help get TextSecure integrated using this process for anyone who wants to take it on.

As for automated crash reporting without Google Play, you can use ACRA then choose which backend you want it to upload to.

@signalapp signalapp locked and limited conversation to collaborators Jan 9, 2015

Stanzi97 referenced this issue Feb 20, 2017

Support for using Signal without Play Services
This is now possible with beta calling, so non-GCM users are a
part of beta calling by default.

// FREEBIE
@moxie0

This comment has been minimized.

Show comment
Hide comment
@moxie0

moxie0 Mar 13, 2017

Member

This is now available here: https://signal.org/android/apk/

I don't recommend that people do this, but we've set this up as a harm reduction strategy since people are already running random APKs signed by other random people instead.

Member

moxie0 commented Mar 13, 2017

This is now available here: https://signal.org/android/apk/

I don't recommend that people do this, but we've set this up as a harm reduction strategy since people are already running random APKs signed by other random people instead.

@moxie0 moxie0 closed this Mar 13, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.