Privacy

Who is responsible

This is run by Jacob Frusher, who can be reached at jacob@frusher.co.uk. It is a personal project, not a company.

For a wedding you create, you decide what goes into it.

There are two ways it can reach a server, and they are not equally private. If you sync with a passphrase, or publish a guest link, I hold bytes I genuinely cannot read. If you make an account, I hold your wedding in a database — encrypted at rest, walled off from every other account, but readable by whoever runs the server. Both are described below. Neither happens unless you choose it.

Where your wedding lives

In your browser. Guests, seating, the running order, the crew and the stationery are all stored on the device you are using, in IndexedDB, and nothing is sent anywhere by default.

You can use the whole application without any of it ever reaching a server. Two things change that, and both are things you have to turn on: syncing between machines, and publishing a link for your guests.

What the server holds when you sync

Ciphertext, and nothing else. Your passphrase is stretched in your browser with 600,000 rounds of PBKDF2 and split into two keys. One encrypts the wedding and never leaves the device. The other proves you are allowed to write, and the server keeps only a hash of it.

That means the server cannot read a guest name, a dietary requirement, a phone number or a note, and neither could anyone who obtained a copy of the database. This is not a promise about how carefully the data is guarded; it is a statement about what is possible.

Uploaded typefaces and artwork are encrypted the same way.

Your passphrase is never sent, and cannot be recovered. If you lose it, nobody can open that wedding again — including me.

What an account holds, and who can read it

An account exists so you and your partner can plan on separate devices. Making one stores your email address, and nothing else about you — there is no password, no profile, and no name field. Signing in sends a link to that address; clicking it is what proves it is you.

Your wedding is then stored in a database as one document, encrypted at rest, with database rules that make it unreadable to any other account. Inviting your partner adds exactly one more person to that wedding, by the email address you name.

Being straight about the difference: this is ordinary, well-guarded storage, not the passphrase system above. I do not read your wedding and there is no support tool that would let me browse it, but I administer the database, so I could. If that matters more to you than syncing does, use the app without an account — it is the default, and nothing leaves your browser.

Every version you save is kept alongside the current one, so a mistake can be recovered rather than being final.

What a guest link contains

Deliberately less than the wedding does. A published link carries names and table numbers, and optionally the shape of the room. It does not carry email addresses, phone numbers, dietary requirements, notes, or anybody who has declined.

It is encrypted under a key that lives in the link's own fragment — the part after the # — which browsers never send to a server. The server stores bytes it cannot read, and hands them to whoever has the link.

There is only ever one live link per wedding. Publishing again replaces what the existing link shows, so a link you have already given out stays correct. Taking it down deletes it outright.

How long it is kept

A wedding that is not written to for 24 months is deleted automatically, along with its uploaded files and its guest link. That is long enough to cover an engagement, the wedding, and a year of still wanting the seating plan.

There is no backup that outlives this. When it is deleted, it is gone.

A wedding held under an account follows the same rule: 24 months with nobody writing to it, and it is deleted the same way. Deleting your account deletes it immediately, regardless of that timer — unless your partner is still on it, in which case it stays with them, because it is their wedding too.

Deleting it yourself

There is a button. In the Data manager, under Sharing, 'Erase this wedding from the server' removes everything: every slice, every uploaded file, and the guest link. It takes effect immediately.

It erases the server copy only. The wedding stays in your own browser, because withdrawing from a server is not the same as wanting to lose your seating plan. To remove that too, clear this site's data in your browser.

If you have an account, deleting it is on the account page and needs no passphrase — signing in is what proves it is yours. It removes your membership, and the wedding with it if nobody else is on it.

Erasing a passphrase-synced wedding is different. It needs your passphrase, like every other write. That is the unavoidable cost of a server that cannot read what it stores: there is no reset link and nobody to appeal to. If you have lost your passphrase I cannot delete your wedding on request, because I have no way to tell it is yours — the automatic deletion above is what eventually removes it.

Cookies and tracking

No analytics, no advertising, no tracking pixels, and no third-party scripts on the page. Nothing here follows you anywhere.

One cookie exists, and only if you sign in: it holds your session, which is what keeps you signed in between visits. It is not used to track you and there is nothing to opt into, because without an account no cookie is set at all.

The browser storage that is used — IndexedDB — holds your wedding, which is the thing you came here to work on. Nothing about you is stored for any other purpose.

Error reporting

When something breaks, a diagnostic report may be sent to Sentry, an error-monitoring service, so the fault can be found and fixed. This is the only third party involved in running this site.

It is configured narrowly and on purpose. No session recording, no personal data, and no console output — the tools log parts of the document while they work, and that is the guest list. Web addresses have their fragment removed before anything is sent, so the key in a guest link can never reach it.

This is done on the basis of legitimate interest: keeping the application working. It sets no cookies and reads nothing from your device.

Staying signed in

If you sync, the credential derived from your passphrase stays in this browser until you sign out or clear the site's data. It is what lets the application keep syncing without asking for the passphrase again.

An account works the same way from your side, with a session that lasts until you sign out.

The practical consequence is worth stating: on a shared or borrowed computer, signing out matters. Anyone using that browser afterwards can reach the wedding.

Your rights

Under UK GDPR you have rights of access, correction, erasure and portability. Most of them are already buttons rather than requests: 'Export backup' gives you the entire wedding as one file, 'Download my wedding' on the account page does the same from the server copy, and the delete buttons above remove it.

For anything else, or if you think something here is wrong, write to jacob@frusher.co.uk. You can also complain to the Information Commissioner's Office.

Changes

The date at the top of this page is the date these words last changed, and it is kept honest by a test that fails if the text moves without it.