Mahvo Privacy Policy Draft

Draft for owner/lawyer review. Not effective or published.

Operator and privacy controller: [Company name] LLC (placeholder; incorporation and legal identity unconfirmed). Business address and jurisdiction: [to be supplied]. Privacy contact: [verified contact to be supplied]. Effective date: [after approval].

Information handled by Mahvo

Mahvo uses account and device identifiers, public cryptographic information, session and routing records, in-app contact relationships and notification tokens to connect people and deliver communications. A Share Code is a connection identifier, not a promise of anonymity. Supported invitation flows may associate the inviter and guest; anonymous invitation paths still expose routing and timing information.

Messages, attachments and sealed Drop payloads are designed to be encrypted on the sender's device. Services can still handle encrypted payloads, sizes, expiry, receipt state, participants and other delivery metadata. The fragment of a sealed link carries sensitive key material; anyone receiving the complete link and any required passcode may be able to open it. Do not forward it to someone you do not trust. End-to-end encryption does not hide every metadata field or prevent recipient capture.

Where reporting is enabled, the selected report information is intended for authorized safety review; actual routing, staff access and retention must be verified before publication. This is different from ordinary encrypted delivery. If you contact support, your message and any information you include are handled to respond. Do not send recovery words, passwords, complete secret links, private keys or unrelated personal content.

Optional store transactions involve the relevant app store. Mahvo handles purchase verification and entitlement information associated with the app identity; payment card processing is handled by the store. Do not infer that only a single entitlement date is retained: actual purchase proof, refund, gift and notification records need final operational reconciliation.

In the reviewed Play purchase implementation, the authenticated server receives the purchase token and associated product and request information. When configured, Mahvo sends that token to Google to verify and acknowledge or consume the purchase. The inspected server path stores account-linked payment/request hashes, product and completion time; hashing does not make these records anonymous. Actual purchase enablement, retention, provider configuration, logs and backups remain unverified. The reviewed per-account device billing journal also retains purchase receipts, including the Play token, after completion; this controller has no age-based pruning. A gift-notice validation window does not establish receipt retention. This source finding does not establish token deletion or a no-logging guarantee.

Permissions and local information

Camera, microphone and selected-photo/file access support the features you choose. Saving permitted media can create a copy outside Mahvo's private storage. In-app contacts do not by themselves mean that the system address book is uploaded. A repository phone-verification path does not establish that phone registration is enabled in the submitted release. Precise location, broad media-library access and advertising identifiers are not demonstrated V1 requirements in the reviewed Android evidence. Final iOS and Android release permissions and enabled services must be verified before publication.

What we count

The reviewed API source emits request-failure diagnostics containing an event label, timestamp, request identifier and a restricted error category. This inspected handler omits request URL/query, credentials, payload and exception text/stack from these records and its fixed error responses. Production capture, recipients, retention, linking and purpose remain unverified. This source finding is not a whole-app no-logging claim.

The designed server counters cover new identities, daily active identities, messages relayed, Drops created and opened, sealed links created/revealed/expired, direct and relayed call time, Plus purchases and errors. The daily-activity counter is designed to use a rotating keyed digest rather than a public user identifier; actual deployment and rotation remain unverified. This is operational analytics; “no third-party analytics SDK” would not mean no counting. Actual log, digest and backup retention must match the final service configuration.

The current source conservatively declares user IDs, device IDs, purchase history, messages, other user content, photos/videos, audio, contacts, product interaction, performance and other diagnostics as linked to the app identity, without tracking. This declaration must be checked against actual enabled flows and partners. It is not a declaration that Mahvo collects no data. Network addresses or derived network blocks can be processed for delivery and rate limits.

Recipients and international processing

The owner-confirmed infrastructure uses Hetzner for API hosting and Cloudflare R2 for encrypted storage and backups, with Cloudflare Realtime TURN for call relay. Native Apple APNs and Google FCM registration/delivery support is present in source, but delivery remains disabled in the current infrastructure handoff. These named services do not establish every recipient, processing country or contractual safeguard, and do not imply completed final-artifact or device-delivery verification.

Information reaches the people you communicate with and may pass through hosting, notification, media-relay, storage, store-verification and support providers. An external mail app/provider separately handles email delivery when you use it. The operator must insert the actual provider names, functions, processing countries, contract safeguards and lawful disclosure process before publication. No unverified no-sharing or no-international-transfer promise is made.

Retention and deletion

Encrypted server backups, which Mahvo can’t read, are deleted automatically within 3 days.

Chat mode, Drop opening, expiry and save settings affect content availability. Disappearing from a screen is not proof of immediate removal from every server, log, backup or recipient device. Copies recipients saved or captured may remain. Travel or local hiding features are not equivalent to permanent deletion, and some local encrypted records can persist for their intended lifecycle.

Use the identity-deletion flow verified for the submitted build, if available; removing the app alone does not request server deletion. The published support/deletion page must explain authentication, scope, completion timing, retained fraud/transaction/legal records, backup lifecycle and request handling. These exact durations and the final deletion journey remain review fields: [operator retention schedule and verified deletion URL]. The specification's aggregate-only and expiry goals must be verified operationally before being promised as achieved.

Source review shows that the normal authenticated server deletion path hard-deletes the account and cascades its payment rows if the required schema is applied and the operation succeeds. It also retains a deletion-receipt token hash with a 24-hour validity window; that window does not prove physical erasure at 24 hours. The retirement-enabled path retains retirement proofs and a signed certificate containing the account subject, device identifier and public signing key, without a source-defined expiry in the inspected path. These exceptions do not justify retaining other data indefinitely. Actual deployment, successful deletion, retention schedules, backups, provider records and local billing-journal erasure remain unverified and must be reconciled before publication.

Security has identified a source-defined whole-identity deletion path: after exact-identity confirmation and private cleanup, it removes that identity’s local metadata and journal directory, including the billing journal, while preserving other identities. This is not per-purchase expiry or deletion on lock/background, and actual execution and external backup/provider effects remain unverified. Retained server retirement proofs support offline linked-device deletion verification and replay after a lost acknowledgement; they remain linked security metadata, not anonymous records.

Your choices and rights

You can choose what to send, decline optional permissions, use report/block controls and request help with access, correction or deletion. Applicable rights and lawful bases depend on your location and the operator's legal obligations. [Counsel to insert lawful bases, regional rights, appeal and regulator contacts, international transfer safeguards and children's policy.] Recommended draft audience is adults 18+; this does not establish an age-verification feature.

Mahvo is closed source. Each dependency's licence text is required to ship in the app's licences screen; final packaged completeness remains unverified. Third-party licences do not grant rights to Mahvo's proprietary source. No completed independent audit, public source access or reproducible-build verification is promised.

Changes and contact

The approved policy should state how material changes are communicated. Contact: [verified privacy/support route]. Do not publish until operator identity, actual recipients, retention, deletion and final SDK behavior are reconciled with the store forms.