Take Control of Your Online Privacy (1.1) (2014)

Improve Email Privacy

When we began discussing this book, Take Control publisher Adam Engst told me that his rule is, “don’t write anything in email that you couldn’t stomach appearing on the front page of the New York Times.” I said I didn’t think that was a very good rule, and we discussed it (by email, naturally) in what became an increasingly contentious debate. I won’t repeat the entire exchange here, because I’m sure you’ll read it soon enough in the New York Times.

But to summarize, Adam was trying to make the point that you can never have an ironclad guarantee of privacy when it comes to email. In that respect he’s absolutely right, for reasons I’ll explain in a moment. My point was that in many cases, email is the only practical means of communication, and yet it’s completely impractical for me to avoid ever sending personal facts, business secrets, colorful language, or anything else by email that wouldn’t cause serious problems if made public. I think I’m right about that, too.

But email privacy is extraordinarily difficult to achieve, and the more control you try to exert, the more cumbersome it becomes. By the end of this chapter, you should have a better appreciation of what makes email privacy so tricky. But you’ll also learn how to keep most email safe from casual snooping, how to make top-secret email messages as private as they reasonably can be, and when it’s best to choose an entirely different means of communication.

Understand the Privacy Risks of Email

If you send me an email message, you might have the impression that you and I are the only two people who can read it. Such assumptions are unwise. Let’s look at a few of the places email might be visible to someone other than the sender or recipient:

· On your end: Your email client may keep a copy of the messages you send. If so, anyone who gained access to your computer (including thieves and people reading over your shoulder—not to mention your employer) could see what you’ve sent.

· In transit: At minimum, an email message must travel from the device where you compose it to a server, and from a server to the recipient. (If both you and the recipient happen to use the same email server, no further hops are required, but usually messages go to an outgoing email server and then take one or more extra steps over the Internet to the recipient’s email server.) An email message could be intercepted along any segment of this journey—for example, by someone “sniffing” an open Wi-Fi network, or by ISPs, corporations, or government agencies monitoring a router. As I’ll explain shortly, the message data might be encrypted during part of its journey across the Internet, but you can’t count on this, even if you use SSL to communicate with your email server.

· On email servers: The email server you connect to in order to send a message may hold onto that message only for as long as it takes to send it, and then delete it. Or it may cache the message for much longer—even indefinitely. Unless you run the email server yourself, you have no way to know for sure. Once it reaches the recipient’s email server, it’ll stay there at least until the recipient reads it, but more likely it’ll stick around forever, because most modern email systems work best when the server stores the master copies of incoming messages, which then sync to client devices. In any case, for whatever period of time the message is on a server somewhere, anyone with access to that server could conceivably read the message without you or the recipient ever knowing.

Note: The U.S. government currently needs a search warrant to access unopened email that’s been stored online for 180 days or less—older unopened messages can be obtained with a (simpler) subpoena. But don’t assume opened messages older than 180 days, or more-recent unopened messages, are off-limits; the law is murky enough that any message on an email server could be fair game.

· On the recipient’s end: Everything that’s true on your end is also true on the recipient’s end, with the additional complication that you have no control at all over what the recipient does with a message received from, or sent to, you. And, if the recipient uses multiple devices or services for email, your message may be on any or all of them.

· In backups: You, the recipient, and whoever runs email servers that process your messages most likely back up your data to one or more other locations such as local hard disks and cloud storage. (Good for you! Backups are mighty important.) Those backups may be encrypted, but if they aren’t—or if someone with access to the media on which the backups are stored can crack or bypass the encryption—that’s another way your email message could be read.

This isn’t even an exhaustive list, but I hope that it explains Adam’s contention that complete privacy of email messages between you and the other party is little more than wishful thinking. Someone who wanted to know what you sent or received by email would have many potential ways to do so.

Note: There’s yet another risk: accidentally sending confidential email to the wrong recipient (or even to a mailing list)! I’ve done it myself, and I’ve also received confidential email addressed to me by mistake. Double-check the address(es) before clicking Send!

None of this means someone is reading your email. I’d wager that the overwhelming majority of email messages are never read by anyone other than the sender and recipient. But if you discuss anything sensitive by email, you should be aware that the possibility exists. And, if the contents of a message are such that someone may have financial, legal, or political motivation to read it, the odds of exposure increase. Unfortunately, because email messages are out of your control the instant you hit Send, it’s impossible to quantify the risk.

