Current state of anonymous email usability

As part of another project, I needed to demonstrate how the various user-interface options for sending anonymous email through Mixmaster appeared to the email sender. This is very difficult to explain in words, so I recorded some screencasts. The tools I used were the Mixmaster command line tool, the Mutt email client with Mixmaster plugin, QuickSilver Lite, and finally a web-based interface.

The project is now over, but in case these screencasts are of wider interest, I’ve put them on YouTube.

Overall, the usability of Mixmaster is not great. All of the secure options are difficult to configure and use (QuickSilver Lite is probably the best), emails take a long time to be sent, recipients of anonymous email can’t send replies, and there is a high chance that the email will be dropped en-route.

In principle Mixmaster can be a secure way to send anonymous emails, but its usability problems mean that there are only a few users and this damages the security it offers. In a number of cases, Tor users have been deanonymised because the user community was too small, and Tor has likely several orders of magnitude more users than Mixmaster.

Mixminion is technically superior to Mixmaster and also has the potential to be more usable (emails are carried over TLS-encrypted connections rather than email, so avoiding the need for a user to configure their Mixminion client with SMTP server details). Unfortunately the experimental Mixminion network has shrunk to such a size that it is no longer possible to send emails through it. The Mixmaster network has shrunk too, but it at least is still able to function.

Currently, webmail-over-Tor is likely the most popular way to send anonymous emails. It is reasonably usable as a result of the efforts of The Tor Project, reliable, and quick. It’s also quite easy to mess up; if you ever log into your anonymous email account without using Tor, all your previous communications can be traced back. Tor is also not secure against powerful adversaries who can spy on a significant proportion of the Internet.

There’s much more that can be done to improve the situation. Better usability for Mixminion would be a start, but it also needs some remailer operators willing to deal with the inevitable abuse that occurs for any messaging service on the Internet. Techniques for managing this abuse would also help, but are unlikely to completely eliminate it.

Other designs show promise too, for example Pond, compared to Mixminion, offers reasonable usability, better security (in some respects), and good abuse prevention by only allowing email to be sent between individuals who already have agreed to communicate. However Pond isn’t ready for widespread use, and it will not be able to handle all use cases (such as a whistleblower leaking information to a journalist who doesn’t use Pond).

The usability of anonymous email could be greatly improved, and there’s plenty of opportunities for research which could have a big impact on freedom of speech online.

