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