Are Gmail Ads an Invasion of Privacy?

If you use Gmail, you undoubtedly know that Google scans your messages for keywords to display ads associated with those words. This process is essentially the same one that results in relevant Google AdSense ads appearing on the Web sites you visit, but it may feel more intrusive in this case because of the impression Google is reading email messages that should be none of their business.

But in fact, delivering ads is pretty much Google’s entire business. Displaying more-relevant ads means advertisers make more money and therefore buy more ads. So it’s in Google’s best interest to show you the ads that are most likely to result in a purchase. The fact that Google earns money from advertising to you is the sole reason the company gives away Gmail accounts for free. You pay, in effect, by agreeing to look at ads, with the qualification that ads should have some relevance to you based on what’s in your email messages.

I always thought Gmail’s free-with-ads concept was both clear and reasonable, but many users feel keyword scanning constitutes an invasion of privacy. To this complaint, I have three responses:

· Were Google to display ads randomly rather than based on what you’re likely to find interesting, the ads would be even more annoying because they’d be less relevant.

· Remember that ads are matched with messages algorithmically. A computer sees the word “iPad” in an email message and looks for an ad that also designates “iPad” as a keyword. Neither Google’s computers nor Google employees know or care what you’re saying about iPads; it’s a one-way, blind system designed for the sole purpose of selling you stuff. In other words, it’s nothing personal.

· If you can’t stomach the idea of targeted ads, you can avoid seeing them. Ads don’t show up in an IMAP or POP client, for example, and ad-blocking software (see Web Privacy Software) works on the Gmail site too. But, neither technique prevents Google from scanning your email in the first place. If you want Google to stay out of your email entirely, the only right answer is use a different email provider.

Reduce Email Privacy Risks

Now that I’ve told you how hopeless complete email privacy is, I want to cheer you up a bit by talking about meaningful steps you can take to reduce—not eliminate—the potential for your email messages to fall into the wrong hands. In this case, you protect your privacy by increasing security. The more of these things you do, the fewer opportunities an attacker will have to read what you send and receive. In most cases, they’ll be enough. And since you now understand that email privacy can’t be perfect, you’ll at least be able to make smarter decisions about what should and shouldn’t go in an email message.

Log In Securely

In the spectrum of email privacy mistakes, perhaps the worst one is to transmit your username and password to your mail server in unencrypted, human-readable cleartext. If you do that, anyone who intercepts the communication between your device and the server can easily obtain your username and password and then log in to your account and read all your email—and send email under your name. Luckily, this is also among the easiest problems to solve.

Numerous methods are available for authenticating—that is, logging in with a username and password—to incoming and outgoing email servers. The good news is that most of these methods encrypt your password in transit, even if your email and the conduit through which it travels are unencrypted. Odds are excellent that your email app is already set up to authenticate securely, but it never hurts to check.

In your email client (such as Apple Mail or Microsoft Outlook), navigate to the preferences or account settings for one of your email accounts (Figure 15). Near your username and password, you’ll usually see an Authentication setting, often in a pop-up menu. If this says Apple Token, GSSAPI, Kerberos, anything with “MD5” (such as CRAM-MD5, Digest-MD5, or MD5 Challenge-Response), NTLM, or TLS Certificate, you’re in good shape. In addition, if your client is set up to use SSL (see Transfer Email Securely, just ahead), then any authentication method will, by definition, be encrypted. However, if you are not using SSL and the authentication method is set to Login, Password, or Plain, your password is probably being sent in the clear.

Figure 15: Apple Mail lets you choose, for each account, which authentication method to use for incoming mail (shown here) or outgoing mail. Remember, “Password” is fine if (and only if) the account uses SSL, which this example does.

Unfortunately, you can’t arbitrarily select a different authentication method; you must choose one that your email server supports. Look at your email provider’s Web site, or contact its technical support department, to find out what your options are. While you’re at it, check on whether SSL is supported—if it is, that’s your best bet, and then the authentication method is unimportant.

Keep in mind that in most cases, you must go through this process twice for each of your email accounts—once for the incoming (IMAP or POP) server and once for the outgoing (SMTP) server. Microsoft Exchange accounts are an exception to this rule; they use the same server and settings for incoming and outgoing mail.

Transfer Email Securely

