The War on Sloth Begins

I think I had a pretty successful first week in the War on Sloth–despite having a particularly rough week at work (60 hours!) I managed to get in some music, a bit of drawing, and a personal coding project that I think is rather nifty. As I said, I’m going to be scatter-shot for a while as I figure it all out. If things at work calm down, maybe I’ll keep it diverse and start doing a post per pursuit, but for now each one is relatively small.

For music, I sat down at the piano long enough to learn the introduction to Ben Folds’ “Still Fighting It”. It will take a bit more time to commit the whole song to memory, but the song is fairly simple, short, and calm–which is a good recipe for a song I can pick up fast and feel good about playing for others. Didn’t spend any appreciable time on the guitar, but this is a good start.

I also spent a bit of time playing with Inkscape and drew a new pig. Here’s the old one for comparison:

The Old Pig

Phlox, the Phlying Pig

And here’s the new one:

The New Pig

Phlox, the Phlying Pig

I still like the old one better (it’s just a better drawing to start), but I like the new one’s open eyes and more comic-like lines. I need a sharper version of Phlox for an icon anyway, for upcoming projects.

This is the biggest thing I’ve started: I’m making a Palm webOS app. There’s a few of them that I have in mind, so my plan is to start with a very simple app and work my way up to more awesome ones after I get the gist of how webOS development really works. So I pulled down the Palm SDK and started tinkering. So far, I’ve got very little that I want to show off, but I’ve learned a lot! So we’ll see what I can come up with for next week.

Until then, what’s your free time like?
Adrian

Back to the Blog

Well, hello!

It has been a long time. Nearly half a year, if I recall correctly. Allow me to reacquaint myself: I’m Adrian Sud; on the internet, I also go by Pigsflew. In the past I’ve described myself as a writer, a hobby guitarist, a gadget tinkerer, a software developer, and a general intellectual—if not all that geeky about any one particular thing. Lately, I can really only count myself in one of those categories: a software developer, I remain.

I’m a developer by trade; as with many in my field, I’m prone to long work hours, caffeine addiction, and forgetting even to put socks on in the morning, let alone take the time to practice on my guitar or put a pen to paper. But recently, I read an article which is stuck in my head: “You Are What You Eat” by Trent Walton. The concept is that, whatever you want to be, just start doing it. The rest will follow.

The simple fact is, I love being a developer, but what brought me to the field is the tinkering, the new technologies, the amazing sense that no matter how long you’re at it, there is so much more to learn—but to take advantage of that, I have to learn on my own time, too. Beyond tech, I’ve always thought of myself as a versatile person, with about as much potential in creative endeavors as logical ones. If I don’t exercise other parts of my head, switch to another mode and put some energy into it, I will—and do— find that potential greatly diminished.

So to that end, I’m coming back to my hobbies. I’m going to devote a bit of time to this blog and LiveJournal, hopefully about one hour a week, to talk about what I’m doing in my free time, and to make sure that whatever it is, I am doing *something*.

For a while, it’ll be fairly directionless. I’ve got about five ideas for things I want to do in my head. All of them will be difficult, but at least two of them I think I could really do well, if I give it a shot. So look for a post in a couple of days, talking about what I’ve started.

Now, will it be technical or creative? Who knows. Perhaps both!

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.