I looked around and couldn’t find any standard Unix commands or shell trickery that did what I wanted, so I wrote a little Python script called timeout.py (available via github) some years ago. Unbeknownst to me, in late 2008 GNU coreutils added a timeout program (documentation here) that is now available on many Unix systems. The basic idea behind timeout.py and GNU’s timeout is the same: run a command with a specified timeout, and 1) exit when the command exits normally or 2) send a signal to the command when the timeout expires.

timeout.py works by setting a SIGALRM signal to be delivered at the desired timeout period, and then forking a new child process to run the specified command. The SIGALRM handler then sends a specified signal (SIGKILL by default) to the child process.

One useful feature that I added to timeout.py (that GNU timeout doesn’t have) is the ability to place the child process in its own process group; when the timeout expires a signal is sent to the entire process group. This is helpful for cleaning up multiprocess programs. PARSEC‘s script for launching benchmarks (parsecmgmt), in particular, forks a bunch of processes to run a benchmark, and killing the top-level parsecmgmt process will not kill the actual benchmark process which lives a few layers deeper.

timeout.py is written in Python, so it’s easy to modify. Its functionality is also exported via a Python module called TimerTask that wraps the functionality of Python’s standard subprocess.Popen() call. One caveat with using the TimerTask module is that, since it uses SIGALRM, it may interfere with other uses of SIGALRM in client code.  In particular, you can’t have multiple simultaneous TimerTasks, each with their own timeouts. TimerTask tries to be safe and raises an exception if there’s an existing SIGALRM handler, but a better approach would be to fork a new child process to run each TimerTask. Maybe I’ll add this someday.

timeout.py is Unix-only due to the use of, e.g., the SIGALRM signal and the preexec_fn argument to subprocess.Popen(). The source code is available under a GPLv3 license at https://gist.github.com/1526975.

Previous editions of this site used a manually-maintained database of conference information but this was growing tedious so I decided to help out the site creators by automating this process. The general idea was to scrape WikiCFP for calls for papers of various conferences of interest, parse that information and then feed it into the mash-up. Pretty standard Web 2.0/SOA/AJAX/circa-2004 stuff, but this is 2011 so it’s even easier now!

Indeed, there were only 2 slightly tricky parts. The first was that WikiCFP doesn’t run a proper web service for obtaining conference information, so this has to be extracted in a somewhat precarious manner from their HTML pages. The second issue is that the same-origin policy prevents this work from happening entirely on the client-side. I would have preferred a solution involving only client-side javascript to keep the design simple and to make it easier for others to see all of the code. But this was not to be: a client script served up by www.cs.washington.edu cannot, try as it might, make requests to www.wikicfp.com. After some wheel-spinning, I decided to take the easy way out and do the cross-domain stuff on the server, via PHP.

When you hit the page, the server script sends a search query to wikicfp.com and parses the resulting HTML webpage (using the fantastic simplehtmldom library). This gives a list of upcoming conferences with their deadlines and locations. The server script packages all of this information into JSON format and sends it in a script to the client. The client then uses Google’s Geocoding Javascript API to figure out where the conference is and add a marker to the mash-up.

Unfortunately, the search results from wikicfp.com do not contain links to the actual conference websites, only to the WikiCFP call for papers pages. It’s nice to have direct links to the conference sites, but doing so would involve another HTML request for each conference displayed, and each request was taking nearly a second to complete (the initial search request also takes about a second). The simplest thing to code up is to perform these requests serially, but with 8 or more conferences to display on the page at once, that’s several seconds of valuable researcher time spent waiting to see where the international conferences are, instead of doing the research necessary to attend these conferences. I shudder to think at the lost productivity this would entail.

So, these requests must be done in parallel. The solution I chose was to send the page to the client with links only to the WikiCFP pages. Then, Javascript on the client makes asynchronous requests to the server to fetch the direct conference links, and the client script sneakily rewrites the links while the user is looking at the page. To resolve the direct conference links, the initial page includes the WikiCFP eventId for each conference.  There’s a “web service” (if 40 lines of PHP can qualify as such) on the server that, given such an eventid, fetches the appropriate call for papers page from wikicfp.com, extracts the link to the main conference site, and then returns that link bundled up in JSON format.

Some unscientific benchmarking on my home machine reveals that the initial page load takes about a second, and fetching each direct conference link takes 700-900ms, but the latency of these additional requests is overlapped. So, if you load the page and immediately scroll down and click on one of the conference links at the bottom (or in the map pop-ups) you’ll go to wikicfp.com. But if you can wait a second (literally) you’ll get the direct conference link. It is humanly possible to trigger this behavior (it took me about 10 tries), but not by any reasonable usage pattern. However, others looking to re-mash this mash-up be warned!

