Pigsflew.com Realization of a Dream

How to fix Email

Recently some work I've been doing required me to send a little personal information along to a client. The personal information was of a delicate nature, and when I found out I was expected to send it by email, I was confounded, and finally convinced them to let me send it to them via courier instead.

People seem to assume that Email is like regular mail only faster, and since it's a federal crime to tamper with postal mail, email communications must be covered the same way, and that the two are equivalently private. The problem is that a government employee (or several) are the ones that physically carry your snail mail from where you dropped it off to its final destination. Therefore the government has some ability to enforce that sanctity of mail--the postal workers are traceable sources of tampering, who can be fired or even legally punished for any evil they do. From there, the only thing you have to worry about is delivery mishap, and non-USPS hands at those weak points, before and after transit, where it might fall into them. These are relatively uncommon, and again, the fact that tampering with mail is a federal crime protects you in almost all cases.

But E-mail isn't carried by someone who has a stake in your privacy. The E-mail, as soon as it leaves your computer, is going to pass through dozens of other computers, some controlled by Comcast or Verizon, some controlled by Sprint or Level 3 Communications, some controlled by other companies you might not even have heard of. The fact is that these companies can easily monitor plaintext emails passing through. Even if you trust these companies, it is always a possibility that one of the servers happens to be compromised from without.

This is where a basic lesson comes in: don't send personal information by email. It is trivially easy to scan for certain things like phone numbers, Social Security numbers, credit card numbers, drivers license numbers, license plate numbers, just about anything else you might not want people to know. If you're sending these things to anyone via an unencrypted digital channel like email, it is very possible that it could be intercepted, identified, and later used for nefarious purposes.

Notice where I said "an unencrypted digital channel like email". That's the key thing. You see, it's safe (or at least much more safe) to enter things like that on an encrypted website, such as https://www.bankofamerica.com--because you trust Bank of America, and because the site has that handy "https" instead of "http", you know that there will be no computer between you and the Bank itself that ever sees your information in cleartext. Instead it sees something encrypted in such a way that it is virtually unbreakable--so that only you and the Bank see anything you type into that website.

So how do we fix it?

Effectively, there are two things you want to know about a message: #1, that it's from who it says its from. #2, that it remained unread until it got to you. This is why I propose that SMTP and IMAP mail servers all include a PKI server.

Here's how it works.

Example Smith (esmith@local.com) wants to send a message to Instance Jones (ijones@foreign.com). Example types up an email and sends it to his mailserver over an https connection, because he knows that he has to be careful about these things.

On a current smtp server, what happens now is that the mail is decrypted at smtp.local.com, and sent to the Instance's mailserver (mail.foreign.com) in plaintext, where Instance is free to access it through her client however or whenever she chooses.

Here's what should happen.

Example Smith sends the message via an encrypted connection to smtp.local.com.

smtp.local.com sends a message to mail.foreign.com asking for the public key of ijones@foreign.com. smtp.local.com then encrypts its message with Instance's public key, and signs it with its own private key for esmith@local.com.

When it gets to the other end, mail.foreign.com is able to decrypt the message using Instance's private key.

When Instance downloads the message (over https of course!) from her mailserver, she can now feel safe that Example's message was kept free from prying eyes during transmission. Her mail server can also decrypt the signature and read it using Example's public key by fetching it using the email in the "from:" email address. If mail.local.com sends back a key that successfully decrypts the signature, then she knows that Example's mail server certifies that the message was sent from Example's email account, through Example's outgoing SMTP server.

This would mean that nobody could send messages on some fake mailserver with the From: address of "someone@pigsflew.com"--because your email reader would be able to contact pigsflew.com on its mail port, find out that it signs its messages, and that it cannot verify that particular email's signature (if it even has one). And it means that the message is almost guaranteed to be safe from prying eyes, at least until it has been received by the receiving mailserver. And it has the added plus of being effectively transparent to the end users--they still send and receive messages on the web or through their email clients in exactly the same way.

