Privacy and the Presumption of Innocence

There are many arguments that can be made arguing for the right to privacy of digital communications.  One I find particularly compelling is the tying of privacy rights to the presumption of innocence.

As it relates to digital privacy, we might say that the presumption of innocence implies that the government cannot collect or monitor digital communication without compelling reason to believe that the target is guilty of a crime.  In practice this would mean that law enforcement has taken charges to the court and that warrants have been made with respect to suspicion of guilt.

One clear example in the U.S. of the violation of these basic rights is the so-called FISA Amendments Act of 2008 which retroactively made legal the warrentless wiretapping of U.S. citizens done during the Bush administration, and has seen continued support to date from the U.S. Congress and the Obama administration.

Privacy and the "Nothing to Hide" Argument

Daniel J. Solove, author of The Digital Person, some time ago published an excellent article on privacy and the fallacy of the "nothing to hide" argument.  Here is an excerpt:

Commentators often attempt to refute the nothing-to-hide argument by pointing to things people want to hide. But the problem with the nothing-to-hide argument is the underlying assumption that privacy is about hiding bad things. By accepting this assumption, we concede far too much ground and invite an unproductive discussion about information that people would very likely want to hide. As the computer-security specialist Schneier aptly notes, the nothing-to-hide argument stems from a faulty "premise that privacy is about hiding a wrong." Surveillance, for example, can inhibit such lawful activities as free speech, free association, and other First Amendment rights essential for democracy.

The deeper problem with the nothing-to-hide argument is that it myopically views privacy as a form of secrecy. In contrast, understanding privacy as a plurality of related issues demonstrates that the disclosure of bad things is just one among many difficulties caused by government security measures. To return to my discussion of literary metaphors, the problems are not just Orwellian but Kafkaesque. Government information-gathering programs are problematic even if no information that people want to hide is uncovered. In The Trial, the problem is not inhibited behavior but rather a suffocating powerlessness and vulnerability created by the court system's use of personal data and its denial to the protagonist of any knowledge of or participation in the process. The harms are bureaucratic ones—indifference, error, abuse, frustration, and lack of transparency and accountability.

Encrypting Email

There are two (interoperable) standards for encrypting email, OpenPGP and S/MIME.  In what follows, I will walk through the process for OpenPGP.

Step 1.  Install OpenPGP software tools.

Although many implementations exist, one good option is using the Gnu Privacy Guard (or GnuPG) implementation.  This software will allow you to create credentials, manage their distribution, and encrypt documents.  Binaries are provided for Windows and Mac OS X.  Binaries for various Linux flavors are typically provided through the associated distribution.

Step 2.  Create credentials.

Users participating in encrypted email identify themselves via their public key.  The public key is encoded into a "certificate".  The tools installed in step 1 can be used to create these credentials.  For example, if you are using GnuPG on Windows (that is, Gpg4win), you can:

  a. launch the Kleopatra tool
  b. go to File -> New Certificate
  c. select "Create an personal OpenPGP key pair"
  d. enter your full name and email address associated with this certificate
  e. enter a strong passphrase

A few notes on this process.  You should create one and only one public key for each email address you will be using for secure communication.  The process will create both a private and a public key.  The private key should be kept in a secure location.  It does need to reside on the machine that will be used to encrypt or read secure email, but otherwise should not be copied unnecessarily to other machines.  It should however be backed up in a secure location, for example a USB flash drive or equivalent.

Step 3.  Publish public key to public key server.

Your public key should be posted to a public PGP key server.  See for example the open director project for a list of key servers.  For example, I have uploaded my key to the MIT PGP Key Server.  You can find my various keys by searching for "hotes".

Step 4.  Install a plugin for your email client.

OK, this can be trickier.  Here are a few options:

  - Outlook Privacy Plugin (Outlook 2010, free, on Google Code)
  - GpgOL GnuPG Outlook Extension (Outlook 2003+, free)
  - Symantec PGP Desktop Home (Outlook 2003+, $99 for 1 yr. license)
  - The EnigMail Project (Thunderbird, free)

Also see this list of plugins.

If you are using web-based email (like Hotmail or GMail), OpenPGP extensions have been made for Firefox and Chrome, but I don't know how well they have been supported.  For example, the once popular FireGPG Firefox extension providing PGP support for GMail is now defunct.  Your best option here is to use POP/IMAP and a native email client.