Most software designed to protect HRD, journalists and whistleblowers is FLOSS. Each binary release is carefully verified by a sophisticated supply chain to spot vulnerabilities and regressions. When a feature is missing, developers living under an oppressive regime have a strong motivation to modify the source code. But they are missing the information to run the supply chain independently. Their sub-standard release may put at risk the very people they are trying to help. F3 is a new Open File Format that combines the source code with all the information that enables developers to produce high quality releases.

The software forge centralization problem F3 addresses, although widely acknowledged, is not funded and only a handful of people worldwide are making concrete work to solve it. It is not just relevant to Internet Freedom, but impacts the entire corpus of Free Software. In this regard F3 covers the same breadth of concerns that the [reproducible](https://www.opentech.fund/results/supported-projects/reproducible-builds/) software project does.

Our society, and especially our communication and information sources, depend on complex technology, which is often and increasingly centralized. The power to control them is in the hands large corporations, that may not have the best interests and needs of the human citizens and users in mind. For underprivileged people living in oppression the need for empowerment is most urgent. Open information access is at the basis of the ability for people to be informed, to reveal injustices and expose censorship. Freedom of expression and other fundamental human rights depend on the control over the technology one uses, and having the ability to participate in its creation. The means for affected people in the region to wield the full range of software development tools is crucial to support activism work. The F3 specification is a critical enabler of that, and part of a larger vision of “Liberating Free Software Development”. Making software be Free is a step toward setting people free.

#### Problem statement

There is **no standard file format to share the content of a [software forge](https://en.wikipedia.org/wiki/Forge_(software)) (e.g. git repository, issues, etc.)**, and only some of them provide an undocumented internal format. It is possible to use the [forgefed](https://forgefed.org) vocabulary to send a message about a particular detail (i.e. an individual commit or an issue) via the [ActivityPub](https://www.w3.org/TR/activitypub/) protocol. But the receiving forge may not know the context in which this information can be interpreted because it cannot conveniently obtain it. As a whole, a software project is a large dataset that is made of numerous interconnected elements stored in a strongly consistent state. **Without a standardized file format, interoperability between forges is very difficult.**

The **[Friendly Forge Format](https://lab.forgefriends.org/friendlyforgeformat) (abbreviated F3) is an [Open File Format](https://en.wikipedia.org/wiki/Open_file_format) for storing the information from a forge** such as issues, pull/merge requests, milestones, release assets, etc. as well as the associated [VCS](https://en.wikipedia.org/wiki/Version_control) (Git, Mercurial, etc.).

**F3 is designed to exchange the state of a software project** between GitHub, [GitLab](https://gitlab.org), [Forgejo](https://forgejo.org), [Gitea](https://gitea.io), etc. for backup, mirroring or federation.

F3 is essential for a forge to provide key requirements:

* **Portability**: the entire state of a software project can be dumped and restored at a later time, on a different development environment.
* **Versatility**: when published and updated as a F3 archive, a software project effectively is [Open Data](https://en.wikipedia.org/wiki/Open_data) on which an unlimited range of applications can rely, even outside of the forge domain
* **Consistency**: it provides a common language to use when talking about the forge related domains
* **Trust**: cryptographic signatures on each F3 dump guard against malicious or unintentional tampering that could compromise the integrity of a software project

And it unlocks the following use cases:

* **Analytics**: data mining the contents of files is more practical than issuing a large number of queries to an API
* **Mirror**: issues and all other aspects of a software project can be conveniently mirrored from a forge to another by publishing a F3 archive in a VCS and acting on the changes
* **Archival**: storing F3 archives in a VCS makes it easier for them to be preserved in long term archives such as [Software Heritage](https://www.softwareheritage.org/)
* **Reporting**: [forgefed](https://forgefed.org) messages can be created from F3 and sent via the [ActivityPub](https://www.w3.org/TR/activitypub/) protocol

#### Why is this effort needed in the Internet Freedom space?

The entire software development landscape is overly dominated by just two major players, Github and Gitlab. In particular the position of Github, owned by Microsoft, is problematic when it comes to securing Internet Freedom. Github's role in the success of Free Software is often lauded, and partly warranted. For Microsoft / Github providing free access was just a very successful strategy to gain market share and establish network effects. Their centralized platform lies at the heart of a huge ecosystem of software tool vendors that optimized their products to integrate with Github services.

Nowadays literally thousands of projects and millions of software developers are subjected to a strong form of de-facto vendor lock-in. Often without even realizing it. For the Free Software movement this is a threat, as Microsoft does not have their best interest at heart. They follow commercial incentives, and are bound by US regulation. By extension here we find substantial threats to Internet Freedom.

There are numerous examples on how these threats materialize in practice.

* **Geopolitical affiliation**: Github as US-based corporation must comply to [foreign policy and Trade Control](https://docs.github.com/en/site-policy/other-site-policies/github-and-trade-controls) and block people and projects from countries that are at odds with USA from accessing their platform. They apply a broad brush to assure they are in compliance, as this [Tweet by Sebastian Slomski](https://twitter.com/sebslomski/status/1344219609923276801) demonstrates. Once blocked it is very hard to find recourse or reparation.
* **Corporate, governmental and military influences**: As a for-profit US enterprise Microsoft / Github intends to maximize revenue and profits. Their most lucrative contracts are with partners that are not known to be favorable to the same Internet Freedoms we, as humanity, crave. How controversial these often secretive and shady deals are is detailed in this [Article by The Atlantic](https://www.theatlantic.com/technology/archive/2020/01/ice-contract-github-sparks-developer-protests/604339/).
* **Surveillance capitalism**: Like all Big Tech companies Microsoft / Github is a significant player in the widespread harvesting and trade of people's personal data. Interactions of Internet Freedom activists on the platform are no exception to that, and may provide a wealth of information. Not only do US intelligence agencies likely have backdoors to the platform, but once information enters the Wild West information markets it can end up anywhere. Like in the hands of oppressive regimes.
* **Artificial intelligence**: The rise of AI has brought data collection to new heights. Github recently launched CoPilot to help with coding, and in the process ingested all Free Software projects on their platform. Under "fair use" regulation you may find your code being regurgitated in proprietary projects. AI systems are also monitoring Terms of Service breaches, making many mistakes in the process. Policy is to err on the side of caution. Microsoft is involved in the the ongoing AI arms race and works on numerous different AI projects. There's no telling how they'll affect our Internet Freedom in the long run. Not having our data available, especially for oppressed people and activists is not more than prudent.
* **Market dominance**: Microsoft continues to increase and fortify their dominant position. Known for their Embrace, Extend and Extinguish (EEE) strategies they will not hesitate to bend open ecosystems to their will, thwart open standards, and increasingly monetize the services for those who are captive to their platform.

Many vendor lock-in aspects are directly detrimental to the conditions needed to assure Internet Freedom:

* Unilateral changes to development features, such as [deprecating API functionality](https://github.blog/changelog/2022-08-18-deprecation-notice-graphql-for-packages/), occur at rapid pace and are hard to adapt to by open projects that have only limited resources at their disposal.
* Proprietary nature of large parts of the product portfolio as well as the services offered by 3rd-party vendors hamper [reproducible builds](https://reproducible-builds.org/). For instance the continuous integration / continuous deployment Security First [umbrella](https://github.com/securityfirst) tools [rely on CircleCI](https://github.com/securityfirst/Umbrella_android/blob/master/.circleci/config.yml). And the anti-censorship project [nthLink](https://www.nthlink.com/) depends on [Github Actions](https://github.com/nthlink/leaf/actions/runs/2573061858).
* Github does not offer a migration path for software projects to move off their platform. There are no open data formats to export to. For example, having an intricate project, Gitea found it impossible to move off of Github and self-host their own software project. After six years the [migration effort](https://github.com/go-gitea/gitea/issues/1029) is still ongoing. Other forge software, like GitLab, Forgejo and Gitea only provide partial migration from GitHub for specific use cases.

To a much lesser extent the points listed above also apply to Gitlab. Its positioning is already more directed towards enterprises, and they are limiting free services they offer. GitLab is a prime candidate for acquisition by another tech giant in the future, triggering a disruption in many projects now using this code forge.

Stacked against these two giant players we find a small number of Free Software projects, like the aforementioned Forgejo. Projects that have huge potential. But also ones that are deployed as lonely hard to find self-hosted islands. F3 is instrumental for bridging divides. In addition efforts are underway to make individual code forges part of the decentralized Fediverse, and thus glue them together. The F3 open data exchange format is also part of that effort.

#### Beneficiaries and the supply chain replication problem

Human Right Defenders, journalists and whistleblowers who have specific needs to protect the privacy of their communication.

Here is a concrete example to illustrate how F3 would have helped in the recent past, based on my first hand experience while working as a developer with the Freedom of the Press Foundation on the SecureDrop project.

In 2017 I began working on developing SecureDrop, attending weekly meetings and landing patches as a volunteer contributor. I also travelled around Europe to meet activists and journalists which allowed me to better understand their need and adapt SecureDrop accordingly. I focused on internationalization and localization because the human right defenders and journalist I met were often not fluent in English.

Over time I established a working relationship with a journalist who specializes in investigations involving state secrets. Together we built a threat model based on his past publications, current investigations and his usage of technical tools. It confirmed that they were targeted by intelligence services and that all their communications as well as the people surrounding them were monitored.

To improve the protection of their communications with sources, a new SecureDrop hardware was installed for their exclusive usage, as well as a dedicated Qubes OS laptop. everything in the setup was using off-the-shelves components, including a vanilla SecureDrop distribution. The architecture in place was entirely specific to their needs but no software component was modified.

As can be expected when someone uses a software such as SecureDrop on a daily basis, feature requests emerged from our discussions. One of them was to enable daily notifications to be sent, informing the journalist that messages were waiting to be picked up. Doing so in a way that did not leak information was delicate and it took weeks for the algorithm to be designed. The associated tests were carefully crafted to ensure future modifications did not introduce regressions that would weaken this protection. It all happened on GitHub and in public because it was generally useful.

Another feature request was specific to this journalist and unfit for inclusion in the standard SecureDrop. Because of my familiarity with the SecureDrop codebase, I had the technical ability to make a custom development. But I also became conscious that by engaging in this development I would expose the journalist I was trying to protect if the state actor monitoring them became aware of my work. I decided to implement the feature on an airgap machine to make sure it was not monitored. Although I was able to download the content of the git repositories to prepare the environment, I was not able to download the existing issues or pull requests or use the CI of SecureDrop itself or its dependencies. Not only did it make my work significantly more difficult, the release that I produced was also less tested than it should have been and its quality was lower than the one produced using the online GitHub environment.

If F3 had existed at the time, I would have had a convenient way to implement this feature offline with the same quality level than the standard SecureDrop distribution. That would have allowed me to better protect this journalist by having a fully functional copy of the SecureDrop development environment as well as its dependencies to develop this specific feature with the same level of quality that is expected when facing a threat from a state actor.

#### How would this project provide long-term support to users at risk?

##### Durable self contained distribution on read-only media

It is common for people living in authoritarian regimes to procure software using physical media like CDs and flash drives. In such cases, only the source code is available since bug tracker, pull request etc. are not conveniently downloadable. F3 will allow developers in authoritarian regimes to setup self-contained, self-sustainable development shops with the full knowledge and experience of the project’s global community. When combined with Git, F3 not only provides a downloadable format but it also benefits from an efficient synchronization method.

##### Long term preservation of the software supply chain

Here is an hypothetical use case relevant to human right defenders in need of long term support:

- In 2022 https://www.nthlink.com/ is used to setup mobile phones and provided to human right defenders in a country that is under an oppressive regime
- Five years later, in 2027, the mobile phones need to be replaced and the application re-installed, with small modifications because the operating system has changed

With F3, the entire project including the build process that makes nthlink reproducible, has been stored in 2022. It only relies on Free Software that was also stored to make the build process durable. In 2027 they can be re-used to build a new version with small modifications and be re-installed on new phones. The effort is minimal.

Without F3, the build environment provided by GitHub has changed and it is no longer possible to use the now deprecated 2022 build process. The nthlink application as it existed in 2022 can no longer be used: it is not supported for newer phones. Upgrading the application would require training the users with the new interface and functionalities. The mobile phones that broke down cannot be easily replaced, a larger effort is required although the 2022 application is still relevant and useful in this particular context. **The solution designed in 2022 was made obsolete because the software project could not be archived together with its build process using an Open Standard**.

#### How could this project impact the FOSS community?

Long term it would transform the FOSS online development environment from being centralized and proprietary into being a constellation of federated Free Software forges communicating with each other. It has been twenty years since SourceForge was created, with the same centralization problem as GitHub. F3 is a stepping stone for the FOSS community to reclaim ownership of the tools that they use daily to develop software, to no longer be under the influence of two global corporation, Microsoft and GitLab.

Short term it would allow:

- A software project to be exported in the F3 format from GitHub and imported into a self hosted GitLab, Forgejo or Gitea using the same format
- A developer to file a bug report on GitHub using the F3 format without the need to create an account, provide personal data and agree to restrictive terms and conditions
- To mirror issues from GitHub into a self hosted GitLab, Forgejo or Gitea and to receive notifications when they change

#### What differences will this project make for developers on a practical level?

Free Software developers will be able to:

Track issues relevant to their software project across software forges and processes. This is an actual need that was discovered by conducting User Research (see the [2021 user research report](https://lab.forgefriends.org/fedeproxy/ux/-/wikis/2021-06-user-research-report) on this topic).

Migrate and mirror software projects from one software forge to another.

Reduce the complexity of implementing software forge migrations. Instead of maintaining a migration process from

- GitHub to Forgejo,
- GitHub to Gitea,
- GitHub to GitLab,
- GitHub to GitHub
- Forgejo to GitHub,
- Forgejo to GitLab,
- Forgejo to Gitea
- Forgejo to Forgejo
- GitLab to GitHub,
- GitLab to Forgejo,
- GitLab to Gitea
- etc.

With F3 it will only be necessary to maintain a migration process from:

- GitHub to F3
- Forgejo to F3
- Gitea to F3
- GitLab to F3
- F3 to GitHub
- F3 to GitLab
- F3 to Forgejo
- F3 to Gitea