Comments on: Dangerous Analogies

By: Usable Security » Blog Archive » Microsoft’s Folly

Usable Security » Blog Archive » Microsoft’s Folly — Mon, 18 Jul 2005 22:40:42 +0000

[...] entally, the explanation of this “Law” abuses the type of real-world analogy I recently described. There’s a nice analogy between running a program and eating [...]

By: amonynouse

amonynouse — Fri, 01 Jul 2005 01:29:25 +0000

Argument by analogy is just like trying to hit a large trout with a spade. While it’s underwater.

By: Usable Security » Blog Archive » Zaptastic Author Misses the Point

Usable Security » Blog Archive » Zaptastic Author Misses the Point — Thu, 19 May 2005 09:03:37 +0000

[...] line, and sinker. This is exactly the type of mistaken comparison I was talking about in recent entries. Viruses are dangerous when they enter your body because they have comp [...]

By: Stu

Stu — Wed, 18 May 2005 04:12:14 +0000

Your comparison between software and a building/bridge misses the mark. Youre comparing a base product (software) with a completed product (bridge). A more acurate comparison is between software and bricks. You use both which are mass produced and identical to create a unique result. The bridge is analogous to your personal computer with the programme installed on it - the person who set this up is responsible for ensuring that it doesn’t break (ie: not the manufacturer).
The company that made the bricks made no guarentee that the bridge won’t fall down, they merely state that if used properly in a suitable environment then all should be fine. If an engineer built a bridge on sand or without enough support stands then the brick maker isn’t at fault when it falls down.
The software in the box IS secure, its when you install it on a system which allows other (bad) people to access it and exploit weaknesses that it fails. This is expressly outside the control of the programmer.
You can argue till your blue in the face that software should be designed with this use in mind (the lowest denominator) but the response is “WHY?”. As an informed user I personally suffer no spam, no viruses, no spyware or any of the other problems people complain about, so the system/software DOES work, only people don’t use it properly.
If this is too hard for the average user then this means that you have to make it easier, not more secure - ie: create a brick that knows how a bridge should be built.

By: Ping

Ping — Sat, 14 May 2005 20:57:33 +0000

You and I are talking about different things. I agree with you that there are certainly human expectations for how parts of a user interface behave. But by “relationships” I didn’t mean relationships in people’s minds; I meant cause-and-effect relationships among the software components. These don’t exist unless you write the code to make them happen.

By: David Hopwood

David Hopwood — Sat, 14 May 2005 17:59:15 +0000

Why?

By: George W. Bush

George W. Bush — Fri, 13 May 2005 18:52:27 +0000

Maybe this blog should include some sort of login to at least kinda-sorta authenticate posts?

By: Richard M. Conlan

Richard M. Conlan — Fri, 13 May 2005 18:51:23 +0000

“The huge difference is that objects in the real world come with existing relationships, but objects in the software world do not.”

Not true. Objects in the software world might not come with existing PHYSICAL relationships, but they are surely saddled with psychological relationship.

At a base level a button is there to be pushed and a slider there to be slid and an option group there to be…erm…optioned. At a slightly higher level there are expectations that, say, blue-colored text is probably a hyperlink (especially if underlined) and clicking it should open SOMETHING; a little disk icon should save whatever I am working on; a little printer should print; &c.

But those are all really simple / low-level expectations. The bigger issue is that a good GUI will often mirror elements of the problem-domain, and inherently brings along some expectations. For instance, if I make an application that models a slot machine then there should probably be a pull handle, drums that spin, an area little coins come out, and so forth. Technically I could model a slow machine where you push a button, random symbols are just displayed, and a counter just tallies wins and losses…but by pulling in the analogy of the real slot machine I add a lot of inherent usability…but at the cost of bringing along certain OTHER expectations that I might not want to include.

The point of all this being that analogies, whatever their evils, tend to be very helpful in creating abstractions, and we have to take the good with the bad. So, we are forced to work within certain restrictions as well, even if the medium doesn’t inherently include them.

By: Nikita

Nikita — Fri, 13 May 2005 04:46:47 +0000

It may be possible to hold programs to a higher standard of correctness, but the real question here is cost. If you offered people to build one bridge you could be sure worked, or 10 bridges that would probably work 90% of the time, people would go for the one bridge. Not the same with software, and with good reason: a browser that only crashes occasionally is much more useful to me than a bridge that only fails sometimes. And I think lots of people made the choice to go with something that may not function perfectly, but has more features, or is available today rather than a year from today. Enough of them in fact that not only did these low-assurance systems succeed, but the whole idea of making high-assurance systems has become very much of a niche field.

The adversarial model, which has always been a concern, but only recently a pressing one, has really turned this whole situation on its head. There are few useful incremental improvements in security. A program with 90% fewer security holes is basically as bad. I think that recently, people have started being more willing to pay the cost for making software more reliable and secure, but our whole process of creating software has a long way to go before that’s really possible.

By: Ian Bicking

Ian Bicking — Wed, 11 May 2005 19:23:02 +0000

I’ve thought about that too — more about the relation or contrast with civil engineers, but the same issue of explanations and metaphors. And always a bit confusing, *computers* actually fulfill all those engineering expectations pretty well, but the programs don’t. So how do we explain that? Lots of people try with process, describing how programmers work differently than engineers, but that’s not a very good justification or explanation; it doesn’t point out the qualitative differences in the work produced. I certainly don’t fully understand the combination of math, bureacracy, and engineering that makes up a typical program, which makes it pretty darn hard to explain.