Sessions, device detection and the email you get when a browser you do not recognise signs in
Every signed-in browser is now listed with its device and approximate location, and can be revoked in one click. How the session row is found without being replayable, how a device is recognised, and why the alert email is idempotent.
The security page now lists every browser signed into your account: what it is, roughly where it is, when it was last seen, and a button to end it. Signing in from a device the account has not used before sends you an email about it. Here is how both halves work.
Finding the row without making it replayable
A session in the list has to be findable from the session itself. The naive way is to store the session id in the row, which turns the table into a list of valid session ids — a database leak would then be a pile of ready-made credentials.
Instead each row carries its own random token, and the token lives in the session payload. It survives the id regeneration that follows every sign-in, so the row keeps describing the same browser across the whole life of the login, and it authenticates nothing on its own: knowing it does not get you a session. The column is hidden from serialization so it cannot fall out of a response by accident.
Each row keeps the address, the user agent and the parsed browser, platform and device, plus the city and country, when it was last seen, and — once ended — when it was revoked and why. Revoking your own session, revoking every other one at once, and following the alert email's link are three different reasons, and the row says which.
Recognising a device
Recognition has two stages, because a brand-new browser has nothing to be recognised by.
Once a browser has been here, it carries a device cookie and that settles it. Before that, the device is matched on a fingerprint of the browser and platform — a hash of those two strings, nothing more. It is coarse on purpose. A fingerprint precise enough to be interesting is a tracking identifier, and this one exists to answer a single question: has this account signed in from something like this before.
The browser and platform themselves come from User-Agent Client Hints where the browser sends them, and from the user agent string only as a fallback. The UA string has been frozen, is trivially spoofable and — for anything Chromium — is deliberately misleading, so it is the second choice, not the first. Vendor spellings are normalised on the way out: nobody should have to read "Chrome Mobile iOS" or "GNU/Linux" in a security email.
Location is best-effort, over HTTPS, cached, and allowed to fail. A slow or failed lookup produces "unknown location" rather than a slow page. Geolocation is a helpful detail in an email; it is never allowed to block anything.
One alert, not a stream
The alert is easy to get wrong in the direction of noise. Ours is idempotent by construction: a given session produces a given alert once, and a device that bounces between two countries on a commute is worth one email a month, not one an hour. An account's very first device is recorded in the activity journal and is deliberately not emailed about — it is the one device nobody needs to be warned of.
The email carries a disavow link, good for fourteen days. Following it ends that session and marks it as disavowed, which is a distinct reason on the row and a distinct line in the journal, so "I ended this myself from my settings" and "I told you that was not me" never read the same afterwards.
Where it sits
Sessions, the journal and two-factor authentication shipped as one piece of work in the same week, and they are meant to be used together: the second factor stops the sign-in, the alert tells you it was attempted, and the journal is what you read afterwards.
Everything here concerns the account you sign in with, not the SMTP credentials your application uses — those are per project and are rotated from the project's own settings. The SMTP setup guide covers that side.