Commit 6a3933b8 authored by Ulrike Uhlig's avatar Ulrike Uhlig
Browse files

Reorder page

parent cf7d2c52
......@@ -2,28 +2,10 @@ Corresponding ticket: [[!tails_ticket 14567]]
## Characteristics of mobile messengers
- the EFF provides a [Secure Messaging Scorecard](https://www.eff.org/secure-messaging-scorecard) (which is updated atm, the old
version is available [here](https://www.eff.org/node/82654)).
I'll provide some additional characteristics which we should consider and from which we can choose down below.
### Additional characteristics
- availability of desktop clients (more or less crucial in the context of Tails, as I don't think that a web client is a feasible option)
- mass adoption / platform interoperability
- metadata security (network-wise, e.g.: what data is the provider saving in terms of me contacting whom and when from where, etc.)
- address book security / contact discovery mechanisms (e.g. some messengers will upload the whole address book to a central server to find out if your friends use the same app, too)
- security mechanisms if a device gets lost (I think this is a bit out of scope wrt. Tails, as we already provide encrypted persistence. But it can be a thing with mobile devices.)
- group chat security (some protocols can't handle this, AFAIR signal does)
- self destructing messages (e.g. Telegram is offering this feature, after a pre-set time the message will be destroyed on the recipients device)
- support of sending files and media such videos, audio, voice messages,…
- online status / status message / profile picture security (metadata security. e.g. can I restrict that people that I don't know won't see my picture or my status, etc.)
- asynchronous messaging
- user enumeration security (is it possible to easily "harvest" accounts via bulk telephone number checking, id-numbers, etc. This is esp. relevant when it comes to nation-wide adversaries who can easily control big phone number ranges)
- requirement of a phone number
- price (as in $$$)
- usability (esp. a GUI which directs the user to a desired level of security or at leasts helps to prevent the user to make fatal mistakes)
- security in adding new devices or clients (maybe two-factor auth or similar?, worst case: an attacker adds a device easily and is able to restore all past messages because the provider stores them all)
- the EFF provides a [Secure Messaging
Scorecard](https://www.eff.org/secure-messaging-scorecard) (which is
currently being updated, the old version is still available
[here](https://www.eff.org/node/82654)).
## General requirements
......@@ -31,15 +13,43 @@ I'll provide some additional characteristics which we should consider and from w
- work over Tor / SOCKS
- provide end-to-end-encryption (OTR, some kind of ratcheting)
- provide high usability and good user experience (i.e. a GUI which
directs the user to a desired level of security or at leasts helps to
prevent the user to make fatal mistakes)
- be free software
**SHOULD**
- provide a desktop client
- be mass-adopted already
- be mass-adopted
- provide platform interoperability
- allow for instant messaging
- asynchronous messaging
- allow for video calls
- allow for audio calls
- allow sending files and media (video, audio, voice recording, pictures)
- allow saving data to a persistent folder
- provide metadata security (network-wise, e.g.: what data is the
provider saving in terms of me contacting whom and when from where,
etc.)
- secure group chat
- provide address book security / contact discovery mechanisms (e.g. some
messengers will upload the whole address book to a central server to
find out if your friends use the same app, too)
- provide security mechanisms if a device gets lost
does)
- provide self destructing messages
- provide online status / status message / profile picture security
(e.g. can I restrict that people that I don't know won't see my
picture or my status, etc.)
- not have requirement of providing a phone number
- security in adding new devices or clients (e.g. two-factor
authentication)
- provide user enumeration security (is it possible to easily "harvest" accounts
via bulk telephone number checking, id-numbers, etc. This is esp.
relevant when it comes to nation-wide adversaries who can easily
control big phone number ranges)
## Possible candidates:
### Briar
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment