special
commented
7 years ago Wow, this is an old issue. It's about time to get this done. Let's talk about file transfers. This is partly requesting feedback, partly trying to convince myself, and partly a braindump, but hopefully it's useful.
UX
I see two broad types of use cases for file transfers. The active users are sending and receiving files during conversations, and expect the file to be part of their conversation. File drops are for an important minority of Ricochet users who want to stay online and be able to receive files at any time, even if they're not immediately active.
Like most messaging applications, we want to do file transfers inline as part of the conversation, and they must not require using any other application (including a browser).
Drag and drop of a file into a conversation is the normal way to send a file. Arguably, it could be easy to accidentally send a file this way. That could be mitigated by dropping the file into the message input box and allowing typing a message to go with it before sending, or more easily with a countdown before sending. There should be another visible UI method for sending files, like a button in the conversation header or near the message input.
Offered files must expire after enough time to reasonably assume the user might've forgotten.
Ricochet's threat model prohibits storing conversation data (including files) automatically. The threat model also sees contacts as potential exploitation adversaries, so we want to reduce the set of actions a contact can trigger without user approval. These suggest that we should require explicit accept by default for file transfers. The user has to explicitly choose where to save each file, unless they configure a default location. This is fine with the active user use case, but for file drops we will need an option to automatically save files (which could also be per-contact).
Active offers or transfers must be easily noticable to both parties. In addition to showing progress on the transfer in the conversation, there should be progress in the conversation header (a transfers tab?) and/or global transfer status somewhere. This is particularly important because the conversation may move on while transfers are ongoing. When a transfer finishes, it should be moved to the end of the conversation.
Completed transfers are opened by clicking, with a warning similar to the browser warning.
Tor has been known to be unreliable, so the ability to resume will be important. We must reconnect and resume automatically whenever possible. If too much time has passed, or one of the clients has lost its history, resuming should still be possible by saving over an existing incomplete file.
Future UX
Displaying images inline with conversations is a standard messaging feature. This is easy to do once we have file transfer in place, except that I don't trust image decoders. Once we find a robust and memory-safe decoder, or cross-platform seccomp-style sandboxing, this is worth doing.
Someone pointed out that we could prefetch files, at least by building connections and buffering up to some in-memory limit, to make the transfer process seem faster.
It would be nice to allow transferring batches of files or entire folders up to some reasonable limit.
Having a way to automatically verify the hash of the downloaded file with the sending server would be nifty.
Protocol
Connections
File data can't be sent over Ricochet's primary protocol connection. Even though we packetize data, because of the buffering properties for Tor streams, very large amounts of data will in queues when flooding a hidden service connection. This causes extreme (often 30s or more) latency for that stream. Any other form of rate control would have too much impact on transfer speeds.
The simple answer is to open additional connections to the peer's service. These connections will be multiplexed by Tor onto the same circuit, but buffering behavior is significantly better. In casual testing there seems to not be significant impact on message latency when flooding data to another stream on the same circuit.
We could also use circuit isolation options to force Tor to build new circuits for transfers. It's unclear whether this would be useful for throughput or latency, and it's unclear whether building additional concurrent circuits would have significant anonymity or traffic analysis impacts.
Ricochet's protocol doesn't allow more than one authenticated connection per contact, because it would be ambiguous which connection should be used and could violate expectations on message ordering. If additional connections use Ricochet's protocol, they will need to authenticate differently to indicate that the connection is only used for data transfer.
Because data transfer is happening over secondary connections, we're not required to package data with Ricochet's protocol. It's worth thinking through the options here.
Option 1: Modified Ricochet protocol
My original thinking was to use Ricochet's protocol for file data transfer on additional connections. This isn't entirely straightforward.
Benefits:
- Could easily send small files inline over the protocol connection
- More consistent with the existing protocol
- No new parser/server attack surfaces
Downsides:
- There can only be one primary connection, so authentication ends up being weird
- Unless we made deeper protocol modifications, data has to be broken up into max-65kb chunks with headers
- The protocol design and implementation is difficult to get right
There's some older work on what this could look like from a WIP branch in FileTransferChannel.proto and FileTransferDataChannel.proto.
Option 2: HTTP (my current preference)
Ricochet clients could offer files over HTTP, using a simple internal server and unique URLs, similar to OnionShare. That server could be on a different (possibly randomized) port of the same hidden service, on new ephemeral services, or even share the same port using protocol detection.
Benefits:
- More robust/standard/future-proof implementation
- Recipient backwards compatibility: can fallback naturally to displaying a URL
- Possible for recipients to download using browsers & other tools
- Could be used to offer files to non-contacts also
Downsides:
- Even a very minimal HTTP client and server are a new protocol attack surface for contacts
- Unclear what C++/Qt implementation would be safe enough to use
Server/client implementation
There is no need for a 100% feature-complete and spec-behavior-compatible HTTP client in Ricochet, because the use case here is very minimal. To keep the potential for bugs as low as possible, I'd limit the implementation to features we need, and not use (e.g.) chunked transfer encoding or esoteric options. We could even force Connection: close if it's helpful. This ends up being a pretty small amount of network-exposed code, and is still generally compatible with other clients and servers.
Server behavior and URL format
I favor putting the HTTP server on a randomized port under the same hidden service. Bringing up new services is sometimes slow or unreliable, and involves many new circuits and distinguishable network activity. This also means we can require the same .onion hostname, which prevents peers from being able to force a connection to an arbitrary .onion.
If the server is always running, it's possible for contacts and non-contacts to find at any time, though this shouldn't be of any value. If the server is only active when there are active file offers, that state may be detectable to contacts or non-contacts who can learn the port.
There is no point or need to try to disguise as anything other than a Ricochet client. All well-formed requests that are not valid file requests should be rejected with a generic 404 error.
I propose the following for download URLs:
http://[address].onion:[port]/ricochet/fetch/[uniqid]/[filename]
[address] must be the contact's ricochet connection address
[uniqid] is a large (>=128bit) random identifier
[filename] is the URL-encoded original name of the file
Only HTTP is permitted, no HTTPS. We do not want to require a TLS
implementation, and .onion makes it unnecessary.
Clients may refuse transfer URLs without a /ricochet/fetch/ prefix.File URLs are related to a specific transfer and are meant for one time use. Range requests must be supported to allow resume, and may be allowed for parallel downloading. Servers should stop offering a URL once they believe the recipient has a full copy.
File offer protocol
We can package a file offer into an extended chat message:
message ChatMessage {
required string message_text = 1;
optional uint32 message_id = 2;
optional int64 time_delta = 3;
// Indicates a file transfer offer. message_text must begin with a valid
// file transfer URL, terminated by the first whitespace or end of message.
// The rest of message_text, if any, should be displayed as a user message
// along with the file.
optional FileInfo file_info = 4;
}
message FileInfo {
// required
optional string file_name = 1;
optional uint64 file_size = 2;
// optional
optional string content_type = 3;
}
message ChatAcknowledge {
optional uint32 message_id = 1;
optional bool accepted = 2 [default = true];
optional bool file_received = 3;
optional bool file_refused = 4;
}Acknowledgement of this message also acknowledges the file offer. The URL may be immediately accessed to download the file. In addition to acknowledging the message normally, the recipient should send an additional ChatAcknowledge when the transfer has completed or if it is refused, with the appropriate field set. Senders should be prepared to consider a transfer completed based only on data transferred and not rely on ChatAcknowledge, to support older clients or alternative downloaders.
This has the neat property of being entirely compatible with clients that don't implement file transfers; the user will see the URL, and can download it in a browser. This isn't especially meaningful, though.
XXX There is no way defined here for the sender to indicate cancellation
Next steps
I'd like to move forward on this pretty quickly, so I'm going to be aiming for nailing down the protocol and major UX decisions very soon.
There's already a good chunk of code written, but it needs some fixing and will need changes based on the decisions here.
Any thoughts?
s-rah
timkuijsten
burdges
JeremyRand
vatterspun
gianni76
ei8fdb
Being able to transfer files would be a useful feature, to enable whistleblowers, etc.