There are two main approaches to keeping apps updated: an "app store" model and a "self-update" model. The "app store" model is generally the approach taken by package management systems that are integrated into the core OS, so for example the Debian package management system, Apple App Store, Google Play, etc. Many apps instead include a way that they can update themselves, for example Firefox, Chrome, etc. The self-update model puts more control in the hands of the app's developer, while the app store model puts more control in the hands of the user.
With the app store model, it is much easier for the user to decide when and what to update since all updates are presented in a single UI. This UI is also the same UI that users use for getting new apps and removing installed apps.
Users operating in high risk areas generally have more awareness of what their current risks are than the developers of the software in question, for example which networks are safer and which are more heavily monitored, or which networks can be traced to the user versus ones which are more anonymous.
For example, if a user wants to ensure that all app downloads and updates go through Tor, with F-Droid, they can just set the proxy in the F-Droid settings, root access is not required.
The app store model also lends itself to much more flexibility of which transports to use because there is a central place to manage connectivity.The way that the current f-droid.org app repository is structured has a major weakness: all apps there are signed by a specific f-droid.org key rather than the developer's official release key. This means that there are two valid APKs for each released version of an app, but they have conflicting keys. This is not a design feature of f-droid.org, but rather a side effect of the goal of verifying that the apps are built entirely from freely available source code. The f-droid.org team is working on turning this weakness into a major strength: with fdroid verify, the f-droid.org build infrastructure will build APKs from source as it always has done, but instead of signing the APK with an f-droid.org key, it will instead verify that the developer's APK matches exactly the APK built by f-droid.org. And since it matches, the developer's original signature can be freely swapped into the APK built by f-droid.org. This turns f-droid.org into a build verification service, reproducing builds made by the original developer while eliminating the duplicate f-droid.org key.
- Deteriminstic builds sound like some pedantic technical process that only the most low level hackers would love. And indeed, getting software to builds exactly the same each time is such a process. But once that process is in place, it can drastically simplify the process of delivering secure software. Projects like Tor and Guardian Project go to great lengths to build releases on machines that have never touched the network, are stripped down to the bare minimum, and are generally difficult to use. If the build process was deterministic, then a release build can be made on any machine, and then verified by various other machines also building that same release.
The FDroid central build server is already set up to be build verification service, so if it is easy for developers to integrate their releases with the FDroid tools, then the FDroid central build server will act as a automatic build verification service. That central build server is all free software, so anyone can set up their own build verification service.
- full stack deterministic build process
- deterministic builds for relevant Debian packages
- contributes to TAILS
The final piece of the puzzle of free, open source software providing open and auditable software is the process of verifying that given source code produces a given app, every time. This is generally known as "Reproducible Builds" or "Deterministic Builds". When anyone build an app themselves and then see it is exactly the same app as the developer has released, they know that all they only need to look at the source code to prove that the app is safe and secure. This is unfortunately a difficult and very manual process.
Luckily, it is a process that is very ripe for automation. For Android apps, the first step is to verify that the Java code generates the same APK as the official release. The problem is that everyone builds their Android apps using the software that builds and releases, so they are all using the same binaries which could all contain and implant the same code on every machine. So then the Android tools should be built in a reproducible way, and the system that the Android tools relies on should also be built in a reproducible way. Debian has started work on supporting reproducible builds, and indeed that is a feature that the TAILS and Tor Browser Bundle authors have requested.
This module of work is focused on providing reproducible builds all the way down the toolchain from apps to Debian itself. Debian already has the process prototyped, key pieces of the Android SDK are already included in Debian, and the FDroid tools already provide fdroid verify for comparing a locally built Android app to the developer's release. The remaining work is finishing the prototypes and making sure everything is integrated and working.
Android tools like Lookout, BlueBox Security's scanner, and Google's APK scanner have shown that local scanners can catch lots of malware without requiring network access. For Android, the most serious exploits like Master Key and FakeID, can be detected by scanning the APK alone. There is also free demo code for doing this. This code can be incorporated into FDroid to catch most malware the first time it hits FDroid on a device.
There are also generic techniques for spotting malware based on comparing APKs that claim to be the same version (versionCode) of the same app (packageName). When two devices swap app information, each device can compare the APKs installed to the information received from the other device. If there are two APKs that have the same packageName and versionCode but have different hashes, then one of them is likely to be either corrupt or malware. FDroid can take this information and prompt the user with actions to take, like uploading to a malware scanning service, uninstalling, or temporarily disabling the app until it can be verified.
With the first round of Bazaar, we added a wide range of app swapping capabilities to the FDroid app store. Users can create an app store on their device, then use Wifi, NFC, and/or Bluetooth to swap local app stores with whoever they encounter. The core functionality is mapped out and implemented already. The next step is to survey users and conduct user studies to figure out how the whole swapping experience can be make more understandable with fewer gotchas.
Cydia is a long-running, self sustained alternative app store for rooted iOS devices (an alternative app store is only possible iOS if the device is rooted, unlike Android). It has a very active developer community with about 1000 individual app repos. It does not include any of the common circumvention techniques that we recently added to FDroid like support for Tor and peer-to-peer app swapping.
While the software in each store would only work in the specific platforms, the core concepts are the same. Including work on Cydia would make sense in terms of cross-pollenation of ideas and shared project management resources.
There is a wide range of great software being developed that allow activists, journalists, etc. to use their mobile devices for private, secure communications and operations. And Google Play provides a secure and established way for distributing apps all over the world. But in many high risk areas like China or Iran, Google Play is entirely unavailable. Google Play is also built to track it's users, and that data is all stored by Google, which means that a number of governments have access to that data, via legal orders or by breaking into Google's systems.
People around the world have found all sorts of creative way of distributing apps and files when they cannot access Google Play, but these are fraught with issues: alternative app stores are a awash in malware, most ways of sending apps and files via the internet can be easily spoofed and monitored, and not many people know how to operate when the internet is completely unavailable.
fdroid verify already passes many appsfdroid verifyconfig.py