Chapter 2 — Discrete mathematics

Lesson map

Lesson 02 published. Map, example, EX004.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Policy as logic"]
  N2["2.2 Sets of people and permissions"]
  N3["2.3 Counting burden"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX004"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Policy as logic"]
  N2["2.2 Sets of people and permissions"]
  N3["2.3 Counting burden"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX004"]

[Learning outcomes]
    |
    v
[2.1 Policy as logic]
    |
    v
[2.2 Sets of people and permissions]
    |
    v
[2.3 Counting burden]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX004]

Learning outcomes

You will (1) use sets and logic to state policy rules; (2) find contradictions between rules; (3) count combinations that affect usability.

2.1 Policy as logic

Aiko translates Greyford's password and access rules into logic. One rule says operators must lock screens when leaving a console. Another says control room consoles must stay signed in during incidents so alarms are never missed. Written as logical statements, the two clash during an incident when an operator steps away briefly. Adams and Sasse (1999) found that staff faced with conflicting or unworkable rules make their own compromises. Writing rules precisely exposes such conflicts before staff are forced to choose which rule to break.

2.2 Sets of people and permissions

Using sets, Aiko lists which staff groups hold which permissions. The intersection of field engineers and people with remote access to pumping stations shows who could change settings from outside the plant. The set difference between people trained on remote access and people who have it reveals eleven staff with access but no training. Sets turn vague worries into exact lists that managers can act on, and they make it easy to check whether a proposed change widens or narrows each group.

2.3 Counting burden

Aiko counts how many distinct sign-ins a field engineer performs on a typical day: laptop, remote access, maintenance system, email, timesheet and two vendor portals. Each has its own password rules. She computes that if each system forced changes on a different schedule, an engineer would face a password change roughly every week. Counting makes the burden visible. Sasse, Brostoff and Weirich (2001) argued that such burden drives the workarounds often blamed on users, so counting is a first step towards design changes.

Worked example

Aiko writes two rules in logic to expose a conflict, uses set operations to find untrained staff with remote access and counts sign-in burden.

Synthetic case. Rules, groups and counts are synthetic; Adams and Sasse (1999) and Sasse et al. (2001) are real.

Errors and limits

Logic captures written rules, not informal practice. Counts depend on a typical day that may vary.

Exercises

• EX004 — Rule conflict. Which two rules conflict in the control room?
  Show marking criteria

  Rubric: 3 = lock screens when leaving versus stay signed in during incidents;; 2 = both rules;; 1 = vague;; 0 = none.
• EX005 — Set difference use. What did the set difference reveal?
  Show marking criteria

  Rubric: 3 = eleven staff with remote access but no training;; 2 = untrained;; 1 = vague;; 0 = none.
• EX006 — Change frequency. How often might an engineer face a password change with separate schedules?
  Show marking criteria

  Rubric: 3 = roughly every week;; 2 = weekly;; 1 = yearly;; 0 = none.

Synthesis

Discrete mathematics turns policies and permissions into exact statements that reveal conflicts and burden.

Continue studying — chapter 02 of 50

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →