Bug: userID a bad IDea
Reported by: Carl Donath
Duration: since user accounts were named
Supplier: nearly all
Users’ response: "I am not a number, I am a free man!"
Product: nearly everything requiring a userID
Bug: Users already have names. Don't invent new bizzare names for them.
Class of Error: Make IT's life simpler at expense of users
Principle: "We don't care that you've had a unique name for three dozen years. We'll give you a new one just to make our lives easier."
Proposed Fix: Ask the user their name and use that. Don't invent something new and expect them to remember it.
Discussion: Users already have names. Except in extremely rare cases (which can be easily dealt with), these names are unique. Computers rarely acknowledge this, instead requiring new and bizarre user IDs. I am "Carl Donath" (never confused with the 2-3 others in this country of 300,000,000 people), but every computer I use requires "ctdonath", "ctdonath2", "donath8642", "confusedAndBewildered", "312-54-9786", "1029-3847-5656-4738", "858-162-4269", "firstname.lastname@example.org", etc. ... but never "Carl Donath". Short efficient IDs might have made sense when computer memory was scarce, but now that computers remember more identifying data about me than I can, surely they can respond to me by my name.
Discussion by Tog: Having a name as unique as Carl’s, I was, at first, in favor of this. However, when I began to consider the length of my full name, I realized I’d rather use a shorter ID. However, it should be my choice, and the system should do the necessary work to support that choice. Many retail bricks-and-mortar systems in the US already support people’s ability to use their full name by requesting both name and zip code, to reduce overlaps.
Bug first observed: First time someone logged on.
Bug reported to Supplier: Every time I’m assigned a new userID.
Bug on list since: Jan 2005
Bug name: Caps-lock Catastrophe
Reported by: Stephen Burgess
Duration: since ENIAC
Alias: “Your password is incorrect”
Bug: Simple user oversight is punished
Class of Error: “Accidents are EVIL!”
Principle: The user should not be punished for a simple, correctable oversight.
Discussion: ÔCaps Lock’ can be an important feature to have. However, it is generally placed right next to a commonly used letter, where even a normally careful typist can occasionally hit it by accident and not notice. Add to this the fact that many weblications (web-applications) and operating systems require a user to enter a password without being able to see what they type, and we end up with a problem: The password is typed in in either all caps or inverse-case. Keyboards do have a light to indicate that the key is active, but many users fail to see it, so the problem can go unnoticed through several attempts at entering the password, especially on web-forms where there is seldom a visual reminder to check the caps lock key. This even occurs on many operating systems which are often aware that the caps-lock key is in use, and should thus be able to compensate.
Fixes by Tog:
Discussion by Tog: Yes, we’ve just cut security in half. Instead of two quadrillion possibilities, the eavesdropper only has to run through one quadrillion possibilities. Big deal! Users have rights, too, and screwing them over by rejecting a password they’ve just typed in exactly as you demanded, just because of an unseen collateral error, is not only mean, it’s incompetent.
This is an issue I’ve been harping on for years. It’s time to straighten it out.
Bug on list since: Jan 2005
Reported by: Carl Myhill
Duration: >20 years
Bug: When asked to supply a password the system often blocks certain characters, like Ô_’ (underline) and some force you to use numbers. We routinely need to remember tens, even hundreds of passwords. If I have to invent new variations for the sake of the password parser, one thing is certain: I will forget what the variation is.
Class of Error: Irrational rules
Principle: Be supportive of users. Save your hostility for eavesdroppers.
Proposed Fix: Make password rules as flexible as possible, consistent with appropriate security.
Discussion: Why can’t i just type in any characters i want into a password field? Ok, some length limits are sensible but all these constraints? Don’t see the point.
Discussion by Tog: Many people have now developed a short list of passwords they routinely use. It is one thing to demand at least six characters for the password. It is quite enough to then limit them to eight characters. One increases security. The other decreases security, while it increases user-hostility.
At the time of this writing, Wells Fargo Bank is one of the culprits. Like many sites making this error I've come across, their users really need the security this practice is compromising. Heath and financial services need to Cut This Out!
Also avoid taking yourself too seriously. If you are a newspaper with free registration, you do not need to demand a 42-character password with a mixture of upper and lower case, plus punctuation & numerical characters.
Bug Name: Secure Destruction
Supplier: Aladdin Systems, Inc.
Alias: "Oops! Sorry!"
Product: Secure Delete, sold separately and as a part of Aladdin Spring Cleaning
Bug: Dropping a file on Secure Delete may permanently and irreversibly eradicate the dropped file or a different file altogether.
Class of error: "Feature"
Discussion: Someone at Aladdin introduced a bug into an early version (1992 or earlier) of Secure Delete: If you drop all but one file type on the Secure Delete icon, it will permanently eradicate that file, as would be expected. However, if you drop an alias (shortcut) file on Secure Delete, it will leave the alias file untouched and, instead, completely and irreversibly destroy the original.
This behavior is exactly contrary to the way the normal Trash works, and this wanton destruction is carried out without any warning whatsoever.
As reader Mark Moss points out, this behavior was undoubtedly intended, since the programmer had to go to extra trouble to track down the target file and leave the alias file actually dropped on Secure Delete intact.
I have been bitten by this bug on several occasions. When I am working on a cluster of documents for a client, I will usually create a "project" folder for them, placing in it the documents along with aliases to the applications I'm using to create them.
Some time after the final report has been sent to the client, I may take that entire project folder and drop it's files on Secure Delete, sometimes forgetting about the aliases. Suddenly, Word, Excel, etc., are no longer with mebut I do still have the aliases as a fond remembrance!
Proposed Fix: Open a dialog announcing that the file (or files) in question is an alias and prompt user for whether just the alias should be removed or whether the original and all aliases should be removed. Then, if and only if the user chooses to delete both original and aliases, open a secondary confirmation dialog.
Discussion: The alias error cuts both ways. Right now, the program destroys the original without warning the user. Having it instead destroy the alias without warning the user that an original document will remain intact for prying eyes would only replace a data-destruction bug with a security bug. Therefore, the user must be able to choose between the two options.
Bug first observed: 1999
Bug reported to supplier: 1999
Bug on list since: 1 Feb 2005