Psychological acceptability

A mechanism harder to use than no mechanism gets avoided

A security mechanism that is harder to use than having no security at all gets worked around. Users pick the weak password because the strong one is unmemorable, click through the warning because reading it slows them down, leave the video feed unencrypted because turning encryption on is one more step in a busy day. In none of these cases is the system being attacked directly. It is being avoided.

Saltzer and Schroeder gave this idea its name in 1975, in “The Protection of Information in Computer Systems”:

It is essential that the human interface be designed for ease of use, so that users routinely and automatically apply the protection mechanisms correctly. Also, to the extent that the user’s mental image of his protection goals matches the mechanisms he must use, mistakes will be minimized. If they must translate their image of their protection needs into a radically different specification language, they will make errors.

The class also uses a shorter, simplified version, which the slides attribute to Bishop, 2003: a security mechanism should not make a resource more difficult to access than if the mechanism were not present. Both wordings are examinable, and the practice quiz tests recognising each separately. They are one 1975 principle stated two ways, not two principles.

The principle is hard to apply because it asks a designer to model somebody else’s mental image, not their own. Programmers find it easy to set file permissions correctly. A secretary, with no training in the permission system, finds the same task much harder. Same mechanism, same interface, two outcomes, because the mechanism was built around the programmer’s mental model rather than the secretary’s.

Pitfall

Do not write “secure” when the question is really asking about “usable.” Psychological acceptability is a usability principle, not a strength measure: a mechanism can be cryptographically sound and still fail the principle because nobody can operate it correctly under normal conditions. Naming both of the wordings, not just one, is worth marks in its own right.

Strong on paper is not strong in use

Compare

Theoretical security

How strong a mechanism is on paper. A smart card stores a high-entropy cryptographic key in tamper-resistant hardware, resists guessing attacks, and matches an intuitive “possession” mental model, a physical key.

Effective security

How strong a mechanism is once real people use it day to day. Cards get left at home, readers malfunction, not every device or OS supports them, and a card left in a hot car stops working. A cryptographically weaker password, with no hardware dependency, gets used correctly far more often.

Recall

Why can a mechanism be cryptographically strong and still fail the principle of psychological acceptability?

Because the principle measures whether people actually use a mechanism correctly, not how strong it is on paper. A smart card can hold a far stronger key than a password and still fail in practice (left at home, unreadable in a broken reader, unsupported on some device) while a weaker password gets used correctly far more consistently.

Passwords show the same tension from the other side. A password chosen for acceptability rather than strength is a name, a place, or a dictionary word: easy for the user to set and remember, and just as easy for an attacker to try. Three attacks target that gap. The attacker checks the target’s own social media for guessable material (social engineering), runs a dictionary attack that also tries common substitutions (security to s3cu4itY), or brute-forces every combination once the search space is small enough to exhaust. Unpredictability defeats the guess and the dictionary; length defeats brute force. Both pull against the “minimal overhead” that psychological acceptability asks for, which is why weak passwords are the norm. 02-05 and 02-06 work through how to get both properties without losing memorability.

Patching and configuration fail on friction, so make the secure option the default

A patch is an update, usually fixing a security problem. Ideally, maintaining system security happens invisibly in the background, which is exactly where it collides with the four ways patching creates friction.

Exam detail

Patching friction comes in four forms. Disruption (halted work, forced restarts). Complexity (some patches need technical judgement a casual user does not have). Notification fatigue (too many alerts for minor updates). Compatibility issues (a patch that fixes one thing and breaks another).

One design resolves the collision: iPhones queue the update and notify the user once, when conditions are already right. “An update is available. It will be installed tonight while your device is charging and connected to Wi-Fi.” The user does nothing, the device loses neither charge nor mobile data mid-update, and the patch still lands.

Building a secure system is not the same as running one securely: it also has to be configured correctly for its environment, and developers understand the available options far better than the people who end up leaving them alone. In 2009, insurgents in Iraq accessed live video footage from US drones because the communication channel was unencrypted. The encryption technology existed on the drones and was simply never enabled. The same failure, at smaller scale, is why most people never touch the privacy settings on a social media account.

The lecture’s fix is not “train the user harder.” It is to set the default to the secure option, so the path of least resistance and the secure path are the same path.