Privacy Statement

01 Who is responsible for what §

Two different relationships live inside one account, and the difference decides who you ask for what.

Your account: The address you signed up with, your name, your settings and a record of what you paid when you subscribe. We decide what happens to this, so for it we are the controller.
Your research: Everything inside a project. You decide what goes in and who may see it, so for that you are the controller and we are your processor: we hold it, show it back, and act on your instructions.

Which means, in practice: a question about your account comes to us. A request from somebody in your tree — to be corrected, or removed — is yours to answer, and the tools to carry it out are in your hands rather than ours.

Anything in this statement reaches us at privacy@leaves.family.

02 The people in your tree §

Genealogy is unusual, and this is the paragraph that says so instead of hoping nobody notices. Most of the personal data in a project is about somebody other than the person who typed it, some of those people are alive, and none of them were asked.

A tree also holds what the law calls special-category data, whether or not anybody set out to collect it: a baptism is religion, a cause of death is health, an origin is ethnicity. Nothing in Leaves stops you recording any of it, and you should know that recording it is a decision with weight rather than a field to fill in.

The responsibility for that is yours, because the choices are yours. What Leaves gives you to exercise it, today, in the product:

A project-wide setting that hides living people from collaborators, on the 110-year rule. The owner always sees everything; nobody else does unless you say so.
A switch on each individual invitation for whether that person may see living people. It is off by default, so turning it on is a deliberate act taken one collaborator at a time.
Roles per project — viewer, editor, admin — so what somebody can do is something you decide when you invite them rather than a consequence of being invited at all.
A setting for whether collaborators may export the project. Off by default; the owner can always export.
Deletion of a person, which takes with it the citations and the media links that pointed at them.

If a living person asks you to remove them, you can, completely, and you do not need us in order to do it. If they write to us instead, we will tell them who the project owner is only where the law obliges us to, and otherwise pass the request to you.

03 What we hold, and why §

Grouped by what it is for, with the ground in law each group rests on. Nothing here is held because it might be useful later.

Account data

Purpose: Your name, your email address, a hashed password, whether the address is confirmed, and your interface preferences. There is no way to have an account without them.
Legal basis: Performance of the contract with you.
Where it comes from: You, at registration and in the account screen.

Project content

Purpose: Persons, families, events, places, sources, citations, notes, research tasks, discussions and the media you upload. This is stored so it can be shown back to you and the collaborators you authorize.
Legal basis: Performance of the contract with you. For the people inside it, you are the controller — see clause 2.
Where it comes from: You, by typing it or by importing a GEDCOM file.

Payment data

Purpose: Your name, the amount, the currency, the term, and the identifiers the payment provider gives back. Card and bank details are entered on the provider's own page and never reach us.
Legal basis: Performance of the contract, and the legal obligation to keep invoices.
Where it comes from: You and Stripe, when you subscribe or manage billing.

Sign-in sessions

Purpose: An address and a browser description for each sign-in, so the sessions screen can say which device it was and you can end one you do not recognise.
Legal basis: Our legitimate interest in the security of your account, and yours.
Where it comes from: Your browser, when you sign in.

Change history

Purpose: Which collaborator changed which record, inside a project. A shared research database that cannot say who changed a date is not a research database.
Legal basis: Performance of the contract with you.
Where it comes from: The application, as edits are made.

Server logs

Purpose: Requests, errors and timings used to diagnose failures and protect the service. When configured, Sentry-compatible monitoring sends sanitized error and performance events to our monitoring service. Browser replay, where enabled and supported, masks text and inputs and blocks media.
Legal basis: Our legitimate interest in keeping the service running and secure.
Where it comes from: The application, API and the monitoring infrastructure operated by Leaves.

We do not profile you, we make no automated decisions about you, and there is no advertising of any kind anywhere in Leaves.

04 Who else processes it §

The sub-processors page lists the external providers Leaves uses, what each handles, and the contractual or location details still awaiting legal review.

Cloudflare hosts the site and application. Leaves runs the API on its own server. Mailtrap delivers email, and Stripe handles subscriptions and billing details. Card and bank details are entered on Stripe’s checkout rather than in Leaves.

International-transfer arrangements and the contracting entities must be confirmed as part of the legal review. The list identifies the details still outstanding.

A new sub-processor goes on that page before it starts, not after.

Read the sub-processor list in full

05 How long we keep it §

The account and everything in it are kept for as long as the account exists. There is no expiry and no dormancy sweep: research that took twenty years should not evaporate because somebody did not sign in for one.

Deleting the account is immediate and permanent. The account, the projects you own, the records in them and the files you uploaded are removed, and every token that could sign you in is revoked in the same transaction. It is not a flag and there is nothing to undelete. Export first.

Sign-in tokens expire without being asked: 15 minutes for the one that carries a request, 7 days for the one that renews it, or 30 days where you asked to be kept signed in. Ending a session from the sessions screen ends it sooner.

Invoices and the payment records behind them are kept for seven years for Dutch bookkeeping obligations, including after an account is deleted.

Server logs have no automatic expiry today. That is a gap rather than a policy, and saying so here is better than inventing a period nothing enforces. It is written down as work to do, and this clause changes when the sweep exists.

06 What you can ask us to do §

You have the rights the GDPR gives you: to see what we hold, to have it corrected, to have a copy in a portable form, to have it erased, to have processing restricted, and to object to anything we base on a legitimate interest. Two of them you do not have to ask us for at all.

A copy of everything: From the account screen, as a single archive holding every project you own and every file you uploaded. One project on its own exports as GEDCOM, the format the rest of the genealogical world reads.
Erasure: Deleting the account, from the same screen, with the effect described in clause 5. Nobody has to approve it and nobody can slow it down.

For anything else, write to privacy@leaves.family. We answer within one month, and if a request genuinely needs longer we will say so inside that month rather than at the end of it.

One limit worth knowing. If you are a collaborator in somebody else's project, the records in it are theirs rather than yours, and a request about those records belongs with the project's owner. What we can always do for you is end your access and delete your own account.

07 How it is protected §

What is actually in place, rather than a paragraph of adjectives.

Passwords are hashed with bcrypt. There is no form of them anybody can read, including us.
Everything travels over TLS.
Signing in issues a short-lived token that rotates rather than one long-lived one. Every session is listed with the device it came from and can be ended, one at a time or all at once.
Every request for a record is checked against the project it belongs to and the role you hold there. There is no route that hands back a record without that check.
Uploaded files are served through the same authorisation as the records that point at them, so a link to a scan is not a way around a role.

If a breach ever puts your rights at risk we will tell you and the supervisory authority within the time the law sets, and we will say what actually happened rather than what is comfortable.

08 Children §

Leaves is not directed at children and we do not knowingly hold an account belonging to one.

Children do appear in trees, of course, as records somebody else entered. The living-person controls in clause 2 are the ones that matter there, and they apply to a living child exactly as they apply to a living adult.

09 Changes to this statement §

Every version carries a version number and a date at the top of this page, and the date is the one to check.

Where a change materially affects you, you will hear about it by email before it takes effect rather than finding a quietly reissued page.

Read the Cookie Statement

10 If you want to complain §

Tell us first, at privacy@leaves.family. It is faster and we would rather fix it.

If that does not resolve it you can complain to the Autoriteit Persoonsgegevens, the Dutch supervisory authority, or to the supervisory authority of the country where you live or work. You may do that whether or not you have spoken to us, and nothing here asks you to come to us first.