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", "carl.donath@us.finagle.us", 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.

Systems should never, ever assign userIDs to people without their input.  I feel less strongly about employee email addresses. Assigning an employee an email address such as  "carl.donath@us.finagle.us" is not only appropriate, but desirable, as it aids predictability.  Even here, however, employees should be empowered to add aliases.  When I worked at Apple, for example, people could write to me as bruce.tognazzini or simply as tog. 

 

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

 

Supplier: all

 

Alias: “Your password is incorrect”

 

Product: many

 

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:

 

• OSs:  When Caps Lock is on, make Shifted characters come out lower-case.  This is the way Windows does it, and Windows is our official, government-supported monopoly.  Those of you with 3% market share, get over it!  You make your user’s lives miserable if you subtly interpret your user’s behavior differently from the Windows computer they are also forced to use.
• Password interpreters:  Accept either the user’s entered password or its inverse.
• Password interpreters alternative: Offer an alert to the user that the caps lock key is down (suggested by Victor Works, based on alert offered by Novell software.)

 

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  

 

Bug Name: Unnecessary Password Restrictions

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 on list since: Jan 2005

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"

Principle: Describing a design error in the manual does not affect its status as a fatal bug.

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 me—but 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

Observer: Tog

Bug reported to supplier: 1999

Bug on list since: 1 Feb 2005