Usable Security

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.

“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.

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.

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