Privacy Policy

1. What we collect

Your account

• A display name for every member.
• An email address for adults — it is how you sign in and the only way we can reach you. Children’s accounts have none.
• A password, which we never store. What is stored is an argon2id hash, from which the password cannot be recovered.
• Your role in the family, and for a child, the member name their parent chose.

What your family posts

Messages, photographs, songs, video clips, recipes, calendar events, chores, lists, notes, kid quotes, projects, pets, contacts, and anything else typed into a card. We do not inspect it, index it for search, or read it.

Technical records

• Sessions. A random session identifier (stored only as a hash), when it expires, and when it was last seen. The last-seen timestamp is also what draws the green dot on the Who’s Around card.
• The audit log. Each family has its own. It records who signed in, who failed to, who invited whom, who changed a role, who reset a password and what an operator did — with the IP address and browser user-agent of the request. It is visible to that family and to us; it is not visible to any other family.
• Sign-in throttling counters, per family, so five wrong guesses lock an account for fifteen minutes. These are deleted once they lapse.
• Server logs. Ordinary web-server request lines — time, method, path, status, IP — kept in the container’s rolling log files (capped at 10 MB × 5) and rotated away as they fill.

Billing

We never see your card. Payment happens on Stripe’s own pages; the card details go from your browser to Stripe and never touch our server. What we store is a Stripe customer id, a subscription id, the status of the subscription, when the current period ends, and whether it is set to cancel. Your billing address, card number and payment history live with Stripe.

2. Children

Children are the point of this product, so this section is the one to read properly.

A child never signs up. An account for a child is created from inside an existing family, by that family’s owner or an admin — in practice, by their parent. It requires no email address: the parent types a member name and a password and hands them to the child. The child cannot invite anybody, cannot start a hub of their own, and cannot reach anything outside their own family.

The parent creating the account is the consent. Under the US Children’s Online Privacy Protection Act (COPPA), a service directed at children needs verifiable parental consent before collecting a child’s personal information. Here, the only route to a child’s account is an adult who has already signed up, agreed to the Terms, and is signed in to their own family, deliberately creating that account. We do not knowingly collect anything from a child except through an account a parent made for them inside their own family. There is no other door.

What we hold about a child is a display name, a member name, a password hash, their role, their session records and whatever they posted. No email, no phone number, no address, no location, no advertising identifier — because none of those exist anywhere in this product.

How a parent removes a child’s account. In the hub, open Settings › Family and remove the account. The effect is immediate: the child can no longer sign in, and every session of theirs is destroyed on the spot. Their posts stay, deliberately — the same button is used to suspend a teenager for a fortnight, and it must not cost the family four years of photographs. Individual photographs, messages and clips can be deleted by the poster or by any owner or admin, from the card they are in.

To have a child’s account and everything they ever posted erased completely, email us from the owner’s address and say so. Removing the membership row cascades to every message, photograph, recipe, event, project and clip that child authored, plus their preferences and sessions. We do it by hand because it is irreversible, and we confirm the request with the owner before we run it.

If you believe a child has an account here that no parent set up, write to us and we will delete it.

3. Who can see what

Between families: a wall

One family must never see another’s data. Three independent mechanisms enforce that, and all three would have to fail at once for a leak: every database query runs inside a scope pinned to one family; PostgreSQL row-level security applies that scope even to the database owner and is written to fail closed, so a query that forgets the filter returns nothing rather than everything; and the foreign keys are built so that a row belonging to two families cannot be represented at all. Security describes all three.

Inside a family: circles

A message, photograph or clip can be addressed to a circle — a named group of relatives — instead of the whole hub. Circles are a privacy preference between people who already trust each other, not a wall like the one between families. They are still real: they are enforced by the database in the direction that shows too little rather than too much, and the owner cannot read a circle they are not in. Everyone can see that a circle exists and who is in it; only its members see what is inside. A parent’s one route to the content is to delete the circle, which returns its posts to the whole family, cannot be undone, and is written into the family’s audit log.

Between linked families: copies

When two families link their hubs, the link is permission to send, never to read. A send writes a new copy into the recipient family’s hub. Nothing is ever read across the boundary. Once a photograph has arrived in your in-laws’ hub it is theirs: revoking the link does not recall it, and deleting your original does not delete their copy.

Us

This is the part most privacy policies are vague about, so: the product is not built for us to browse your family’s content, and the operator console genuinely cannot reach it — no message, photograph, recipe or event is fetchable from that host, and a test in the suite checks the exact field names it returns so that a future change cannot quietly widen them. What we see there is structure and money: how many families, their addresses and names, their status and subscription, how many members each has, and that family’s own audit log. Every action an operator takes is written into the affected family’s log with the operator’s verified email address, so you can see it.

Could we technically read your content anyway? Yes. Anybody with direct access to the database or the disk can read what is in it, and the nightly backups are ordinary database dumps. Your photographs, songs and clips are stored as files, not encrypted at rest with a key we do not hold — if they were, a forgotten password would mean the pictures were gone forever, which for a family album is the wrong trade. So the protection is that access is limited to one operator, that the console is built not to expose it, that every operator action is logged where you can see it, and that we have said we will not. We would rather write that plainly than imply a cryptographic guarantee we do not have.

4. Where your data lives

On one server, in a house, in the United States, with the database and the media files on an attached disk. It reaches the internet through a Cloudflare tunnel rather than an open port, so every request is encrypted in transit and the house has no inbound hole in it.

If you are outside the United States, using the service means your family’s data is stored and processed in the US.

Backups. The database is dumped every night at 03:30 and the media files are mirrored. We keep 14 nightly dumps and 8 weekly ones, which is roughly two months. Being candid: those backups are on the same physical disk as the live database. They protect against a mistake, not against the drive failing. There is no off-site copy yet. That is the single biggest gap in this setup and it is named again on Security.

