Skip to content

PATTERN Cited by 1 source

Ephemeral per-trip sensitive input

Problem

A two-sided marketplace needs one party to give the other party a piece of high-sensitivity information for a single interaction — a gate code, a building access pin, an intercom shortcode. Storing this persistently (as a user preference) increases the breach surface significantly: a compromise of the rider-profile store leaks access codes to physical spaces where riders live.

But: the information is genuinely needed — the platform can't simply refuse to transfer it without forcing riders back into the communication black hole.

Solution

Treat the information as ephemeral sensitive data scoped strictly to the trip:

  1. Never persist beyond trip boundary. Delete at trip completion (or cancellation). No cross-trip memory.
  2. Audience-of-one. Only the specifically-matched driver on this trip sees it — not past drivers, not future drivers, not other riders in the same household.
  3. User-controlled visibility + revocation. The rider can view what was shared and delete it at any point during the trip.
  4. Anti-exfiltration hardening. Screenshots blocked on the driver's screen where the code is rendered, to prevent the driver from saving it and re-using it on a future trip (or passing it to a third party).

Canonical instance — Lyft gate codes

Per the 2026-04-23 Lyft write-up (sources/2026-04-23-lyft-smarter-pickup-experience-for-gated-communities):

"We built in privacy controls that let you view or delete your instructions at any time after sharing. Gate codes are never stored between trips, and only your matched driver ever sees them on their navigation screen on their way to pick you up. To further ensure your gate codes stay protected, we implemented safeguards to prevent screenshots."

Mapping the four controls:

Control Lyft implementation
Never persist beyond trip "never stored between trips"
Audience of one "only your matched driver ever sees them"
Rider-controlled visibility + revoke "view or delete … at any time after sharing"
Anti-exfiltration "safeguards to prevent screenshots"

Why this shape works

  • Threat-model matched. The sensitive part of a gate code is its long-lived validity (the same code opens the gate next Tuesday too). Ephemeral per-trip storage breaks the long-lived attacker value: even if one trip's rendering session were intercepted, the platform itself doesn't hold anything past trip end.
  • User agency retained. The rider can see what they shared, delete it if they made a mistake, and control the interaction within the trip.
  • Minimal cross-trip graph. If the rider uses Lyft at a different address tomorrow, the previous gate code doesn't follow them around.

The persistent-preference split

Lyft explicitly signals the non-sensitive kind of instruction might move to persistent storage in future work (e.g. "call building A concierge") — but sensitive codes stay ephemeral. The design move worth noting is that the platform makes the distinction between persistent preference and ephemeral sensitive data explicit, rather than treating all gate-related context as one data type.

Last updated · 550 distilled / 1,221 read