Why Johnny can read Pr0n.

Security Breaches have become a common event. Common wisdom is that the companies involved are not prepared to commit the time or money required to keep consumer data securely. Used correctly, every breach could have been prevented by cryptography. Is this because the users are stupid or because security applications are stupidly designed?

While these conditions may not be exclusive, the second is certainly true. Almost a decade after usability was exposed as a key problem in security applications by Whitten and Tygar, virtually every security application on offer is demonstratively unusable when attempting to perform the most basic workflow tasks securely. We can't know if the user is incompetent because we never gave them a chance.

One simple test to see if a security application is usable or not is to pick a simple task the user might attempt, replying to an email, copying music or video onto their computer, etc. and then consider if it is reasonable to expect the user to complete the task securely with respect to the type of risks that they might reasonably be concerned by. Does the user have enough information to be able to determine whether a particular choice is safe or not? Is effort required to determine the security context unreasonable?

When common applications are examined in this way it appears that nobody has ever performed a use case analysis. The systems turn out to be completely unusable. But use cases have been standard practice in security protcol design for years, what is the problem?

A part of the problem is that security is still largely regarded as a checklist compliance issue rather than a real requirement. The user asks for security so they are given a system that can be used securely, not one that they are likely to use securely. Current Web browsers 'solve' the security context problem by bombarding the user with useless warnings every time the security context changes. These are not meant to keep the user safe, the designers know that they will be turned off as the program is unusable otherwise. The only purpose is to dump responsibility for security problems onto the user.

Checklist security is the reason why it is impossible for a home user to use ACLs to protect their home movie content on their Windows Home Server. home Server is based on Windows Server 2003 which implements ACLs to comply with Orange Book and the Common Criteria. It is quite likely that use cases were performed in the design but I strongly suspect that they were security use cases, not use cases designed to determine if a typical user task could be completed securely.

Bad use case: Can Alice set read permissions on a directory?
Better use case: Can Alice store pr0n on her home computer so that she can read it but her son Johnny cannot?

Stated in this fashion it is pretty clear that the first one is not really a use case at all. But I now realize that I sat through a whole standards working group with thirty plus members that spent several years looking at a use cases document that was almost entirely of the first kind rather than the second. Writing good use cases is hard.

Another problem is that it most people find it very difficult to interpret the second use case correctly. Every one of the O/S vendors representatives I asked about the second use case interpreted it as 'how does Alice stop pr0n getting onto her computer' which is an entirely different problem. Since Marty Rimm's notorious 'cyberporn' media circus this particular security concern has been framed entirely in terms of controlling the communication channel: that is filtering Internet access. Framing is a real hazard when designing a system, what appears to be the primary security concern often is not.

As a parent of very young children I am far more concerned that they might find violence and horror than pornography. What they don't understand is unlikely to harm them but a young child can find relatively innocuous content very scary and have nightmares as a result. I have episodes of HBO Rome and Dr Who on the Home Server, the children are certainly not ready to watch those, we had to stop watching The Beatle's Yellow Submarine because it was too scary.

Trying to set protections on the 'scary stuff' directory using ACLs failed. Not only did it fail but the design of the Home Server means that it is impossible to achieve the desired outcome using ACL protections. To set access controls using Home Server you have to use the Home Server console. This system is actually somewhat easier to use, but only if you know it is there and the user experience does nothing to make the user aware of it when they discover that there is going to be no way to set the ACLs correctly.