After secure authentication, the next logical step to keeping your email private is to use SSL (Secure Sockets Layer), also known as TLS (Transport Layer Security), to secure the connection between your email client and your email server. With SSL enabled, not only are your username and password encrypted on their way to the server, but so are the contents of your incoming and outgoing messages. In this way, SSL prevents eavesdropping on email traveling between your computer or mobile device and your email server, even if you connect to the Internet via an unencrypted Wi-Fi connection.

If you check your email in a Web browser rather than a stand-alone email client, SSL still applies—you’ll know you’re using it if the URL starts with https: instead of http:, or if your browser displays a lock icon—usually in or near the address bar. If it doesn’t, consult your webmail provider’s documentation to see how you can enable that feature.

Now, I must be clear about the limits of SSL. It protects messages only while they’re in transit between your local device and your email provider (going in either direction). SSL does not mean that email messages are stored in an encrypted form on your device, at your email provider, or on the recipient’s device. And, crucially, SSL is only rarely used for email servers talking to each other. So, even if I use an SSL connection to send a message from my computer to my email server and the recipient of my message does the same thing, my message will most likely travel in unencrypted cleartext from my email server to the recipient’s email server, and it could be intercepted as it moves along that path.

In addition, a flaw in SSL’s design or a bug in an SSL implementation could open the door to hackers—Apple’s SSL bug being one recent example, as I mentioned in the sidebar SSL Implementation Bugs.

Even so, SSL is an incredibly good idea, and if I ruled the world, it would be used by default on all email clients and servers. Even though I don’t (yet) rule the world, SSL adoption has been increasing rapidly, and it’s a default setting more often than not. But sometimes you have to turn it on manually, and in a few unfortunate cases, email providers—notably, certain large ISPs—don’t even offer it as an option.

Enabling SSL/TLS is usually a matter of selecting a checkbox in your email program, which in all probability will be in the same place as your username, password, and authentication setting (refer back to Figure 15, earlier in this chapter).

As with secure authentication, you must enable SSL separately for incoming and outgoing email, for each of your email accounts on each device. If you enable it and your email stops working, your email provider might not support SSL (shame on them), but check with your provider’s tech support to find out one way or the other. If your provider says SSL isn’t available at all, you might consider looking for a new provider that does offer SSL.

And, as a reminder, if you have SSL enabled, your username and password are automatically encrypted along with all other data on that connection, so you can use authentication methods that would send your password in the clear were you not using SSL.

IMAP vs. POP Privacy Implications

IMAP and POP are the two most common protocols for delivering incoming mail from servers to clients. I’ve long been an advocate of IMAP, which typically keeps the master copy of each received, sent, and filed message on the server but synchronizes these messages with each of your local clients. Compared to POP, which usually deletes messages from the server after you download them, IMAP makes it much easier to use more than one device for email. (For more on POP and IMAP, including common misunderstandings about IMAP, see my article FlippedBITS: IMAP Misconceptions.)

An IMAP privacy concern is that if your password were compromised, someone could see all your email messages, not just a handful of recent messages in a POP account. A combination of an excellent password and (if available) two-factor authentication (see the sidebar About Two-Factor Authentication) reduces the threat considerably.

I’ve also heard people say they prefer POP for privacy on the theory that the less time messages are stored on the server, the lower the risk that an unauthorized person might read them there. However, I am skeptical that downloading messages from a POP server and deleting them on the server provides significantly better privacy. If, for example, a government agency had a black box in your email provider’s data center capturing all email, it would catch incoming POP messages before they were deleted. And, even though POP messages may be deleted from a server after they’re downloaded, they could be backed up or cached without your knowledge. If you think of POP as a magic bullet to circumvent snooping, think again.

Meanwhile, it’s often possible to change the settings in an email client that’s using IMAP so that only some messages (such as those in your Inbox) are automatically synchronized. And that, in turn, could increase your privacy if someone gets access to your device, because the messages wouldn’t be sitting there waiting to be read. (You would, however, want to change your password in the event of loss or theft to prevent someone else from connecting to your IMAP account and downloading more messages.)

Email Your Doctor, Accountant, or Lawyer Privately

Members of certain professions, such as doctors, accountants, and lawyers, regularly discuss highly personal and sensitive topics with their clients. Given everything I’ve said about the privacy risks of email, you may be wondering whether you can communicate safely with such people by email. The short answer is maybe.

