Branches Privacy Policy

Effective date: 2026-09-22
Operator responsible for this Service: Zahr LLC
Address: 5806 Grove Ave, Richmond, Virginia 23226, United States
Privacy contact: aminedzare@gmail.com

Branches lets invited family members build and explore family trees together. This Policy explains personal information handled through the Branches app and related services at branches.love. It also covers information about people who do not have an account but appear in family records supplied by others. The initial release is offered to users in the United States.

1. Information we collect and where it comes from

We collect information you provide, information other members provide about you, information from sign-in and delivery providers, and technical information generated when the Service runs.

Account and sign-in

Information and source
Email address; account identifier; display name and any profile image reference; account creation and update times; account status; sign-in attempts and rate-limit records; hashed email verification codes and session tokens; session expiry and last-use times. If you use Sign in with Apple, we receive a signed identity token for verification and store Apple's account identifier and supplied email, which may be a private relay address.

Why we use it
Create and authenticate accounts, maintain sessions, associate your activity with you, restrict tree creation to invited creators, and prevent abuse.

Family profiles

Information and source
Names, alternate and birth names, birth year, birth and current places entered as text, living/deceased status, death year, minor status, pronouns, gender, biography, and portrait selection. You or relatives may provide these, including about nonusers.

Why we use it
Display family cards and let members contribute to and correct records.

Relationships and family material

Information and source
Parent, child, partner, and sibling connections and their types; relationship dates, status, notes, and confirmations; occupations and organizations; stories and their dates and storytellers; source citations, links, notes, and confidence labels.

Why we use it
Build trees and ancestry views, derive kinship descriptions, and preserve family contributions.

Photos

Information and source
Images you select for upload; normalized images and thumbnails; captions, descriptions, source notes, dates, person associations, portrait positioning, permission confirmations, upload status, file sizes, types, and integrity hashes.

Why we use it
Process, store, display, and control access to family photos.

Collaboration and preferences

Information and source
Terms acceptance version and timestamp; family names and memberships; roles; invitation and onboarding records; account-to-person links; sharing choices; proposed and previous values in change requests and edit history; contributor identifiers and timestamps; reports, review decisions, notifications, contribution activity and scores; celebration and notification preferences.

Why we use it
Coordinate access, approvals, corrections, history, moderation, and contribution features.

Notification registration

Information and source
With notifications enabled: an app installation identifier, push-delivery token, device platform, registration/activity times, and notification destinations such as family or person identifiers.

Why we use it
Deliver and route family update notifications and manage device registrations.

Diagnostics and service access

Information and source
Error and crash reports, stack traces, app/runtime and device information, technical request context, and short-lived hashed network identifiers and counters used to limit public erasure attempts. Our hosting, storage, and delivery providers may process IP addresses, request paths, timestamps, and delivery or access records.

Why we use it
Diagnose failures, deliver the Service, secure it, and investigate abuse.

Requests you send us

Information and source
Contact information and the details you choose to include in support, correction, or privacy requests.

Why we use it
Respond, verify authority where necessary, and document how a request was handled.

You can omit optional profile details. Account authentication requires the relevant sign-in information. Photo access and notification permissions are optional; declining them limits those features.

The current app does not request your contacts, precise device location, microphone recordings, advertising identifier, or DNA data. Places in profiles are entered by people, not obtained by GPS. Photo selection does not upload your entire library. Images and free-text contributions can nevertheless reveal sensitive information, including about relatives. Only share information you are entitled to provide, and avoid unnecessary sensitive details.

2. How we use information

We use the information for the purposes in the table: running accounts and family trees, displaying and organizing content, applying permissions, providing optional notifications, handling requests and disputes, maintaining security and reliability, and meeting legal obligations. Relationship and ancestry results are derived from entered records, not from genetic testing or independent verification. We do not use these results to make decisions about credit, employment, insurance, or legal eligibility.

The current Service does not sell personal information, share it for cross-context behavioral advertising, display targeted advertising, or send family content to a generative-AI provider for model training. Service-provider processing and sharing within a family are described below.

3. Who can see information

Family members. Access requires authorized family membership. Active cards' names, family names, and relationship connections can be visible within the tree even when additional details are restricted. A “name only” setting does not make a person anonymous or remove them from the tree. Additional profile details and associated content depend on sharing settings and permissions, including sharing with the tree or a confirmed descendant branch. Confirmation records affect access rules; they do not verify biological relationships.

