Last updated: 2026-08-25
This notice explains what personal data RootMe processes, why, and what your rights are. It is written to satisfy KVKK art. 10 (Türkiye) and GDPR art. 13–14.
Everything below is what the application actually does. No assurance appears here that has no counterpart in the code — we would rather leave a gap visible than promise something we do not do.
The data controller has not been configured. Whoever operates this installation must set LEGAL_CONTROLLER_NAME, LEGAL_CONTROLLER_ADDRESS and LEGAL_CONTACT_EMAIL before going live.
The controller is the person or organisation operating this RootMe installation. Their identity and contact details are shown below.
RootMe keeps two groups apart: the account holder (you) and the people recorded in a tree. The second group is mostly not users of the product, and that distinction is maintained throughout this notice.
| About whom | Data | Where it lives |
|---|---|---|
| Account holder | Name, email, password hash, email-verification state | user, account, verification |
| Account holder | Session record: session token, IP address, user agent, expiry | session |
| Account holder | Which trees you belong to and your role, your notifications, your connection preferences | tree_memberships, notifications, connection_preferences |
| Account holder | If AI features are enabled: usage metering (feature, token counts, cost) | ai_usage |
| People in a tree | Given names, surname, display name, gender (free text), living or deceased | persons |
| People in a tree | Birth and death dates and places, biography, notes, profile image | persons |
| People in a tree | Alternative names; residence, occupation, education, military service, religion and custom facts | person_names, person_facts |
| People in a tree | Contact details: full address, landline and mobile numbers, email; with label, source and note | person_contacts |
| People in a tree | Family links: parent–child, partnerships, siblings | parent_child, unions, sibling_links |
| People in a tree | Photographs and the people tagged in them; memories with their dates and places | media, media_persons, memories |
| Guests of an occasion | Invitation name, phone number, note, attendance, gift record | event_parties, event_guests, event_gifts |
| Account holder | Outbound-mail counter: a keyed hash of your address (never the address), the kind of message, the time | email_sends |
| Account holder and people in a tree | Change history: who changed what and when, including before and after | audit_log |
Photographs are re-encoded on upload and EXIF metadata — GPS coordinates included — is not retained. That is proven by a test, not an intention.
| Processing | KVKK | GDPR |
|---|---|---|
| Account and session management | art. 5/2-c — performance of a contract | art. 6(1)(b) — contract |
| Storing and showing tree data | art. 5/2-c — performance of a contract | art. 6(1)(b) — contract |
| Data about third parties in a tree | art. 5/2-f — legitimate interest | art. 6(1)(f) — legitimate interest |
| Contact details of living people | art. 5/2-f — legitimate interest (narrower) | art. 6(1)(f) — legitimate interest (narrower) |
| Cross-tree discovery and connections | art. 5/1 — explicit consent | art. 6(1)(a) — consent |
| AI features | art. 5/1 — explicit consent | art. 6(1)(a) — consent |
| Special-category facts such as religion | art. 6/2 — explicit consent | art. 9(2)(a) — explicit consent |
The legitimate-interest assessment for third parties in a tree requires legal advice and has not been completed. This is a known gap, stated rather than hidden. For contact details the assessment has to be made separately and more narrowly: unlike a birth date, an address and a phone number are directly actionable.
A family tree is, by its nature, made of information about other people. Most of them are not RootMe users and did not give us their data themselves — whoever built the tree entered it (GDPR art. 14 territory).
The application therefore behaves protectively by default:
The application allows a fact of type “religion” to be added to a person. Under KVKK art. 6 and GDPR art. 9 this is special-category personal data and may only be processed with explicit consent.
Today there is no separate consent mechanism for such entries, and they are included in cross-tree projections and exports like any other fact. We are writing this down rather than hiding it: it is a known gap, and until it is closed we recommend not using that field.
There is no field anywhere in the application for health data, biometrics, race or political opinion.
A person can be given a full address, phone numbers and an email address. This data is kept apart from the rest of the tree and governed by its own rules, because a birth date is part of a record while an address and a phone number are things somebody can act on.
The application therefore treats this field more strictly than the rest of the tree:
Responsibility for this field rests with the person writing it into the tree. Where there is a family dispute, a separation, a protection order or a safety concern, recording someone's address can cause serious harm. Anyone who wants a record about themselves removed can use the data-subject request form at /requests, whether or not they have an account.
| Recipient | When | What goes |
|---|---|---|
| People you invite to your tree | When you create an invite link | Tree data, as far as their role allows |
| A tree you connect with | After mutual acceptance | Only the scope you chose; living people as silhouettes |
| Anthropic (USA) | Only if AI features are enabled and you run one | The text and document photograph you submit |
| Email provider | Only if sending is configured: for confirmation and password-reset messages | Your email address, your name and the message itself — never tree data |
| Hosting provider | Always | All data needed to run the application |
No recipient receives contact details — that holds for every row in this table. Anthropic is a sub-processor and this is a transfer to the USA; the contract and transfer mechanism this requires are not yet in place. With no ANTHROPIC_API_KEY set, AI features do not appear at all and no data leaves. The email provider is a sub-processor too; which company it is and where its servers are depends on how this installation is configured, and the contract — plus a transfer mechanism if it is outside the country — is likewise not yet in place. With sending unconfigured, no message leaves and the confirmation and password-reset surfaces do not appear at all.
Your tree data is kept until you delete it — a family record that expired on its own would be wrong. Everything else has a per-category period, and expired records are removed by a daily cleanup job.
| Record | Kept for | Why |
|---|---|---|
| A deleted person | 90 days | So an accidental deletion can be undone; then removed permanently |
| A deleted photograph (file included) | 30 days | The most sensitive record here; the file leaves the disk too |
| An expired session | immediately | It grants nothing; keeping it preserves an IP and user agent for nothing |
| The outbound-mail counter | 2 days | It exists to enforce the daily send limit; a row outside the 24-hour window can no longer affect any decision |
| A used or expired invite link | 180 days | Long enough to answer who invited whom |
| An RSVP link | 180 days after the occasion | A link that travels through a family group chat and can be forwarded; once the occasion has passed it can inform nothing, so the link is cleared and the guest-list entry stays |
| A read notification | 90 days | It has done its job |
| An unread notification | 365 days | After a year it will not be read |
| The change log (audit log) | 365 days | It holds before/after copies of personal data |
| AI usage metering | 400 days | A full year plus a margin for reconciliation; it holds counts, not content |
| Product usage counters | 400 days | A day, an event name and a number — no person, tree or session is recorded |
| An answered data-subject request | 3 years | Proof that we answered; then it goes |
| A person's contact details | removed at once | The undo window covers the genealogical record; an address and a phone do not wait |
This table is not a statement of intent: the periods are defined in one place in the code (src/domain/retention/policy.ts) and the cleanup job applies exactly those. Whether that job is scheduled on this installation is the responsibility of whoever operates it.
Under KVKK art. 11 and GDPR art. 15–22 you have the right to:
Someone who is recorded in your tree and is not a user can ask for that record to be removed through the in-product claim and removal flow.
To exercise your rights or ask about this notice, contact the controller at the address shown above.
If you have no account — for example because you believe somebody else's tree holds a record about you — use the data subject request form at /requests. The response deadline is 30 days.