Privacy & security — the kist

Last updated: 2026-10-19

We built the kist to help you catalog what you own — so you know what is worth selling in a pinch, and so you have documentation if you ever need to make an insurance claim. That means you are handing us photos of your home and a list of your valuables. Here is exactly what happens to them.

In short

• Your photos, your descriptions, where you keep things, the room-scan list, what each item is — its name, category, tags, brand, model, model year and condition — and what any of your items is worth are sealed with a key only your device can produce.
• Sealed at rest is not the same as never seen. Our servers learn what an item is while they identify it, and while they look up what it is worth; the detail below says exactly when. What they keep afterwards is sealed. A shared table of what products are worth is readable — it names no owner — and what links one of your items to a row in it is sealed too.
• If you scan a room, which of your items came out of the same room photo is readable, even though the scan list itself is sealed. Grouping your things by room is what that tells us; it does not tell us which room, or where in it anything sat.
• Our servers do decrypt your photos, briefly, to identify what is in them. A third-party AI provider sees the photo, one at a time; it is not told whose photo it is, and it is contractually prohibited from training on it. It does keep its own copy for about a month afterwards, which we cannot delete and which the detail below is specific about.
• We do not have an operator master key. This is also not end-to-end encryption. Both are true at once, and the detail below says exactly which is which rather than letting you assume.
• We never receive where a photo was taken. GPS and camera metadata are stripped on your device before the photo is uploaded.
• We keep your catalog until you ask us to erase it — there is no automatic expiry. What does expire is the operational record around it, and the copies the services we run on hold for their own reasons; the detail below names each of those and how long it lasts, measured rather than assumed. There is no "delete my account" button yet either: ask us and we run it for you, through the same code path a button would use.
• We do not sell your data, and there is no advertising in the kist.
• We do not publish the names of the providers we run on, and we say why below.

Nothing in that list is broader than what follows it. If a line here and a line in the detail ever disagree, the detail is the one we hold ourselves to.

In detail

What we collect

Your account. Your email address, and a passkey — the cryptographic credential your device creates when you sign in. We never see or store a password.

Your items. The photos you take. Anything you say or type to describe an item. When you dictate rather than type, your browser does the transcribing — not us. We receive the words it hands back, never the audio. On most browsers that means the recording goes to the browser vendor's own speech service and comes back as text; that step is between you and your browser, and the kist is not party to it. We say this on screen before we ask for your microphone, and you can decline and type instead. The name, category, storage location and tags for each item — and, where we can work them out, its brand, model and model year — plus where each of those came from: what the AI proposed, and what you confirmed. Where the photo shows it, we also keep the condition the AI read off it, as one of five grades from "new" to "poor". If you ask what an item is worth, we also keep the figure we estimated. All of it is sealed like your photos; the detail below says what is not.

A room's contents, if you scan one. If you photograph a whole room, we keep a machine-readable list of everything we recognized in it: each item's name, category, and roughly where it sat in the frame. It is the most detailed record we hold about your home, and you should know it exists before you scan a room rather than after. It is sealed with the same key as the photo it came from, so it is not readable in our database — with the same caveat that applies to everything on this page: sealed means not readable at rest, not that we could never read it. We write it during the same brief decryption that reads your photo.

One part of that is not sealed, and you should know which. When a scan becomes individual items in your catalog, each of those items records the scan it was cut from. The list itself stays sealed — what we recognized, and where each thing sat in the frame. What is readable is the link: we can tell which of your items came out of the same room photo. That groups your things by room, which is more than the item names alone would say. It does not tell us which room it was, or where in it anything stood.

A history of changes. Every edit is recorded with a timestamp, so each value on an item can be traced back to what the AI proposed and what you confirmed. This audit trail is the product, not a side effect — it is what makes the record credible to an insurer.

Basic usage counts and diagnostics. Counters recording that something happened — an item captured, an item confirmed — and, when something breaks, a short trail of your recent actions plus your browser version, so we can debug it.