Basically, if this feature was implemented, it would take only until Gmail, MSN, and Yahoo started using it, and then a good chunk of email would be safer, and the rest could be flagged as being unverifiable, unprotected, or both. If you had an email client supporting the extensions, you could set your send messages to require or prefer protection, in the preferential case having your SMTP server warn the client that the email will be unencrypted for transit if the recieving mail server doesn't support it. Assuming that you trust your mailserver administrator, the server administrator for the person you're sending the message to, the company that runs their e-mail, and the receiver him- or herself to treat your information with care, you could now effectively rest easy, although Social Security numbers and the like would still give me pause.

The major advantage is that you'd be able to make a more informed decision about whether you trust the information to this medium--since no hands should be able to touch the information.

It'd also be cool if your entire mailbox on your mailserver was encrypted with the user public key and the user's password, decrypted at user access time with their password and that user's private key. Then it'd be safe sitting at endpoints too.

Telemarketers

A lady just called me on my work phone asking if I was an engineer or an IT person. "I'm an engineer," I said, thinking perhaps it was someone else in Newton looking to contact IT. She then asked if I could give her the number of one of the heads of IT.

I said, "I really can't give out that information, but you can send a message to their email address--they're extremely quick at getting back to people." I gave her the aforementioned address.

She responded callously: "Well, I spoke to"--and proceeded to name mispronunciations of several of my more senior coworkers--" and Raja, who I actually met in person recently"--here she probably meant a coworker of mine named Raju--" so my contacts are all in engineering, but can you cut me a break here and direct me to someone in IT?"

When I again declined to give her any specific information of my coworkers, she asked, "Your office is--the Boston office, you're in, what, Needham, right?"

And here I had the overwhelming temptation to say something I did not say, but am convinced would have been the right thing:

"Ma'am, I'm sorry, I have to stop you right there. You're not very good at this--I know, I know, cold calling is hard--but it sounds like you just incorrectly read off everyone listed on my LinkedIn profile. You should take a little time to try to pronounce names--like Raju. That's an Indian name, and means something completely different from the word 'Raja', which means 'King', and was incedentally the name of the tiger from Disney's Alladin. You should also sound confident in more details, like the name of my company, the location of my office, et cetera. I'm not going to ask you who you're calling for; I can't do anything for you anyway, but you should convince yourself before you call that my company needs what you're selling. Give it another try with someone else on LinkedIn, I'm sure you'll do great. Have a nice day, ma'am."

Instead I was more direct, and simply told her I couldn't give out any information further than the address I'd already given her.

One day I am going to be an old man who shouts inanities at telemarketers.

I look forward to that day with great relish.

Ruby URL Get/Set Field methods

I was writing a quick script and needed to modify a url quickly to change the fields on a url.

def url_get_field ( url, field )
  m=/.*[&?]#{field}=(.+?)(&.*)/.match(url)
  n=/.*[&?]#{field}=(.+)/.match(url)
  if !m.nil?
    return m[1]
  elsif !n.nil?
    return n[1]
  else
    return ""
  end
end

def url_set_field ( url, field, value )
  m=/(.*[&?]#{field}=)(.+?)(&.*)/.match(url)
  n=/(.*[&?]#{field}=)(.+)/.match(url)
  if !m.nil?
    url = m[1] + value + m[3]
  elsif !n.nil?
    url = n[1] + value
  else
    unless /.+[?&].+?=.+/.match(url).nil?
      url = url + '&'
    else
      url = url + '?'
    end
    url = url + field + "=" + value
  end
  url
end

def url_remove_field ( url, field )
  m=/(.*)([&?])(#{field}=(.+?))(&(.*))/.match(url)
  n=/(.*)([&?])(#{field}=(.+))/.match(url)
  unless m.nil?
    url = m[1] + m[2] + m[6]
  else
    url = n[1] unless n.nil?
  end
  url
end

Now it's easy enough to do! check this out:

irb(main):160:0> url = 'http://pigsflew.com'
=> "http://pigsflew.com"
irb(main):161:0> url = url_set_field( url, 'test', 'omg' )
=> "http://pigsflew.com?test=omg"
irb(main):162:0> url = url_set_field( url, 'archives', '526')
=> "http://pigsflew.com?test=omg&archives=526"
irb(main):163:0> url_get_field( url, 'test' )
=> "omg"
irb(main):164:0> url_remove_field( url, 'test' )
=> "http://pigsflew.com?archives=526"
irb(main):165:0>