The person linked to a profile can control its sharing. Owners and admins have specific management and review permissions, including access to certain unclaimed deceased profiles. Their role does not give unrestricted access to all living members' restricted details. Edit history, attribution, contribution features, and reports can expose information to members authorized to see those features. Proposed changes may be visible to their submitter and the people authorized to review them before they become an approved family record.

Copies outside the app. Family owners can export the family information they are permitted to see. That export excludes hidden profile details, private audit entries, invitations, sign-in data, and photo files. Members can also take screenshots or otherwise copy information they can see. Branches cannot recall independent copies when settings change or data is removed.

Service providers. We use the following providers for specific functions:

Heroku / Salesforce

Function and information involved
Hosts our API, background workers, and PostgreSQL database, processing account records, family content and metadata, and service requests.

Amazon Web Services (S3)

Function and information involved
Stores private uploaded/processed photos and thumbnails and associated storage/access records.

Resend

Function and information involved
Delivers sign-in email, processing recipient email addresses, verification messages, and delivery information. Our database stores verification-code hashes, but the delivery provider processes the code in the email itself.

Apple

Function and information involved
Provides optional Sign in with Apple and iOS push delivery. Sign-in information is exchanged when you choose that method; push delivery involves delivery identifiers and notification payloads.

Expo

Function and information involved
Registers and delivers enabled push notifications using push tokens and notification payloads. Current family-update notifications use generic wording and may include family/person identifiers for opening the relevant screen.

OpenAI

Function and information involved
Screens normalized uploaded photos for content safety and returns moderation decisions. Text filtering stays on Branches servers.

Sentry

Function and information involved
Receives app and server error/crash diagnostics when configured, including technical device/runtime information and error context.

Diagnostics are configured to reduce personal information: explicit user data, request bodies, headers, cookies, and URL query strings are removed from designated diagnostic fields. The app disables screenshots, screen hierarchy attachments, and session replay. These safeguards do not make every diagnostic or provider access record anonymous; technical identifiers and request paths may still be processed.

Content safety checks. We check submitted family text on our server using a limited list of objectionable words. This text check does not send the text to an outside moderation provider. Reports may quote objectionable language so that it can be investigated.

Before a new photo upload, the app asks you to confirm permission to share it and explicitly agree to OpenAI's safety check. We record that permission's version and server timestamp with the photo. You can cancel the upload if you do not agree. New uploaded photos are screened using OpenAI’s Moderations API before family sharing. OpenAI receives a normalized image for this safety check; we do not send account names, email addresses, or family-tree records with the request. We retain a safety decision, policy version and check time with the photo, and may reuse a matching result for the same uploader's identical image in that family. Authorized Branches operators can review a flagged photo. Screening can make mistakes and does not verify the truth, ownership or appropriateness of every family record. Contact aminedzare@gmail.com to request review of a mistake.

OpenAI states that API inputs are not used to train its models unless a customer opts in. We do not opt in to sharing these photos for training. Its published Moderations endpoint table lists no abuse-monitoring retention or application-state storage. Separate provider account/security records and legal requirements are not a promise of zero retention of every kind of information.

Other disclosures. We may disclose information when reasonably necessary to comply with law or valid legal process, protect rights and safety, investigate abuse, or handle a business transfer such as a merger or acquisition, subject to applicable law and this Policy. We may also share information at your direction. A family relationship alone does not entitle someone to obtain private information from us.

We also use Google Gmail to receive and handle messages sent to our published support/privacy address. Google processes the sender address, message content, attachments you choose to send, and correspondence metadata for that mailbox.

4. Storage and security

Our Heroku application runs in its United States region. Structured records are stored in a PostgreSQL database hosted by Heroku. Photos are stored separately in private Amazon S3 object storage in the US East (Northern Virginia) region, us-east-1. Production connections use encrypted transport. Photo storage uses server-side AES-256 encryption at rest, blocked public access, and versioning. The server checks authorization before granting private photo access, including short-lived signed links where used.

We store hashes of session tokens and salted hashes of email sign-in codes in the database. The app keeps its session credentials and Apple sign-in identifier in operating-system secure storage. Push installation identifiers also use secure storage. Other device storage includes tree-preview files containing record identifiers, connections, and layout positions, in-memory app data, and temporary files for selected photos and exports. These are not all stored in the secure credential store. Exports you share may remain in the destination you choose.

