Privacy Policy

This is a local-build privacy notice, not a final production privacy policy. It describes the records modeled in the current repository and the safeguards implemented in code.

Production use requires an approved data controller, provider inventory, retention schedule, incident contact, deletion and export procedures, deployed security controls, and jurisdiction-specific legal review.

The code models Firebase account identifiers and email, private profile and timeline data, wish metadata, check-in and activation records, recipient metadata, client-encrypted contact deposits, client-encrypted wish deposits, deposit receipts, Memory Marks, object capsules, readiness results, contact messages, and audit events.

The local contact endpoint derives a secret-keyed rate-limit token from request network metadata. It stores the token and submission record for abuse control; the public client cannot write contact records directly.

Source profiles and timeline entries are private to the owner and trusted operational roles. Public profile pages read a separate allowlisted projection containing only approved display fields.

Public receipt pages omit private content commitments, member identity, recipient identity, wish identifiers, and message content. Public Memory Mark and object-capsule projections omit owner and encrypted-record metadata.

The browser can create AES-256-GCM envelopes with random content keys and initialization vectors. A passphrase-derived wrapping key protects the content key, and server code verifies the submitted ciphertext hash before storing a deposit.

Passphrases are not sent to or retained by the current server. Recovery, recipient key release, key rotation, post-activation access, and long-term custody are unresolved production requirements.

Private APIs require Firebase identity tokens with revocation checking. Administrative operations require an approved custom claim. Firestore rules are deny-by-default and separate member, verifier, administrator, server, and public access.

These controls are verified locally through unit and emulator rules tests. They are not claims that the rebuilt rules or configuration are deployed to the live domain.

The modeled records support account access, profile publishing, wish planning, encrypted deposits, readiness checks, support responses, rate limiting, administrative review, and auditability.

Firebase is the selected application platform in the repository. A final production processor list, hosting region, analytics policy, email provider, payment provider, delivery provider, subprocessor agreement, and cross-border transfer review have not been approved.

No final production retention or deletion schedule is in force for this local rebuild. Immutable audit, receipt, contact-deposit, and sealed-deposit records require a documented legal and operational policy before real use.

Backup configuration, restore testing, account export, erasure exceptions, deceased-member handling, and legal-hold procedures remain production blockers.

Do not use this local build for minors, estate administration, identity evidence, health information, financial instructions, legal notices, or other regulated records.

Age assurance, parental authority, verifier consent, identity proofing, estate authority, evidentiary custody, and jurisdiction-specific rights require separate policies and controls.

A member can keep a profile private, explicitly publish or unpublish its safe projection, choose what to enter, and avoid sending sensitive content through the contact form.

Production access, correction, export, objection, and deletion requests need a verified request workflow before they can be promised as operational service levels.