These carry no name and no email. They are not fully anonymous, and we are not going to call them that: they share an internal id with your account history, so we could join them back to you if we set out to. We do not, and once your account is erased that link is broken permanently — but "anonymous" would be the wrong word for it today.

If you ask for an invite. While the kist is invite-only, an address with no invite is turned away at sign-in, and you can ask for one instead. We keep the address you typed sealed so only the operator can read it — our servers can store it but cannot read it back — until that day's list of requests goes to our own inbox, and then we delete it. To stop one address asking over and over, we also keep a scrambled fingerprint of it for 30 days to stop repeats, and then delete that too. Asking creates no account and sends you nothing; if an invite comes, it is the ordinary invite email.

We do not collect location data. GPS coordinates and camera metadata are removed from a photo on your device, before it is uploaded, and removed again on arrival. We never receive where a photo was taken.

Where it lives

These are the services that hold or handle your data:

• A managed database and file store — your items and your photos live here.
• Application servers — where the kist itself runs. The company hosting them also keeps whatever our servers print while they work — the same operational record the logging service further down this list holds, plus a little more of the surrounding detail. It is the shortest-lived of those copies: we measured it at seven days, after which it is deleted for us. We cannot lift one person's lines out of it before then.
• A third-party AI provider — receives your photos, one at a time, to identify what is in them. It receives the photo only; it is not told whose photo it is, and it is contractually prohibited from training on them. It does keep a copy for about a month after each request, by its own published policy — and for as long as two years if one of its automated abuse checks flagged that particular request, which is not something it tells us. We would rather write the longer number here than the reassuring one.
• Your browser's speech service, if you dictate — the odd one out on this list, because it is not a service we choose, contract with, or pay. Live dictation is a browser feature: on most browsers the audio goes to the vendor's own speech service and returns as text. We never receive the audio, and nothing here is a claim about what that vendor does with it.
• An email provider — sends the sign-in codes we mail you, and your invite, and, once a day, a sealed list of invite requests to our own inbox. For the messages it sends you, it receives your email address and the wording of that message, and nothing else: no photos, no items, nothing from your catalog. It keeps both for 30 days, and its backups for a week beyond that.
• A managed logging service — our operational logs. Error reports and performance traces, and also a record of each request our servers handled: which address was called, whether it worked, and how long it took. Those records carry internal ids — the reference number of an item, a device or a sign-in session — and no name, no email address, and nothing describing what any item is. They keep two clocks and we measured both rather than repeating what the provider publishes: the log records roll off after roughly two weeks, the performance traces after about a month. Neither needs anyone to remember to delete it.

We do not publish the names of these providers. A public inventory of the services we run on is more useful to someone attacking us than it is to you, and what actually protects your data is what is encrypted and who holds the keys — described below — not which vendor is named on this page.

We will name every provider that handles your data to a regulator, an insurer, or a business customer who asks, and we will name them here if we are ever required to.

What is encrypted, and what is not

This is the part most privacy pages are vague about, so we will be specific.

Encrypted so that our storage provider cannot read it: your photos, the thumbnails generated from them, anything you type or dictate to describe an item, where you tell us each item is kept, the room-scan list described above, and the name, category, tags, brand, model, model year and condition of each of your items, in the history of changes as well as on the item. (The readable copies we held before we sealed these were deleted, not sealed — there was no key on our side to seal them with.) These are sealed with a key only your device can produce — derived from your passkey, or from the 12-word recovery phrase you were given when you signed up. Keep that phrase safe: it is the other thing in the world that can open your data.

What stays on your device. On a device where you have signed in, the kist keeps a wrapped copy of that key in the browser's own storage, so a photo you take with no connection can be saved on the spot. It is ciphertext: only your passkey, on that device, can unwrap it, and it is removed when you sign out. Photos captured offline wait on that device sealed the same way, and are sent once you are back online.

Not encrypted that way — readable in our database: which of your items came out of the same room photo, described above, and the bookkeeping around each item: whether it is still being identified, awaiting your confirmation or confirmed; when it was captured and confirmed; how it was captured; how confident the AI was; whether a condition grade came from the AI or from you; and, when you edit or correct an item, which fields you changed — never what you changed them to. None of that says what an item is.

