How Your Private Emails Can Be Used Against You in Court | Hacker News Reader

How Your Private Emails Can Be Used Against You in Court

theatlantic.com

22 pointsJamesLowell15 comments

I have no illegal or incriminating emails. So I'm not worried about that. What bothers me is that overly broad requests would see all sorts of my personal life unrelated to the request. What pizza I ask my wife to order, private jokes I may share with my close friends, and things like that. Stuff that is my (and my family's) personal life.

None of that content is illegal or even unethical, but it's my personal data and I'm concerned that others will be looking over it or causing it to be some kind of public record because they are too lazy to filter out the unrelated stuff and just want to enter all of it as exhibit A.

I expect (hope) that strong laws will be introduced soon to address these issues. We're all in the same boat with cloud data and big corps being the gatekeepers.

You don't get to decide what's illegal or incriminating, the court and justice system do. Just because you don't think it's incriminating doesn't mean it can't be used against you.

It would be great if more email clients had encryption built in, and encrypted emails to people with known public keys.

Barring that, perhaps something like a peer to peer network where messages are automatically encrypted and addressed to a public key could work. Those emails could then float around the p2p network until a client with that public key joined, and downloaded that message, decrypting it with their private key obviously.

Unfortunately, most people don't care enough about encryption to put in effort using it.

I'd love it if when people sent me unencrypted email, their mail server noticed that I have a published PGP key, and encrypted the email with it before passing it on.

EDIT: Also, as for your P2P idea, IIRC there are Usenet groups where people post PGP encrypted messages for the intended recipient to pick up.

> more email clients had encryption built in

I believe every single relatively popular client supports S/MIME out of box, and a lot of them support PGP/GPG.

Most casual users just don't know/care enough about their privacy up to the moment it is severely violated..

You are probably right regarding email clients, I haven't actually used one since I switched to Gmail and Google Apps. I do count services like Gmail as email clients though, but I don't think any of them have S/MIME or PGP/GPG support out the box.

Last time I tried sending a GPG encrypted email through Gmail on windows, there was no simple way of doing it.

Such support would require either client-side browser extension to do the crypto or giving your private key to webmail provider.

I doubt there are a lot of people that would want to encrypt their messages, but still trust someone other with their keys.

It's not really private if you are using a freemail service like Google or Yahoo.

I am more interested in the law, for those who run their own SMTP and IMAP servers.

IANAL.

If you run your own mail server, then they would serve the subpoena to you, and you would have the opportunity to contest it. The subpoena assumptions - that those holding the data have an interest in it - hold, and the system works as it's supposed to.

Now, I don't know if they can issue blanket subpoenas to Google to request e-mails you have sent to Google customers. Certainly, they could for specific Google users, but it'd be interesting to know if they can issue open-ended ones in hopes you sent something incriminating to someone using GMail.

I would also like to know how VM hosting providers like Rackspace, Amazon, and prgmr.com fit in to this. They provide hosting and storage, but do so opaquely without knowledge of what I've stored or how I have done so. Can they serve a subpoena against prgmr.com to rifle through my disk image looking for mail, or would they serve it against me as the manager of the mail server?

If the mail server which stores your email is doing this:

https://grepular.com/Automatically_Encrypting_all_Incoming_E...

Then the person running the mail server couldn't hand over your email even if they wanted to.

Holy moly, that is awesome! I'm going to look into this.

EDIT: Oh, this is so cool - a true UNIX utility, it just reads from STDIN. I don't even need to play with my sendmail config. I can integrate it with my .procmailrc. This is fantastic!

EDIT 2: Overall - it's a very cool idea. I love playing with procmail stuff, but from a security point of view it's encryption after the fact. Most e-mail is transported in the clear. I'll probably use it as part of a cron job to move stuff from my inbox into an archive.

Yeah, there's a guy in the comments who has apparently had it working with procmail. He provided an example procmail recipe.

Regarding your second edit. It doesn't provide end to end encryption, which is what people immediately think of when PGP encryption of email is discussed. End to end encryption is still the best possible option, but it requires both parties to be involved. What it does provide however is the next best thing, for people who receive non-encrypted email.

It protects your mail content even if your IMAP account details are compromised. It protects your mail if the mail server is compromised, and it protects your mail if one of your mail clients is taken.

In theory Amazon cannot access your AWS instances. Everything is encrypted - communications, the virtual disk itself. How well this holds up in practice, I don't know, because the only key they don't have saved for you on their websites (in case you should lose it of course) is your SSH private key.

I claim it's not private even if you run your own mail servers, unless you encrypt it. If you send plain-text emails, they're going to bounce around in plain-text all over the place. Email is not a private medium - unless you encrypt them, which very few people do.

Reply on news.ycombinator.com