Before sign-in, the app asks for your birth month and year, without a day. That input is processed on your device and is not sent to Branches. If you are not yet eligible, the app saves the calculated eligibility month in local secure storage, without an email or account identifier. This is age-related information: the eligibility month corresponds to the month after your thirteenth birthday. The restriction remains across app restarts and stops blocking signup on the first day of that month, using your device's local calendar. The saved month may remain on the device after it stops blocking signup. There is no in-app reset before eligibility. Crash reporting is initialized only after sign-in; signed-out diagnostic events are filtered out.

The Service is not end-to-end encrypted: Branches servers and providers must process information to operate it. Private family sharing is an access control, not a promise that only relatives can technically access the underlying data. No storage or transmission method guarantees absolute security.

Resend states that it stores customer data, including email content and delivery records, in the United States. Its email-sending region is a separate setting from its storage location. Other providers may process information in the United States and other countries. Offering the app initially in the United States does not mean that all provider processing is confined to this country. Our Sentry organization's crash/error event storage region is the United States.

5. Cookies and similar storage

The current native app and first-party API use session tokens rather than browser cookies to authenticate users. We do not currently implement advertising cookies, tracking pixels, or cross-site advertising trackers in them. Device storage described above keeps you signed in and supports app functionality; it is not an advertising-tracking system.

Apple sign-in, external links, and any service-provider pages you open can have their own cookie and storage practices. Your browser controls apply to those pages. Browser cookie controls do not delete your Branches account or erase the native app's secure storage. The current Service does not change its behavior in response to a browser's Do Not Track signal. If we add website cookies or other tracking, we will update this description and provide choices or obtain consent where required before introducing them.

Our integrated providers receive information to host the Service, deliver email and notifications, authenticate users, or diagnose failures. We do not integrate advertising networks, advertising attribution tools, or data-broker services, and do not authorize providers to use Branches family content for cross-app advertising. This does not mean providers receive no technical identifiers or that their independently operated websites have no tracking.

Open tracking and click tracking are disabled for our Resend sign-in emails. Resend still processes the recipient address, message content and delivery records needed to send and troubleshoot the email.

When you open an external source link or website, its operator handles the information it receives under its own privacy policy. Review that policy before providing information there. Our responsibilities for providers processing information on our behalf remain as described in this Policy.

6. How long information stays

We retain account information and associated family contributions to provide the ongoing family-history service while the account remains open and the Service continues, unless particular information is removed earlier through the Service or an applicable privacy request. There is no fixed account-retention period or automatic deletion merely because an account is inactive. Terms acceptance records are kept while the account exists and are removed with account deletion. When an account is deleted, our policy is to delete its associated personal information and contributions, subject to the shared-record review and lawful retention exceptions described in section 7. If we discontinue the Service or information is no longer needed for its disclosed purpose, we will delete it unless a continuing lawful reason requires limited retention.

Family records independently contributed by other members may involve several people; a deletion request concerning those records is reviewed as described in section 7. Owners and admins can view activity logs, but cannot restore earlier tree versions. Account deletion removes logs for erased records and strips content snapshots from remaining logs in affected trees. Event and field-name metadata may remain without the deleted account's identity. Hiding a profile or removing a visible entry is not necessarily permanent erasure.

New email and Apple sign-ins create sessions valid for three years (1,095 days), unless you sign out, delete your account, or the session is otherwise revoked. Existing sessions keep the expiry assigned when they were created. This session lifetime is separate from how long we retain your account.

To enforce an account ban, we retain a hash of the normalized email address and, when available, a hash of the linked Apple identifier, together with a reason category and timestamps. Hashing does not make these records anonymous. Access is restricted to service operations. A ban can have an expiry date or remain until lifted; expired bans stop blocking access immediately and are removed by hourly cleanup. Bans without expiry are reviewed when challenged or when the safety reason no longer applies. These limited records may remain after account deletion to prevent re-registration; the ban does not preserve the deleted profile or family contributions.

An hourly cleanup removes used or expired sign-in codes after 24 hours, expired session records seven days after expiry, and email authentication rate-limit records seven days after their window began. Removal occurs on the next successful cleanup; these rules do not shorten valid sessions.

Photos held for a safety review are not shared with the family. If not approved, they become eligible for removal after seven days; cleanup depends on a successful storage operation. Rejected photos are removed through the operator review process. Moderation metadata follows the photo record's retention and account-deletion rules. Monthly photo-check totals contain no user or photo identifiers and may be retained for cost control.

