Bazaar2 Monthly Report - December 2016
There was some solid progress on the existing efforts, as well as some groundwork laid for the final big development sprint of this project funding. We nailed down the v0.102 stable release of the F-Droid client app, which includes a lot of core improvements. This stable release sets us up for a longer alpha cycle for the next round to support the major overhaul of the client app.
We also started the hiring process to find more contributors to take on more subprojects for the final sprint. This and other Guardian Project job descriptions here:
Objective 1 Simple multi-pronged distribution
The F-Droid package index metadata format was redesigned from scratch in order to support lots of essential new functionality: media and other non-app packages, screenshots, store graphics, and full localization of text and graphics. This is currently implemented, and is very alpha functional prototype.
One of the key issues of this whole project is how to build an app store ecosystem that is as difficult as possible to abuse, even for the people operating the app store or attackers who have gained full control of the app store’s binary repository. Reproducible builds allow anyone to reproduce the binaries served by f-droid.org, and binary transparency makes it possible to track the history of all binaries released. In support of this effort, we attended the Reproducible Builds Summit in Berlin, where we worked with most of the major GNU/Linux and BSD distros, the Google Bazel team, as well as a handful of other projects.
The first public instance of an F-Droid Verification Server, https://verification.f-droid.org/, is now up and running. This is wholly separate build infrastructure that automatically rebuilds all apps published to https://f-droid.org and then checks whether they match the official release. If they do not match, then it publishes the differences using https://diffoscope.org.
Good software update systems should release reproducible binaries, then have an unchangeable record of all releases made. This makes it possible to verify that an app that a device is using is the actual file that was by the update system, and is not an impersonator. At the Reproducible Builds Summit, we also we worked with a couple people who are focused on designing binary transparency systems to put together a prototype of a “Binary Transparency Log” for F-Droid. This is implemented as part of the fdroidserver app store kit, and it will eventually be deployed to f-droid.org, once it is proven stable.
Objective 2 Curation Tools for Organizations
No notable progress on this.
Objective 3 Modern App Store with Built-in Circumvention
The overhaul of the f-droid.org website has begun, led by NicoAlt, a long time volunteer contributor, and fxedel, a new contributor. The core of this work is converting almost the whole site to use Jekyll, a static website generator used by GitHub Pages and many other projects. This also generalized the website so that it can be easily reused for other people setting up their own app stores. This work will make it much easier to update the website’s user experience to match the new client app user experience.
There was a major push to get the entire base level of the new UX design implemented at a basically usable level. There is now a very raw but functional alpha of almost the whole new user experience.
We reviewed the user testing results from the field tests, and put together a snapshot document with the primary takeaways from all tests conducted in 2016.
Objective 4 Partner Deployments
As part of the new app/package index metadata format, the code for parsing the index metadata on the client side was modularized. This is the groundwork work for a library to allow apps to directly update themselves from the same index file that is used within the F-Droid client app itself. This expands the F-Droid toolset so that it can be used for both of the two major update approaches: an “package manager” which updates all installed apps; and apps that now how to update themselves. This approach also means that apps can seamless use both approaches without having different server-side setups.
Objective 5 Usability Research on In-country Developers
We started designing a user test based on some of the F-Droid server-side tools in order to test the whole process of figuring out issues that arise in developers’ workflows while finding, learning, and using tools for the app development process. This user test is slated to begin in late January.