(400 words recommended, 1000 word max)
A great number of mobile apps have been developed to assist users in high-risk scenarios, but little has been done to address the issues facing distribution of the apps themselves. Google Play is blocked in many countries, and app stores like iTunes often censor to comply with regional law, whether just or not. Regional app stores are often cesspools of malware. In many countries, people exchange apps through web forums, email, bluetooth, SD Cards, or any other method they can figure out, whether safe or not. Effective techniques for circumventing censorship and internet outages exist, and work in many places, but none work in all, and most organizations are not able to keep track of them all. This current state requires users, trainers, developers, and organizations to be fluent in and aware of many technical details in order to effectively distribute mobile apps and media.
In Cuba, only 5% of the population have internet access, but many have smartphones and computers and share files using DIY networks and thumb drives. In Vietnam, swapping apps and media with Bluetooth is widespread. In Burundi, people get apps via SD cards using "APK installer" apps. Each of these workarounds can also be useful in many other parts of the world. In China, the internet is ubiquitous but heavily filtered and monitored; but "collateral freedom" techniques have proven effective. Beyond the Guardian Project's use of these methods (https://guardianproject.info/fdroid), this matches real world needs expressed by our colleagues. Psiphon already contributed support for Amazon S3 to automate their own process, Benetech needs highly targeted app collections to deploy their Martus system, and these distribution channels must be secret and secure. StoryMaker is pushing for distribution of their app, along with supporting third-party apps, to highly censored contexts. They all need a well-defined and audited process for ensuring that apps and media safely reach users and are kept up-to-date, regardless of the pitfalls and roadblocks along the way.
The past five years have produced big developments in security and privacy on the internet. Tor is ever expanding while getting quite easy to use; HTTPS is the widespread default for sites that manage private information; and apps like ChatSecure, CryptoCat, and TextSecure make secure messaging easy. Even the big players like WhatsApp and WeChat are also improving. The interest in tracking journalists and targeting activists has only grown, and the tools for mass surveillance are getting only cheaper. As the old channels of surveillance get shutdown, new paths for feeding that massive desire is the app developers themselves. More and more software developers are being targeted. If a backdoor can be placed in an app, or even more effective, in a common developer tool, then the attacker who controls that backdoor will gain access to data from the masses despite recent progress.
Basically all of these distribution methods are ripe candidates for the kind of automation that software does so well. We do not have to to convince developers to pay detailed attention to security first, we can entice them to improve their security by providing secure tools that reduce their workload. Google Play and iTunes demonstrate that "app stores" work well for distributing media as well as apps. We have a collection of working prototypes for a wide variety of techniques from the first phase of the Bazaar project, FDroid and Guardian Project have been honing those in the meantime. The next step is encapsulating all of them into a single system that provides smooth interactions for developers, organizations and end users.
This proposed second phase of the Bazaar project, aka Bazaar2, will implement the entire system and user experience for Android, the most popular computing platform in the world. FDroid is the perfect community to build upon to spread into repressive environments because it is made up of activists and hackers who had privacy as a goal from the beginning. Projects and organizations focused on internet freedom can then pool their resources for managing circumvention techniques in this common platform. Additionally, since this model has already proven effective, we will also prototype extending this system to other major mobile platforms like iOS as well as to the desktop.
(800 words recommended, 3000 word max)
In the past few years, there has been a lot of attention to improving the base level of security on the internet, and glaring issues that allow mass surveillance are being fixed. Even Chinese companies like WeChat utilize encrypted network connections and local storage. This means that repressive governments are looking for new channels to exploit. The standard mobile developer work process is a ripe target, but we can nip this in the bud for internet freedom developers by building upon the work of groups like Tor Project, FDroid, Debian, and more.
Targeted attacks are getting easier through the use of software like Finfisher. Key internet freedom tools are proven to provide privacy and security, and more developers and organizations are developing tools for privacy and circumvention. Users of these internet freedom tools are targeted: Occupy Central in Hong Kong was recently targeted) via download links in WhatsApp that delivered tailored malware. It is only a matter of time before there are regular attacks directed at the people creating the tools. Standard software development practices simply cannot survive targeted attacks of today's scope and scale, and the internet freedom community must improve distribution methods to stay ahead of this curve. From the software user's point of view, internet freedom tools and media need to be as easy as possible to distribute, otherwise people will find easier ways, regardless of the risks. We know how to build privacy and security into apps, and there are many good circumvention techniques in use already. It is time for the next big leap in internet freedom tools: a complete distribution ecosystem that provides secure, streamlined tools for developers and organizations, while providing an easy "app store" experience with built-in circumvention.
our users and developers need to stay safe in shark-infested waters
Our focus is mainly on Android, since it is the largest smartphone platform, and in many countries it is more popular than any other computing platform, including Windows. This project will therefore create a complete experience on Android. Since building a thriving media ecosystem requires spreading beyond a single platform, we will also address iOS, desktop and others.
Effective techniques for circumvention of internet filtering and monitoring exist. They include accessing services via proxies, mirroring content on cloud services, and direct peer-to-peer connections (like direct Bluetooth connections and local WiFi links). Device-to-device transfers are especially valuable when internet access is prohibitively expensive (Burma, North Korea, Cuba), or unreliable or disabled by states (Syria, Iran, Zimbabwe, etc). By combining a centralized app store with federated app stores as well as direct peer-to-peer distribution, the Bazaar2 experience will provide an easy to use central system with the flexibility of all three methods. Google Play also provides a secure way to get apps and media on Android, but is not available in many parts of the world (Iran, North Korea, Cuba) and is frequently blocked in many others (China, Syria, Vietnam, Ethiopia, etc). The Bazaar2 system will work in conjunction with Google Play for app distribution, when available.
This idea is already implemented in the FDroid app store for Android. The central f-droid.org app repository allows FDroid to deliver over 1300 apps without any configuration by the user. The `fdroidserver` developer tools allow anyone to set up their own repository of apps, so users can easily add that repository to FDroid. This also provides a channel for users to get apps via “collateral freedom” techniques, using Amazon S3, Akamai, etc. to distribute files where major hosting services like those are unlikely to be blocked. The FDroid app itself can act as an app repository; devices can connect to each other using local WiFi, mesh, Bluetooth, and removable media. The remaining challenge is combining them all into a usable experience. This has been tested, discussed, sketched out, and our first implementation of an integrated user experience is available for testing.
![](centralized.png")
centralized and federated systems
mixed system of centralized, federated, and peer-to-peer
Developers rarely have time to implement strong security, and are a very ripe target for targeted attacks. For example, managing signing keys on a fully offline system is the best practice, but few do this. Even worse, Google provides tools) that encourage developers to keep their signing key on their regular development machine. Using common browser exploits, it would be easy to get the signing key and password in that setup. Hardware security modules (HSMs boost key security and are cheap, but difficult to use. Both offline key management and HSMs are problems that are well automated. The combination of reproducible builds and HSMs means developers can achieve high security processes using standard practices for setting up and running their computers. Specialized setups like offline builds and signing will then only be required for the most extreme risks. Once setup, this process will simple to use, there will be only three commands for regular use:
Developers focus on making sure that their apps are private and secure, but the tools for improving the process, like bug/crash reporters, and beta channels etc. are usually not designed with strong privacy in mind. For example, if an Orbot user posts a standard crash report, information contained in that report can deanonymize the user as well as their Tor traffic. In order to deliver secure software, the entire toolchain must be designed with privacy in mind. Some core parts have already been developed by free software projects, like Redmine for issue tracking and ACRA for crash reporting. There are far too many options, so we will integrate these tools and techniques into a single tool suite. To get buy-in from developers, we will provide a smooth, simple workflow that serves as management tool for software distribution.
There must also be a seamless user experience for organizations that distribute software and media, and one tailored for it's non-technical users. Bazaar2 will provide tools that save time and effort to trainers and trainees who rarely have extra time to figure out new software.
The last key piece is translation. No matter how good software is, if it is not in a language the target audience understands, it will be useless to them. We will build integrated translation management, drawing from our own experience of managing translations in many languages for the software, related text, descriptions, and tutorials.
Systems built upon free association can be poisoned by bad actors when the community is still small. This concern is even greater if the system might be targeted by large state actors, like China, who have the human and technical resources in place to work against the construction of a flourishing ecosystem. Two aspects of this proposal are vulnerable: anyone can start an app store, and apps can be freely swapped between devices without being verified on centralized resources. We have included a couple of approaches to prevent this. First, we will rely on well known methods of building up social software and hire people to work specifically on this issue. Second, we will tap into our existing channels to app developers around the world to get them involved as early as possible.
This project is well positioned since there is already a dedicated, flourishing FDroid community with an excellent security track record, and over 50 million downloads. The FDroid community includes many highly technical people who have a strong interest in privacy and security. Also, there are many active and passionate users who care about spreading Free Software. While our mission is to spread internet freedom, there is so much overlap that FDroid's activist point of view encourages the existing community to support internet freedom activism around the world
FDroid is already the premier hacker app store, popular on Hacker News, referenced by CyanogenMod as a supported option, even long time tech journalist Dan Gillmor uses FDroid. More technical people involved means more people looking out for funny business.
To build out the Bazaar Internet Freedom community on top of FDroid, we will work directly with trusted partners and organizations to lay the core building blocks of the ecosystem. Getting the initial community members in place will be labor intensive, and will require a dedicated community manager as well as developer resources to directly address the needs of the initial organizations. Also, FDroid community is already a willing testbed for circumvention features, and it has not yet gathered attention from known adversaries.
This then highlights the biggest social challenge: getting buy-in from users and developers. App store users often stick with what they know, and insecure app stores are often familiar and perhaps easier to use. In Iran, there were basically no good alternatives to Google Play, until Cafe Bazaar. Cafe Bazaar is now rapidly gaining market share because they focused on providing an easy experience for getting apps, including pirated software from outside of Iran. They have also tied into national pride by highlighting apps from Persian developers. China has many alternative app stores that are based on vast collections of pirated software but they are often corrupt and mislabeled. Xiaomi and Baidu are focusing lots of effort in developing their own app stores, and are both required to collaborate with the Chinese government. Their market share and resources could be very difficult to compete with on a grand scale.
Promotion and outreach must be multi-pronged in order for a project to take off. We have been talking with commercial ROM makers and device manufacturers about including FDroid as a default app store. We are working on getting contributions from developers around the world, and that can also serve as fodder for national pride. Google Play automation is now possible, and there are no notable projects providing solid features there, so FDroid will soon be the first tool to automate the whole release process. The more developers that ship popular apps on fdroid, the more users will use it. For example, AdAway was popular in Google Play before Google banned it. The developer said to get it from FDroid, then FDroid saw 2 million downloads in a short period of time. Another successful promotion technique is providing access to banned content, like Free Weibo does. We plan to market FDroid as a store for blocked apps.
Developers rarely have time to learn new tools, so the developer experience must provide compelling features that make the developer more efficient. If there is a clear benefit to using a new tool, developers will invest the time to switch to it. Therefore, this proposal also addresses tasks that Android developers are already doing, like providing alpha and beta channels, managing releases in Google Play, working with translators, and uploading apps to VirusTotal.
The biggest implementation challenge will be putting together an understandable user experience that guides non-technical users through an array of options for getting apps. We will provide a functional distribution experience because we are building upon existing circumvention techniques known to work in the real world and gathering them together into a common user experience. We'll be taking the best practices from the field, smoothing them out and automating them, not creating new techniques.
The promise of Bazaar2 makes taking this on worthwhile. Once the ecosystem is seeded and there are many users who can swap apps, it's nearly impossible to block the flow of these apps and media. When internet-based central services are available, they will be utilized transparently, but it is only needed here for initial seeding and then to check that malware has not infiltrated. Users can always fall back to entirely local, peer-to-peer methods of data transmission (bluetooth, local wifi, etc), or use local, decentralized networks. This changes the dynamic of app distribution: users can still have open distribution channels even during a full internet outage.
The technical approach will combine new development efforts with integration work. Free software projects, including FDroid, ACRA, and gitian, can solve large pieces of the problems presented in this proposal. The largest chunks of development work relate to building unified and intuitive user experiences for the app store, publishing mechanisms, and developer tools. The core of this work, focused on Android, will happen as part of the FDroid project. FDroid is the best developed free software app store for Android, so our improvements will be included in the community-maintained software. The app is already translated into many languages, including Arabic, Chinese, Farsi, Uigher, and Spanish.
There is an alternative to the app store model for updating software: the "self-update" model. The app store model is generally the approach taken by package management systems that are integrated into the core OS, like the Apple App Store, Google Play, etc. The "self-update" model means the apps update themselves, on the desktop like Firefox, Chrome etc. The self-update model gives more control to the app's developer, while the app store model gives more control to the user, letting the user decide when and what to update. Putting the user in charge allows them to adjust the behavior and timing of updates based on their risks and situation while still providing timely and transparent updating.
The current f-droid.org app store has a major weakness: all apps are signed by a specific f-droid.org key rather than by the developer's official release key. This creates confusion because two valid builds of an app could be signed by conflicting keys. This is not by design, but rather a side effect of their core goal: verifying that the apps are built entirely from freely available source code. The Bazaar2 project will turn this weakness into a major strength: the f-droid.org build infrastructure will build APKs from source as before, but it will then verify that the developer's APK is exactly the same as the APK built by f-droid.org. Since a reproducible build will match exactly, the developer's original signature can be copied into the APK built by f-droid.org. f-droid.org becomes a build verification service, reproducing builds made by the original developer while eliminating the duplicate f-droid.org key.
Malware detection is an essential part of any software distribution ecosystem, more so on Android devices since the core software isn't often updated by the manufacturer. Google provides its malware scanning services via Google Play, so places without access to it lack that malware service. A number of the worst Android exploits, like "Master Key", are relatively straightforward to detect with free and available working code. Bazaar2 will include work to integrate this code into the FDroid app store and developer tools providing baseline malware protection everywhere in the world. This protection will work in conjunction with others, like malware scanner apps from Lookout or BlueBox.
A free software tool, ACRA is shaping up to be the preferred way to include crash reporting in apps. ACRA will be integrated into the Bazaar app store and developer tools to provide full featured crash reporting in a privacy-preserving way. FDroid already provides beta channel functionality, so it just needs to be fine-tuned. Since Google Play provides an integrated experience with solid security, it is reasonable to assume that other app stores can achieve this. Alternative app stores exist in many countries,but with terrible security and frequent filtering and/or monitoring. They lack basic security practices: aptoide.com does not have HTTPS by default, and CafeBazaar.ir does not have functional HTTPS available, even to developers uploading their apps.
A developer in Iran has created some apps and wants to distribute them to as wide an audience as possible. He knows that some apps have been blocked from Cafe Bazaar, so he wants to make sure that there are as ways as possible for people to get this apps. He sets up the FDroid tools to manage publishing his apps to Cafe Bazaar, Google Play, f-droid.org, and a couple "collateral freedom" services like github and Amazon S3. He then runs two simple commands to update his app repository and publish it to all of the app stores. He makes his releases using the FDroid reproducible build and harded signing process. Even though other local developers have found Finfisher on their computers, he feels confident that his release process has not been infiltrated.
StoryMaker is making a targeted campaign that delivers everything that a user needs to make a video, including tutorials and guidelines for that specific campaign, and a channel to publish videos to others. They need everything delivered to users' devices with a single download and single install process. It must also automatically stay updated. They use a custom FDroid installer bundle that includes everything needed in a single download link. This same link will also direct users who already have StoryMaker to the campaign without making them download everything again. For new users, FDroid is first installed, and it then downloads a standard StoryMaker release with a trigger for it to get the campaign materials. Since FDroid is now installed, it will automatically get StoryMaker updates while also providing a full app store to users. Users publish their videos from StoryMaker, which also adds them to this campaign's FDroid media channel, so they can easily get the videos that others are making.
A human rights organization produces videos and ebooks of training materials and important information, they also have their own mobile app. In their trainings, they use apps from Tor and Guardian Project. A trainer sets up an app store that includes their app and all their videos and publications, and set it up to automatically include the most recent updates from Tor and Guardian Project. At trainings, students get an FDroid bundle from the local app store on the trainer's phone. The installation process lets them click through to install Orbot and ChatSecure, and FDroid is set up with direct access to download and share all of the videos and ebooks.
(500 words recommended, 2000 word max)
Getting developers to put their apps into this eco-system is a central part of the mission. Therefore, the developer experience must be easier to use than existing ways to make it worth the work of switching to a new workflow. It must also provide unique benefits that are difficult to achieve. Automating the whole build and release workflow will save developers time. Providing a deterministic, verifiable build process will give developers the unique benefit of removing the requirement for hardened build machine for making secure builds.
Organzations like Amnesty and trainers like Tactical Tech need to distribute media and apps from multiple sources to users who face a wide array of challenges to getting unfettered access.
The key to this whole system working is presenting it all to the end user in a familiar and intuitive interface. There are many design patterns that large app stores follow, so they are well tested and familar to many users. Most of this system fits neatly into a standard app store experience, so the app store itself can handle figuring out which network circumvention technique to use. Secure device-to-device sharing requires the user to manually opt-in, so the "swap" interaction is then added in to the standard app store experience at the points where they are intuitive.
It is not possible to develop effective tools without having regular and frequent communications with people who are directly affected by the issues that we aim to address. Therefore, we work in partnership with organizations on the ground. This means that they can bring their direct experience to us, and we can have rapid and regular feedback on the software we develop. For this project, we have three partners covering three different sets of challenges.
There has been very little user research done on developers who are working countries where the internet is heavily monitored and filtered, so the issues that they face are not well known outside of the circles of these developers. A core part of this project is partnering with developers who operate in Iran and Cuba. After we have worked with them to address real distribution issues, we will publish user stories and information based on our experience. Also, we will seek feedback about more general problems that they face. The goal is to produce user stories and information that can be shared with other organizations working on internet freedom.
(500 words recommended, 2000 word max)
Below are the major groups of activities that we are seeking funding for. These represent a range of work from supporting the first phase of the Bazaar project to tackling a large new area with an even larger potential impact. This work must be multi-faceted in order to most effectively develop and deliver real solutions that address core problems that affect many people and organizations work on internet freedom.
The majority of our work will be software development, testing and deployment. The bulk of the work will be done by Guardian Project and FDroid core team members. To encourage community contributions, we will also work in the open and make time to be available to answer any questions. All of the software and tutorial material that we produce is Free Software, and freely usable and modifiable by anyone. We also aim to freely publish all of the written materials that we produce, as long as there are not privacy or security concerns. We push our development discussions to public email lists and IRC chat rooms. All source code, including tutorials, will be published on public, open git hosting services like Guardian Project's github and FDriod's gitlab.
Other work includes user studies, specific development activities, and interfacing with developers, users, trainers, and organizations around the work. We will tap our own network of highly qualified consultants to help us deliver solid and transformative tools. With a project of this size, we also need to broaden our horizons, so we will also seek out new voices to help us shape these core activities.
simple developer experience
regular software releases
ongoing developer support
generate online walkthrough tutorials
support for organizations and trainers plugging into the Bazaar distribution system
(500 words recommended, 2000 word max)
In rough order of portion of total budget:
(300 words recommended, 1000 word max)
In terms of the core software, the FDroid app and tools, it has been developed and maintained by the FDroid community for a couple of years before we based our internet freedom work on it. The community is represented by a small non-for-profit organization that receives direct donations to cover the maintenance of its infrastructure. The FDroid team makes all of the releases and runs the infrastructure, those are not dependent on Guardian Project or its funding. We actively discuss this proposal with the core FDroid team and they are completely support our efforts so far, so our contributions will maintained as part of the whole package.
Additionally, the core mission of this proposal is to get developers to use the FDroid tools as their primary method of making releases of their software. FDroid already receives contributions from many developers, and the more developers that we can get setup using these tools means more contributions from those developers who have vested interest in maintaining the tools they use in their own processes.
- small partnership consulting projects to aid larger orgs to get setup in the FDroid eco-system
(300 words recommended, 1000 word max)
(400 words recommended, 1000 word max)
(200 words recommended, 1000 word max)
(400 words recommended, 1000 word max)
There are a couple of software companies like Apperian and Aptoide that provide a service for creating and running custom app stores. The ones that we have looked did not have solid security. Most are also not free software, so we can not customize them ourselves. Apperian does have the advantage of supporting Android, Blackberry, iOS, and Windows Mobile. Aptoide is also a company, but it's client app is a free software (the FDroid client app started out as a fork of Aptoide's). At this point, Aptoide does not provide even close to the same level of security as FDroid does, and the FDroid developers were specifically interested in user privacy as a goal, while Aptoide is not. Aptoide has recently greatly improved its app store user experience, giving us the possibility to learn from their experience while we are designing ours.
The Tor Project's work on reproducible builds has been very informative to our research on reproducible builds for Android. Also, Debian has a very active effort to provide reproducible builds for all packages. We are already planning how to best collaborate on this work with The Tor Project and Debian. Guardian Project core team member Hans-Christoph Steiner is an official member of the Debian project as a "Debian Developer", and has been participating in the Debian effort.
For the specific issue of secure software updates, The Update Framework (\url{http://theupdateframework.com/)} addresses the need for a secure updating system. It is a research project that has already produced a number of interesting ideas, but it is not directly applicable because: a) it is written in Python, which is difficult or impossible to run on mobile; and b) it is intended to embedded into each app to update itself, which major mobile platforms do not allow.
Cafe Bazaar (\url{http://cafebazaar.ir/?l=en)} is an Iranian company that provides an Android app store focused on the Iranian market. It highlights apps from Persian contributors, but also includes pirated versions of many popular apps and games from outside Iran, like Google Chrome, Twitter, and as of September 24th, 2014, a real version of our ChatSecure app. Apparently, they receive funding from the Iranian government intended to support Iranian businesses that compete against foreign companies, so it seems safe to assume that they must be working with the government.
(400 words recommended, 1000 word max)
(400 words recommended, 1000 word max)
Evaluation and assessment is built into all Guardian Projects and project partnerships. We use both formal and informal methods as well as qualitative and quantitative measures, however exactly how depends on the particular situation. We will monitor data collected through the project to ensure we are on track to meeting proposed targets and to ensure we adapt to changing circumstances or unforeseen developments as the project progresses. A comprehensive list of indicators will be tracked throughout the project. It is extremely important to self-evaluate and assess, but we must always consider the safety of our users and target audience. Metric information can often be deanonymized and can put users at risk, running counter to our mission. We will assemble overarching reports at the midpoint and end of the project. Our evaluation methods will include:
While it is fully possible to implement systems that track users and provide detailed usage information, we avoid tracking our users since that data can be mistakenly leaked, or deliberately stolen. We do use data from distribution channels that require user tracking, like Google Play and Amazon S3, so that can provide a rule of thumb based on situational knowledge (for example, Google Play is blocked in Iran and China). We will set certain development targets and quantitatively measure how much we achieved, for example, how many languages an app has been translated to. For these kinds of things, we will track them and report them quantitatively. For more detailed stories about the progress, qualitative metrics must be the focus in order to avoid publishing too detailed information about specific users.
We do gather information on people and organizations that we have a relationship with, handling it with all due caution. From this, we can also generate some concrete metrics, albeit in a state largely disconnected from individual people. We aim to work in public as much as possible, including when evaluating our progress. Since we are dealing with a lot of high risk users and it is easy to mistakenly leak identity information when providing dataset to the public, we feel we do not have the resources available to publish all of these metrics publicly.
Running hands-on trainings is a very valuable form of informal, qualitative feedback since we can directly experience how people learn and use our software. For example, we ran a very successful "practocalypse" workshop in collaboration with OTI/Commotion and Eyebeam where the Bazaar prototype version of FDroid was used to distribute all the Android apps at that workshop. This experience provided the most valuable feedback confirming our overall design was effective while pointing out the usability issues we still needed to address.
Some key goals to measure:
Some quantitative metrics that we aim to meet over the project time span:
And qualitative metrics: