What must each row of a signed-in-devices list carry, and how far can a user trust those fields?

## What this list is for A signed-in-devices list is a **projection of the server-side session records** held for one subject — one row per live record, rendered for a human to read. It is not an audit log and not a security report. Its single job is **recognition**: a yard supervisor whose account is signed in from several wagon-inspection tablets has to look at a row and decide *that is the tablet I left in the cab on Tuesday*. Every design decision on this surface follows from that job, and from one uncomfortable fact — the server knows far less about the client than the row implies. The rows are the same records the authentication check reads on every request. The list does not introduce new state; it exposes state that already exists, which is why the surface is cheap to build and easy to get subtly wrong. ## The fields, and what each one is actually worth | Field | Where it comes from | What it proves | |---|---|---| | Device label | Parsed from the `User-Agent` string the client sends, or a name the user typed | Nothing on its own — the caller asserts the string and may send any value | | First seen | The server's clock when the record was created | Reliable | | Last seen | The server's clock on the most recent request presenting this reference | Reliable, but only as fresh as your write policy allows | | Approximate location | Inferred from the network address the request arrived from | A guess: carrier and shared-egress addresses land in the wrong city routinely | | Current session | The server comparing the presented session identifier against this row's own key | The one thing about the client the server knows first-hand | Two consequences fall out of that table: - **Parse the agent string, never render it.** `Mozilla/5.0 (...)` means nothing to a supervisor; *a tablet browser* does. Keep the raw string for support, show the parse to the user, and accept that a caller who wants to look like something else can. - **Label the location as an inference.** *Near Doncaster* invites a false accusation when the tablet is on a mobile connection that egresses two hundred kilometres away. *Approximately, from the network address* is honest and still useful, because what the reader is really checking is whether anything looks wildly wrong. A row may also carry a **created-by** hint — signed in with a password, or with a second factor — but keep the field count low. Every extra column is one more thing the reader has to interpret, and interpretation is exactly what this surface is trying to avoid. ## Keeping last-seen fresh without a write per request Last-seen is the field readers trust most and the one that costs the most. Writing it on every authenticated request turns a record you otherwise only read into a write on every request, on the hottest path in the system. The usual resolutions, in increasing order of effort: 1. **Rate-limit the write.** Compare before writing: if the stored value is younger than a few minutes, skip it. Precision of five minutes is far more than a human needs, and the write rate drops by orders of magnitude. 2. **Ride an existing write.** If the record is already being rewritten for other reasons on each request, last-seen costs nothing extra — it rides along. 3. **Publish the precision.** Say *last seen about 5 minutes ago*, not a timestamp to the second you cannot back up. An interface that claims more precision than the write policy delivers will be caught out by the one user who tests it. ## The surface has two possible readers The legitimate user is one of them. The other is whoever else currently holds the account. For that reader the page is a **reconnaissance surface**: it tells them exactly which of their footholds you can see, and which of their sessions you have not noticed. That does not mean the feature is a mistake — a user who cannot see where they are signed in cannot act — but it does shape it: - Show enough to recognise a device and not enough to evade detection. - Do not expose internal record keys; a row identifier the page uses is enough. - Whether opening the page should demand fresh proof of identity is an elevation decision, made once for all sensitive pages, not something this surface invents for itself. ## Where the list stops The row displays. Deciding that a row looks suspect is a separate judgement with its own signals, ending every session at once is a separate mechanism, and the clocks that expire a record on their own are separate again. Confusing display with state is the classic bug here: hiding a row from the list does nothing whatever to the record behind it, and a user who pressed something and still sees a stale row on another device will report exactly that.