Unclaimed temporary cards expire seven days after creation. Automatic cleanup removes the expired card, its bound invitations and onboarding drafts, and associated card records, and queues associated photos for removal. This period starts when the temporary card is created, not when an invitation is received or opened. Once claimed, a card becomes an active family record and does not expire under this rule. Expiry of an invitation to an already active profile does not by itself erase that profile. If you created an account but did not finish joining a family, temporary-card cleanup does not delete that account or its authentication records.

The Service also has cleanup processes for abandoned or deleted photos and deleted family trees. Photo cleanup includes stored versions. These processes are asynchronous and depend on successful completion, so seven-day expiry is not a guarantee that every stored copy is erased at that exact moment. Sign-in code or session expiry prevents further use of that credential; expiry does not by itself mean the corresponding database row has been erased.

The account-retention policy does not mean we keep all technical information for the lifetime of the app. Backups, provider logs, delivery records, and diagnostics have separate purposes and can have different retention periods from active data:

Any retained information must have a continuing lawful purpose. We will explain applicable retention exceptions when responding to a deletion request.

7. Choices, requests, and account deletion

You can use available profile-sharing and correction controls, submit reports, and disable notifications in the app or device settings. Changing visibility limits subsequent access under the app's rules; it does not erase stored data or copies already made by other people. The family export is an owner feature, not a complete personal-data access response.

Contact aminedzare@gmail.com to request access, correction, deletion, or another applicable privacy right. You may contact us without creating an account, including about a profile or photo supplied by someone else. Include enough information to locate the relevant account or family record. Do not send passwords, sign-in codes, or unnecessary identity documents. We may ask for proportionate verification of your identity or authority to protect against unauthorized disclosure or deletion.

In-app account deletion: choose Delete account from the Families screen or family Settings. Confirm ownership with an email code or fresh Sign in with Apple verification. An email address alone is not sufficient. Apple authorization is revoked as part of deleting an Apple-linked account.

Before deletion, you can transfer each tree you own to another active member. Transfer is strongly recommended but optional. Any tree you still own is deleted for everyone after you confirm the displayed list. Deletion removes your account, your linked cards and their connections, unclaimed cards you created and their attached content, and contributions you supplied—including photos, stories, sources, occupations, and relationships. Cards claimed by other accounts remain; fields last supplied by you are cleared or replaced with neutral placeholders, without restoring older values. Content independently supplied by other members on surviving cards remains.

The app confirms success after deletion from the live database and photo storage, including stored photo versions. If deletion cannot finish, it reports failure and lets you verify again and retry; some photos may already have been removed. Backup and provider-copy handling follows section 6.

Invite-code erasure: choose Erase invitation information from the app's welcome or sign-in screen. No account or Terms acceptance is required. After confirmation, a valid code erases its unclaimed temporary card, bound invitations, onboarding drafts, connections, attached content, and associated photos from the live service. An account created while joining is not deleted by this flow. Expired codes can still authorize erasure while the temporary card exists. Revoked codes cannot; claimed cards require verified account deletion or a privacy request. Invalid or already-erased codes receive an unavailable response without revealing family details. If photo deletion fails, the app reports failure and you can retry; some photos may already have been removed.

The browser form is available at https://branches.love/erase. It uses no analytics or cookies. A first-party script formats the code locally as you type or paste it. The form sends codes in a form submission, not in the URL. Public erasure attempts are rate limited using short-lived hashed network identifiers. The worker removes rate-limit windows older than one hour; this cleanup depends on successful worker operation. For other requests or help, contact aminedzare@gmail.com. Unclaimed temporary cards also expire under the seven-day rule above.

Invitation links carry the code in the URL fragment, which is not sent in the web request. The landing page reads it locally to let you open Branches or copy your invitation. The app writes an invitation link to the clipboard only when you choose to copy it; it does not automatically read your clipboard or use fingerprinting to match an installation to an invitation.

Signing out, uninstalling the app, being removed from a family, or deleting a family tree does not itself delete your Branches account.

An account-deletion request covers your account and associated personal data and contributions, subject to any lawful retention requirements. Because family trees contain information about multiple people, please identify any records about you contributed by others that you also want addressed. We will review those records against your rights and any applicable rights of others; their presence in a shared tree is not a blanket exception to deletion. We cannot erase independent screenshots, exported files, or records held by others outside our control.