6 thoughts on “Current state of anonymous email usability

  1. I can’t help thinking that for some use cases, an “internet version” of some old fashioned methods would be more appropriate and easier to use. Variations of the old “put a coded ad in the personal section of the local newspaper” for example.

    The “old fashioned” newsgroups (for younger ones – look it up !) offer the advantage that it’s not possible to know who has read a message – nor if it’s a large enough group (carried by many servers across many legal jurisdictions), even where the message has propagated. Combine with something like Tor to hide the origin of the coded message, and it *should* make tracking difficult.

    Of course, this doesn’t get round the initial problem of exchanging information on the group(s) to be used, and the codes to look for.

  2. You mention some possible ways forward. Have you looked into Bitmessage combined with an SMTP gateway? It clearly has some challenges in scalability (and needs some serious security analysis) but it seems like it can offer good anonymity (as well as features like replies, emails initiated by either side, etc).

  3. Someone wrote this reaction.

    Subject: Re: usability study
    Newsgroups: alt.privacy.anon-server

    ===============================
    Overall, the usability of Mixmaster is not great. All of the secure
    options are difficult to configure and use (QuickSilver Lite is
    probably the best), emails take a long time to be sent, recipients
    of anonymous email can’t send replies, and there is a high chance
    that the email will be dropped en-route.
    ================================

    I think the author of this study somewhat misunderstand Mixmaster
    and misdefines ‘difficult to configure’. First, Mixmaster isn’t
    hard to configure at all. At least on Linux, it’s usually one or
    two commands if you’re just going to use it as a client. As far as
    using the client goes, it’s pretty self-explanitory if you take 10-
    15 minutes to /read/ about how things work. Perhaps ‘difficult to
    configure’, in this authors mind, means ‘I can’t just jump in and
    use it without learning about it’. But this is your /privacy/ we’re
    talking about! That ‘it just works’ mentality is exactly why we’re
    in the shit we are with the NSA/GCHQ/Others.

    Secondly, the ’emails take a long time’ is insane. Had he spent
    some time researching /why/ emails take a long time, he’d
    understand that it’s actually a security feature. There’s no
    “reason” why emails would take a long time save for added security.
    Again, we can see that ‘but I don’t want to have to /learn/
    something to use this! I just want to be protected!’.

    Third, and again showing his lack of research, he misses the point
    of remailers entirely with his statement ‘recipients can’t reply to
    an email’. While it’s true that in most cases they can’t, the fact
    is that, in most cases, it doesn’t matter. Remailers are often used
    to /convey/ information anonymously, not hold an anonymous
    discussion. There are other/better ways to do that.

    But, had he done a bit more searching, he could have seen that
    there are these things called ‘nyms’ which /do allow/ recipients to
    reply to anonymous emails.

    Sorry, it’s hard to take this guy seriously when it doesn’t look
    like he fully understands what he’s talking about.

    =====================================
    In principle Mixmaster can be a secure way to send anonymous
    emails, but its usability problems mean that there are only a few
    users and this damages the security it offers. In a number of
    cases, Tor users have been deanonymised because the user community
    was too small, and Tor has likely several orders of magnitude more
    users than Mixmaster.
    ======================================

    I’d like to see some hard proof that Tor users have been
    deanonymized because the network is ‘too small’. I hear this claim
    a lot but, honestly, if you look at most (possibly all, I haven’t
    looked at them all) busts related to Tor, it’s been because of
    something the /user/ did wrong. Again, it’s a case of someone
    wanting a tool to protect them when they don’t want to take the
    time to learn how to properly use it. That’s not Tor’s fault,
    that’s the user.

    Both Tor and Mixmaster could use some heavy love. Things could be
    much better and they will get there eventually. But this ‘usability
    study’ really just seems like a ‘let’s hate on Mixmaster/Tor’ piece
    without very much substance from an author who doesn’t really
    understand the software he’s reviewing.

  4. I think part of the problem may be that anonymous email is meant to serve two distinct user needs: on one hand it covers the use case where Alice wants to send an email to Bob, but hide her identity from Bob (sender anonymity), and on the other Alice and Bob know each other, but wish to hide their conversation from third parties (3rd party anonymity). I would argue, that the first case is rather infrequent, while the second one should be expected form a communication system “out-of-the-box”.

    The first use-case inevitably provides a very restricted user experience — no replies can be supported, spam and abuse is a problem, and even a stable pseudonym seriously degrades security. The second case could be integrated in the normal user experience of messaging.

    The problem is, besides chronic underinvestment, that the reviewed systems try to provide both function at the same time.

    PS I would like to thank the previous poster (Elvis) for reminding us about the grim reality of the level of discussions on usenet.

  5. Simon, your example of the ad in a newspaper is exactly how the current pseudonymity systems work. The newspaper is Usenet and the column is alt.anonymous.messages. All users download all messages and attempt to decrypt them, only succeeding when the message is encrypted to their own key.

    One problem with this system is scalability. Should it actually become popular, it’s very processor/bandwidth intensive to attempt download and decryption of thousands of messages. Another problem is lack of forward secrecy. If a key is broken, every message ever encrypted to it can be read. Single Use Reply Blocks can solve both of these issues but they require an order of magnitude more users than currently exist, otherwise an observer stands a good chance of linking source to destination.

    The only way to get sufficient users is to refine a client app to the point where people can reasonably consider it as an alternative to their normal email client. Even the server side has to be sufficiently simple that would-be operators aren’t discouraged. Mixmaster has demonstrated repeatedly that the requirement for a fully-functional DNS/MTA puts most potential operators off before they even get to the Mixmaster install.

    Of course, the principle goal has to be strong anonymity but if that comes at the cost of usability, the system will probably fail to achieve broad acceptance and a large user base.

  6. @Graham

    I hadn’t looked at Bitmessage before but it does seem interesting. From a quick skim of the whitepaper though, there are some potential issues. In particular all members of the network must receive every message, which puts a serious limit on its scalability.

Leave a Reply

Your email address will not be published. Required fields are marked *