If multiple email accounts simultaneously connect via Delta.Chat using the Tor proxy, each account should have the correct type of connection to Tor that will trigger full circuit isolation, even if all email accounts share the same domain.
Previously, Tor’s circuit isolation was mostly domain, port, client, or address based, which might not have been helpful for isolating same-domain email connections in an email client implementation.*
A recent development has been that Tor may now isolate streams based on the container tabs spawned by that corresponding extension (Firefox Multi-Account Containers) in Firefox. It is currently unclear how container tabs trigger circuit isolation in Tor; whatever this method may be could prove effective if Delta.Chat were able to use this same method for isolating multiple simultaneous same-domain connections.
*Whether an email address qualifies as address-based is not currently clear.
It is unknown if multiple logins/connections to the same provider over Tor in Delta.Chat share a stream. If they did, it could completely break identity compartmentalization and therefore pose a very large security risk.
At the moment, Tor is not supported very well. Part of the problem is that tor works very differently on different platforms.
deltachat-desktop offers to use a socks5 proxy, which works with the lokal tor daemon if it is configured to listen on localhost:9050 via socks5 (for example). On Android phones traffic can be routed over Orbot, and on iOS I think there is some Tor VPN integration into the system, but in all of these cases, Delta Chat doesn’t really interact with Tor directly.
This would be super nice to have though. At some point the rust implementation of tor could be integrated into the delta chat rust core, then we could use it directly, and probably also use different circuits for different accounts.
It needs to be said that this is only a risk if you use multiple Delta Chat accounts and need them to be compartmentalized.
Which I am not sure is something that should be done at a messenger-app-level. I think using Qubes OS or several Whonix or Tails instances is a better practice. But maybe I’m just being too conservative.
Either way, as @missytake pointed out, right now the SOCKS proxy thing is still pretty leaky in Delta Chat, so it’s better to use a Tor proxy at a higher level, e.g. OS-level or higher, such as with Tails or Whonix.
Also, there’s the Go implementation from Lightning/Lnd, tor.streamisolation=true, that seems to be directly facilitating the same kind of blanket isolation needed here.
if you use multiple Delta Chat accounts and need them to be compartmentalized
While there are use cases where one might have different accounts on the same domain and not need them to be compartmentalized, that indifference is mostly an artifact of the past, when various kinds of isolation were not technically possible without extreme and impractical precautions, in which times separate accounts were primarily used for convenience.
Generally, in the modern sense where isolation is increasingly a well supported feature, all separate accounts should be compartmentalized by default. It’s easy enough to conjoin them deliberately later, for instance in the case of sharing some kind of authentication.
using Qubes OS or several Whonix or Tails instances is a better practice
See above re: extreme and impractical. These suggestions involve pivoting to a desktop platform, which is likely to be unavailable to anyone in motion, specifically meaning beyond a desk.
Rust may come to the rescue here! But I’d still like to discover how Firefox’s Multi-Account Containers triggers that isolation in legacy (C) Tor. It may provide a more immediate, or at least interim, solution.
I agree that it’d be better if Delta Chat could stream-isolate accounts. This probably gives some extra privacy. I agree that a lot of people are not willing to set up Whonix, so for them it’s either Delta Chat with Tor or Delta Chat with no proxy.
What I want to say is that I doubt that the SOCKS w/ Tor setup for Delta Chat is ever going to be as private as a Whonix setup. One example that came to mind is: should Delta Chat fetch emails for accounts that are not the currently active one, to show notifications for them; because it would allow for timing correlation attack; when you launch DC, all accounts get active at the same time.
While there are use cases where one might have different accounts on the same domain and not need them to be compartmentalized, that indifference is mostly an artifact of the past, when various kinds of isolation were not technically possible without extreme and impractical precautions, in which times separate accounts were primarily used for convenience.
Hm, I can’t follow entirely? Which kinds of isolation do you mean which were not technically possible in the past but are now? Under which deanonymization threat model?
Another thing you can do here is set up multiple different SocksPorts in Tor. The provided default is just one, 9050, but you can add more. This is something that must be done in Orbot or by editing the torrc file itself.
If you add as many new SocksPorts as you have email accounts, and specify one SocksPort per account in Delta Chat’s settings, that should assist with compartmentalization, since each SocksPort gets its own circuit by default.
It may also help to set a proxy username and password for each account, because it looks like that may also trigger circuit isolation in Tor, though it isn’t a commonly used feature and it may not be necessary.
These of course are all Tor-specific solutions, other VPNs will work differently, and it still doesn’t solve the issue of getting Delta Chat to trigger isolation by itself without having to specially configure an outside app.
Thanks @ghostlands for these tips. You say that this is something that must be done in Orbot or by editing the torrc file itself, but the references for your post are only for Tor on desktop. Would you care to explain or post a link showing how to set up multiple SocksPorts with Orbot?