In the future I’d like to get the initial page load time down as well.  Since I’ve already used the parallelism silver bullet, I suspect it’s time for caching to make an appearance…

To moderate that blatant sales pitch, I will add that I actually used Tableau to make all the graphs in the paper.  Making publication-quality graphs is, unfortunately, clearly not what Tableau was designed to do.  It was a somewhat painful process but produced (to my eye) decent results in the end.

For all the graphs in the paper, you can see our exact performance numbers (no more zooming in on the PDF and interpolating with a ruler, as I have occasionally had to do), see the data points behind the averages, and download the data to crunch for yourself.  It’s like we’ve got interactive graphs in our paper (but with one level of indirection).  If you find this useful in some way, shoot me an email or a comment!

Library Dependences

The simulator requires v1.40 of the Boost C++ libraries.

Installation

You’ll need an installation of Intel’s Pin binary instrumentation tool.  Extract the RCDCsim tarball into the PIN_INSTALL_DIR/source/tools/ directory, where PIN_INSTALL_DIR is the top-level directory where Pin is installed.

From the PIN_INSTALL_DIR/source/tools/rcdcsim/ directory, run make to build the simulator.  You can then run make run-unittests to run the included unit tests, and make test-time to run the ls program under the simulator as a simple integration test that everything works.  The Makefile also has a target for running parsec benchmarks, though you will need to edit some paths before this will work.

High-level Simulator Structure

The simulator is structured into multiple processes that communicate through FIFOs.  The frontend (frontend.cpp, PinCallbacks.cpp) is a pintool that instruments every thread in the target program to generate events (e.g. memory accesses).  These events are funneled, via a lock-free queue, into an I/O thread that pushes these events into the frontend FIFO.  The use of a single queue for all program threads maintains causality order (e.g. between a lock release and acquire), which makes the backend simulator easier to write in some cases.

To have valid comparisons across simulation configurations, the configurations should see the same event stream.  For example, to compare performance of RCDC with nondeterministic execution, the two configurations should be fed the same event stream.  Thus, events are broadcast to multiple other FIFOs via the pipefork program (pipefork.cpp), which simply copies events from the frontend FIFO to a number of simulator FIFOs.  Each simulation then runs in its own process, reading events from its own FIFO.

The important simulator files are:

• SimulatorThread.cpp: contains the simulator’s main(); receives incoming events and sends them to the MultiCacheSimulator
• MultiCacheSimulator.hpp: creates the cores and manages all system-wide state, like shared caches
• SMPCache.hpp: manages per-core state, such as that core’s private cache hierarchy
• HierarchicalCache.hpp: models a single cache; these can be chained together into arbitrarily deep cache hierarchies

Design Decisions

I decided to adopt a multi-process design in this pintool because I was tired of 1) tracking down concurrency bugs in my multi-threaded Pin instrumentation (the irony of which, as a concurrency researcher, is not lost on me), and 2) not being able to use gdb on my pintool (despite the Pin manual’s attestations that this is in fact possible).  These two features combined are particularly unhelpful.  Alternatively, keeping the simulator proper in its own single-threaded process means that the “untrusted” multi-threaded code is kept to a minimum, and that the simulator is very gdb-friendly.  The simulator can even be written in a completely different language: I mean, isn’t it about time we started writing architecture simulators in Haskell?

However, there is a downside to the multi-process design in that there is not really much feedback from the simulator to the event generator.  There is back-pressure via the FIFOs, but RCDC’s execution model in particular requires finer-grained control.  RCDC sometimes requires events for a specific simulated processor P (say, if all other processors are waiting for P to hit its quantum boundary) to make forward progress.  In a situation like this, the simulator has no way to say to the event generator: “stall everyone other than P“.  Instead, the simulator must constantly accept events, buffering them locally until enough events for P arrive to let P finish its quantum, which lets all processors make progress again – which allows the buffered events to be processed.  This buffering is currently done with per-processor buffers, which has the side effect of destroying the nice causality-ordering of incoming events, so causality has to be reconstructed in the simulator.

This was generally not a problem in the experiments we ran, but it did occasionally lead to out-of-memory crashes.  Execution models that do not pause processors would not, however, suffer from this issue.

License and Acknowledgments

