1---
  2layout: post
  3title: Email & privacy/security concerns
  4date: 2020-03-21 01:46 -0400
  5draft: true
  6---
  7
  8## Plaintext email
  9
 10Email is inerently insecure. By default, everything is sent in plaintext from
 11one server to the next with no encryption whatsoever. Servers can encrypt mail
 12in-transit by implementing SSL and TLS but that still leaves copies of your data
 13in plaintext on both servers. For example, see [this email I sent to
 14myself](https://bin.nixnet.services/?f76b8366e6b7a7b0#95skPFhsptkfyMH3i1n25ENZeUzrmYEUHzDVezaToGn).
 15At the very bottom, the content of my email is shown in the file for anyone with
 16access to the server to see. At first glance, this may not seem like such a huge
 17deal. It does, however, become a big deal when you're conducting private
 18business over email. If I so chose, I could go to that directory and read
 19everything you're saying and there's nothing you could do about it. Any mail
 20provider has this capability: Gmail, Yahoo! Mail, Fastmail, the list goes on.
 21Unless special measures are taken to encrypt your emails _at rest_, this holds
 22true in every single case.
 23
 24## Encrypted email
 25
 26Providers like [Protonmail](https://protonmail.com) and
 27[Tutanota](https://www.tutanota.com/) do exactly this and that is their main
 28draw. Mail to and from other users of the same platform (Protonmail ->
 29Protonmail, Tutanota -> Tutanota) is encrypted from end-to-end as well as at
 30rest so the only parties that can read it are the sender and the receiver; the
 31provider itself can't access them. However, the benefit of at-rest encryption
 32becomes absolutely meaningless the _second_ you communicate with someone on a
 33server that _doesn't_ implement it. Protonmail -> Gmail is 100% insecure and
 34Google is free to perform whatever text analysis and user profiling they wish.
 35NixNet Mail will implement at-rest encryption in the near future but, even then,
 36there is no way to verify that that's _actually_ the case unless I gave everyone
 37root access to my server at all times (security and compliance **_nightmare_**).
 38The only viable solution is to take your privacy into your own hands and encrypt
 39emails yourself.
 40
 41## GPG encryption
 42
 43"GPG" stands for "GNU Privacy Guard" and is a libre implementation of "PGP" or
 44"Pretty Good Privacy", originally created by [Phil
 45Zimmerman](https://en.wikipedia.org/wiki/Phil_Zimmermann). PGP was eventually
 46bought by Symantec and became Symantec Encryption Desktop and GPG quickly became
 47the most widely used implementation of [OpenPGP
 48standards](https://tools.ietf.org/html/rfc4880). GPG integration is especially
 49common in open source email clients such as
 50[Thunderbird](https://www.thunderbird.net/) and
 51[Evolution](https://wiki.gnome.org/Apps/Evolution). It relies on [public-key
 52cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography) and allows
 53users to encrypt their emails with another user's public key. The email would
 54then be *de*crypted using the receiver's _private_ key. Take a look at this
 55[encrypted email I sent to
 56myself](https://bin.nixnet.services/?70f0ac93b8df9416#Fske8BYAVdoYzD76VgBb5AimRqm2yY8HgnpdcAzUwuD7).
 57As admin of the server, that is literally all I can see. The text between `BEGIN
 58PGP MESSAGE` and `END PGP MESSAGE` is the email body and it just looks like a
 59block of random characters to me. To the person receiving the message, however,
 60after decryption, they'll be able to read it just like the plaintext one linked
 61in the first section.
 62
 63If you want to learn more about GPG encryption and protecting your privacy when
 64using email, I recommend reading through [Email
 65Self-Defense](https://emailselfdefense.fsf.org/en/), a fantastic resource from
 66the Free Software Foundation.
 67
 68**_NOTE:_** Encrypting an email _does not_ encrypt the metadata. When you sign
 69up for a new email service, send one to yourself and inspect the headers to see
 70if they obfuscate identifying details.
 71
 72## Metadata
 73
 74Another thing to keep in mind with emails is metadata in the headers of the
 75emails. In Roundcube, you can view these by clicking `More` then `View source`.
 76In Thunderbird, just press `CTRL` + `U`.For other clients and web UIs, you'll
 77just have to look around for options to show headers, view source, download,
 78something like that. You can also take a look at the [email I sent
 79myself](https://bin.nixnet.services/?f76b8366e6b7a7b0#95skPFhsptkfyMH3i1n25ENZeUzrmYEUHzDVezaToGn).
 80
 81I'll break down some of the lines and explain what they are. Some of it is
 82irrelevant to this and will be skipped though.
 83
 84`Return-Path: <amolith@nixnet.xyz> ` 👉 Address your reply will go to
 85
 86`Delivered-To: amolith@nixnet.email ` 👉 Address the email was sent to
 87
 88`To: Amolith <amolith@nixnet.email> ` 👉 The _displayed_ receiver
 89
 90`From: Amolith <amolith@nixnet.xyz> ` 👉 The _displayed_ sender
 91
 92`Subject: Email demonstration ` 👉 Subject of the email
 93
 94`Date: Sat, 23 Nov 2019 00:20:46 -0500 ` 👉 Timestamp at which the email was
 95sent. This does include the timezone and can be used to identify you
 96
 97`User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 98Thunderbird/68.2.2 ` 👉 Full user-agent the email application includes with the
 99email. In this case, it consists of the organisation, my display server, my
100operating system and architecture, the HTML rendering engine, and the email
101client and version. This can _really_ be used to identify you.
102
103The rest of it is server-side stuff that doesn't matter too much for _this_
104document but will likely be discussed elsewhere in the future. Together, all of
105this metadata can be used to identify people in a conversation. Timezone (vague
106location), OS, email application, correspondents, and client version. That last
107component could actually be useful for determining whether or not the client is
108susceptible to certain malware attacks