Skip to content

Changes

Page history
Rename collaboration page. authored by akwizgran's avatar akwizgran
Hide whitespace changes
Inline Side-by-side
Ouisync-Briar-Collaboration.md 0 → 100644
View page @ 5537be1a
[[_TOC_]]
# Introduction
The [Ouisync](https://ouisync.net/) and [Briar](https://briarproject.org/) teams have been collaborating to share knowledge about peer-to-peer (P2P) and device-to-device (D2D) communication techniques, and to explore the possibilities for interoperation and code reuse between the two systems.
# Technical Notes on Ouisync
Ouisync is a P2P file sharing application designed for synchronising files between sets of peers.
A collection of files is known as a repository (repo).
Each peer that's sharing a given repo can have read-write, read-only or blind access.
Blind access means the peer helps to synchronise the repo's encrypted content but can't decrypt the content.
Each peer with read-write access can make changes to its local copy of the repository without needing to be connected to other peers.
These changes are synchronised when the peers next connect.
(In terms of the CAP theorem, Ouisync chooses availability and partition-tolerance.)
Consistency is handled by keeping a version vector for each file.
Changes made by different peers are merged automatically where possible.
If peers make concurrent changes to a file then these are exposed to the users by showing multiple versions of the file.
Users can then merge the changes manually (eg by updating or deleting one of the versions), or may choose to leave the multiple versions intact.
Deleting a file creates a "tombstone" (not visible to users) that marks the place of the deleted file for synchronisation purposes.
To reduce the amount of information about file sizes and directory structures that's exposed to blind peers, files and directories are divided into chunks.
Blind peers synchronise encrypted chunks but can't tell which files the chunks belong to.
Each repo has a secret ID. Sharing the secret repo ID with a peer allows that peer to join the repo as a blind peer.
Connections between peers are secured with keys derived from the secret repo ID.
The [Noise protocol framework](https://noiseprotocol.org/) is used for securing these connections.
Ouisync uses the [BitTorrent DHT](http://www.bittorrent.org/beps/bep_0005.html) for peer discovery.
The secret repo ID is hashed to produce a [BitTorrent info-hash](http://www.bittorrent.org/beps/bep_0003.html).
Each peer can use this info-hash for publishing its own IP address in the DHT and looking up other peers' addresses, without exposing the secret repo ID to DHT nodes.
A separate encryption key, derived from a password, is needed to decrypt the repo's content.
Sharing this password with a peer gives it read-only access to the repo's content.
Read-write access is managed via a data structure in the repo that holds the public keys of authorised writers.
Updates to the repo must be signed with a private key corresponding to one of these public keys.
The version vectors used for merging changes are based on the set of writers identified by this structure.
Initially, the creator of the repo is the only peer with read-write access.
Any peer with read-write access can grant read-write access to another peer by updating the set of writers.
Other apps can use Ouisync as a library.
The API currently allows apps to create and manage repos.
In future, Ouisync's P2P networking functionality may be exposed via the API for the benefit of apps that need to make P2P connections but don't need to use repos.
The DHT functionality could also be separated into its own service, allowing multiple apps on the same device to share access to the DHT efficiently.
# Using Ouisync as a Data Transport for Briar
The Ouisync and Briar teams found that it's already possible to transport Briar messages between contacts via Ouisync.
This is done by using Briar's file export feature, designed for transporting messages via removable drives, to export encrypted messages to a Ouisync repo.
We developed a proof-of-concept of this technique using the production versions of the Ouisync and Briar apps.
No modifications were required to either app.
A video demonstrating the use of Ouisync as a Briar transport layer can be found here:
<https://vimeo.com/839579124>
This idea could be further explored by adding features to Briar to more easily export large amounts of messages, or even to automate the import and export of encrypted files.
The Ouisync and Briar teams discussed the feasibility of using this technique over the long term.
Each time messages were synced between Briar contacts via a Ouisync repo, a short-lived file containing the encrypted messages would be added to the repo and then deleted.
Deleting a file from a Ouisync repo creates a "tombstone" that marks the location of the deleted file.
The teams determined that in order to avoid any potential problems with the accumulation of tombstones in the repo over the long term, the files should be placed in directories that could be deleted periodically.
This would allow all the tombstones in the directory to be replaced by a single tombstone for the directory itself.
Directories could be nested if necessary, with more deeply nested directories being deleted more frequently, allowing arbitrarily slow accumulation of tombstones.
## P2P Connections across National Intranets
One open question related to Ouisync, Briar and other P2P networking tools is how they perform in situations where a national intranet is cut off from the global Internet, and peers inside the intranet want to connect to each other.
If reliable ways to make P2P connections across national intranets are found, they could significantly improve people's ability to communicate during partial Internet shutdowns.
Briar can currently operate over local area networks and the global Internet, but it can't make connections across a national intranet.
The Ouisync team anticipates that when a national intranet is disconnected from the global Internet, any BitTorrent DHT nodes inside the intranet will eventually self-organise to form a functioning DHT among themselves.
If Ouisync peers can bootstrap into this DHT then they can use it for peer discovery just as they would if they were connected to the global Internet, except that any peers they discover will be inside the national intranet.
Thus Ouisync peers inside the intranet should be able to discover and connect to each other.
## Threat Models
Being able to communicate across a national intranet by using Ouisync as a data transport would be a significant enhancement to Briar's functionality.
However, there are potential risks that also need to be considered.
Briar currently uses the Tor network for all long-range communication, in order to protect communication metadata from surveillance.
If Briar were to use Ouisync as a data transport for communicating across a national intranet then some metadata about users' communication would be exposed to network observers, including users' ISPs and BitTorrent DHT nodes.
Whether the potential risks of this metadata exposure outweigh the connectivity benefits is not a question that can be answered in the abstract - it depends on many factors including the political situation at the time of the partial Internet shutdown, the technical capabilities and preparedness of bodies that might carry out surveillance during the shutdown, and the degree of risk that individual users are prepared to take on.
Briar's approach to risks like this is usually conservative: we don't assume that users have the technical knowledge needed to evaluate risks such as the exposure of metadata to unknown parties, and so we only provide features that can be used safely without such knowledge.
Applying this approach would mean that we would not implement features for communicating across a national intranet: in other words, we would sacrifice connectivity for safety.
# A Filesystem-Based API for Connecting P2P Communication Tools
During our research on using Ouisync as a transport layer, we had some thoughts on an approach to generalize Briar's file import/export feature.
Briar already includes methods to import/export encrypted messages from/to files, which could be used in an automated way to link Briar with other applications automatically via the filesystem.
We originally conceived of this as a way to link Android apps, but it could also work on other platforms.
A description of a possible implementation of this idea:
- Outgoing messages would be encrypted and written to an assigned directory for each contact/group.
If there was no assigned directory for a given contact/group, the messages would either be stored in a default directory or simply not written to a file.
- The user would configure a watch-list of directories for Briar to periodically scan for new files.
Briar would check each file for a tag indicating that the file came from a known contact.
Files with recognised tags would be imported and deleted, while other files would be ignored.
This approach is not limited to Ouisync; developers of arbitrary data transport layers could create applications following this file import/export system, allowing Briar messages to be tunneled through other transport systems, such as a public mesh application.
Some advantages of this system:
- Asynchronous queuing: if we just have a directory that we write outgoing messages to, the other app doesn't immediately need to do anything with the files. This allows loose coupling between applications.
- Portability: Lots of applications already operate with files, so by going in this direction Briar could receive lots of transport layer integration "for free".
- Usability: "Files" are a computing primitive that even most non-technical users understand, so providing the interface in this form might be more useful for both technical and non-technical users.
Another possibility would be to use network sockets for communication between apps, perhaps defining a REST API that various apps could implement.
This would require tighter coupling between apps than using the filesystem, but might reduce the amount of metadata exposed to other (untrusted) apps on the same device, or left behind on the device in case of seizure.