Chapter 11 — Networks and protocols

Chapter 11 — Networks and protocols

Lesson map

Lesson 11 published. Map, example, EX031.

flowchart TD
  N0["Learning outcomes"]
  N1["11.1 Email authentication"]
  N2["11.2 Signals users see"]
  N3["11.3 Actionable warnings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX031"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["11.1 Email authentication"]
  N2["11.2 Signals users see"]
  N3["11.3 Actionable warnings"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX031"]

[Learning outcomes]
    |
    v
[11.1 Email authentication]
    |
    v
[11.2 Signals users see]
    |
    v
[11.3 Actionable warnings]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX031]

Learning outcomes

You will (1) explain how email authentication helps users; (2) relate protocol signals to what users see; (3) design warnings that people can act on.

11.1 Email authentication

Aiko studies how email moves across networks and how domains publish records that let receiving servers check whether a message really came from them. When checks fail, the receiving system can mark or reject the message. At Greyford, many phishing emails imitate the utility's own domain. Strong domain checks stop much of that before staff ever see it. Aiko notes that every attack stopped by a protocol is one that no person has to judge, which is the most reliable form of human factors design.

11.2 Signals users see

Some checks result in signals shown to users, such as a banner saying a message came from outside the organisation. Aiko examines how staff read the banner. Interviews show that because almost every supplier email carries it, staff ignore it. The signal is technically correct but carries little information. She proposes showing a stronger warning only for external senders using names similar to internal staff, which is rarer and more meaningful. She tests the idea on a month of synthetic mail logs and finds the stronger warning would appear on about two messages per person per month, rare enough to be noticed.

11.3 Actionable warnings

Aiko applies lessons from usable security research. Whitten and Tygar (1999) showed that security interfaces confuse users when they demand understanding of concepts users do not have. A good warning says what is wrong in plain words and offers one clear action, such as reporting the email. Aiko drafts a warning: "This sender is outside Greyford but uses a Greyford colleague's name. If unsure, press Report." She tests it with ten staff, eight of whom correctly choose to report. Two staff asked what Greyford colleague meant, so she adds an example.

Worked example

Aiko explains domain checks, finds an ignored external banner and designs a rarer, actionable warning tested with staff.

Synthetic case. Warnings and tests are synthetic; Whitten and Tygar (1999) is real.

Errors and limits

Lookalike-name detection has false positives. Warnings lose force if overused.

Exercises

• EX031 — Protocol value. Why are attacks stopped by protocols valuable for human factors? Rubric: 3 = no person has to judge them;; 2 = no judgement;; 1 = vague;; 0 = none.
• EX032 — Ignored banner. Why do staff ignore the external sender banner? Rubric: 3 = almost every supplier email carries it;; 2 = too frequent;; 1 = vague;; 0 = none.
• EX033 — Warning test. How many of ten staff chose to report with the new warning? Rubric: 3 = eight;; 2 = 8;; 1 = vague;; 0 = none.

Synthesis

Protocols remove many decisions, and warnings work only when they are rare, specific and actionable.

Continue studying — chapter 11 of 50

← Chapter 10 (draft) · Course chapter index · Chapter 12 (draft) →