Reading your Instagram login history

Somewhere in your export is a file most people never open: a table of every recent
sign-in Meta recorded — when, from where, on what. It is the closest thing the
archive has to a security camera, and like most security cameras it is grainy,
windowed and honest only about what it actually saw. This post reads that file with
you: where it lives, the six fields it contains, what this product's Login Guardian
does with them (including the exact score arithmetic — no black box), and the limits
that decide how much a "fair" verdict should worry you.

The feature itself lives in Settings → Account → Login Guardian and computes
entirely on your device the moment an archive is loaded — no account, no upload,
no server round trip.¹ What follows is its whole logic, because a security
score you cannot audit is a mood, not a measurement.

1. 1minwhere the file is and the six fields it holds.
2. 3minthe flag rules and the score's line-by-line arithmetic.
3. 5minthe limits that decide what a verdict can and cannot mean.

Where the file lives, and what is in it

The source is login_activity.json — or login_activity.html in older exports —
inside the security_and_login_information folder of your archive.² The
parser accepts both: the JSON path reads the export's string_map_data rows, the
HTML path converts the table, and both land on the same record shape:³

A second file feeds context, not scores: account_history (from
account_history.json or profile_changes.json) contributes password-change and
bio-change counts — "1 password change(s) on record" is shown as security context,
not as a deduction.⁴

That is the entire sensor. Six values per sign-in, one file of profile edits. The
next section is what gets computed from it.

What the Guardian computes

Everything runs through one function the moment your archive loads — deterministic,
repeatable, and testable: the repo's test suite asserts the model version, the
0–100 bounds and the verdict bands on every run.⁵

The three flags. Each recent login is checked for:

1. odd-hours — the login's hour is between midnight and 05:00 UTC. The code

   comment states the reason for the fixed window plainly: the report is computed
   once and cached, and a local-time hour "would make the same login flag
   differently per viewer TZ".⁶ Deterministic beats clever here — but see the
   limits section, because one product card phrases this differently than the code.

2. unknown-device — the device field is empty.
3. no-location — the location is empty or the placeholder —.

The counts. Distinct devices, distinct IPs, and a location histogram where
—/empty buckets as "Unknown". Locations display sorted by frequency, capped at
ten; the recent-logins list shows twelve; flagged odd-hours entries show twenty.⁷

The deductions. Score starts at 100 and loses, in order:⁸

Then clamp 0–100, map to bands — excellent ≥85, good ≥70, fair ≥50, else
at-risk — and write findings: location count (warn past 3 cities, alert past 6),
odd-hours share, new-device count (alert past 3), password-change context, a
recommendation to change the password and enable two-factor when the score lands
below 50, and a coverage line that tells you how far back the file reaches.⁹

