CS / ITS PREPCOURSE · EXERCISE 05

No names.
Still identifiable?

Link fictional festival visits to public posts, then explore what different observers can see along a Tor circuit.

Offline teaching lab · synthetic data · no Tor connection or installation needed

Part A / Join the clues · about 15 minutes

  1. Use the visit records and public posts to find three unique name–visitor matches. Record the supporting row IDs. Keep Sam's ambiguous match separate.
  2. Check your candidate sets with the tool below. “Unique” means unique within these supplied records and assumptions.
  3. Try publishing times in broader buckets, then try event totals. Preserve distinct visitor counts per event while preventing your original row-level links.
  4. Export your revised release and your observations.

All visits occur on the same fictional day. Public posts report exact, accurate check-in times for this exercise. The visitor IDs are stable across events. There are no names in the visit table.

Visit records

20 records · 8 visitor IDs

RowVisitorEventTime

Public posts

RowNamePublic check-in statement

Try matching the rows yourself before revealing the candidate set.

Publish less revealing data

Buckets start on the hour and round down. A label 10:00 in a 15-minute release means [10:00, 10:15). Matching maps both visits and exact public clues into the same buckets. The source table above remains visible for comparison; only this preview is the proposed publication. These are alternative release designs: changing a release cannot undo information already disclosed.

Hint · What must the organisers keep?

They need a distinct visitor count for each event, not a list of individual visits. Aggregating can remove the stable IDs needed for your row-level join. It is not a general proof against all possible inferences.

Part B / Tor: inspect an observer's view · about 10 minutes

This model shows a three-relay circuit to an ordinary website, not an onion service. It models one passive observer at a time. Relay compromise, browser fingerprinting, malicious endpoints and combined observations are outside this single-observer view.

Client→Guard→Middle→Exit→Website
  1. Inspect guard, middle and exit views with HTTPS enabled. Save one observation that depends on your position.
  2. Compare the exit view with HTTPS enabled and disabled. Capture the change.
  3. Enable the identifying account login and inspect the website view. Capture the result even with HTTPS enabled.

Turning off HTTPS is a hypothetical comparison. This page never visits a website; Tor Browser normally uses HTTPS-Only Mode.

Tor relays remove successive layers of circuit encryption. HTTPS, when used, adds encryption to the website itself. Neither hides information from its intended endpoint.

Bonus / Compare patterns at both ends

An observer has recordings near users and near destination sites. These toy traces give burst start times in seconds. Compare the offsets from each trace's first burst; a constant delay may shift all times.

Entry-side traces

Exit-side traces

Try to match X and Y by hand first. More than one entry may fit.

Deliberately simplified synthetic patterns: real traffic has noise, multiplexing, padding and variable delays. A matching pattern is evidence for a hypothesis, not proof of a user's identity. This is not an algorithm for reliably identifying Tor users.

Programming bonus: implement candidate matching and time bucketing in bonus/starter.py. JSON source data is supplied.

Your lab record

Saved observations and observer snapshots remain until reload. Export before closing.

Further reading from the Tor Project