All the simulator code is licensed under GPLv3 (except for some stuff I stole from SESC which is GPLv2, and the lockfree queue which is under the Boost Public License).  Many thanks to Tim Blechmann for the lockfree queue, and the SESC developers for the code of an earlier version of this simulator.

Version History

version 0 (27 Jan 2011): initial release
version 1 (7 Nov 2011): added missing header file

With Google-given example code I was indeed able to get something basic working pretty quickly that made the entire abstract either visible or not, by twiddling the display CSS property.  Then I started thinking: what would it take to have the abstract appear with a “slide in” animation, instead of just suddenly becoming visible?

Well, at least I had good intentions to start.

After many hours of fumbling, I got something pretty decent working with jQuery.  The only issue was that the animation was a bit “jumpy” at the end.  This weirdness persisted across all the browsers I tried (Firefox and Chrome on Linux, and Firefox and IE on Windows).  Many of the examples I found on the internet were for sliding in fixed-height content, but I couldn’t specify the height of each abstract in advance, since they were all of different lengths (i.e., word counts).

My desperate mind turned to thoughts of hacking at the jQuery code, and then, slightly more plausibly, rendering the text invisibly in the background, reading its height via Javascript and recording it in CSS, and then making the text display: none; again.  I was setting in on coding this solution (which I still think would have been a lot of fun, despite its patent horribleness) when I discovered this comment on the jQuery documentation page for slideToggle().  Turns out I just needed to set the width of the content (which was fixed for my page), and that would add enough constraints to the layout to allow browsers to render the animation smoothly.

It was all of a 1-line CSS fix in the end.

p.s. You can see the “jumpiness” that results when the div being animated doesn’t have a width constraint in this example I put together.  There’s also a demo of the fixed code.  Curiously, an explicit width on some parent div (which I’d had all along) is not sufficient to force the smooth animation of a child; the child itself needs a width (or height).  This code uses jQuery 1.4.3.

Next came the supposedly easy part: create a disk image with Linux on it (I wanted to use Ubuntu Karmic Server) and start simulating.

It turns out that running the Ubuntu installer in bochs is a real pain.  Not only is it slow, but I encountered an assertion failure (in bochs) during the disk partition step of the installation.  It turned out that this was due to some funkiness in the bochs plugin system (which is based on dynamically-linked libraries); switching to static linking finally got me past the assertion failure.  After that adventure I had some kind of boot loader corruption that caused the virtual machine to fail to boot.  Don’t even ask about getting networking to work (it still doesn’t), or why the terminal occasionally looks like the picture below.

graphical corruption of the terminal in bochs.

Ultimately, I found some success when configuring bochs with the command listed below (everything should be on 1 line):

./configure --enable-sb16 \
  --enable-ne2000 \
  --enable-all-optimizations \
  --enable-cpu-level=6 \
  --enable-x86-64 \
  --enable-sse=2 \
  --enable-pci \
  --enable-acpi \
  --enable-usb \
  --enable-usb-ohci \
  --enable-show-ips \
  --enable-clgd54xx \
  --enable-pci \
  --enable-smp \
  --enable-debugger \
  --enable-disasm

An alternative approach is to use debootstrap to setup a chroot Linux installation, and then copy that installation onto the virtual hard disk, as outlined here.  However, this is a pretty involved procedure, debootstrap with Ubuntu didn’t install any kernels for me, and installing the boot loader also seemed tricky.

Contrast these circuitous approaches with qemu, which is very fast (even without using KVM acceleration) and installed Ubuntu without a hitch on the first try.  With networking.  And a nice virtual monitor via VNC.  All straight out of the box.  qemu+kvm might even be fast enough to compile code inside the VM, which would ensure that the right headers, libraries, etc are used (otherwise you can always just mount the virtual drive as a regular filesystem and use cp from the host machine).  qemu is everything I could ask for — if only its codebase was more in tune with what I wanted to do!

The Best of Both Worlds

It took me a while to realize that I could have my bochs and qemu it, too, as both emulators can read and write a common virtual disk format: it’s called “raw” for qemu and “flat” for bochs.  Essentially, it just uses a single regular file as the virtual disk.  The only trick is that you have to create the virtual disk using bochs’ bximage program; if it’s created with qemu’s corresponding qemu-img program then bochs won’t recognize the virtual disk for some reason.

With this hybrid approach, I can boot the disk using qemu for installing the OS, interactively setting things up via the commandline, downloading packages from the internet and so on, and then reboot into bochs to run simulations.  It gives me the excellent speed and hardware emulation of qemu, with the more-natural-for-simulation interface of bochs.

