Stadium turnstiles must validate season passes offline at kickoff — how do you model a decision the server cannot make?

## Why this leaf's usual answer does not apply Everywhere else in client threat modeling the conclusion is the same: the client-side check is UX, so move the decision to the server. Season-pass turnstiles at a full stadium are the case where you cannot. Ten thousand people arrive in twenty minutes, the gate has to resolve in a few hundred milliseconds, and connectivity at kickoff inside a concrete bowl full of phones is exactly when it is worst. The requirement is not negotiable, so the scanner validates against a list synced overnight and the authorization decision genuinely executes on hardware you do not own. The senior move is to stop arguing and start pricing. A threat model whose only output is "this design is unsafe" for a design that cannot change has produced nothing. What it should produce is the list of properties you lose, what each loss is worth, and what you buy back with detection. ## What you lose, precisely **Revocation lag.** The local list is as stale as the sync interval. A pass cancelled for non-payment, a chargeback, or a banning order keeps working until the next sync. The risk window is a design parameter you can shorten — sync more often, push a small high-priority deny list on a faster cycle over whatever connectivity exists between events — but never eliminate. **No global uniqueness.** Gates cannot see each other in real time, so nothing stops the same pass being presented at three entrances within a minute. This is the property that turns a single leaked pass into an economic problem instead of an anomaly, because it scales. **Format disclosure.** A reseller who buys a scanner from a decommissioned venue, or gets ten minutes alone with one, learns the pass format and the validation logic. Assume the scanner is fully understood by your adversary. That is the same modeling assumption as any client device, applied to hardware you never think of as a client. **Secret extraction.** If the scanner holds a venue-wide secret that lets it verify or, worse, mint passes, extracting it forges passes indefinitely. This is the difference between an attacker who can copy one pass and an attacker who can print them, and it should drive the design more than anything else — nothing in the scanner should be sufficient to create a valid pass, only to check one. ## The judgment call: which way it fails This is the question the model exists to answer, and it is not primarily a security question. - **Fail closed.** Ambiguous scan, the gate stays shut. Protects a small, bounded per-admission loss — one person's ticket price. Costs you people backed up outside a gate that will not open, which at scale is a crowd-safety event, a licensing conversation and a front-page photograph. - **Fail open.** Ambiguous scan, let them through and log it. The loss is duplicated admissions, which is money, and money at a known unit price. For a stadium at kickoff, fail open is usually the right call, and being able to say *why* is what separates a principal answer from a reflexive one: the asset protected by failing closed is smaller and more recoverable than the asset destroyed by failing closed at the wrong moment. The same reasoning would invert for a gate protecting a restricted area with no crowd pressure behind it. The principle is that fail-safe direction is set by which asset the failure mode threatens, not by a general preference for strictness. ## What you buy back Having conceded prevention, spend the budget on bounding and observing: - **Make copies expire.** A pass that presents a code changing on a short cycle, derived from something the pass holder's device or card computes, means a photographed or screenshotted code is worth minutes rather than a season. The scanner still verifies offline; the copy just stops being durable. - **Reconcile as connectivity allows.** Gates upload scan logs between surges and after the event. Duplicate entries surface, and the same pass appearing at gates far apart is a strong signal. - **Detect during the event where it is cheap.** A steward alerted to a duplicate scan at a gate, or a seat-level check on a contested seat, resolves the case without holding the queue. - **Act after the event, not at the gate.** The consequence for a duplicated pass lands on the account: cancellation, a charge, a ban. Enforcement moved from the millisecond path to the business process, which is where it can afford to be careful. - **Cap the exposure per pass.** A pass that has already entered can be flagged locally at that gate, and per-account limits on how many passes may be transferred bound how far one compromised account scales. ## Stating the residual out loud The model ends with an accepted, quantified loss: some duplicate admissions per fixture, bounded by the code rotation window and the transfer limits, detected afterwards and charged back where possible. Writing that number down is the deliverable. It converts "the client cannot be trusted" from a slogan into a business decision someone can own, revisit when the numbers move, and defend to a finance director who asks why the gates let anyone in unverified. ## The interview signal Weak answers here try to eliminate the constraint — put it online, add a cellular backup, require an app. Strong answers accept a genuine availability requirement as a first-class input to the model, name the properties lost, choose the failure direction with an argument about which asset is worth more, and close with a residual risk stated as a number rather than a shrug.