Unhappy Security Dialogs
usersinhell.com
usersinhell.com
http://www.squarefree.com/2004/07/01/race-conditions-in-secu...
That delay has driven me nuts since it was implemented. It's the one thing I hate about Firefox: could never understand why the one button I wanted to click was never active when I wanted to click it, then became active after some flurry of activity trying to make it work.
Time delays are not a suitable solution to bugs. Time is money; don't waste mine for some obscure simplistic solution when there is another solution (even if the latter is harder to implement). If you _are_ going to use it, do something to indicate to the user that the system knows time is passing and the user should be patient: if the "yes" button is going to activate after 3 seconds, show a countdown timer or "thermometer" or fuse burning or something so I know "wait until an indicated time is reached". Don't just do nothing for a while.
At least now I know why it happens. I do appreciate that.
"People trying to be evil" isn't really a bug. Is a safe with a timer not a suitable solution for a McDonald's or a bank?
So why's it gone in Firefox 4?
It's exactly the same dialog, with exactly the same fields. The only difference is an icon that you'd never realize was different unless you had two dialogs open side by side. If a guy who writes software for a living can't tell them apart, I don't think the average user stands a chance.
If they actually want to fix this, they need completely different looks for the two popups. Or better still, simply skip the warning altogether for signed apps. If you downloaded it off the internet with the intention of running it, you're going to want to run it. Popping a dialog in your face isn't going to change that fact.
From that perspective, maybe the dialogs for signed and unsigned programs don't _need_ to be very different; most users don't care. The interesting distinction is between "this a program, which may take over your computer" and "this is a music file, which can do no harm".
The basic issue, of course, is that those are completely different statements, and only one of those can be easily checked.
On the other hand: the only thing that accomplished is that I now stopped using IE even if I quickly have to download something inside my development VM.
The advice really doesn't seem to fit the real world. Suppose you had a place with a dangerous undertow and a sign to warn people about it. If five people died one year after choosing to ignore the sign few people would agree that a sensible course of action would be to remove it.
"Yes, I want to run it. That's what I told you to do, stupid computer. What kind of moron do you take me for, anyway?"
What have SSL certificates got to do with code signing? I have a feeling it involves speaking authoritatively on a subject you clearly don't understand ("properly-encrypted checksum" indeed).
Likewise, code signing is an anti-tamper and publisher identification mechanism rather than anything which gives the end-user a reason to trust any signed executable. Again, having 15USD does not make you trustworthy.
Nothing in the world can make you trustworthy, I don't want to get into that discussion, which is also why I put it in scare quotes.
When you download a program, you will get one of three results, a big green bar, indicating lots of users who used this code were happy, a red bar, indicating lots of users who used this code was unhappy, or a grey bar, where nobody has ever used this code.
Red = Do not run this unless you want pain. Grey = It's new because it's probably new malware. Green = It's probably good, (though it could be a virus masquerading as a useful app)
You could get around this system by spoofing positive results, but it makes the job of the virus writer harder, because they have to work hard to "make it look legitimate".
This scheme is easily subverted many ways: by having the executable only being bad a few times, or much later than when the user could identify it as the source, or a collision attack against the hash function.
Also note that digital signatures are only as strong as their components. It doesn't matter that you signed it if you use md5sum in the process of signing it. An attacker just needs a binary that has the same digest as the one the signature says it does, which results in attacks that completely ignore the bits that involve the asynchronous keys.