Privacy laws have led to the widespread adoption of secure Web portals for communicating with doctors and some financial institutions. The way these work is that both you and the person on the other end connect to a secure Web site with a username and password, and all email remains solely on that site—it works very much like any other webmail service, except that all messages are stored encrypted on the server, and are not accessible via POP or IMAP (or to Gmail, Outlook.com, or other email services).

In some cases, a secure Web portal may send you a conventional email message to let you know a secure message is waiting on the server, and that you should log in to read it. That may seem awkward, but there’s a good reason for it: sending the message directly to you outside the secure system may be not only risky but also illegal.

Confusingly, the rules and policies governing secure email vary by country and profession, and they’re always changing. When I lived in France, I regularly exchanged ordinary email messages with my doctor, but my bank pushed me to use a Web portal. Here in the United States, my doctor will only use a Web portal, but my banker sometimes sends me conventional email.

If you want to send confidential email to a doctor, accountant, or lawyer, ask if she has access to a secure Web portal or a comparably secure method of communication. If not, a phone call might be a better choice. And, if you’re a professional in one of these sensitive occupations and don’t use a Web portal to communicate with clients, I strongly recommend reviewing the relevant laws and professional conduct standards for your area to determine your best course of action. Be careful sending confidential information over ordinary email—you could be exposing yourself or others to legal liability.

Encrypt Your Email

Even if you use SSL with all your email accounts, you’ve seen that messages are unencrypted while they sit on various email servers, and often for their journey from one server to another. The only way to be sure they’re private from end to end is for you as the sender to encrypt them, and for the recipient to decrypt them.

Encryption, like SSL, is a great idea, and in an ideal world, perhaps all messages would be encrypted all the time. In a moment I’ll mention a few ways you can go about encrypting messages if you choose to. But first, let me try to talk you out of it. That’s right: I think encrypting email is a less-than-optimal solution for most people, most of the time. Here’s why:

· Once the recipient has decrypted your email message, anything could happen to it, and it’s entirely out of your control. A message may stay private all the way to Mr. X, but if he’s not careful (or if his computer or phone is stolen or hacked), your message could still get out.

· Configuring an email client to encrypt messages can be (depending on the platform and software) a cumbersome process. Once you’ve done that, encrypting individual messages is usually simple, but requires that your recipients use the same type of encryption, and set up everything correctly on the other end. Even then, in some cases you must go through extra steps to obtain a public key or certificate from the other person before you can send secure email; in other cases, both parties must find some way other than email to swap passwords. You wouldn’t want to go through this bother for every message you send.

· Although encryption protects the contents of your messages, it doesn’t protect their headers, which means that someone with access to your encrypted email while in transit or on a server could still see the message subject, sender and recipient’s email addresses, date and time, and other information that may itself be private.

· As things currently stand in the United States, the NSA can retain indefinitely any encrypted email messages it happens upon, presumably to help the agency learn how to break that encryption. Unfortunately, the very fact that you encrypt messages—regardless of their content—may mark you as a suspicious person subject to more in-depth monitoring. Encrypting email messages not only draws attention to yourself but could mean that any messages that are intercepted will be kept until the NSA can figure out what they say or decides it’s not worth knowing.

Those qualifications aside, if you still want to go for it, there are three main techniques you might use:

· S/MIME: Almost all modern email clients, including Apple Mail on Mac OS X and iOS, Outlook, and Thunderbird, support an industry standard called S/MIME (Secure/Multipurpose Internet Mail Extensions). S/MIME uses a form of public-key cryptography: you give me a public key (in the form of a file called a certificate) that I use to encrypt a message I send you, and then only you can decrypt it with your corresponding private key. To reply to me, you reverse the process, encrypting a message with my public key; I decrypt it with my corresponding private key.

Before you can use S/MIME, you must obtain the necessary certificates and install them on your device; it’s a tedious and non-obvious process. (I describe how to do this in Apple Mail—for both OS X and iOS—in Take Control of Apple Mail.) Your correspondents must also use S/MIME, and you’ll need their public certificates to send them encrypted messages.

· PGP/GnuPG: The commercial PGP (Pretty Good Privacy), owned by Symantec, and the compatible, open-source GnuPG (Gnu Privacy Guard, also known as GPG) represent another flavor of public-key cryptography. Conceptually, PGP/GnuPG is roughly comparable to S/MIME (in fact, newer versions of GnuPG also support S/MIME), although the implementation is different.

