Skip to main content

Privacy

Last updated 10 August 2026

This page describes what the software actually does today. Where something is planned but not built, it says so rather than describing it as though it already protects you.

Read this first

This is one instance of Family Temple Planner, run by one person on their own machine as a favour. There is no company, no staff, and no support desk. That person controls the database and its backups, and can read anything in it.

Anyone with a Google account can sign up, so other families using this same instance are strangers to you. Their plans are never visible to you and yours are never visible to them — that is enforced in the code, not merely promised here — but it does all sit in the same database.

Nobody has to make an account

There are three ways to be here, and they store very different amounts about you.

  • You were sent a link. You type a name and answer. There is no account, no password and no email address. What is stored about you is your name as you typed it, which days you said work, and which of the temples on the list you said you can get to. That is the whole of it.
  • You are arranging the trip, with no account. This is the ordinary way to host. You name the trip and get a private link to it; that link is the only credential, and we store only a keyed hash of it, never the link itself. What is stored about you is the same as for anybody answering: your name and your answers. No email address, no password, nothing to remember.
  • You are arranging the trip, and you signed in. Optional, and it buys one thing: a list of your past trips, so you stop depending on a link you have to keep. That means an account — see below.

If you were sent a link

  • The name you typed. Free text, shown to everyone else on that trip beside your answers. Nothing verifies it — anyone with the link can call themselves anything, and that is the trade for not making the whole family sign up.
  • Which days work for you, and optionally which parts of those days.
  • Which of the shortlisted temples you can get to. Two answers per temple: you can, or it is too far.
  • A secret in a cookie on your device, so returning to the same link finds your answers again. Only a keyed hash of it is stored on the server, so a copy of the database cannot be used to answer as you.
  • When you last opened the link. Used to show the organizer who has turned up and who has not.

You belong to one trip. There is no profile that follows you, no history across trips, and no way for an old link to reach something the family started later.

If you signed in to organize

  • Your email address. This is your identity. It is normalized to lower case and stored in plain text, because sign-in links must be delivered to it.
  • A Google account identifier, if you signed in with Google. Not your name, picture, profile or any access token — only the fact that that Google account is this account.
  • An optional display name and a time zone.
  • Your live sign-in sessions, each with a coarse device label such as “iPhone — Safari”. Never an IP address.
  • Which plans you organize, and whether you started each one.
  • The plans themselves — a name, a window of dates, a time zone, the shortlist of temples, and the option the family settled on.
  • Unused co-organizer invitations — a keyed hash of the link, a short non-secret fragment so you can tell two apart, and an expiry.
  • An activity log per plan — who changed the temples, who made or replaced the link, who chose the option, who recorded the booking. Answers are deliberately not logged there; a family of ten filling in a fortnight would bury everything else.
  • A booking, once an organizer records one — temple, date, times, what the family intends to do, how many places were reserved, and any instructions they typed for everyone.

What is never stored, at all

  • Church Account credentials. You are never asked for them. This software never signs in to any Church system, cannot read appointment availability, and cannot make or cancel a reservation.
  • Membership record numbers. No column for one exists anywhere in the database.
  • Anything about your standing or your ordinance history. A plan records what the family intends to do as a group. It records nothing about any individual.
  • Where you live. No address, and — since August 2026 — no coordinates of any kind. There is no latitude or longitude column attached to a person anywhere in the database.
  • Analytics, advertising or third-party trackers. No scripts from anyone else load on any page.
  • Raw sign-in links, invitation links or participant secrets. See below.

The location point deserves a note, because it used to be different. The product once offered a deliberately blurred “approximate area” so it could work out how far each person would travel. Asking people directly whether they can get to a temple turned out to answer the same question better — it accounts for a lift from a cousin, a work shift, and a car that will not make the journey — so the map, the consent screen and the coordinate columns were removed rather than kept for a calculation nothing needed.

Secrets are stored as hashes, never as themselves

Sign-in links, co-organizer invitations, session cookies and the per-person secret behind a share link are all bearer secrets: whoever holds one can act. The database keeps only a keyed hash of each, so somebody who obtained a copy of it still could not sign in as you or answer as you.

  • This means an invitation link cannot be shown to you a second time. If you lose it, the organizer creates a new one.
  • It also means the person running this server cannot recover your session for you, only end it.

One deliberate exception: the family share link.It is stored as it is, not hashed, because an organizer has to be able to look it up again every time another relative asks for it, and a one-way hash cannot be read back. What compensates is how little it grants: it reaches exactly one trip, it can only be used to answer, it can never see the activity log or change the temples or touch the booking, and replacing it kills the old link instantly without disturbing anyone’s answers.

The host link is hashed, and that has a cost worth stating plainly.The private link to a trip you are arranging is stored only as a keyed hash, because nothing ever needs to read it back — your browser already has it. So a copy of the database cannot be used to take over anybody’s trip. The cost: if you lose that link and never signed in, nobody can send it to you again, not even the person running this server. It is gone, with everybody’s answers in it. Bookmark it, or sign in to keep a list.

Who can see what

Plans are private. There is no directory, no search across plans, and no public page for any plan. Every request for a plan is checked against the requester’s own organizer record or their host link; a plan identifier in a URL grants nothing by itself. A request for a plan you do not organize returns the same “not found” response as a plan that does not exist, so the existence of other families’ plans is not disclosed.

Within one trip, everyone can see everyone else’s name and answers. That is deliberate — the entire point is for the family to work out together who can come and where.

Only the person arranging a trip — whether through an account or by holding the host link — can see the activity log, the private organizer note on a booking, or change anything about the plan. Holding the family share link gets you none of that. Anyone who has the host link can do all of it, which is why it says on the page to keep it to whoever is arranging the trip.

Nobody can change anybody else’s answers. An organizer can remove a person from a plan entirely, which deletes their answers along with them, and that removal is recorded in the activity log.

Email

This deployment sends one kind of email: a sign-in link, and only if email is configured at all. It currently is not — signing in is done with Google.

Nothing else is ever emailed. Nobody is sent reminders, notifications about a vote, or a copy of the booking, because most people here never gave an address. Chasing a relative who has not answered is a text message from the organizer, the way it always was.

Deleting your data

An organizer can delete a plan, and it is real deletion. Every participant, every answer, the booking record and the whole activity log are removed from the database — not flagged as hidden. Nobody can get them back afterwards, including the person running the server.

If you answered through a link and want what it holds about you removed, ask whoever sent you the link. They can remove you individually, which deletes your answers, or delete the whole plan.

An organizer account itself cannot yet be deleted through the interface, and there is no data export. Those are real gaps rather than oversights being hidden. No contact route is published for this instance, so there is currently no way to request that. If you need one, ask the person who gave you the link — they know who runs it.

Retention

Data stays until somebody deletes it. Nothing expires on its own, and there is no scheduled cleanup: expired sign-in links and unused invitations are refused when used but are not purged from the database. Backups are whatever the person running this server keeps.

There is no promise this instance keeps running. It is offered free as a favour and may be switched off, possibly without warning. See the terms.