5. Who else touches it

Here is the complete list of companies whose servers are involved in running this, what each one is for, and what actually reaches them. It is taken from the code, file by file, not from memory.

That is the whole list. There is no email provider (we cannot send email yet), no error-reporting service, no customer-support tool, no CDN for fonts — the typefaces are served from our own server — and no advertising network. The only measurement anywhere is the cookieless page count on this public site, listed above; there is none inside a hub. The inspirational quotes on the dashboard are a list in our own code, not a service.

Embeds: your browser, their rules

Family Radio, Family TV and the video cards work by embedding rather than hosting. The browser’s own content-security policy permits frames from exactly six hosts and no others:

• www.youtube-nocookie.com
• www.youtube.com
• open.spotify.com
• embed.music.apple.com
• w.soundcloud.com
• bandcamp.com

Nothing loads from any of them until a member clicks play. A card you scroll past shows a still plate and tells those companies nothing. When somebody does click, that company sees the request the way it would on their own site — IP address, browser, and whatever cookies that browser already carries for them — under their privacy policy, not ours. YouTube is embedded through its no-cookie host wherever possible. Internet radio streams and podcast episodes play directly from the station’s or show’s own server, which likewise sees your IP address.

Links your family saves to anywhere else — a TikTok, an Instagram reel — are stored as plain links and open on that site in the usual way. They are not embedded, because the policy above will not allow it.

6. Photographs, and what comes off them

Every photograph is decoded, rotated, resized and re-encoded by our server before it is stored. The file that lands on the disk is one our own code wrote, which means the EXIF block does not survive — including the GPS coordinates your phone wrote into it, the camera serial number, the timestamps and any IPTC or XMP tags. That is not a setting we could forget to turn on: it is what re-encoding does, and the pipeline deliberately does not ask for the metadata to be carried over.

Photographs, songs and clips are stored outside the web root and are reachable only through an authenticated route scoped to your family. The server refuses to start if the media directory is ever configured somewhere a static file server could reach it.

Songs and video clips are the one exception to re-encoding: there is no video encoder on this machine, so they are kept exactly as you uploaded them, which means any metadata inside those files is kept too. They are still private and still served only to your family.

7. What we do not do

• No advertising. There is none in the product and none is planned. We are paid by families, which is the whole point of charging.
• No tracking pixels, and no analytics inside your hub. Not one third-party script runs on a page your family signs in to — the browser’s own security policy forbids loading one there, which is a rule we cannot quietly break. On this public site there is exactly one: the cookieless page counter in section 5, which sets nothing, stores no identifier and cannot follow anyone anywhere.
• No selling, renting or sharing your data with anybody for their own purposes. The list in section 5 is service providers doing a job for us, nothing more.
• No AI. No large language model, no machine-learning service and no automated classifier reads your family’s messages, photographs or anything else. There is no such integration anywhere in the codebase, and your content is never used to train anything, ours or anyone else’s.
• No profiling and no automated decisions that have any effect on you.

The one cookie that is not strictly a session cookie remembers which family this browser last signed into, so the front page can say “Open my hub”. It carries a family address and nothing else — no user, no name, no session — our server never reads it, and “Forget this device” clears it.

8. Keeping and deleting

• While your hub is live, we keep what your family posts until your family deletes it.
• If the subscription lapses, nothing is deleted. The hub goes read-only and everything stays readable until it is paid or you ask us to delete it.
• Delete a hub and it all goes — every member, every photograph, every message, the audit log, the lot. Copies then persist in the nightly backups until those roll off, which takes up to the retention window in section 4 (14 nightly, 8 weekly).
• Copies in another family’s hub are theirs. Anything one of your members sent over a kin link belongs to the family that received it and is not deleted with yours. Ask them.
• Audit entries live as long as the family does; they are the record of who did what, and they deliberately outlive the membership they describe.
• Sessions and invitations expire on their own and are swept away. Login-throttle counters are deleted once they lapse.

9. Your rights

Whatever law applies where you live, this is what we will do if you ask, from the hub owner’s email address:

• A copy of your family’s data. We will produce one. It is assembled by hand rather than by a button, so give us a few days.
• Correction. Most of it you can edit yourself in the hub; tell us about anything you cannot.
• Deletion of a member, a child’s account and everything they posted, or the entire hub. Irreversible, so we confirm first.
• To ask what we hold about you, or object to something we are doing with it.

We do not charge for any of this and we do not treat you any differently for asking. If you are in the EU or UK, we are the controller for your account and technical records, and a processor for the content your family posts; our lawful basis is the contract between us, plus our legitimate interest in keeping accounts secure. If you are in California, we do not sell or share personal information as those words are defined there, and we have no financial incentives to disclose.

10. Security

The mechanisms — how the isolation works, how passwords and sessions are handled, what is and is not encrypted, and the honest list of what we do not have — are on their own page: Security. It also says how to report a vulnerability.

If a breach ever affects your family’s data, we will tell the hub owner by email without undue delay, and describe what happened in plain words: what was reached, when, and what we did.

11. Changes to this policy

When the product changes, this page changes with it — including the subprocessor table, which is meant to be edited in the same commit as the code that adds a service. Small corrections move the effective date at the top. Anything that materially affects you gets an email to the hub owner at least 30 days before it takes effect.

Questions

Latch & Lantern is operated by The DAS Board LLC, which is the data controller for the purposes of this policy. Write to [email protected] for anything on this page — an export, a deletion, a question about the table above, or to tell us it is wrong.

Honest note. This page has not been reviewed by a lawyer. It was written by the person who built the product, working from the code, to describe what actually happens to your family’s data. It is not legal advice. If you find a claim on this page that the product does not live up to, that is a bug and we want to hear about it.