Industry
Part of 8 things a family tree can honestly claim to show you
Getting family trees privacy right the first time
Family trees privacy: a blanked entry surrounded by full ones is not anonymous, because its neighbors locate it, and the dead disclose the living beside them.
You can label a box "living" and still publish the person inside it. The box has edges, and the edges are attached to people you did name, with dates you did print, in places you did specify. Redaction removes a label. It does not remove a position.
That is the difference between privacy on a page and privacy in a structure. A page can be trimmed sentence by sentence. A structure discloses through its shape, and the shape is what you published.
What to take away
- A blanked entry surrounded by full ones is not anonymous. Its neighbors locate it.
- One person's research reaches relatives who never agreed to be researched, and genetic results reach further than paper does.
- Consent cannot be gathered from a family tree. There is no mechanism, and the absence of one is a reason to publish less.
Redaction fails in a graph
Suppress a name, and what remains is still a node with relationships: two named parents, dated siblings, a place the family was recorded, and a position in a sequence of births. This is the graph version of the effect documented under data re-identification.
Redacted node vs full graph
Redacted entry
- Name
- Blank
- Siblings
- Hidden
- Place
- Withheld
- Birth order
- Unknown
- Dates
- Suppressed
- Result
- Not anonymous
What neighbors reveal
- Name
- Two named parents
- Siblings
- Dated, ordered
- Place
- Recorded location
- Birth order
- Position in sequence
- Dates
- Bounded by relatives
- Result
- Often identified outright
Each detail narrows who the person can be, and together they often identify them outright.
The effect compounds in three ways. Multiple partial disclosures across separate pages combine because structure is the join key and anyone can perform the join.
A single dated event about a named relative sets a boundary on the redacted person's own dates. The number of siblings, plus their order, plus one age, narrows the field to very few people even before a name appears anywhere.
Per-entry redaction is the wrong tool. Assess the published subgraph as a whole, because what matters is what someone who is trying can derive from everything you have shown, taken together.
That is the aggregation test: judge what you have published by everything a determined reader can derive from it taken together, not by each field on its own. It sits at the center of the profile standard this site works to, and in a tree it applies to a structure rather than a paragraph.
What the dead disclose about the living
Records for people who have died open up, and the material in them is about their relatives as much as about them. In the United States, census schedules pass to the National Archives under the Census Bureau's 72-Year Rule, and birth and death certificates stay with state and county vital-records offices, many of which release them only to immediate family. In England and Wales, census returns stay closed for 100 years. Those rules govern the record; none of them governs your page.
| The open record | What it hands a reader about a living person |
|---|---|
| A parent's death certificate | The married name of a living daughter, and the town the family lived in |
| A census household schedule | Names and ages of children who are alive today |
| An obituary listing survivors | Current names and locations of living siblings |
| An old marriage record | A relationship a living person has never made public |
Dead records, living exposure
Published about deceased
- Birth place, maiden name
- Two verification answers
- Dated marriage, household
- Childbearing window, count
- Obituary survivors
- Named living set
- Death date and place
- Where family still is
- Estate filing
- Proven relationships, addresses
Fixes about living relative
- Birth place, maiden name
- Dated marriage, household
- Obituary survivors
- Death date and place
- Estate filing
Nothing in an open record is private by itself. What the record hands over is a fact about a person who was never asked, assembled from material that was opened for a different purpose. None of that changes because the record is old or the search is free.
A record's being accessible answers a question about the record, not about your page. See the guide to what each document can carry.
Research that reaches sideways
Genealogy is unusual among research activities in that participating implicates people who did not.
Genetic testing is the clearest case. A result describes relatedness, and relatedness is shared. One person's test reveals information about parents, siblings, and cousins who made no decision at all. The strongest inferences often concern relationships a family has reason not to discuss.
A discrepancy between paper and biology is not an error to be published. It is usually a real event in somebody's life. If living people are involved, it belongs to them.
Paper research reaches sideways too, more slowly. A branch someone documented for their own interest becomes, once published, a searchable record about cousins who have never heard of them. And a tree published to help relatives find each other is also a tree published to help anyone else find them.
The working rule is that the ability to establish something is not permission to display it. Where a finding is about a living person, the default is a private note, and the person concerned is the one who decides whether it goes further.
Consent has no mechanism here
If a person in the tree is a child, the interest is theirs to waive, not a relative's. The Convention on the Rights of the Child frames it that way.
For a single-subject profile you can at least ask. A tree of living relatives holds dozens of people, most of whom you cannot identify well enough to contact, several of whom would refuse, and some of whom do not know they are in it.
Two consequences follow, and neither is a formality. First, if you cannot ask, publish less; do not proceed without asking.
Second, one relative's enthusiasm is not agreement from the rest: a family member who supplies material gives their own view of a shared subject, and that subject includes people who see it differently.
Requests, when they arrive, will therefore come from people who are not the subject of your page and may not appear on it by name. Treat them as first-party requests anyway. The person objecting to a structure that identifies them has standing regardless of whether their name is printed.
The rules that give a request its weight
A published tree is personal data about living people, and in most places the law says so plainly. In the EU and the UK, the General Data Protection Regulation and the UK Data Protection Act 2018 give a living person the right to erasure of data that identifies them, and the supervisory authority — the Information Commissioner's Office in the UK, the national data protection authority in an EU state — is where a complaint goes when a publisher refuses. In California, a covered business must honor a resident's right to delete under the California Consumer Privacy Act as amended by the California Privacy Rights Act, enforced by the California Privacy Protection Agency and the state attorney general. Nothing about genealogy exempts a tree from any of it.
The Convention on the Rights of the Child points the same way for minors — Article 16 is the privacy article — and its weight lands hardest on the easiest part of a tree to publish: a child relative with no account, no say, and no way to ask you to stop.
What the living portion can carry
- Relationships the people involved have made public themselves, and nothing beyond the relationship.
- Years rather than dates, where a date is needed at all, and usually it is not.
- Regions rather than places, and no place specific enough to visit.
- No children beyond the fact of the relationship where a parent has published it, which is the standard argued out in the guide to claims about children.
- No health information about anyone, at any distance in the tree.
- A note of what was deliberately withheld, kept internally, so a later editor does not read the gap as an oversight.
The last one matters more in a structure than in an article, because a tree with a hole in it advertises the hole. An unexplained absence in a symmetrical diagram is an invitation, and the person most likely to accept it is the next person who works on your file.
What the living portion can carry
- Relationships the people made public themselves
- Years rather than dates, where needed
- Regions rather than visitable places
- No children beyond a parent's own publication
- No health information at any distance
- Internal note of what was withheld
The settings that decide it
Three platform decisions do most of the work, and all of them are made before the first entry. Ancestry withholds living people from public tree views and gives you a private or unlisted tree option; MyHeritage applies its own living-person privacy setting; FamilySearch shows living people only to the contributor who entered them. On 23andMe the DNA Relatives list is a tree of another kind, and each match opted in on their own terms rather than yours.
A GEDCOM export carries everything you entered, living people included, and a file shared with a cousin is a file you no longer control. Export after the living have been reduced, never before. Read the platform's own privacy page too, because the controls are not identical across them and a forum summary is usually out of date.
The first publication, in order
- Choose the audience before you type a namea private file, an unlisted tree, or a public tree.
- Enter the living under the rules abovea relationship they have published themselves, a year rather than a date, a region rather than a place, nothing about health, and nothing about a child beyond what a parent already published.
- Run the aggregation test as a stranger wouldeverything on the page, plus what is trivially searchable, and how many people still fit.
- Trim before you export, and check the GEDCOM for living-person entries.
- Keep an internal note of what you withheld and why, so the next contributor does not fill the gap.
- If someone asks to be removed, act first and explain second, and route a refusal through the platform's privacy process and then the supervisory authority named above.
Common questions
We publish only years and no places. Is the tree safe?
Safer, and not safe by itself. Test it the way an outsider would: take everything on the page, plus what is trivially findable elsewhere, and see how few people fit. If the answer is one, the tree identifies them whatever fields you left blank.
A living relative gave us their own information. Can we publish it?
Their own, yes, within what they agreed to. What they told you about others is not theirs to release, and this is the most common route by which a private person ends up in a published tree.
Someone asks to be removed but their name never appears.
Remove what identifies them, which will usually mean pruning links rather than a label. Explain what you have actually done, since taking a node off your page does not reach copies, archives, or anyone who downloaded the file, and overpromising produces a second conversation later.
How does this apply to a list rather than a diagram?
The same way, with one difference: a flat list hides the structure while still containing it. So the disclosure happens without the reader or the compiler noticing.
What flattening loses and keeps is worked through in the guide to turning a tree into rows. The household distinctions that make a structure hard to draw honestly are in the guide to describing relationships rather than membership.
A public figure is in the tree. Does their fame change what their relatives lose?
No. A person who has chosen publicity has given up part of their own privacy; the sibling, the child, and the former partner in the same diagram have given up nothing. A tree carrying a well-known name gets opened far more often, which makes the aggregation test stricter, not looser: the famous name is the strongest join key in the file, and everything hanging from it is easier to reach than it would be anywhere else.
