January 7th, 2006

Autosave your form fields.

Bam! I just lost 45 minutes of writing into a stupid LiveJournal textarea. I hate that. I decided i hated it enough to go looking for some sort of autosave feature for Firefox forms.

There's a nice extension called Scribe that lets you save your form contents into a file. But it didn't do the trick for me, for two reasons:
  1. It only works for Firefox 1.0, and refuses to install if you have Firefox 1.5.
  2. To save your form, you have to go File > Save Entry..., then a file dialog pops up and you have to navigate to where you want to save your file, type in a filename... blah blah blah. There's no way i'd be conscientious enough to do that every few minutes.
So i downloaded Scribe, unpacked it, and fixed these two things (for some definition of "fixed"). I have a hacked-up version that installs in Firefox 1.0 or 1.5, and if you tell it to, it will save whatever you've entered in your form automatically every minute. To use it, install scribe.xpi, then in the Tools > Extensions window, select Scribe and click "Preferences". Check the "autosave" option and enter the path to a directory where you want it to save your form contents.

Be warned: this is a quick and dirty hack, and it does not delete old files! You may end up with a lot of little files piling up in that directory after a while. But that's better than losing work, i think.

(And yes, i know there are clients for LiveJournal that can autosave. I don't want one.)

My research topic: verified UI for voting machines.

Ever since i changed research topics last fall, i've been meaning to write a post describing the change, so this is long overdue. What finally prompted me to write this is the law that was just passed in Wisconsin concerning the source code for voting machines. At first, lots of people thought the law required voting machines to use open source. But as it turned out, the source code isn't released unless there's a recount, and even then the people who examine it have to sign a strict confidentiality agreement.

There's a tension between the voting machine companies, who want to keep their source code secret so they can compete with each other, and those of us who want a transparent election process. Over at Usable Security, i've posted an idea for resolving (or at least mitigating) this conflict, and i'm interested in your thoughts on it.

Anyway, what's my topic? All last year i told people that i was working in security and usability — making computers safer and easier to use at the same time. Specifically, i was trying to prevent phishing: sneaky e-mail messages and websites that fool people into giving away their passwords. Identity theft is a billion-dollar business, and it's still growing. (I think i have a decent answer to the phishing problem, which i hope to explain in another future post.)

Now i'm working on voting machines. It's still about security and usability, just from a different angle. The question is: How can we be sure the ballot hasn't been rigged? This isn't just a security issue, it's a UI problem! The ballot is the user interface of the election.

The approach is just the same concept as the sample ballot. When elections are run with paper ballots, a sample of the ballot is prepared before the election so everyone can see that the ballot is fair. If a candidate's name is missing or unreadable, for example, you can see it right there on the sample ballot.

When the ballot is a computer program, we should have sample ballots too. (In fact, the sample ballot is even more important for an electronic election, because when you go in to vote, you don't get to see everything.) So i'm working on a way to separate the design of the ballot from the running of the machine, so that the election officials can commit to a ballot design in advance and publish it. Everybody should be able to see the ballot design and try it out on their own computer if they want before the election. And the ballot design should be presented in a way that many people can understand — certainly lots more people than just voting machine makers, security experts, and even programmers in general.

I'm very happy to be working with David Wagner, who has joined Marti Hearst as my co-advisor. David and Marti are the dream team of security and usability — among the strongest researchers in these respective fields — and i'm fortunate to have them both advising me.

I like this topic for quite a few reasons. First, it's useful — it has a practical application, and it might actually make a difference. Even if the particular system i build isn't the actual one used in an election, just showing that it can be done could have some impact. Second, people get it! Whenever i describe what i'm doing to people, i barely have to finish my first sentence before they understand why it's important. It's wonderful to get such a positive reaction instead of having to struggle to find convincing words. Third, it's specific — the solution i'm building is well defined, it's clear in my head, and i get to think about designing a system, which i enjoy. Fourth, i get to work with people — it's not all about sitting in front of a computer, because usability and accessibility are huge requirements for a voting system. I have to watch people actually use it and see what happens; i have to go talk to blind people and people with other disabilities and learn what works for them. Fifth, it has broader academic merit — although there has been lots of work on software verification, as far as i know, there hasn't been any work on verifying the user interface itself.

And it's a nice blend of my interests: security, usability, democracy. There will even be a place for information visualization, since there's the challenge of displaying a program in a way that non-programmers can understand.