Voice over Tor¶
Concept Summary¶
The solution will utilize either one or both of new data transfer services that Gibberbot is implementing support for. The first is XMPP Stream Initiation File Transfer (XEP-0096), and the second is an experimental extension to OTR v3's support for shared symmetric key generation, and passing arbitrary bytes within the OTR packet itself. Since Gibberbot itself already supports proxying the XMPP connection over Tor (using Orbot on Android), both of these data methods will work over Tor through the XMPP connection.
The voice recording and playback will happen within the flow of a standard chat session, interleaved into text messages. The audio will be recorded using built in Media Recorder features of the Android API, and will use a bandwidth efficient encoding, such as SPEEX, OPUS or Codec2.
Progress¶
July 2013¶
- Finalizing implementation of OTR Data and OTRv3 implementation in OTR4J classes that are part of Gibberbot core project. OTR Data pull request under review: https://github.com/guardianproject/Gibberbot/pull/233
- Meetings held with design and usability teams to discuss the user interface, feature set, and which existing voice messaging apps we should study and emulate
- Gibberbot/ChatSecure v12 in stable alpha, beta shortly; Voice-over-Tor will be released as part of v13 #
Design Notes¶
Usability Thoughts¶
- people don't separate content types when sharing with mobile messaging: picture, voice, emoji, whatever; they just want to communicate something
- media is not an attachment to a message; all messages have a a content-type and that is rendered to the user with the appropriate UI mechanism
- implementation should support both one off messages, and push to talk back and forth type model for active conversations
- in whatsapp, media sharing is buried under actionbar paperclip icon; should audio voice messaging be a first order option? next to input field.
- Line's UI is preferrable to WhatsApp... the + icon is next to emoji/stickers right on message input bar
What Tor provides¶
- defense against traffic analysis of voice messaging / audio conversations
- increased security of traffic, mostly when using XMPP services via hidden services
Additional security beyond Tor that is needed¶
- Anonymity/de-rezzing of audio to mask voice identity
- encryption/verification via OTR Data
- local media encryption / secure storage of media when transfered
Specification¶
- App MUST add new media sharing icon to chat view window, ideally next to message input box, but possibly accessible via a menu
- App MUST display a built-in audio recording widget that will record audio message in memory, and encode into a compressed, efficient format
- App MUST never store the audio data in an unencrypted format on persistent storage
- App MUST store all media data as part of message data in encrypted local SQLCipher database
- App MUST create an outbound message with audio media embedded/attached to it, to ensure audio data is part of standard messaging workflow
- App MUST handle inbound messages with audio media embedded/attached, and display them appropriately to the user
- App MUST support a reliable, auto-retry mechanism for ensuring transfer of audio media is simple and not burdensome to the user
- App SHOULD allow the user to decide whether they want to accept the inbound attached audio content or not
- App SHOULD support fall back XEP file transfer mechanisms if other app does not support OTR-DATA, or for sending audio messages over Tor without OTR
- App SHOULD support a means of semi-anonymizing voices captured in audio through reducation of bit and sample rate of audio
- App SHOULD support export of audio media to external storage or another app
- App MAY support more sophisticated voice masking/anonymization capabilities using advanced audio processing
- App MAY support a configurable set of audio encoding/codec qualities to allow the user to utilize higher quality audio if they choose
Line App - screenshots to emulate¶
