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 — once billing opens — a record of what you paid. 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, and the scans and photographs you upload. This is the service; it is stored so it can be shown back to you and to the people you invited.
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 the payment provider, once billing opens. Nothing today.

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, which include addresses. Read when something breaks or when something is attacking the service.
Legal basis: Our legitimate interest in keeping the service running and secure.
Where it comes from: Our own servers.

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 full account is on the sub-processors page, and it is a list rather than a promise of one: every party is named, with what it handles and where it runs.

The short version. Our own servers are in the Netherlands. The payment provider is Dutch. The static host and the DNS for this public site are run by a company in the United States, which sees the address of a browser reading these pages and nothing at all from inside the application.

That company is the one party outside the European Union. Transfers to it rely on the European Commission's standard contractual clauses.

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.

Once billing opens, invoices and the payment records behind them are kept for seven years, because Dutch tax law requires it. That is the one category deleting the account does not remove.

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.