For requests submitted by email, our target is to complete deletion from active systems within 30 calendar days of receiving a request. We may need to verify your identity or authority before taking action. We will meet any shorter deadline required by applicable law, explain any legally permitted extension, and confirm the outcome, including information retained and the reason. Backup and provider-copy handling follows the separate retention rules described in section 6. These requests are reviewed and handled manually. We record when a request was received, any verification needed, the action taken, and our response. Verification does not restart the 30-day target.

Depending on your location and the laws that apply, you may have rights to access or obtain a copy of your information; correct or delete it; restrict or object to processing; receive a portable copy; withdraw consent where processing relies on consent; and appeal a refusal or complain to a privacy regulator. Withdrawing consent does not make earlier lawful processing unlawful. You can contact us to exercise or appeal a request, and you may contact your regulator directly. We will not unlawfully discriminate against you for exercising privacy rights. Authorized agents may act where permitted, subject to verification of their authority.

Requests and appeals in the United States. You can use the contact above for access, correction, a copy of your information, or deletion, whether or not you have an account. An authorized agent may contact us; we may need evidence of authorization and proportionate verification. A parent or legal guardian may act for a child where permitted by law. We do not require you to create an account to make a request.

To appeal a refusal or incomplete response, reply to our email or email aminedzare@gmail.com with “Privacy appeal” and identify the decision you want reviewed. We aim to respond to appeals within 30 calendar days, explain our reasons, and provide a way to contact your state attorney general if the appeal is denied. You may complain to a regulator without first appealing to us.

We do not sell personal information or use it for targeted advertising, so there is no sale or targeted-advertising use to opt out of. A browser's Global Privacy Control signal does not turn off necessary sign-in, hosting, or security processing. We do not discriminate against people for exercising privacy rights. Specific statutory rights depend on the law that applies; these request channels are available to all our users.

Removal of material posted as a minor. If you are under 18, you may request removal of information you posted by using account deletion or emailing us to identify particular material. You may also report information other people posted about you. Removal from Branches does not recall screenshots or copies held independently by other people; any applicable retention or legal limits will be explained in our response.

8. Children and information about relatives

Accounts are for people aged 13 and older. Children under 13 may not create or use an account. Users aged 13 or older who are under the age of legal majority must obtain a parent or legal guardian's permission where required by applicable law. Where the law requires Branches to obtain parental consent before providing access or processing information, that consent must be obtained before the relevant access or processing occurs. Agreement to our Terms does not substitute for required parental consent. A family record about a child is different from an account operated by that child. Relatives may submit names, images, and family connections about children; the existence of those records does not establish parental consent or make the Service suitable for independent use by children.

Only provide information about a child when you have lawful authority and any required permission. Do not provide a child’s home address, school schedule, or real-time whereabouts. Branches is not intended to hold medical histories, diagnoses, treatment details, reproductive-health information, or genetic-test results about living people. We do not derive health predictions from family relationships. Parents, guardians, and people concerned about a child's information can contact aminedzare@gmail.com for review or deletion requests. If we learn that an account was created by a child under 13, we will take steps to remove that account and associated personal information, subject to any legal retention requirement. The age screen uses a self-reported birth month and year on the device; it is not identity-document verification or parental-consent verification. Existing signed-in users who need to accept the published Terms also pass this screen. We do not offer an under-13 signup exception based on a Terms checkbox or a relative’s invitation. A parent or guardian’s relationship to a teenager does not automatically give them access to the teenager’s account.

We can revoke sessions and prevent new sign-ins for a reported account, including one confirmed to be operated by a child under 13. Access restriction is separate from erasing stored information. A person whose account is banned can still contact our published email to request deletion or appeal the ban. After reviewing a confirmed under-13 account or another case requiring account removal, an authorized Branches operator can erase the account and its associated content using the same deletion rules described above. The limited ban record remains subject to its expiry or review, so erasure does not itself permit re-registration. Any trees still owned by that account are also deleted.

For operator deletion of an Apple-linked account, we can remove Branches data without requiring the banned person to sign in again. Because we do not retain Apple access or refresh tokens, automatic Apple revocation is unavailable in that operator flow. We provide instructions for the person or appropriate guardian to remove Branches from Sign in with Apple; we do not represent that manual follow-up as completed automatic revocation.

9. Changes and contact

We will update this Policy when practices change and show the new effective date. We will provide appropriate notice of material changes and seek consent when required before using information in a materially different way. Continued use does not replace consent where the law requires it.

For questions or privacy requests, contact Zahr LLC at aminedzare@gmail.com or 5806 Grove Ave, Richmond, Virginia 23226, United States.