I’d like to have this email archive searchable from gmail.  And I would really like to have all those tags I’ve accumulated over the years show up as gmail “labels”.  Fortunately, this isn’t too difficult thanks to the following:

1. Thunderbird stores message tags in a special X-Mozilla-Keys header in the email message itself.  So it’s easy to recover the tags by parsing the email.
2. Google provides an email migration API for uploading messages into some hosted Google Apps gmail accounts.  Unfortunately, “This API  is only available to Google Apps Premier, Education, and Partner Edition domains, and cannot be used for migration into Google Apps Standard Edition email or Gmail accounts” sayeth the Google.  You also have to have your Google Apps administrator enable email migration by end users – be default, only administrators can migrate email.

There are a few other nice thing about using the migration API (as opposed to just copying the emails from one IMAP folder to another).  One is that time/date information is preserved.  With an IMAP copy, emails all appear to have arrived on the day that the copy was made.  Also, metadata can be preserved (e.g. messages flagged “Important” in your mail client can be translated into “starred” messages in gmail).  Overall, your/my obsessive-compulsive side will be much happier if you can use the migration API.

tbird2gmail.py

So, I wrote a little Python script program that uses the Google email migration API to upload a bunch of emails from Thunderbird (or any ol’ mbox file, but it only understands how to read “tags” set by Thunderbird) into a hosted gmail account.

installation

You’ll need:

1. the Google Python API (I used version 2.0.4)
2. the actual python script (for the curious, a darcs repository is also available)

usage

You need to ensure that Python can find the code in the Google Python API.  The simplest way is to set your PYTHONPATH environment variable to include the root directory of the API files.  For example, if you extract the Google API files into the same directory as the tbird2gmail.py script, any you’re using bash, you can run everything with:

PYTHONPATH=$PYTHONPATH:gdata-2.0.4 python tbird2gmail.py arguments...

The tbird2gmail script works by taking a series of mbox files as command line arguments, and uploads their contents to the specified hosted gmail account.  You need to provide your login information (email address and password).  One particularly useful feature is to specify (via the --label command line flag) a label to be applied to all uploaded messages.  In case the upload fails for some reason (see below) it is easy to find all the emails that were part of the upload, so you can e.g. delete them and try again.

caveats

I used this script to upload roughly 30,000 emails (about 1GB in size) into my UW gmail account.  Emails are uploaded in batches of configurable size; I found that when using a batch size any larger than about 2MB, the gmail server would get overwhelmed and close the connection.  So I shrunk the batch size, added a delay in between batch sends, and the thing ran happily all night. The theoretical maximum batch size allowed by the Google API is 32MB.

This is definitely a hack; the Google API docs say that the server should return a 503 error when it becomes overworked, but in practice I found this was not triggered reliably before the connection was simply terminated.

This script should not be used if the underlying mbox files can be modified by another application.  Doing so could result in a corrupted mailbox file, costing you all your mail!  So close down your mail client before uploading any email.

Gmail will also reject mail that does not conform to the RFC822 specification.  I had a few emails that were missing proper Date: headers, and others that had invalid attachments (generally bounce messages).  tbird2gmail will log these failed emails into a new mbox file, where you can edit them and then try uploading again.  The failure reason returned from the Google server is stored in a special X-Tbird2gmail-Upload-Failure-Reason header in the message itself.  You can read more about what these failure codes look like at http://code.google.com/apis/gdata/docs/2.0/reference.html#HTTPStatusCodes.

Update (3 May 2010): Lisa, another grad student here at UW, has written some python scripts for migrating mbox files into Google Apps that don’t depend on the now-deprecated interface in the Google Python libraries; just pure Python 2.6.  You can find the scripts here.

The reason all this works is because you can do function calls up from the Flash movie, through the ActiveX container and into VBA code attached to the Powerpoint presentation.   You can also call down from Powerpoint into Flash in a similar manner, though I haven’t experimented with this.

The Easy Part

Perhaps surprisingly, writing the code is the easy part.  The Visual Basic code attached to the Powerpoint slide looks like this:

Private Sub ShockwaveFlash1_FlashCall(ByVal request As String)
  'request looks like:
  '<invoke name="foo" returntype="xml"><arguments></arguments></invoke>;
  If InStr(request, "gotoNextSlide") > 0 Then
    ActivePresentation.SlideShowWindow.View.Next
  ElseIf InStr(request, "gotoPrevSlide") > 0 Then
    ActivePresentation.SlideShowWindow.View.Previous
  End If
