Preamble: Today was my last day at FSC Internet but I started writing the piece below some time ago. It still needs some work, so it’ll probably get a few more edits as time goes along, but I wanted to post it up here to mark the day I left the field of Internet security. 🙂

Ever since I started working for an Internet security company, I’ve been using PGP (GnuPG) a lot more both in my daily work, and at home. Even though PGP has been around for ages, it hasn’t been widely adopted. Even other secure e-mail technologies like S/MIME have not enjoyed wide acceptance either. I started to ask myself why, and I’ve come up with a number of explanations as to why secure e-mail hasn’t taken off:

• Insufficient size of critical user base. This is the classic technology adoption problem that faced inventions from the cell phone (who are you going to call if nobody else has one) to the VCR (what are you going to play in your VHS VCR if all the movies are still in BetaMax). With PGP, the problem is compounded by the fact that the trust value of your key is affected by the trust value of the keys of the peers that have signed your key; if nobody signs your key, the trust value of it is very low.
• No interoperability between competing secure e-mail technologies. In part, we can blame the invention of proprietary
  and closed technologies like that "Secure E-mail Certificate" widget in Microsoft Outlook. PGP has been around for years; why didn’t they just use that? On the other hand, PGP itself has been through many mutually incompatible revisions; PGP 2.x; Network Associates PGP 5.0, PGP 6.0, and finally, GnuPG as an open-source alternative to PGP proper. Such needless forking does nothing to build the image of secure e-mail technology as reliable and robust.
• Poor GUI frontends to PGP. Before writing this piece I decided to do some investigation as to what frontends were out there, that are still being actively maintained. There certainly aren’t a lot. On this Debian GNU/Linux box I picked out two that appeared worthwhile: gpgp and kgpg. gpgp as I soon discovered was out of date. kgpg core dumped when I tried to retrieve keys from a remote keyserver. Neither of them implements the features that I would want in a front end, namely, easy modification of all parameters of a given key on the keyring, including trust levels, adding and removing signatures, and so on.

Fundamentally, though, these aren’t insurmountable problems. Technical and adoption issues, while irritating, are comparably easy to fix. (Okay, convincing Microsoft to use PGP in Outlook might be more difficult, but even the PGP GUI is a problem waiting to be solved.) It’s my belief that the lack of interest in secure e-mail technologies as a whole is motivated by people’s desire to not only be anonymous on the Internet, but to never be held accountable for anything they say.

Perhaps I’ve been hanging around too many marketing weasels, but there are plenty of folks who don’t want to be held accountable at a later date for some bald statement they made today. I’m sure that the Enron and WorldCom executives wished they hadn’t sent certain e-mails that are now sitting in evidence vaults. Those e-mails would probably carry even more weight (against said executives) if they were digitally signed with the originator’s PGP key.

The lesson to be learned here is one that relates to human nature. Once you have attached a digital signature to something, you can’t take it back. Ever. Particularly if the message is in the public domain, it can come back to haunt you. This is not generally what people want to hear; it makes them feel less secure, not more. This is the critical flaw in secure e-mail technology.

After four months I am leaving FSC Internet to get back into the field of software development. While security is interesting, it, like many things, is only interesting to me if I don’t have to do it full-time.

This doesn’t mean that I’ll stop weighing in on security matters. Heck no. I have a few parting thoughts as I wrap up at FSC.

Today’s Daily Dave is, as usual, pretty entertaining. It’s not quite as cohesive as past entries, since he tries to talk about a whole plethora of topics, eventually winding up at a discussion about how many security companies are being co-opted by developing “partnerships” with the very industries they are supposed to be protecting. In principle, I agree with him: from a 30,000 foot view, it would seem that any security company that’s been hired to assess vulnerabilities in a client’s products would not do anything to embarrass the client.

However, any ethical security company would still disclose security vulnerabilities to the client, and to work with them to deliver a measured advisory and response to the community. Failure to do this means the security company isn’t worth its salt.

In the specific case Dave mentions in his article, there is a glaring remote root exploit in the code for RealNetworks’ streaming media server products. He is claiming that the various security companies that RealNetworks has hired over the years to do vulnerability assessment are accomplices in this massive coverup to hide the security hole.

I don’t particularly buy this point of view. By the principle of Occam’s Razor I believe there is a simpler explanation: the security companies that RealNetworks hired are simply incompetent. In the article Dave says that the hole can be found within 10 seconds of starting up SPIKE (which I’ve mentioned here before in this journal) but there’s nothing to prove that the security firms actually tried to use this tool, or any other tool. For all we know, their "code audits" could have been a complete joke — and not necessarily just because they were working for RealNetworks. Perhaps it was just a quick smash-and-grab for them to assuage the vulture capitalists.

I have one more viewpoint to post on security issues — it’s about PGP/GnuPG and why I think digital signatures/encryption of correspondence isn’t more widely used. I’ll tidy it up and post it on Wednesday, my last day at FSC. After that, I’m on vacation to NYC for a few days before starting my new position as a software developer for the CBC.

Ed Foster pointed out in a recent GripeLog entry that TicketBastard‘s privacy policy is a complete joke. To paraphrase the point of the article: If you have ever bought a ticket from TicketBastard, they have reserved the right to sell all your personal information to their "Partners" and they specifically state in their privacy policy that you may not ever opt-out of receiving spam from their "Partners".

Although we would all love to avoid TicketMaster, unfortunately they have a monopoly in this country — behold, my friends, the American Dream! Anyway, if you can’t find a patch, at least find a workaround: my workaround would be: a) Don’t buy tickets online through Ticketmaster.CA or Ticketmaster.COM; b) Pay cash when you buy Ticketmaster tickets in person at the Ticketmaster outlet; c) Give fake credentials if the ticket clerk asks you for them (although I can’t see why they would).

I’m aware that this behaviour would probably tip off the authorities in the police state we call the U.S.A., since it probably matches some kind of Terrorist Profile generated by the Abteilung der Faterland-Sicherheit. If that isn’t ironic…

If you get the Daily Dave newsletter run by Dave Aitel over at Immunity, Inc. you’ll already have seen this. In a recent message he pointed listmembers to an internal FoundStone memo forwarded to that fantastic site, InternalMemos.Com.

I really will just let that memo stand on its own. There’s hardly anything to add but to state the obvious: marketing people are weasels. (See my previous entry on July 5th for Scott Adams’ bang-on perspective on marketing drones.)