What an item is worth is on the sealed side of that line — both figures. A value you type in is sealed along with your description, and so is the one our servers work out: when we price one of your items, we seal the figure with your item's own key before it is written down, so the history described above records that we priced it, when, and from which source, without recording the number in a form we can read. The two are treated identically on purpose. Sealing your correction while leaving our estimate readable would have closed nothing — a copy of our database would still have answered what is this person's item worth?, just with our figures instead of yours.

The same figure is also written to a second place, and that one is readable: a lookup table keyed on what the item is rather than on who owns it, so the next person who catalogs the same model can be answered from that row instead of from a fresh paid lookup. That row carries nothing of your account and outlives it — it is a fact about a product, not about you — and it is the row that makes the whole thing affordable to run.

That lookup is where the limit of all this sits, and we would rather state it than have you find it. To identify an item, our servers decrypt its photo for that one operation. To look up what it is worth, they hold its category, brand, model and year for that one lookup — and when you confirm an item, your device sends those four in the clear so the shared table can gain a row for that product. None of that is written down against you: what we keep about your item afterwards is sealed, and the pointer from your item to the product it matched is sealed with it. But a server that is working on your item knows what it is while it works, and we are not going to claim otherwise.

We are not going to dress that up either. Identifying an item, and looking up what it is worth, requires our servers to know what the item is while that one operation runs, and sharing those lookups across users is what keeps the cost of running this low enough to be worth doing. Keeping those words readable between operations was never part of that need, so we stopped: as of the date at the top of this page an item's name, category, tags, brand, model, year and condition are sealed at rest, and the readable copies we held before that were deleted. Sealing them had a cost we chose to pay: our servers can no longer search or filter your catalog for you. That has to happen on your device, and it is not built yet.

When you tell us we identified an item wrongly, two separate things are recorded — and only one of them is the opt-in. We used to describe only the second, which made the setting sound like the thing that decides whether anything is written down at all. It is not, so here is both.

The report itself is always recorded, against your account. It goes into the history of changes described above, with a timestamp and the account that filed it, exactly like any other action you take in the kist — and like the rest of that history, it is readable in our database. That happens whether the setting below is on or off. It is cleared when your account is erased, and not before: the history is append-only by design, so we cannot reach in and pull a single entry back out of it.

The opt-in decides one further thing: whether a row about the report joins our model-evaluation set — which item it was, which photo the report was about, and when. That is how we keep score of how often we get it wrong. That row carries no name and no account id, but we will not call it anonymous, because it is not: it is linkable to your item, readable by us for scoring, and deletable by you — turn the setting off (it lives on your Account page, and it starts off) and every evaluation row you contributed is deleted. The history entry described above is not deleted with them; it stays until your account is erased.

Reporting a misidentification always works whether or not you opt in; the setting only controls whether your report joins the evaluation set. Nobody re-runs your photos through anything: scoring reads the stored guess and the answer, and opening the photo itself still takes the per-ticket permission described above.

One kind of evaluation row will not be yours to switch off — and you are reading this before it exists, not after. Everything above is about the reports you file. We also intend to flag misidentifications ourselves, from our own review of our own answers, and a row we flag is not governed by your setting: it can be written whether the setting is on or off, and turning the setting off will not delete it. Nothing in the kist writes one today — every row in that set so far came from a report someone filed with their setting on, so the paragraph above describes all of them. When that changes it will stop doing so, and we would rather say it now than move the line quietly later. Two things do not change either way: opening your photo still takes the per-ticket permission described above, and the row still carries no name and no account id.

Our servers do decrypt your photos, briefly, to identify what is in them. The plaintext exists only for the length of that operation, is never written to disk or logs, and the key material is erased from memory as soon as the work is done.

The honest one-line summary, and the one we will hold ourselves to:

Your data is encrypted in transit and at rest with user-keyed access. Server-side decryption happens only for required processing (photo identification, value lookup) and is not logged in a way that persists plaintext. We do not have an operator master key.

