Holy cow, I wrote a book!
There are a variety of message digest algorithms out there,
MD5 being a particularly popular one.
These generate a "message digest" (essentially, a hash)
so you can detect whether
somebody has tampered with a file,
the theory being that it's hard to tamper with a file without
changing its hash.
But make sure you record the file size as well as the digest.
Not that collisions are necessarily easy to create by mistake.
(I've heard a rumor that the deployment team has seen an MD5 collision,
but it's just a rumor. I have no evidence. Heck, maybe what really
happened was that somebody
on the deployment got their MR2 into a car accident...)
Anyway, the possibility of a "reset attack" makes collisions
trivial to create.
Hash generators typically operate on a stream.
The hash engine maintains some state.
The file to be hashed is broken up into chunks, and each chunk
is combined with the engine's state variables in some complex way.
When you have passed all the data through the engine, you push a
button on the engine and out pops the hash value (which is typically
a copy of the state variables, or possibly a subset of them).
Now suppose somebody came up with a way of "resetting" the engine;
that is, returning it to the initial state.
Here's how they can
make any document match your digest:
First, create an alternate message and send it through the hash engine.
Next, generate the bytes necessary to "reset" the engine.
Finally, append the original message.
In other words, the fake file looks like this:
[alternate message][garbage][original message]
where "garbage" is the reset.
This fake file has the same hash as the original message, since
the "garbage" resets the hash engine to the initial state,
at which point the replay of the original message regenerates the
Result: A file with the same hash as the original, but with
In a proper attack, of course, the "alternate message" would be
crafted so the garbage and original mesage would be ignored.
You might end it with a marker that means
"Ignore everything after this point."
(For HTML, you can just say <NOFRAMES> and everything after
that point will be largely ignored by all modern browsers.)
Many other file types
encode the expected file length in the header,
in which case you can append whatever garbage you want without
having any effect.
But if you also store the file size with the hash,
then the reset attack fails, because a reset attack always
generates a file bigger than the original.
To create a collision, they would have to create a shorter
alternate message than the original, and then fiddle with the
extra bytes to get the desired target hash to come out.
This is significantly harder than just resetting.
(I'm not aware of anybody who has successfully
been able to reset MD5, mind you.
This is a protective measure: If somebody figures out how
to reset MD5, a small bit of work on your side will prevent
you from falling victim.)
Geocaching is sort of like
global hide-and-seek (with hints) for technology geeks.
I stumbled upon a non-GPS version of this diversion,
(not to be confused with
movies, another subject entirely).
By the way, if geocaching isn't enough "fun with a GPS" for you,
you can try
The Degree Confluence Project.
See the world with a GPS, experience other cultures, learn a few
words of the local language:
The Thais kept asking how many farang (foreigners)
did this and how much they got paid.
I must have heard the phrase "farang Baar",
(foreigners are crazy) more than a couple of times that evening.
Just because you have
the ASCII table memorized
doesn't mean you know how sorting works.
I remember a bug filed where somebody said that the "sort"
command was sorting underscores incorrectly:
this was claimed to be wrong "because underscore character
follow uppercase letters and precedes lowercase letters".
Well perhaps it does if you think ASCII sorting is the way
sorting should be.
ASCII sorting is so last century.
describes two types of sorting, "word sort" and "string sort".
And both of them sort punctuation before letters.
Public Radio International,
The Next Big Thing
The Gameboy Music Match.
These days, a lot of electronic music is performed directly
off of a laptop, which most people complain looks a lot like
someone up there on stage checking their email.
But Gameboy music isn't just for listening.
It's also a performance.
Nullsleep plays with both thumbs
tapping, both feet moving, and head swaying.
Okay, yeah, it looks like he's playing a video game.
But a really great
Read the episode rundown or listen directly to the fourth story,
Hot GameBoy Music Club.
(The story was re-run a year later under the much catchier title
New Old Sounds.)
When do you put "..." after a button or menu?
For example, some menus say "Save as..."
and some buttons say "Customize...".
What is the rule for dots?
Many people believe that the rule for dots is
"If it's going to display a dialog, then you need dots."
This is a misapprehension.
The rules are spelled out in the
Windows User Interface Design Specifications and Guidelines
(what a mouthful). Scroll down to "Ellipses".
I could repeat what's written there, or I could just tell you to read it.
I'm going to tell you to read it.
Okay, maybe I'm going to repeat what's written there, but briefly:
Use an ellipsis if the command requires additional information
before it can be performed.
Sometimes the dialog box is the command itself, such as "About"
or "Properties". Even though they display a dialog, the dialog
is the result, as opposed to commands like "Print" where
the dialog is collecting additional information prior to the result.
Plane-spotters to require government license.
The article spins it as a "benefit" for ground-based aviation buffs,
but this is just one of those "two steps back, one step forwards"
things. Plane-spotters were outright banned from airports in the
summer of 2003.
Now they can go back, but they'll need to shell out £15
for the privilege.
And if I, random small-time aviation buff, want to go out and look at the
pretty planes as they fly overhead, I'm out of luck.
The "authorized" plane admirers might even report me as a security risk.
I hope I won't be
convicted of international espionage.
Mike Pesca undertakes a textual analysis of the Friends theme song.
picks up the history ball and describes
how those FILE_SHARE_* values came to be.
When you're displaying a menu item or a dialog option,
and the option is not available,
you can either disable it or you can remove it.
What is the rule for deciding which one to do?
Experiments have shown that if something is shown but
disabled, users expect that they will be able to get it
enabled if they tinker around enough.
So leave a menu item shown but disabled if there is something
the user can do to cause the operation to become available.
For example, in a media playback program,
the option to stop playback is disabled if the media file
is not playing. But once it starts playing, the option
becomes available again.
On the other hand, if the option is not available for
a reason the user has no control over, then remove it.
Otherwise the user will go nuts looking for the magic way
to enable it.
if a printer is not capable of printing color,
don't show any of the color management options,
since there's nothing the user can do with your program
to make that printer a color printer.
By analogy, consider a text adventure game.
The player tries something clever like
"Take the torch from the wall", and the computer replies,
"You can't do that, yet."
This is the adventure game equivalent to graying out
a menu item. The user is now going to go nuts
trying to figure out "Hm, maybe I need a chair,
or the torch is too hot, or I'm carrying too much
stuff, or I have to find another character and ask him
to do it for me..."
If it turns out that the torch is simply not removable,
what you've done is send the user down fruitless paths
to accomplish something that simply can't be done.
For an adventure game, this frustration is part of the
fun. But for a computer program, frustration is not
something people tend to enjoy.
Note that this isn't a hard-and-fast rule; it's just a guideline.
Other considerations might override this principle.
For example, you may believe that a consistent menu structure
is more desireable because it is less confusing.
(A media playback program for example might decide to leave the
video-related options visible but grayed when playing a music file.)
The commentary after
my entry on taskbar grouping
drifted into people asking for still more features in taskbar
Writing the code is the easy part.
Designing a feature is hard.
You have several audiences to consider.
It's not just about the alpha geeks;
you have to worry about the grandmothers,
the office workers,
the IT departments.
They all have different needs.
Sometimes a feature that pleases one group
So let's look at some of the issues surrounding the
proposed feature of allowing users to selectively ungroup
items in the taskbar.
One issue with selective grouping is
deciding the scope of the feature.
Suppose the user ungroups Internet Explorer,
then closes all the IE windows,
then opens two new IE windows:
Do the new ones group?
If so, then you now have an invisible setting.
How do you configure grouping for programs that aren't running?
(How do you configure something that you can't see?)
Suppose you've figured that out. That's fine for the alpha geeks,
but what about grandma?
"The Internet is all disorganized."
"What do you mean?"
"All my Internet windows are all disorganized."
"Can you explain a little more?"
"My taskbar used to be nice and organized,
but now the Internet parts are disorganized and spread out all over the place.
It used to be nice and neat.
I don't know how it happened.
I hate the Internet, it's always messing up my computer."
What is the UI for selective ungrouping?
Anything that is on a context menu will be executed
accidentally by tens of thousands of people due to mouse twitching.
Putting the regroup onto the context menu isn't
necessarily good enough because those people don't even
realize it was a context menu that did it. It was just a mouse twitch.
Mouse twitches cause all sorts of problems.
accidentally dock their taskbar vertically;
accidentally resize their taskbar to half the size of the screen.
Do not underestimate the havoc that can be caused by mouse twitching.
Soon people will want to do arbitrary grouping.
"I want to group this command prompt,
that notepad window, and this calc window together."
What about selective ungrouping?
"I have this group of 10 windows,
but I want to ungroup just 2 of them,
leaving the other 8 grouped together."
Once you have selective/arbitrary grouping,
how do you handle new windows? What group do they go into?
Remember: Once you decide, "No, that's too much,"
there will be thousands of people cursing you for not doing enough.
Where do you draw the line?
And also remember that each feature you add will cost you another
feature somewhere else. Manpower isn't free.
But wait, the job has just begin.
Next, you get to sit down and do the usability testing.
Soon you'll discover that everything you assumed
to be true is completely wrong,
and you have to go back to the drawing board.
Eventually, you might conclude that you over-designed the feature
and you should go back to the simple on/off switch.
Wait, you're still not done.
Now you have to bounce this feature off corporate IT managers.
They will probably tear it to shreds too.
In particular, they're going to demand things like
remote administration and the ability to force the
setting on or off across their entire company
from a central location.
(And woe unto you if you chose something more complicated
than an on/off switch: Now you have to be able to deploy
that complex setting across tens of thousands of computers - some
of which may be connected to the corporate network via slow
Those are just some of the issues involved in designing a feature.
Sometimes I think it's a miracle that features happen at all!
(Disclaimer: I'm not saying this is how the grouping feature
actually came to be. I just used it as a starting point for
For another perspective, you can check out
KC Lemson's discussion of the feature-design
process a few days ago under the topic
There's no such thing as a simple feature.