End Sub

ShockwaveFlash1 is the name of the ActiveX control for the Flash movie. If you only have one of these on a slide, this will be its name. But if you have more than one, the names will be ShockwaveFlash2 and so on.

In ActionScript land, the code that calls out of the Flash movie looks like this:

import flash.external.ExternalInterface;

if ( ExternalInterface.available ) {
   ExternalInterface.call( "gotoNextSlide" );
}

The Hard Part

Unfortunately, this code won’t do anything out of the box.

This is because of the Flash player security model, with which I became overly familiar over the course of this project. There are several different security sandboxes in which a Flash movie can potentially be running.  In order for ExternalInterface function calls to work, the movie needs to be, sensibly, in the most trusted sandbox: the LOCAL_TRUSTED sandbox. Fortunately, a movie can check what sandbox it’s running in with the following code:

import flash.system.Security;
trace( Security.sandboxType );

If you run a Flash movie in the standalone Flash player, it runs with LOCAL_TRUSTED privileges. However, if you run that same movie via an ActiveX control in Powerpoint, the default security settings put it in the LOCAL_WITH_NETWORK sandbox, which is insufficiently privileged to allow Powerpoint-Flash interaction to work. Instead, things will fail silently.  And no amount of tinkering with Powerpoint’s security settings (trusting ActiveX content, macros, etc.) will fix things. After much anguish, I discovered that you have to talk directly to the Flash runtime to get a movie into the LOCAL_TRUSTED sandbox when running inside an ActiveX control.

There are several ways of telling the Flash runtime to put a particular movie in the LOCAL_TRUSTED sandbox, all of them documented at the Adobe link above. Probably the easiest way is via the Flash Security Settings Manager gui: it’s a Flash applet that runs in your browser to control your local Flash settings – spooky!  You can decide to trust particular .swf files, or directories, or even the Powerpoint executable itself which will automatically trust all movies that are included in Powerpoint slides.  I’ve blogged previously about how to do this, but there are a few tricky parts I haven’t covered before.

If you’re embedding Flash movies into Powerpoint (as opposed to just linking to the movies), then you have to trust the Powerpoint binary, as the Flash movies don’t have a real filesystem location – if you check where an embedded movie lives via root.loaderInfo.url you will get the path to the Powerpoint binary. Trusting the Powerpoint binary is a hack that allows the movie, indirectly, to be trusted as well.  Trusting Powerpoint will also enable non-embedded Flash movies to run in the LOCAL_TRUSTED sandbox.

If your Powerpoint slides just link to the Flash movies, then you can have finer-grained control over security, but of course you have to ensure the links are always valid or the movies won’t work.

Other security considerations

Getting the Flash player security settings right was definitely the trickiest part, because they’re a bit out of the way and not terribly popular topics of conversation according to Google.  But to make Powerpoint and Flash play nice together you also need to (clearly) enable macros in Powerpoint and allow ActiveX controls to run.  ActiveX controls don’t need any special treatment however: they can run in Safe Mode with privileges that prompt you before they are enabled with “minimal restrictions”.  I never saw a prompt, because I don’t think the Flash ActiveX control requires any special privileges.

Once you get the security settings resolved things work great. It is highly unlikely, however, that things will work out-of-the-box if you move the presentation to a new computer, due to the default security settings. But once you get things integrated, you get the power of Flash for doing complicated animations with the ease of Powerpoint for the simple stuff. Pretty much the best of both worlds!

I love Amazon’s Elastic Compute Cloud, and have been using it to run research experiments without having to worry about multiplexing computing resources among other members of my research group.  No running top after I login to make sure I’m not stepping on someone else’s experiments: I launch an instance and I get it all to myself.

Sharing storage across instances, however, is tricky.  For my purposes, having a read-only copy distributed among my instances is sufficient; of course adding read/write access makes things substantially trickier.  Yet even given that I was fine with read-only access, none of the solutions that immediately came to mind were satisfactory:

1. Put everything in the root partition of my instance.  Every instance launched will have this same image, which is great.  The problem is that the root partition is just 10GB and doesn’t seem to be able to be increased.  Also, bundling up an instance is quite slow, making updates painful.
2. You can get copious amounts of ephemeral storage via /mnt on each instance, but this doesn’t persist across the lifetime of an instance.  I could download a tarball from S3 and extract it to /mnt every time when I launch an instance, but this seems very hackish.
3. You can get persistent network storage in the form of the Elastic Block Store, but this can only be attached to one instance at a time.  Doh!
4. You can run NFS or GFS or whatever you want on your instances after you launch them, but this seems like a lot of work.  I’m supposed to be working on research, after all.

