FDroid was built from the ground up to avoid tracking and respect privacy. FDroid has already attracted a lot of attention for being the most private alternative to Google Play, (which gathers a lot of data from the users' devices). For that reason, it is included in Mike Perry's Mission Impossible project, which aims to be the most private Android setup.
Also, FDroid already provides a lot of flexibility for how apps can be distributed. This gives organizations many options that are not available via Google Play, including: distribution channels without the internet; and, very private channels for a small set of high risk users.
h3.How aware are developers of the existing distribution deficiencies? Please provide more information on the deficiencies themselves as well.
Developers are generally aware of major, widespread deficiencies, like when things do not use HTTPS, but overall there is not a lot of scrutiny of the security of developer tools. Tech media also spends much less time on security issues that only affect specific developers since it applies only to a much smaller audience. For those reasons, we will entice developers with secure tools that improve their workflow rather than first trying to convince them that they should be concerned about exploits in their tools.
The most common type of deficiency is developer tools that download and execute code without a decent method for verifying they are unchanged, like Maven and Gradle. Those both also will not warn people if the download happens over plain HTTP, yet with either, a per-project config file can force HTTP. Another common practice is to blindly trust downloaded `.jar` files when adding them to projects.
Here are some examples that are relevant:h3.How will this new system be pitched as a value add to developers?
There are many tasks in the process of managing Android app releases that can recently be automated. These are tasks that no developer enjoys, and act as a barrier to every release. This system will include all these things into a single tool set. Then these tools will be an easy sell as part of Guardian Project's and FDroid's regular outreach to developers because the time savings are easy to demonstrate. Here are tasks that will be covered:
h3.What new feature or characteristic will factor in most prominently to this promotional effort?
In promoting to users, we are planning on two new approaches, on top of our standard outreach methods:
1. market FDroid as "blocked apps repo"
2. get official FDroid distribution of some key apps
We are taking inspiration from Great Fire with their Free Weibo project that catalogs censored messages from Weibo. That got a lot of attention in China, and drove lots of users to their offerings. We will get list of blocked apps from Baidu, Tencent, Xiaomi, etc. and built up an app store of blocked apps for use in China.
To expand the offerings easily available in FDroid, we will work with our contacts at Lookout, Firefox, Twitter, and others to set up official distribution channels for their apps within the FDroid ecosystem. Lookout already provides direct downloads for devices without Google Play. Also, we succesfully lobbied Twitter to add proxy settings in order to support Orbot/Tor, so we think they could be receptive.
h3.What will be F-droid’s involvement in this project? Will they be participating in pushing adoption and/or deployment?
The FDroid team is focused on their core mission of providing the premier Free Software app store for Android. That overlaps a lot with our mission, so that work directly aids this Bazaar2 project. For example, FDroid wants to prove that the app builds only using available source code, which is the same functionality needed for reproducible builds. They will continue to promote FDroid, and independently working to get FDroid included into more custom Android distributions like OmniROM and CyanogenMod. FDroid team members regularly speak at various developer and free software conferences in Europe and Australia.
h3.Are the budget numbers safe approximations or hard numbers?
Since this kind of funding is based on fixed amounts, our budget numbers are the amount needed to guarantee minimum useful functionality. Our track record shows that we usually deliver a lot more than the minimum. That said, reducing the funding of a given chunk would not guarantee failure, but it would increase the chances of ending up with incomplete code.
h3.Why is the scope of Bazaar 2 so much larger than Bazaar 1?
The first phase of Bazaar was an experiment to see how we could open up app distribution. It was limited in scope since it was not clear whether it would be successful. Now that we have that core functionality built and it is being used, this approach has proven both clearly viable and quite valuable. So for this proposal, we instead outlined the complete platform as we imagine it to order to greatly expand the coverage of these solutions.
All vulnerabilities identified in the server-side were fixed in January 2015. The high risk vulnerabilities in the Android client were fixed by early February 2015. As of version 0.89 of the FDroid app, all vulnerabilities from the audit have been addressed.
h3.Do other malware protection tools exist? How effective are they?
There are some good malware scanner apps available in Google Play, like Lookout. Starting with Android 4.2, the operating itself provides some malware scanning. Google also runs regular malware scans on the apps in the Play Store. These are reasonably effective, and we recommend people install Lookout on their devices. The malware scanning in FDroid addresses devices without Google Play (which includes most devices sold in China), as well as the very low end devices that are still being sold with Android 2.3.3.
h3.Could the top apps receive more rigorous security testing than the testing proposed?
Top apps will definitely receive more attention. One key goal of this project is to have the top apps built using a reproducible process, guaranteeing that the versions included in f-droid.org only include what is actually in the source code, and nothing else. This provides a trustworthy distribution chain all the way from the developer's source code to the end user. The most common malware pattern that we see is to take the binary APK file of a popular app, then modify it to add exploits like Master Key, like the various fake Angry Birds.
Work is already underway to get apps from Firefox, Guardian Project, and LEAP building reproducibly. Mobile Firefox (aka Fennec) is also the base for the Tor Browser for Android that we are in the process of finalizing. We are happy to assist any Android developer in making their build process reproducible, and regularly propose to key developers that they adopt a reproducible process.
Providing wholesale malware testing or auditing is beyond the scope of this proposal, since there are existing products like Lookout available without payment and it would be quite expensive for us to build and run such a system.
h3.What other avenues do you expect attackers to take?
As the encryption of network traffic becomes the default, attackers and agencies looking to track, monitor, and exploit devices via the network will have to look to new methods. Commercial malware like Finfisher mostly exploit users when they visit websites using HTTP. But as recent leaks have shown, those companies are working hard to diversify their exploit methods, which includes more emphasis on Android malware.
h3.Why is budget included for translation? Could this be replaced by the OTF Localization Lab?
We are big believers and users of the OTF Localization Lab. We have found that it works very well for many languages, like French, German, and Spanish, but other languages that are more important to this project, like Arabic, Tibetan, Chinese, Persian, and Burmese get very few contributions from volunteers. Therefore, we must hire translators in order to ensure that we get translators for those languages.
h3.Why was the budget reduced by $40,000 after the first round of feedback?
We are finalizing contracts with Benetech to implement features in FDroid as part of their Secure App Generator project. They expanded the scope beyond what we originally thought when writing this proposal, so $40,000 of that work is directly applicable to the work outlined here. Also, the FDroid team has implemented more of the peer-to-peer swap process than we thought they would take on.
At its core, this project is entirely about usability and that is why we believe that OTF is the best funder. We appreciate the push back that we get from OTF, especially from non-technical points of view, because that keeps us focused on what matters most in real world situations while we are mired in the swamps of annoying technical details. Based on feedback, we have reduced the scope of the project to keep the focus on making proven technology usable by the target audiences that most overlap with OTF's and Guardian Project's missions. We eliminated the more experimental aspects, like extending the F-Droid platform to also work on desktop and iOS. We also reduced the focus on the less urgent security issues, like reproducible builds of the tools used to build Android apps. This project serves three audiences, listed by priority:
1. users: people installing, sharing apps, videos, e-books, etc
2. curators: people and organizations wanting to promote a specific set of apps, videos, e-books, etc
3. developers: people and organizations making apps for/in high risk contexts who need to distribute them safely, securely, reliably
This project will make proven techniques usable in the contexts important to internet freedom, specifically in places where there are strong, active forces working to thwart the free flow of information. The tools required to circumvent censorship and prevent tracking are currently not easy to use. Starting with modern mobile user experience design and a core of well proven ideas like Tor support, signed metadata for secure distribution, and app stores that handle media, we will integrate the proven techniques into a system that is as transparent and familiar as possible. Every technology in the project is already functional, whether widely used or a prototype. Certain arcane technical approaches can unlock possibilities for a more usable ecosystem by eliminating certain hard problems from the system. Reproducible builds are in this project to enable key usability improvements for developers, which in turn makes it easier for them to distribute apps in a flexible yet secure way.
h1.Questions and Answers
h3.Why these particular budget reductions?
We have reduced the overall scope and budget of this project in direct response to the feedback that we have received. Here is our rationale behind the reductions:
h3.Is this effort more focused on giving users a means to access censored apps via the play store or to combat malicious app distribution? Is it about safely distributing apps or everything including media?
This project is focused on guaranteeing access in the face of a variety of forms of restriction and tracking, with apps at the center and media as part of the package. An essential part of that problem is combating malware, as we can we see with Google's efforts in their own app store. This proposal includes only essential malware prevention, e.g. things that can be statically detected and blocked. It does not include to develop new anti-malware approaches, since those are available from third parties like Lookout, VirusTotal, etc. Instead it integrates existing source code, and where possible, like with https://virustotal.com and https://andrototal.org.
We included media in the project due to feedback from organizations like Amnesty, Internews, StoryMaker, etc. For example, this would allow a trainer to use a local swap to distribute the apps with the associated training materials in eBook and video form, with no internet required. Combining apps with media is a proven model, as seen with iTunes, Google Play, Amazon, etc. F-Droid already provides reliable infrastructure for moving large blobs of data around, so it will not require much work, and the technical work will have a very low risk of going over budget. Therefore, we believe that including media is an important part of this project.
h3.The proposal did not adequately explore the means and impact of malicious actors blocking access to F-Droid.
We know of no other app that does more to get around blocking than the plan we've laid out here:
FDroid already uses NetCipher to provide solid support for secure networking, as well as integrated support for Tor. It uses Moxie Marlinspike's AndroidPinning library to limit HTTPS certificates to a trusted set of Certificate Authorities. We are currently working with Psiphon, Lantern, and Tor obfuscated transports to get support integrated into NetCipher, which FDroid will then inherit. The FDroid ecosystem is fully decentralized, anyone can provide an app store via any webserver on any network, including most cloud services.
We are happy to answer specific concerns as well.
h3.Will the people most at risk actually use this or will only technically advanced users adopt the platform?
We are confident that this project will give FDroid a comparable user experience to the popular app stores, and we will include apps that are popular in the target markets. So the barriers to entry will be as low as possible. We partner with other organizations in order to reach key networks of users, as well as get usability feedback from them. Trainers will see the biggest improvements since it will provide a reliable app and media distribution method that works without internet on the phone they are already using. We work with many trainers and will continue to address the usability issues they encounter. Trainers are working directly with the people most at risk.
h3.Will malicious apps or implementations of the platform undermine trust within the ecosystem of FDroid and limit the effectiveness/impact of the approach?
The short answer is: yes, and we are doing everything possible to combat that. As with any app store including Xiaomi and Google Play, if it has too much malware in it, then users will stop trusting it. Like Baidu, Cafe Bazaar, and Amazon: users have to install the F-Droid app store themselves. That is inherint issue for all third party app stores. Combating this problem is mostly a question of user behavior: people should only install software from trusted sources. Therefore, we will make it easiest for users to avoid the dangerous behaviors and use trustworth paths to installs. Next, there must be methods to verify what someone has is from the original source, and that there isn't malware. This project also provides multiple methods for verifying the source of files and integrates with malware databases like VirusTotal and AndroTotal.
We chose to base this work off of F-Droid because it is built by a strong community with a good track record for security and privacy. F-Droid provides the strongest security of any Android app store, including Google Play. Including the f-droid.org central app repository is also important to provide a central source of trust information for things distributed via other app stores and/or peer-to-peer via app swapping. We will also make F-Droid use the developer's original APK files whenever possible, verified via a reproducible build process, so that the APKs distributed via F-Droid match exactly the APKs distributed in Google Play. There are already a few apps in F-Droid that are included via this process.
Users can choose additional app stores based on their trust of the organization, so we build upon existing user knowledge of how to verify trusted. For example, we host our FDroid app store on our regular website, so people can easily see that the app store comes from the same organization. So anyone can see that the HTTPS is green in the browser and the URL is the same as what is listed in Google Play before adding our app store to F-Droid on their phone.
Lastly, there is a large, active technical community around F-Droid that takes pride in its trustworthiness. They are already serving to monitor and police the apps that are included. Part of the standard process for including any new app in f-droid.org includes an audit for tracking and non-free software.
For more on this topic, see the "Weaknesses and Challenges" section of the Proposal Narrative.
h3.How exactly will the reproducible builds work?
An app's build process is described in a metadata file, then that build process is then run in a virtual machine (VM) which is setup based on that build metadata. That provides a reproducible setup for the build. After the build is complete, it is compared to the developer's original APK signature. The mechanism is simple: copy the developer's APK signature into the FDroid-built APK and then run standard JAR/APK signature verification process.
It turns out that running reproducible builds has a lot in common with setting up an app for "Continuous Integration" (CI), i.e. automated test builds provided by services like Jenkins, Travis CI, etc. Continuous Integration is already considered a best practice, and it widely used in app development. To set up a build for Continuous Integration, the whole setup and build process is written into a script. That same script can then be used to run a build on multiple machines and/or virtual machines. To support reproducible builds, the tools just compare the output of those repeated builds and provide feedback on what is different between builds.
h3.What confidence should we have that these f-droid systems can resist attack?
Guardian Project is quite confident that the F-Droid systems are very resistant to attack, so much so that we have based our distribution on F-Droid when Google Play is not available. F-Droid has been running for almost 5 years, and there have not been any successful attacks against it's infrastructure. The metadata signing is modeled after Debian, a well proven example security-wise. And F-Droid has been publicly audited. There were no egregious issues found, and all issues found in that audit have been fixed. We plan a full penetration test of the core infrastructure to further prove attack resistance.
h3.What security mechanisms will exist for creating own app repositories?
What exists currently:
h3.Doesn’t app signing already prevent the TLS MITM attack?
Android app signing does not protect against a MITM attack when the app is being installed for the first time. The first time an Android app is installed, there is no check of whether the app signer is trusted, it is entirely "trust on first use". So if an attacker can reliably recognize first installs from the network traffic, then the attacker can automatically insert malware when the requested app is not already installed. Also, Google Play and other app stores will accept commands from the server to install apps, giving a MITM attacker a method of installing custom malware that is always a first install.
Basically all app stores except FDroid require user data when downloading apps, giving a MITM attacker a means of tracking who has which apps installed. That means that the security of installing apps for the first time is entirely reliant on the TLS connection. Google has done a good job with TLS, but even still, there has been vulnerabilities. Other app stores have a much worse track record, including many like Baidu and CafeBazaar that lack even HTTPS/TLS connections.
Additionally, there are a number of well known exploits in the app signing, such as Master Key. These are fixed in the very latest Android releases, but most Android devices are running older releases. For example, the most affordable Android devices being sold now are still running Android 2.3, which was released in 2010 and last patched in 2011.
h3.Is it a good idea to centralize trust into a single authority which keeps signing keys online rather than have them distributed?
This question reads like a rhetorical question since the answer is: of course not. Let me unpack it so I can give a more sensible answer.
We will make it easy for internet freedom developers to use a secure release process without having to devote significant resources. The FDroid eco-system already provides an example of best practices here: fully offline signing, reproducible builds, signed metadata, hardware security modules for signing keys, HTTPS pinning, support for developer's own signature on release APKs, etc. The app repositories at https://f-droid.org and https://guardianproject.info/fdroid both use fully offline signing for APKs and repository metadata. This security model is available in the FDroid tools now, what needs to happen is to make this easy for any organization or app developer to use.
Decentralized APK signing is a big feature for sure, and FDroid supports APKs signed by the developers' keys via the reproducible build process. FDroid's central signing key management is still a valuable service, since it is a fully offline process. Many developers use this service even for apps that are uploaded to Google Play because they do not have the time or skill to setup and manage a fully offline signing process.
h3.Does F-Droid pull code from GitHub and build it?
Yes, F-Droid pulls the source code from a git, mercurial, or subversion repository. All apps included in the f-droid.org repository have been built from a source repository, not a source tarball or other package.
h3.What makes it so hard for an attacker to install their own fake FDroid, via sharing, or spear-phishing, or manufacturer compromise?
The risk of a fake FDroid used for spearphishing are real, as with any software that is installed via direct link. Since manufacturers do not yet include FDroid, all users will have to get it installed. That does then provide an avenue for spearphishing attacks. Since our target audience is already installing app stores, we are not encouraging this as a new behavior. In China, there are many popular app stores that people add. Xiaomi does have a built-in app store, but Xiaomi is still a small minority of devices sold and used in China. In Iran, Cafe Bazaar is a popular app store and it still must also be installed by end users. Amazon and Aptoide are other popular app stores that also must be installed by the users.
Spearphishing attacks rely on human behavior to work, and human behavior is difficult to change with software alone. We are certainly not encouraging users to learn new, risky behaviors, like installing software from random links. Instead, this project aims to replace that widespread practice for the hundreds of millions of Android users who do not have access to Google Play. By moving users to FDroid secure distribution channels, this project makes the safer behaviors easier than the risky behaviors, and thereby greatly reduces the opportunities for spearphishing.
The more users understand a process, the less likely that process can be exploited. This project includes a lot of work to keep the install as simple as possible:
Also, by pushing users to get apps via FDroid "swapping", that works only on nearby connections (Bluetooth, WiFi hotspot, etc), we can steer users away from ever directly downloading APKs at all. As for the attacker sharing directly a fake version, this would be an extremely limited attack requiring lots of chutzpah because of the way that the app swapping is structured. It is only ever something that people do face-to-face, since both "swappers" must opt in, and it uses Bluetooth and the local WiFi network to transmit the data.
For technical users and organizations that setup their own Android devices, FDroid has an update.zip that is flashed onto an Android device using the same mechanism that people add Google Play to ROMs like CyanogenMod. This allows a trusted partner to do bulk device setup with FDroid as a system app, leaving "Unknown Sources" disabled.
Verification is also important, so FDroid provides mechanisms for technical people to verify that they have gotten the original version. For example, all FDroid APKs are also GPG signed: (e.g. https://f-droid.org/FDroid.apk and https://f-droid.org/FDroid.apk.asc). The APK signing key information is also published so the APK signature can be verified, for example, using our utility app Checkey.
If an attacker compromised a manufacturer, then why would that attacker bother with making a fake FDroid? This attacker would have transparent, root access to the device, including FDroid, by inserting their own malware wherever it can be best hidden (e.g. in Android itself). This attacker could also install a compromised version of Google Play.
h3.Does F-Droid verify that the developer’s signature matches their own?
With the reproducible process, FDroid builds an APK from source, then downloads the developer's signed release APK. It copies the signature from the developer's APK into the FDroid-built APK then runs a standard jarsigner verification. So the developer's signature is the only one that is used. We are working towards creating reliable methods for reproducing the exact same file, bit-for-bit (i.e. APKs with the exact same hash). We are able to do this manually, so with time to work on it, it is possible to automate.
h3.Could an attacker compromise the F-Droid build systems?
Any system can be compromised, so we plan accordingly. The current state of the f-droid.org infrastructure is solid:
Verification is also essential for strong security. We are currently almost to alpha for a "verification server" that serves as pre-packaged, automated auditor by running all of the builds that f-droid.org does, then comparing the results to make sure they match. We would love the opportunity for a full penetration test of this infrastructure as part of this proposal.