Keeping control of your LMKFR data
What the settings page is actually for, how erase and its 30-day window behaves, what sync puts on a server, and the three honest answers about the part of your data you were always allowed to say no to.
The most dangerous page of a privacy product is its settings page. It is where the
choices that shape your exposure result from the ones you made at export, and where a
read-every-word assumption stops working. What stays in LMKFR's settings is a set of
things that are yours and should be yours, reported plainly: what the app currently holds
about you, what pulses away from your device, and what it costs to end either. This is
the page of the series about closing that loop.
Everything on this page has an off, and an off means it stops working, not it hides.
Local mode never touches a network; sync is opt-in and split-key; Ghost Mode — the
setting for the LMKFR account that exists for the opt-in sync tier — erases on a
deadline you can no longer cancel once the deadline lapses, and a 30-day grace window
exists for the other case. The privacy report enumerates what the app understood about
your archive, in your own device, and then it lets you end it.
- 30sthe app's answer to three questions: what it holds, what it sends, what it
- will delete.
- 4minthe contents of the settings page that matters, one by one.
- afterwards — the opt-in sync tier, its keys, and why erase is also on this list.
The settings you should know exist
| Setting | What it actually does |
|---|---|
| Login Guardian | Reads the device and location trail from your own login storage: timestamps, IPs, and low-frequency flags. It is the two-line audit of your own history, on your own data. |
| Privacy report | The inventory of what the archive already says about you, in the same place: ad interestsand topics, the advertisers whose requests you are on, synched contacts. It is your own data, reported back to you because the export is where it lives. |
| PDF report | The snapshot of the account read, printed. Snapshots you produce are your own and you keep them; the copies inside LMKFR's report are the export of the understanding, nothing else. |
| CSV export | The same numbers, the same offer. A version of your figures that the rest of your tools can read. |
| Install as a PWA | Makes the app a home-screen app rather than a browser tab. There is no privacy commitment in that; it is bookkeeping. |
| Erase | Two cases, one visible: the LMKFR account, and the archive itself on this device. Threey of yours alone to finish. |
Login Guardian is an audit of you, not you of others
Every archive holds the sign-in record: device, location, timestamps for the login
events. Login Guardian reads that record on your device and reports the odd hours and
the device list in the shape an auditor would write. It is the same list you asked Meta
for and were not given, set out to answer one question from the record that has been
already sitting in your export.
Erase is two cases dressed the same
The first case is your LMKFR account. If you ever opted into sync, the account that
holds it has an erase, and the erase follows the two-tier rule we already described
everywhere this site asks whether a thing is yours: the data is cut to Meta's default
state in the shortest period we can offer, and the grace window exists so that a request
aimed at someone else can be stopped by the one person who can. Two endpoints, the same
shape.
The second case is the archive on this device itself — and that erase is immediate when
you say go, there is no grace period, because the archive is unrecoverable from outside
this machine. Neither case takes anything with them: the counts, the figures, the Wrapped
card, none of it is preserved as we will never know we had any of it.
What sync actually puts on a server
The sync tier earns its paragraph by being the only sale this site allows that is not
"everything on your device." It is opt-in, it is off until an account, and what it sends
is far more specific than "your archive":
- The tokens the platform gives you are split in four, and no single one of them can
reconstruct the data. The server holds one; you hold one; recovery codes are their own
; the email escrow is separate again. A breach of any one of those is not a read of you. - No media is stored. The images are yours, and they are the part that does not travel.
- Messages do not travel either, unless you say so explicitly. The default is the
opposite of compression for its own sake.
- Your username and contact information are the only names the account layer holds, and
the one on your public page is the only one the public ever sees.
The three honest questions
Most settings pages are a confession of which assumption the product was built against.
Ours are the opposite, which is why three of them are made visible even before you open
the page:
- Can the tool read my archive without me asking? No. It asks, you open the file,
and the whole parse is local.
- Is the thing it understands about me ever leaving my device? Not unless you told
it to, in an account that does not exist by default.
- If I say erase, what does erase mean? The account, the split keys, and the grace
window designed for a request that was not aimed by the owner. The deletion then
begins, and nothing else of yours is kept.
The answer is not "we take your data." It is that the data you decide to share is the
data the sync tier has — and by default it has none of it.
Questions this comes up
What exactly does the erase delete, and how long does it take?
The erase removes the LMKFR account and everything the sync tier holds for it — the split
keys, the profiles and any sync data — and it is the case where the rows that tell the
system what to delete stay in place until the deletion is proven, not after. The archive
on this device is erased the moment you ask, with no grace window of its own.
Does LMKFR send my archive anywhere if I never sign in?
No. The local mode never touches a network; the sync tier is opt-in and split-key, and
it starts only when you create an account. Without an account there is no server record
to send to.
What if I only want the sync, not the account's public page?
The sync account and the public snapshot are separate settings. You can use the
split-key sync between your own devices without publishing a stat card, and you can
publish nothing that the erase would not also clear — the two cases are wired to the
same erase.
Can someone else request the erase of my account?
Only from the device that holds one of the split keys, which is the part that proves the
request came from you. The 30-day grace window in the settings page exists precisely so a
request made against your account can be seen and stopped by the one party who knows it
is wrong.
Where this was checked
The erasure contract is the hard one of these, and it is where the system's own
documentation is the most worth reading because it is the most worth auditing. The
eraseLedger is where the deletion is ledger-logged, and it is careful about the mistake
it could most easily make: logging success without confirming that the deletion did the
job. If the erase cannot be proven to have erased, the family of rows that tells the tool
what to delete stays where it is, and the delete is retried — because an erase that
cannot be proved is not yet an erase.
The privacy report and the activity inventory it reads sit in packages/shared/src/
(types and the features/feature-vectors.ts surface), the sync keys are described assync/lean-profile.ts, and the PDF report draws on report.ts. Where the prose gives
behaviour, the behaviour is at that module, and where it gives words "erase" to mean
"the file that says what to delete stays until the deletion is proven," that too is the
module.