2012-01-19
How not to do repeated fields in web forms
There's a certain sort of web form which really wants to make sure that you've entered something correctly, so they ask you to enter it twice in two different fields. You've probably seen this in some web form sooner or later; this is the 'please enter your password again in this field too' or 'please re-enter your email address' field. I tend to think that this is bad on its own, but I've now seen an even worse implementation of this basic idea, which I'll call an anti-confirmation field, one that's practically designed to create errors.
What the people behind this did was quite simple: they made it so that their second fields would not accept pasted input (probably using JavaScript, which I had on because I didn't feel like finding out which bits of the registration process required it). I had to retype both my email address and my password by hand, which was especially annoying because I was pasting both of them from elsewhere. I call this an anti-confirmation field because of course retyping things by hand is more error-prone than pasting things in; in fact, I twice made a mistake retyping the password.
(My web password for this site was a strong random password, as usual. Random jumbles are hard to transcribe accurately by hand, especially when they jump back and forth between character case.)
I suspect that the website designers justified this by saying that they were worried about people entering a bad email address by hand in the first field and then 'confirming' it by just cutting & pasting it into the second field. However, even at its best this logic doesn't work for password fields since browsers don't let you copy the plaintext content of a password field once you've entered it. I also suspect that the designers do not have any actual data on how many genuine errors this prevents (versus how many artificial errors are created).
Sidebar: how to measure the numbers
Assuming that you've committed yourself to (anti-)confirmation fields in the first place, you just need to track field values across time when a submission fails because of mismatched fields. In a transcription error the first of the two fields will turn out to be correct (ie, the same as the final submitted value) and the second field will change. In a genuine error the first field will be different between the failed submission and a subsequent valid one.
Doing this with email addresses raises basically no security issues. If you do this with the password field you'll want to one-way hash them somehow in your tracking data.
Let's make it official: Solaris 11 is closed source
You may remember back in August 2010 when there was a leaked Oracle memo that said, among other things:
We will distribute updates to approved CDDL or other open source-licensed code following full releases of our enterprise Solaris operating system. [...]
At the time I noted that 'full releases' might be construed to be 'Solaris 11' instead of the next 'Solaris 10 update X' release and was unhappy about it. That was then. Now it's been a couple of months since Solaris 11 was officially released to the world and, well:
; cd onnv-gate ; hg incoming comparing with [...] searching for changes no changes found ; hg log | fgrep date | sed 1q date: Wed Aug 18 15:52:48 2010 -0600
I think it's safe to conclude that there will be no further updates to public (Open)Solaris source code from Oracle, ever. Solaris is now a closed source, 'source-not-available' operating system once again (and probably stronger than it ever was; it used to be sort of possible for universities to get Solaris source code, but I doubt that's on the table from Oracle).
(I'm sure that almost everyone concluded this some time ago. Sometimes I remain hopeful even in the face of all but certain disappointment.)
This matters a lot for us; our ZFS spares system and parts of our ZFS status monitoring system are built around information obtained from undocumented internal library interfaces because there is no other alternative. It seems extremely unlikely that we will ever upgrade to any future version of Oracle Solaris. Lack of (Open)Solaris kernel code also significantly reduces the usefulness of DTrace, one of the theoretical signature Solaris features.
(It is vaguely possible that some version of Solaris will sometime expose public interfaces for the information we need, but frankly I really doubt it. All evidence to date suggests that it is strongly against the engineering culture of ZFS; they had five years to do it and steadfastly didn't. I will skip any number of angry remarks.)