Privacy Policy

FamilyGraph helps extended families collaboratively record their own history. Because the records you upload describe other people — some of them children, some of them deceased — this policy is more deliberate than the SaaS norm. It explains what we collect, why, who we share it with, and what you and the people you write about can ask us to do with it.

What we collect

Account data. Your email address, display name, a one-way hash of your password (we never see your plaintext password), the secret used to verify your second factor if you enrol multi-factor authentication, and a stable identifier from your external identity provider if you choose to sign in that way.

Family-graph data. The names, dates, places, relationships, and photos you (or other contributors with edit rights) record about family members. This is the core of the product.

Behavioural and operational telemetry. Sign-in timestamps and IP addresses in server logs, error reports and stack traces from our error-monitoring provider, and aggregate request-completion metrics. We do not infer behavioural categories from this data.

We do not collect inferred categories (advertising profiles, demographics, location history) and we do not run third-party analytics or trackers in the browser.

Why we collect it

Account data is used to authenticate you and keep your session secure. Family-graph data is the product itself — without it the service has nothing to display. Telemetry is used to keep the service running, debug failures, and protect against abuse; we retain only what is needed to do those things.

Categories of processors

To run the service we rely on a small number of processors, described below by category and region. Where you choose to sign in via an external identity provider, that provider receives the minimum data needed to authenticate you; your family-graph content is never shared with them.

A federated identity provider, used only when you choose to sign in with one. The provider receives your email and basic profile to authenticate you.
A managed database provider hosted in the EU, which stores account data and the family graph.
A cloud application platform hosted in the EU, which runs the service and stores uploaded media.
A transactional email provider, which delivers verification, magic-link sign-in, password-reset and similar messages.
An error-monitoring provider, which receives stack traces and runtime errors from the backend and frontend so we can debug failures.
A source-code and CI host, which holds the source repository and build pipeline; it receives no end-user content.

Each processor is contracted to handle data only on our instructions. We do not sell, rent, or trade your data. The specific vendor names and their data-processing terms are available on request — email privacy@dube.africa.

Data uploaded about other people

A family graph is, by design, a record of people who have not themselves chosen to use FamilyGraph. We treat this with care.

Lawful basis.We process information about non-account-holding family members on the basis of legitimate interest in family record-keeping. POPIA s. 11(1)(d) and GDPR Art. 6(1)(f) both recognise this basis where the processing is balanced against the data subject's rights.

Takedown and correction.If you are named in someone else's family graph and would like a record removed or corrected, email privacy@dube.africa. The operator processes takedown requests manually within 30 days. Where a record is shared with multiple contributors, removal may mean redaction of identifying fields rather than deletion of the row, so the surrounding graph structure stays intact.

Children

FamilyGraph does not require children to create accounts and does not solicit them. A child may appear in the family graph as a record entered by an adult relative. When that child reaches the age of majority and chooses to create their own account, the link-request flow gives them edit rights over their own row; existing edit rights held by the relative who entered the record remain (the family record is shared, not transferred).

Parental and guardianship semantics inherit from the platform's standard permission model: a parent or guardian who holds edit rights over a child's record can update or remove it on the child's behalf. Disputes between guardians about a single record are escalated to the operator via privacy@dube.africa.

Deceased family members

POPIA and GDPR rights generally do not survive the data subject's death; family-record platforms are nevertheless common holders of information about deceased ancestors. Our posture: deceased persons remain in the graph as historical records. Next-of-kin retain takedown rights via privacy@dube.africa; we will redact or remove a deceased relative's record on request from a verifiable family member.

Your rights

You can request access to, correction of, export of, or deletion of your account data and the family-graph rows you created. POPIA gives you the right to a data-subject access request; GDPR Articles 15–21 cover the same ground in slightly different shapes. To exercise any of these rights, email privacy@dube.africa. The operator processes requests manually; we acknowledge within 7 days and complete within 30.

Deleting your account removes your authentication identity and unlinks you from your linked family-graph row. Family-graph rows you created remain in place by default — they describe shared history that other contributors may rely on — but you can additionally request the deletion of specific rows you created in the same email.

Data retention

We retain account data for as long as your account is active. When you delete your account, the authentication identity is removed within 30 days. Family-graph rows and uploaded media you created stay in place by default (they describe shared history); rows you specifically request to delete are removed within 30 days of the request.

Operational logs and error reports are retained for the rolling window our processors keep them — typically around 30 days. Database backups follow the provider's default retention. Specific retention windows are available on request via the contact address below.

Feedback you submit

When you submit feedback (a bug report or a feature request) through the in-app form, we forward it to a third-party issue tracker so the maintainer can act on it. Bug reports include a snapshot of your browser environment — page URL, browser version, viewport, language, theme preference, connection type, and the last few uncaught errors your browser reported — to help reproduce the issue. Feature requests include the same browser snapshot minus the error log.

The error log captures the message strings exactly as your browser produced them. If your browser surfaced an error message that incidentally includes personal data (for example, a URL containing your email address or a stray field value from a form you were filling out), that text will be sent verbatim. The pre-submission panel below the bug-report form lets you review the full payload and cancel the submission if anything looks sensitive.

Before you submit a bug report, an expandable panel on the form shows you exactly what will be sent. Nothing in the snapshot identifies you beyond what your account already does (your email is attached so the maintainer can follow up). The snapshot is stored alongside the issue and is visible to operators only.

To remove a feedback record after the fact, email privacy@dube.africa with the issue number from the confirmation email.

Cookies and local storage

We set one first-party encrypted session cookie that keeps you signed in; it is essential to the service and cannot be disabled. We also use your browser's local storage to cache recent responses from our own API so navigation feels instant. We do not set third-party cookies, advertising identifiers, or analytics trackers.

Contact

For privacy questions, takedown requests, or data-subject access requests:

privacy@dube.africa

We acknowledge requests within 7 days and aim to complete them within 30. South African data subjects may also escalate to the Information Regulator (POPIA); EU/EEA data subjects may escalate to their national data protection authority.

Updates to this policy

The current version is stamped in the header above. When we update this policy in a way that changes how we handle your data (new processor, new data category, materially different retention), we will surface a notice in the app on your next sign-in. Minor edits (typo fixes, clearer wording) are made without notice; the version number and effective date track them all.

The full revision history is visible in the source repository — every word of this page is a Git commit you can inspect.