The Community for Technology Leaders

Pet Peeves

Fred , IBM T.J. Watson Research Center

Pages: pp. 4-5

One advantage of becoming IC's editor in chief is that I get a bully pulpit from which I can write about anything I like, every other month. I can theorize, I can pronounce, I can educate … and I can rant. I have several pet peeves about the Internet. Where to start?

Email Hell

I devoted part of my first EIC column to the subject of phishing and the lack of authentication — something we're told is finally coming, someday. Although being able to identify that mail that appears to be coming from my bank really is coming from my bank is certainly of paramount importance, there are so many other issues with email that I hardly know where to begin.

First, there's just too much of it. Excluding the 90 percent of email that's actually spam, the 10 percent that remains is plenty. I've been using Google's Gmail system for personal mail since shortly after it became available to the public. As I write this, I'm using nearly 800 Mbytes — just over one-fourth of the amount purportedly available to me — and because the limit keeps increasing, I might never reach it. I have almost 40,000 messages, and, appallingly, over 25,000 of these messages are unread! I have a few rules to categorize incoming messages and can see that about 8,000 of the unread ones are categorized as "computer": mailing lists from various free services telling me about lots of aspects of computer science, little of which I actually have time to read. Of course, the ability to search this accumulated mail easily and quickly means that I can find what I want if I know what to look for. Still, it's far too easy for the important messages to get lost among the unimportant ones. It turns out that allowing my airline to communicate with me via email rather than snail mail is a dangerous thing: I came this close to never noticing the flight reschedule notice that moved my vacation flight later this year to three hours earlier.

Is there a remedy? Perhaps. I'd like my mailer to support variable prioritization. For one thing, rather than just showing me the most recent messages, it should show me the messages that are most important for me to read, using a function of both my rules and the sender's rules. Random spammers — that is, senders I haven't authorized — should never be able to send me urgent mail. But my airline, if it acts responsibly, should be able to send something designed to get my attention. Conversely, mail that I've ignored for a while should be highlighted (if important enough) or deleted (if bulk mail). The value of any given type of message might decay at different rates; I don't need to see the "one-day only sale" messages from an online retailer after the sale is over, but other types of mail should stick around for weeks, months, or years. (Note that if I never hit my 2.8-Gbyte limit, I don't really have to delete messages at all, but prioritization can both keep me below the limit and cut down on extraneous results from searches.)

What next? My second pet peeve for email is that everyone else gets too much of it, too. This means that if someone I email doesn't reply in the first few hours, the odds increase that they won't reply at all. It seems that none of the mailers have really gotten conversation management right — even those that thread messages on the same subject can't really tell users when a reply is overdue. If a user can schedule a reminder for a later time, such as with Lotus Notes' "follow up" feature, the reminder will be triggered at that time regardless of whether the user received the reply. To solve this problem, I want some extra conversation tracking:

  • a checkbox on outgoing mail to say I expect a reply;
  • a way to specify how much time to allow for this reply before getting a warning;
  • a pop-up to ask whether to remove this check if a reply is received; and
  • a warning (via email or pop-up) if the time elapses without the expected reply.

My other email pet peeves go back to the problems of spam and authentication. It seems I can't go more than a few weeks now before an email address I've given out to some company starts getting spammed, presumably because someone grabbed (or was given) their mailing list. I use procmail ( and add rules to either disable those addresses entirely or limit their use to mail coming from legitimate senders, but this is cumbersome. At the same time, I get enormous amounts of mail to bogus addresses on my personal domain, which procmail must also filter out. (Almost all of that mail consists of bounce messages to email purporting to come from these bogus addresses.) It's to a point where about the only mail I accept is from an address I already recognize, going to an address I recognize; if mail authentication doesn't arrive soon, even that approach will fail me soon enough.

(In)Security and Fixing What You Break

Last September, I discovered that a worm had infected my home computer. A few days later, I learned that the worm had used an exploit that had been publicized in May, but I hadn't heard about it, and the program in question had no provisions for auto-updating.

What went wrong? For one thing, not many applications have provisions for propagating security fixes automatically. (The most common applications and operating systems generally do, or the situation would be much worse.) But auto-update is not the only way to get things fixed. I registered for this software when I first obtained it, so the company that provided it could have emailed me to request that I upgrade. It was the least they could do, after all.

What will it take to ensure that future notifications of vulnerabilities go straight to users? Legislation might help, but it's an unlikely solution because software comes from all over the world. Voting with one's wallet might be the only choice, but by the time a breach has taken place, it's often too late. (As an aside, I registered a news alert to receive email about the company in question, lest I miss other vulnerabilities. I currently have nine such alerts in my mailbox, eight of which are unread. But I've read and deleted another dozen or two.)

This example is, of course, the tip of a large iceberg. Updating software over time is just one piece of the puzzle, and we have to deal with many other types of insecurity. Further, I recognize that even auto-update systems have their risks. But when there's a gaping hole in a piece of software that lets in worms, take my email, please. And use it.

Another place we could use help is at the operating system level. Once infected, what could I do? My antivirus software, which wasn't up to the task of keeping the worm out in the first place, did complain that it found something and cleaned it up. But I couldn't really be sure that my system wasn't compromised. Although this is more of a Microsoft Windows rant than an Internet rant, it's clear that Windows could do a better job of helping me find rogue software by, for instance,

  • telling me what software is signed, and by whom;
  • taking me directly from the task manager to the copy of the executable, rather than making me search my entire file system for something by that name; and
  • highlighting recently installed executables.


This short list of pet peeves is just the tip of a different iceberg. In preparing it, I quickly searched for Internet pet peeves online, and there are a ton of them. Most complain about things like PEOPLE WHO USE ALL CAPITALS and other breaches of online etiquette. But if you have a technical pet peeve, here's a thought. Fix it and tell us about it.

Another thing worth noting is that some of these problems, and others like them, have already been tackled in research environments, sometimes several years ago, without making their way into widely used applications. When I showed a draft of this column to a colleague, he pointed me to work done at IBM (, Microsoft (, PARC (, and elsewhere — just on the topic of email overload. (There is similarly a large body of work in thwarting spam, worms, and so on, more of which is commercially available.) When more of the ideas from these projects make it out of the lab and onto my desktop, I can move on to be peeved about other things instead. Their time has come, hasn't it?

IC Welcomes New Board Member

Mark Manasse is a principal researcher at Microsoft Research in Mountain View, California. He works in a variety of theory-related areas of distributed computer systems research and has worked on Web search technologies and Web page evolution. Manasse has a PhD in mathematics from the University of Wisconsin. He was a member of the design committee for the Inter-Client Communications Manual for the X Window System. In 1994, Newsweek described Severe Tire Damage (the band Mark founded and for which he plays bass) as "lesser-known" than the Rolling Stones, following STD's unauthorized appearance as the opening act in a multicast performance. Contact him at


Any opinions, errors, or omissions in this column are my own, and do not reflect the views of either my employer or IEEE Internet Computing as a whole.

66 ms
(Ver 3.x)