Skip to content

GitLab

Last edited by intrigeri
Page history

mobile_messaging

Corresponding ticket: tails#14567

Characteristics of mobile messengers

Use cases

Signal for attorneys

People we met at the IFF 2019 started experimenting with using Signal as point of contact for attorneys and their clients or whistle-blowing sources.

They have a script that makes it possible to validate a land-line phone at the attorney's office to create a Signal account attached to it. This Signal account can then be used from Signal on a desktop computer, or even better, on Tails.

This setup has several advantages:

  • Giving your office telephone to a client doesn't look as dodgy as sharing your personal mobile phone number.
  • Attorneys are obliged to have a land-line phone as their official point of contact.
  • Attorneys can keep their work and personal contacts separate.
  • Attorneys can attend their work Signal even when outside of office and keep secure communications with their clients even when traveling.

An important limitation for this to work is that you can't change the name of contacts that were added, using a phone number, to Signal desktop. There is a feature request for this upstream.

General requirements

XXX: where does the current list come from? For example, the list of "SHOULD" is so long that it looks like a brainstorming of all possibly desirable properties, more than an actionable decision. IMO we need finer-grained prioritization. -- intrigeri

MUST

  • 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
  • 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

Tox

  • Tox website
  • tails#10071
  • client (qtox) available in Debian Buster
  • decentralized
  • it is possible to set it to work with Tor as a SOCKS5 proxy
  • end-to-end encryption
  • it is possible to opt-out IPV6 and UDP in the client settings

Briar

  • decentralized
  • works over Tor
  • no Linux client yet

Matrix/Riot

  • Riot website
  • tails#15209
  • decentralized
  • Riot supports: IM, VoIP, Videocall & - conferencing, File Transfer (of course) and SMS
  • bridges to Slack, Gitter, IRC, Telegram, Twitter etc.
  • works over Tor
  • TLS by default
  • Debian packages, but no official ones

Ring.cx

  • end-to-end encrypted
  • video calls

Signal

  • Signal website
  • tails#15200 (closed)
  • centralized server
  • mass adopted
  • the Chromium-based app actually moved to the Electron application framework in early 11/2017
  • is installable via apt (with installed apt-transport-https) and the repo's from the Signal project. it's 198MByte big after installation
  • double ratchet
  • instant messaging
  • Proof-of-concept for installing and running Signal in Tails: https://bisco.org/notes/installing-and-running-signal-on-tails/
  • have to enter a phone number
  • With the mobile client, voice calls don't work over Tor (sajolida, 2018).

feedback from testing the flatpak based installation:

Telegram

  • works over Tor (You can configure Tor as a SOCKS5 proxy in the configuration. The traffic seems to go through HTTP.)
  • is in Debian
  • When first starting the app, you have to enter your phone number and validate it through an SMS. Then you get all your messages and conversations back, even your stickers!
  • So it's not anonymous in the sense that it's linked with your phone number but it's super easy :)
  • instant messaging
  • The desktop client doesn't support end-to-end encryption for chat and voice calls: only the mobile one does.
  • Voice calls on desktop client work on Tails.
  • https://web.telegram.org/ works from Tails. You need your phone to authenticate.

WhatsApp

  • With the mobile client, voice calls don't work over Tor (sajolida, 2018).

Wire

XMPP

  • XMPP website
  • related: tails#11541 (closed)
  • Protocol with lot of choices for clients
  • decentralized
  • desktop client available
  • works over Tor, supports hidden services and private identities on .onion domains
  • double ratchet end-to-end encryption (OMEMO), OpenPGP and OTR supported
  • video calls supported by protocol, but clients lack good implementations
  • desktop clients in Debian: Gajim, Dino, Psi+

Related

Free and random thoughts

  • modern (mobile) messengers replaced SMS/MMS and a bit of e-mail, too, as mobile internet became widespread available in the beginning of this century
  • are nearly exclusively used on mobile devices (smartphones/tablets) with operating systems such as Android OS by Google and Apple's iOS
  • some use (or even require and are based on) mobile phone numbers as identifiers for their users
  • started as (cost-effective, due to availability of mobile data/WiFi) replacement for SMS, but more features were added during time (group chats, media/file sharing, profile pictures, voice messages, "broadcasts", own status texts, voice calls, etc.)
  • mostly aimed at mobile platforms as Android, Apple iOS, Windows Phone. sometimes desktop clients are available for Windows, macOS and also Linux. For some products web clients are available which run in any modern web browser (but may require a running phone in parallel)
  • single platform/protocol. Mobile messengers are incompatible with other platforms/messengers
  • mostly client/server (or client/federation) software
  • mostly run by commercial companies which provide the client software, updates, servers
  • client and server applications are mostly closed source, some providers allow free software based clients. sometimes parts of the client/libraries are open sourced for review. some messengers implement free software protocols or libraries (e.g. Axolotl Ratchet, NaCl)
  • all modern messengers don't require the recipient(s) to be online at the same time when sending a message (in other words: they support asynchronous messaging)
  • nearly every mobile messenger is (money-wise) free-to-use
  • in the end, even if a product is presented and promoted as open source aka. free software, it may be, but won't be totally. The providers claim that the client software is free software. And it indeed is in nearly every case, even if it's doing some weird stuff (looking at Telegram here). But no one will effectively show us what's running on the other side. Maybe some source code is opened, but in the end no one will know, what is executed on the shiny silicon of WhatsApp, Telegram, Signal, etc. We even won't know what metadata will be kept there, for how long, for which purpose, and witch which and with whom this data is going to be shared. Let's assume that the math in the modern crypto works. The provider/state will only see encrypted garbage. Fine. But what about the layers around? From, at which time the message is leaving, to which data center? (etc. etc. you get the picture) This is definitely not in our hands anymore (in most places).