secure-development-handbook/src/server.md

# Cwtch Server

The goal of the Cwtch protocol is to enable group communication through
**Untrusted Infrastructure**.

Unlike in relay-based schemes where the groups assign a leader, set of
 leaders, or a trusted third party server to ensure that every member of the
 group can send and receive messages in a timely manner (even if members are
 offline) - untrusted infrastructure has a goal of realizing those properties
  without the assumption of trust.
  
The original Cwtch paper defined a set of properties that Cwtch Servers were
expected to provide:

*  Cwtch Server may be used by multiple groups or just one.
* A Cwtch Server, without collaboration of a group member, should
  never learn the identity of participants within a group.
* A Cwtch Server should never learn the content of any communication.
* A Cwtch Server should never be able to distinguish messages as belonging
  to a particular group.
  
We note here that these properties are a superset of the design aims of Private
Information Retrieval structures.

## Malicious Servers

We expect the presence of malicious entities within the Cwtch ecosystem.
 
We also prioritize decentralization and permissionless entry into the
 ecosystem and as such we do not base any security claims on the following:

* Any non-collusion assumptions between a set of Cwtch servers
* Any third-party defined verification process

Peers themselves are encouraged to set up and run Cwtch servers where they can
guarantee more efficient properties by relaxing trust and security
 assumptions - however, by default, we design the protocol to be secure without
 these assumptions  - sacrificing efficiency where necessary.
 
### Detectable Faults

* If a Cwtch server fails to relay a specific message to a subset of group
members then there will be a detectable gap in the message tree of certain
peers that can be discovered through peer-to-peer gossip.
* A Cwtch server cannot modify any message without the key material known to
the group (any attempt to do so for a subset of group members will result in
identical behavior to failing to relay a message).
* While a server *can* duplicate messages, these will have no impact on the
group message tree (because of encryption, nonces and message identities) - 
the source of the duplication is not knowable to a peer.
 
## Efficiency

As of writing, only 1 protocol is known for achieving the desired properties,
naive PIR or "the server sends everything, and the peers sift through it".

This has an obvious impact on bandwidth efficiency, especially for peers using
mobile devices, as such we are actively developing new protocols in which the
privacy and efficiency guarantees can be traded-off in different ways.

As of writing, the servers allow both a complete download of all stored messages, and a 
request to download messages from a certain specified message.

All peers when they first join a group on a new server download all messages from the server, and
from then on download only new messages.

*Note*: This behaviour does permit a mild form of metadata analysis. The server can new messages for each
suspected unique profile, and then use these unique message signatures to track unique sessions over time (
via requests for new messages). 

This is mitigated by 2 confounding factors:

1. Profiles can refresh their connections at any time - resulting in fresh server session.
2. Profiles can "resync" from a server at any time - resulting in a new call to download all messages. The most 
common usecase for this behaviour is to fetch older messages from a group.
   
In combination, these 2 mitigations place bounds on what the server is able to infer however we still cannot
provide full metadata-resistance. 

For potential future solutions to this problem see [Niwl](https://git.openprivacy.ca/openprivacy/niwl)
  
# Protecting the Server from Malicious Peers

The main risk to servers come in the form of spam generated by peers. In the
prototype of Cwtch a spamguard mechanism was put in place that required
peers to conduct some arbitrary proof of work given a server-specified
 parameter.

This is not a robust solution in the presence of a determined adversary with
a significant amount of resources, and thus one of the main external risks to
 the Cwtch system becomes censorship-via-resource exhaustion.
 
We have outlined a potential solution to this in 
[token based services](https://openprivacy.ca/research/OPTR2019-01/) but note
 that this also requires further development.