You’ll typically need to install extra software on your device to use PGP or GnuPG, and it may not be available for your favorite platform or version. However, the process of obtaining public/private key pairs is simpler than with S/MIME, and both systems optionally use keyservers, which let you obtain someone else’s public key by looking up a name or email address rather than having to contact that person first. Although it’s rare for webmail services to offer encryption, Hushmail does support PGP.

· Encrypted attachments: A somewhat simpler, lower-tech approach is to send an ordinary email message containing an attachment that’s encrypted; inside the attachment is the private content you want to transmit. A popular tool to do this is WinZip—despite the name, it’s available not only for Windows but also for Mac OS X and iOS. If you and the recipient are both Mac users, you can also use Disk Utility to create an encrypted disk image.

In any case, this approach is great for one-shot communications, such as when you need to send someone a Social Security number, credit card number, or some other isolated piece of sensitive information but don’t need whole email messages to be encrypted regularly. However, there’s just one problem, which is that the recipient needs the password, and you can’t send that by email! The sidebar ahead discusses what to do.

Transferring Passwords Out of Band

When you need to send someone information using a different communication method than the one used for the main content of the message, that’s called out-of-band communication. Even if the out-of-band channel isn’t secure, the fact that you’re conveying the password by a different means than the message itself reduces the likelihood that the same person will intercept both pieces of data.

For example, say you’ve sent me an encrypted file and you need to tell me the password. How might you do that? Here are some ideas:

· In person. The best and most reliable method, if practical, is to tell me the password face to face.

· By phone. Phone calls can be tapped or overhead, but it’s harder to do and may be trickier legally than eavesdropping on email.

· By chat or private message. Exchange the password with an encrypted text or voice messaging system such as Skype or Apple’s iMessage. The former is known to have a government back door while the latter is currently believed to be highly secure. As with all electronic communications, there are no guarantees, but they’re safer than email.

· Via shared knowledge. If you know the recipient well, you may be able to construct a story that implies the password without spelling it out. For example, “The comment that girl next to you at the concert made about your shirt, plus your sister’s age when we first met.”

Send and Receive Email Anonymously

In rare cases, email privacy requires anonymity; revealing your name, your real email address, your IP address, or other personal facts could get you in trouble. I’m thinking, for example, of a confidential source contacting a reporter, an informant telling the police about suspected illegal activities, or someone making politically hazardous statements. In such situations, you may need to disguise the source of the message in such a way that it can’t easily be traced back to you specifically.

Numerous services exist for just such a purpose. A quick Web search turns up options that let you send anonymous email with a simple Web form (such as SendAnonymousEmail) as well as services that let you set up an account that provides disposable return addresses (such as Anonymous Speech). With some research you’re bound to find many others, including one that suits your particular needs.

However, as usual, I must caution you to read the fine print. Some of these sites log your IP address or other details in such a way that messages could be traced back to you if necessary, and no matter how secure a site claims to be, vulnerabilities could exist that might expose you. And be aware that textual analysis could provide clues to your identity based on word usage and writing habits. Tread carefully if you feel you must use such a service.

Use Email Alternatives

Regardless of encryption or anonymity, you may encounter situations in which email doesn’t make sense as a means of communication. In particular, if you’re worried about something you write being found on someone else’s computer in the future, email is not a good choice.

In the sidebar Transferring Passwords Out of Band, I mentioned several ways you might send someone the password for an encrypted file; all the same methods can be used as alternatives to email if you have something to say that you simply can’t take any chances with. And I go into more detail about one such category in the next chapter, Talk and Chat Privately.

Another option I should mention is the self-destructing digital message. Although these take various forms, the general idea is that you send someone a link to a message on a Web site, or using a mobile app—and once viewed, that message is visible for only seconds or minutes, after which time it’s permanently deleted. Although such systems aren’t foolproof—the recipient might, for example, take a screenshot of the secret message before it self-destructs, or use file recovery software to undelete it after the fact—they do reduce the risk that a private message will later be discovered on someone else’s device, at least by technically unskilled people.

I found many such services and apps on the Web, although I haven’t tried them personally, so I can’t speak to how effective, secure, or easy to use they may be. A few examples:

· DestructingMessage.com

· Self-Destructing-Email

· Snapchat

· This Message Will Self-Destruct