cwtch.im
/
secure-development-handbook
3
0
Fork 1
Code Issues 1 Pull Requests Releases Wiki Activity

Formatting

This commit is contained in:
Sarah Jamie Lewis 2020-11-27 14:20:18 -08:00
parent d2aae573d4
commit 8687d23f60
1 changed files with 17 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
src/open-questions.md
View File

@ -10,13 +10,17 @@ Here are the problems we know about:
* **The User Experience of Metadata Resistance Tools**: Environments that offer
metadata resistance are plagued with issues that impact usability, e.g.
higher latencies than seen with centralized, metadata-driven systems, or dropped connections resulting from unstable anonymization networks. Additional research is needed to understand how users experience these kinds of failures, and how apps should handle and/or communicate them to users.
higher latencies than seen with centralized, metadata-driven systems, or dropped connections
resulting from unstable anonymization networks. Additional research is needed to understand
how users experience these kinds of failures, and how apps should handle and/or communicate them to users.
* **Scalability**: Heavily utilized Cwtch servers increase message latency, and
the resources a client requires to process messages. While Cwtch servers are
designed to be cheap and easy to set up, and Cwtch peers are encouraged to
move around, there is a clear balance to be found between increasing the
anonymity set of a given Cwtch server (to prevent targeted disruptions)
and the decentralization of Cwtch groups.
* **The (Online) First Contact Problem**: Cwtch requires that any two peers are
online at the same time before a key exchange/group setup is possible.
One potential way to overcome this is through encoding an additional public
@ -29,18 +33,15 @@ Here are the problems we know about:
aim of disrupting new connections). However, the benefit of first contact
without an online key exchange is likely worth the potential DoS risk in many
threat models.
* **Reliability**: In Cwtch, servers have full control over the number of
messages they store and for how long. This has an unfortunate impact on the
reliability of group messages: if groups choose an unreliable server, they
might find their messages have been dropped.
While we provide a mechanism for detecting dropped/missing messages, we do
not currently provide a way to recover from such failures. There are many
possible strategies from asking peers to resend messages to moving to a
different server, each one with benefits and drawbacks.
A full evaluation of these approaches should be conducted to derive a
practical solution.
* **Discoverability** of Servers: Much of the strength of Cwtch rests on the
assumption that peers and groups can change groups at any time, and that
servers are untrusted and discardable. However, in this paper we have not
introduced any mechanism for finding new servers to use to host groups.
We believe that such an advertising mechanism could be built over Cwtch itself.
* **Reliability**: In Cwtch, servers have full control over the number of messages they store and for how long. This has
an unfortunate impact on the reliability of group messages: if groups choose an unreliable server, they might find
their messages have been dropped. While we provide a mechanism for detecting dropped/missing messages, we do not
currently provide a way to recover from such failures. There are many possible strategies from asking peers to resend
messages to moving to a different server, each one with benefits and drawbacks. A full evaluation of these approaches
should be conducted to derive a practical solution.
* **Discoverability** of Servers: Much of the strength of Cwtch rests on the assumption that peers and groups can change
groups at any time, and that servers are untrusted and discardable. However, in this paper we have not introduced any
mechanism for finding new servers to use to host groups. We believe that such an advertising mechanism could be built
ver Cwtch itself.