What I really wanted was the ability to mount an EBS volume read-only on multiple instances.  Since things are read-only, there won’t be any consistency issues but, still, Amazon doesn’t support this.  Until I discovered a hack to make it possible, using EBS snapshots.

The basic idea is to have a master EBS volume V that you want to replicate with read-only copies across a number of instances.  Upon bootup, each instance makes a snapshot of V and then its own personal volume Vp based on that snapshot.  Each instance can then attach the volume Vp and voila – we’ve got our data replicated across our instances.  No fancy network filesystem or S3 hacks necessary.

What makes all this go is that EBS snapshots are very fast (because they’re lazily constructed).  My master volume V is 10GB in size, and about 7GB full at the moment.  And this whole take-a-snapshot-and-mount-it routine takes less than 10 seconds.  After I’m done with an instance, I have it throw away the snapshot and volume Vp to save space.  But since snapshots are built on diffs, having a bunch of snapshots doesn’t take up much room in S3 (i.e. cost much money) anyway.  Ultimately, EBS is doing exactly what I would want to provide a high performance read-only version of the volume: lazy creation of snapshots makes replication fast, and each snapshot volume functions as a cache to increase read bandwidth.  And all this without any extra engineering on my part!

I put together some Python scripts (with the help of the excellent Boto library) to automate this read-only replication of an EBS volume.  All you have to do is edit some parameters in ec2lib.py and then link these scripts into your distro’s boot/shutdown routines; this code is designed to be run from the instance itself.  The code is available under the MIT license (like Boto itself).  The repository includes a copy of Boto 1.7a to keep things self-contained.

How Lockfox works

Lockfox works in a manner similar to the SSH known_hosts database, but instead of remembering an association between public keys and domain names, Lockfox remembers an association between a password submitted on a web form and the domain to which that password was submitted. For added privacy, Lockfox stores only the SHA1 hash of the password, not the password itself. Lockfox monitors all password submissions and checks on each submission if a remembered (hashed) password is being submitted to a new, unknown domain. Lockfox prompts the user with a dialog to ensure that the user wants to submit their password to a new domain. If the user authorizes the submission, Lockfox forges a new trusted association between the password and the new domain. Otherwise, Lockfox redirects the user to the old, trusted domain.

For additional security, Lockfox also remembers any SSL certificate information available for the site to which a password is submitted. If this certificate information changes unexpectedly for some password submission, Lockfox requires the user to authorize the submission. The intuition here is exactly the same as that behind SSH’s known_hosts database: an unexpectedly changed SSL certificate likely indicates a man-in-the-middle attack.

Why Lockfox (hopefully) works

The intuition behind Lockfox is that a password is generally used only with a very limited set of domains – if a password gets sent to a different domain, it is likely that a phishing attack is taking place.  Lockfox has a number of advantages compared to existing anti-phishing techniques:

• Lockfox works entirely locally, building up a custom set of associations for each user without any global coordination or public key infrastructure.  There’s no blacklist to be broadcast or constantly updated.
• By remembering a set of trusted associations between passwords and web sites, Lockfox builds up a custom set of associations for each user.  This is, in a sense, a per-user whitelist: it has the advantages of a whitelist (shorter to specify, default action is to be secure) but without the disadvantage of maintaining a whitelist that works for all users.
• Lockfox is able to detect and prevent phishing attacks at exactly the moment that they occur, which will hopefully result in an effective form of user education about how to detect and avoid phishing sites.

To be fair, there are some disadvantages to Lockfox’s approach, too:

• If a user recycles a password between multiple sites, the user will receive a Lockfox warning for each new site.  This may annoy the user enough to make them disable Lockfox altogether.  To try to ameliorate this, Lockfox can optionally, at installation time, import passwords (and their corresponding web sites) that are remembered by Firefox as “trusted”.  So if you’ve built up a large set of remembered passwords with Firefox, Lockfox can automatically trust those sites that you, implicitly, already trust.
• Lockfox works only for passwords, and not for other information a user may want protected, such as credit card numbers, social security numbers, etc.

Ultimately, Lockfox is just one more tool for keeping people safe online.  It will work best when combined with existing anti-phishing techniques (such as those already built-in to Firefox).

Are you using Lockfox?  Thanks for your bravery, and please post any feedback in the comments!