We do not describe the kist as "end-to-end encrypted," because it is not, and we would rather tell you that than let you assume it.

How long we keep it

Your catalog, until you ask us to erase it. We do not expire or auto-delete any of it, and we would rather say so plainly than imply a retention policy we have not built.

The one exception is the operational logs and traces described above — the record of requests our servers handled. Those are not part of your catalog and hold nothing describing your items, and they roll off on their own without anyone asking: about seven days on the machines the kist runs on, roughly two weeks for the error logs, and about a month for the performance traces. Those are numbers we went and measured, not ones we assumed.

Deleting your account

If you ask us to erase your account, we will: your items, photos, encryption keys, history, any queue still holding something of yours mid-processing, and your invite.

Four things you should know, because they are true today:

1. There is no "delete my account" button yet. Erasure is run by us, on request — but it is no longer run by hand: since 2026-09-22 it runs through the application, which checks its own work and refuses to report success if anything of yours survives. We have executed it end to end on a test system — not a policy we intend to write later. A self-service version is something we want to build; it does not exist.

2. Some records survive, and they are more than a tally — so here is exactly what. Alongside a plain count of things that happened, we keep a per-item operational record: when each of your items was processed, and what the AI work on it cost us. None of it holds your name, your email, or anything describing what an item is. Once your items are gone, the ids inside those records point to nothing at all — the join described further up is broken permanently, and there is no route back from them to you. We keep them because they are how we know what the service costs to run. We are spelling them out because "usage counters" would have undersold them, and we would rather over-explain than have you find out later.

3. Erasure does not reach the copies other services are already holding. Those records do not sit in one place, and we would rather list the places than let "the logs" stand in for all of them. The machines the kist runs on keep what our servers printed for about seven days. The specialist provider we send a copy on to keeps the error logs for roughly two weeks and the performance traces for about a month. Deleting one person's lines out of any of them is not something we can do from here — none of them gives us a way to remove a single record, and each clears itself on the window above. So rather than claim a reach we do not have, here is exactly what is left behind: internal reference numbers, timings, and error reports, holding no name, no email, and nothing describing your items. Like the counters, once your items are gone those numbers point to nothing.

   The same is true of the email provider above, and there we can be specific. Its record of what it sent you carries your address and the wording of the message. It holds both for 30 days, and its backups for a week beyond that. We went looking for a way to delete a single message early and there is not one — no button, no API call; the only route is to write and ask, with no commitment on when or how far it reaches. We decided the honest answer was to tell you the window rather than to promise a request we would be making by hand and could not verify. Our erasure does not reach it; after those 30 days there is nothing left in it to reach.

   And the same is true of the AI provider that looked at your photos. It keeps each photo it was sent for about a month afterwards — up to two years if one of its automated abuse checks flagged that request, which it does not tell us either way. It states plainly that it does not support deleting an individual request, so there is no ask for us to make on your behalf: those copies go when their own clock runs out, counted from when we sent them rather than from when you asked us to erase you. We are telling you this because the alternative is letting "we delete your photos" quietly mean "the ones we hold".

4. If you took one of our research surveys, those answers stay. We built that surface so the answers you gave us in a survey are not linked to your account — on purpose: nothing anywhere records which set of answers is yours. That is what makes them safe for us to keep, and it is equally why we could not pick yours out to delete even if you asked. They carry no name and no email, and none of your items.

Ask us and we will do it. We are a small enough operation that this is a real answer, not a deflection — and honest about the fact that it does not scale forever.

What we don't do

• We do not use your photos to train AI models.
• We do not sell your data, and there is no advertising in the kist.
• We do not require a password, so there is no password of yours to leak.
• We do not ask for more than the above — apart from research questions we may put to you directly, with your consent, if you agree to take part in an interview. Those answers are stored separately from your catalog.

When this changes

This page describes the product as it actually is on the day it was published, not as we hope it will be. When the encryption boundary, the retention policy, or the deletion path changes, this page changes with them.