Unusual sign-ins must be reported proactively
Aliases: new device alert · impossible travel · sign-in notification
What it is
People do not open the session list every day. Proactive notice means that after the server judges a sign-in unusual (new device, new region, odd hour, impossible travel), it pushes the event to the person on an already-verified channel: mail, a push, or SMS, with coarse device and place, time, and a “that wasn’t me” entry. This entry is about the system finding the person. It does not cover how the list is drawn, and it does not cover how a single session is revoked after the tap—notice must arrive; revocation is the next act.
Why it happens
The window on unusual occupancy is often short: a stolen session immediately changes email or moves assets. Waiting for the next casual visit to settings closes the window. Proactive notice turns detection from “people come looking” into “the event comes looking.” False positives train people to ignore (a new VPN, travel, an OS upgrade seen as a new device), so real alerts are swept away too. The notice channel must be independent of the suspicious session just created: a “welcome” only on the new device notifies the intruder. Mail or a push to an old device or old mailbox sends the message where the person might still be. Copy must support “was this me,” not only “activity detected.”
Studying it
With a real or injected new-device sign-in, compare no notice, in-app bell only, and a push to an old channel: delay until the person finds the anomaly, and ignore-rate on false positives.
Independent variables: channel (push to old device, verified email, welcome page on the new device only), unusualness rule (new device, cross-city, impossible travel), whether copy includes checkable traits. Dependent variables: time from unusual sign-in to the person acting, false-positive taps on “this was me,” true anomalies ignored.
In the lab “unusual” is announced by the experimenter, so people are alert. Field work must count travel and cafe Wi‑Fi as false positives. Open rate is not success—“that wasn’t me” must lead to an action that can void the session. If the channel itself is stolen (mailbox already lost), notice fails; mark that as a recovery-design bound.
Where it stops holding
Accounts with no verified contact cannot be found proactively; say so when binding a channel (“without this you will not get unusual-sign-in alerts”) rather than pretending notice will occur. High-frequency login on integration test accounts will flood the channel; those need a user-facing digest, not one mail per event. For supervised accounts the notice goes to the guardian channel. Law or enterprise policy may forbid putting place in email; use device class and time instead. A brand-new account has no “old device”; the first sign-in is not unusual.
Applying it
- After a successful sign-in from a new device or an unexplained place, push to the email or old device verified before that sign-in, with time, coarse place, device class, and a “that wasn’t me” link to a handling page.
- “That wasn’t me” must not open a help article; it should land on the session list or one-tap void of that sign-in, and suggest checking password and bindings.
- Exclude clear owner patterns (just replaced a phone and confirmed on the old one) to cut false positives; offer “this was me, remember this device” on false alarms.
- Verify: sign a test account in from a never-before device; the old mailbox or old device should receive an understandable notice promptly, and the new device must not be the only place that “that wasn’t me” works—otherwise the control protects the intruder. After tapping it, the new session should die. Track false-positive rate, but do not silence notices for brand-new devices just to lower it.