November 24, 2024

9/11

Five years ago this morning I was in a hotel room in Minneapolis, getting dressed. I flipped on the TV and saw smoke streaming from a skyscraper. Nobody knew yet what it meant.

My plan had been to meet a colleague in the lobby and walk over to our meeting. Everybody in the lobby area was watching the big-screen TV in the bar. It’s there that I saw the second plane hit.

There was nothing to do but go to the meeting. Not much got accomplished and we all spent much of the day in my hosts’ conference room watching a projected image of CNN. Much later I visited the same room and found a big painting of a firefighter hanging near where I had stood that day.

My wife and I had just moved to Palo Alto, California for a sabbatical year. The attacks affected folks in Palo Alto and Princeton quite differently. In Palo Alto, it happened during breakfast. Families were together; many learned of the attacks by phone from East Coast friends and relatives, and spent the morning watching together. In Princeton, adults were at work and kids at school; most kids learned of the attacks from parents who had had a few hours to think about what to say. In Princeton, the horrible question was: Who do we know who works There? Many people commute from Princeton to New York. The social network buzzed. Exactly where does M work? Exactly which train does he ride?

We didn’t lose any close friends, but at least two people I knew died. Later, reading the 9/11 report, I learned that one of them had been killed horribly by the hijackers to intimidate the other passengers. Several people we know were scarred. One man, who had been staying in a hotel across the street from the Trade Center, was haunted by images of falling bodies. A new doctor who had emergency duty at a Lower Manhattan hospital sent an email that I wish you could read.

As for myself, I was stuck in Minneapolis. As the week went on with no definite date of departure, we extended our meetings, trying to put our time to use. The hotel quickly emptied, as cancellations flooded in and those who could get home bolted. The few remaining guests bonded with the staff. One morning in the coffee shop, I was the only customer. The waitress sat down at my table and we had a long talk about what it all meant. I visit that hotel occasionally, and it still feels different to me than every other hotel in the world.

Eventually the airports reopened and I was on one of the first flights out of Minneapolis. The security screeners were jittery and ultra-vigilant, but also polite. I was disconcerted to note that nobody ever checked my ID that morning. When I mentioned this to the flight attendant, she quietly told me not to bring it up again.

I was happy to be at home and looked forward to some quiet time. Little did I know that I was about to be called to Washington for the final settlement talks in the Microsoft antitrust case. A month working in a DOJ building, in immediate post-9/11, post-anthrax Washington, is an experience not soon forgotten. Perhaps I’ll write about that next year.

E-Voting, Up Close

Recently the Election Science Institute released a fascinating report on real experience with e-voting technologies in a May 2006 primary election in Cuyahoga County, Ohio (which includes Cleveland). The report digs beneath the too-frequent platitudes of the e-voting debates, to see how , poll workers and officials actually use the technology, what really goes wrong in practice, and how well records are kept. The results are sobering.

Cuyahoga County deserves huge credit for allowing this study. Too often, voting officials try to avoid finding problems, rather than avoiding having problems. It takes courage to open one’s own processes to this kind of scrutiny, but it is the best way to improve. Cuyahoga County has done us all a service.

The election used Diebold electronic voting systems with Diebold’s add-on voter verified paper trail (VVPT) facility. One of the most widely discussed parts of the report describes ESI’s attempt to reconcile the VVPT with the electronic records kept by the voting machines. In about 10% of the machines, the paper record was spoiled: the paper roll was totally blank, or scrunched and smeared beyond reconstruction, or broken and taped back together, or otherwise obviously wrong. Had the election required a recount, this could have been a disaster – roughly 10% of the votes would not have been backed by a useful paper record, and Ohio election law says the paper record is the official ballot.

What does this teach us? First, the design of this particular VVPT mechanism needs work. It’s not that hard to make a printer that works more than 90% of the time. Printer malfunctions can never be eliminated completely, but they must be made very rare.

Second, we need to remember why we wanted to augment electronic records with a VVPT in the first place. It’s not that paper records are always more reliable than electronic records. The real reason we want to use them together is that paper and electronic recordkeeping systems have different failure modes, so that the two used together can be more secure than either used alone. In a well-designed system, an adversary who wants to create fraudulent ballots must launch two very different attacks, against the paper and electronic systems, and must synchronize them so that the fraudulent records end up consistent.

Third, this result illustrates why it’s important to audit some random subset of precincts or voting machines as a routine post-election procedure. Regular integrity-checking will help us detect problems, whether they’re caused by glitches or malicious attacks.

There’s much more in the ESI report, including a summary of voting machine problems (power failures, inability to boot, broken security seals, etc.) reported from polling places, and some pretty pointed criticism of the county’s procedural laxity. The best system is one that can tolerate these kinds of problems, learn from them, and do a better job next time.

Lost Comments

Yesterday somebody defaced this site. This trashed the database that backs the site, so we had to restore it from a backup. Everything seems to be back to normal, except that any comments submitted after the backup (about two days ago) were lost. Sorry for the inconvenience.

Silver Bullet Podcast

Today we’re getting hep with the youngsters, and offering a podcast in place of the regular blog entry. Technically speaking, it’s somebody else’s podcast – Gary McGraw’s Silver Bullet – but it is a twenty-minute interview with me, much of it discussing blog-related issues. Excerpts will appear in an upcoming issue of IEEE Security & Privacy. Enjoy.

Don't Be Evil, Yet

Mike at TechDirt writes:

As everyone is talking about Google’s (not particularly surprising or interesting) move into offering hosted business apps (basically taking their existing mail and calendar apps, and allowing you to run them for your business), it seems that the story of AOL’s new download software being criticized for secretly installing plenty of additional apps is perhaps more indicative of the drive away from client-side software. These days, it’s gotten to the point where you basically can’t trust any downloadable software at all not to clutter your machine, whether on purpose or not. So, while many people tout the “access it anywhere” or “no setup involved” features of web-based software, the simple lack of additional annoying crud getting installed on your computer may turn into a powerful added incentive for moving towards hosted apps.

The TechDirt guys are usually pretty sharp, but I’m afraid they’re too optimistic here. I’ll grant that today’s web-based software tends to come with less crud than desktop apps, but I doubt that will last.

It’s quite possible to distribute crud with web apps. AOL’s download app installed a browser toolbar; but a web-based app can carry its own crud-filled toolbar – it just has to put that toolbar inside the browser window, just above its app functionality. The main difference is that web apps’ crud has to be displayed inside the browser window, which doesn’t seem like much consolation to a user who depends on the web app.

So why is AOL distributing crud with its app while Google isn’t? One possibility is that Google practicing its “Don’t Be Evil” motto. Another possibility is that the companies are at different stages of a standard software business model, which goes like this:

  1. build market share
  2. lock in customers
  3. profit from lock-in

Economics tells us that if a customer is locked in so that he would have to pay a cost of C (in money or hassle) to stop using your product, then you can extract extra revenue of C from that customer. You can extract that value by charging him a higher price or by subjecting him to hassles that he would pay C to avoid. In this case the hassle is crudware that the vendor is presumably being paid to deliver.

AOL’s client software is at Stage 3 of this plan, so it makes sense for them to be cashing in with crudware. But Google’s web apps are still at Stage 1, where the goal is to attract customers. The same is true, presumably, of most web-based apps – which means that once we all come to rely on web-based apps, they’re likely to start delivering crudware too. Being an early adopter has its advantages.