Note the shape of the table: every deduction is a quantity rule — how many
cities, how many addresses, what share of rows — because quantities are the only
thing six fields can support honestly. There is no provenance logic, no ASN or
VPN lookup, no comparison against anyone else's account: the model can notice that
the file is wide, and it cannot notice that the file is wrong. The findings
translate each quantity into language ("If you travel this is normal — otherwise
review each one below") precisely because the arithmetic alone reads like an
accusation.

The findings are the disclosure mechanism. The score is a heuristic — model version
guardian-1.0, an LMKFR construction, not a Meta measure — and the product's own
score-honesty sweep kept this one precisely because its inputs are visible on
screen: the arithmetic above is the spec.¹⁰

What the score is, and what it is not

Two things make this 0–100 safe to show, and one makes it worth showing at all.

It is safe because the deductions are published (the table above is the whole
model — there is no learned weight, no hidden factor, no data leaving the device to
produce it), and because the findings explain it: a number without its reasons
is a nag; a number with its reasons is a report. It is worth showing because
security is the one area where a coarse signal genuinely helps — "at-risk" plus
four visible causes beats a nagging feeling you cannot name.

It is not a measure of whether your account was compromised. It cannot know.
There is no breach feed here, no password-check service, no session inspection —
the arithmetic sees quantity and timing of recorded sign-ins, nothing more. Two
cities and a new phone can push a perfectly healthy account into "fair"; a quiet,
compromised account with one stolen session in the export's window can look
"excellent". The verdict describes the pattern in the file, and the file is a
window (see the limits below).

The honest limits, in the order they bite

It is recent history, not your life. The coverage finding says so itself:
"Instagram exports only include recent history — check Settings → Security in the
app for the live session list".¹¹ The export is a snapshot of a window;
the live session list on your phone is the authority on what is signed in right
now. This is the same date-range honesty the FAQ applies to the whole archive:
the export is only as complete as the range you requested.¹²

Locations are Meta's labels. No IP→city lookup happens in this product — the
location string is copied verbatim and bucketed by exact match. Where Meta wrote a
city, you get a city; where it wrote —, you get "Unknown". The score penalises
the number of distinct labels, never their provenance: it cannot tell a frequent
flyer from two home cities, a VPN from a second household, or a spoofed address
from a real one. The findings say as much — "If you travel this is normal —
otherwise review each one below."

Device strings are only as good as the export's. The HTML table path never
fills the device field, so every HTML-export login is an automatic
unknown-device flag — a parser limitation, not a fleet of strange machines.¹³
There is no hardware fingerprinting; "unknown" means "the column was empty".

Odd-hours needs a parseable timestamp. Logins whose time fails to parse become
time = 0: they still count in the total, but drop out of the odd-hours ratio and
the flagged list. A file full of unparsed times would read as calm — which is why
the report prints the coverage line instead of hiding the denominator.

No 2FA data is read. The export folder contains two-factor activity, but this
product's parser does not turn it into findings — the report can recommend
enabling 2FA when the score falls below 50, and it has no way to know whether you
already have it. The live settings page on your device remains the only place that
answer exists.¹⁴

Scores are inputs-disclosed heuristics, not verdicts on your security. Read
the deductions, read the findings, then go look at the actual session list the
coverage line points you to. The score's job is to make you open that list.

Questions this comes up

The security-privacy post for the archive's whole privacy surface; the
keeping-control post for local erase and what this audit touches; the
what's-in-the-export post for the folder this file came from.

¹: apps/web-next/src/views/Settings.tsx (Guardian mounted inside Settings
→ Account) and views/LoginGuardian.tsx — the report is built with
buildLoginGuardian(archive) in component state; nothing is transmitted.
²: packages/shared/src/parsers/privacy.ts — filename match
/login_activity\.(?:json|html)$/i, with an HTML→JSON conversion for the table
form.
³: types/privacy.ts — LoginRecord: ip, userAgent, device, location, time, timeLabel; time parse order is the time value, then the row timestamp,
then the title, else 0.
⁴: analytics/login-guardian.ts — password changes matched by /password/i
in title or value, bio changes by /^bio$/i, from archive.privacy.accountHistory.
⁵: analytics/login-guardian.ts (MODEL_VERSION = 'guardian-1.0') and
test/run-tests.ts — asserts the version, score ∈ 0..100, band membership and
that the location total equals the archive's login count.
⁶: analytics/login-guardian.ts — flag condition getUTCHours() < 5, with
the inline rationale: local-time hours "would make the same login flag differently
per viewer TZ".
⁷: analytics/login-guardian.ts — locations top 10, odd-hours rows first 20,
recent logins first 12.
⁸: analytics/login-guardian.ts — the deduction table and 0–100 clamp,
verbatim source of the table above.
⁹: analytics/login-guardian.ts — findings builder: counts, location
warn/alert thresholds (3/6), odd-hours warn (>0.2), new-device alert (>3),
password-change context, sub-50 recommendation, coverage line.
¹⁰: Score-honesty sweep record in the project state log: the Guardian score and
privacy-footprint percentage were kept specifically "which are disclosed with their
inputs" — unlike the engagement-style scores removed from Insights.
¹¹: analytics/login-guardian.ts — "History covers logins up to {date}.
Instagram exports only include recent history — check Settings → Security in the
app for the live session list and enable two-factor authentication there."
¹²: The FAQ's date-range answer — the export is only as complete as the
range you request; "All time" is the only safe setting.
¹³: parsers/privacy.ts — the HTML extraction path leaves device empty by
construction; only the table path fills it from the user-agent column.
¹⁴: types/privacy.ts — PrivacyData carries no 2FA, verification-method or
login-success field; the report's 2FA mentions are recommendations only.