Privacy Policy

1. End-to-End Encryption (Arc Protocol)

Arc is developing its target messaging security architecture with pinned libsignal primitives and independently versioned Arc protocols. The presence of a cryptographic dependency or partial implementation does not establish an end-to-end product guarantee. Until the authorization, durable lifecycle, migration, minimum-build, and physical-device gates pass, do not rely on Arc for information that requires verified end-to-end confidentiality.

• PQXDH and ML-KEM-1024: standardized post-quantum key establishment is a target design; its production writer is currently disabled.
• Double Ratchet: the durable atomic send, retry, and recovery lifecycle remains a release prerequisite rather than a current public guarantee.
• Sender Keys for group chats: the live normal-group writer is not connected to the target Sender Keys architecture and is not claimed as production E2EE.
• Cryptographic primitives: Arc does not treat an unverified or partially connected primitive as proof that the complete messaging path is secure.
• Sealed Sender: disabled while its sender-certificate authority, anonymous ingress, generic notification, and recovery boundaries are incomplete.

Arc uses platform security facilities for supported local secrets, but its complete identity, device migration, revocation, and key recovery lifecycle remains under verification.

2. Information We Collect

We collect the minimum information necessary to operate Arc:

• Account identifier: Your chosen Arc ID (e.g. arc_XXXX) and an opaque Firebase Authentication user ID. We do not require a phone number, real name, or government identifier.
• Security material: enabled builds may store public-key material, device and enrollment identifiers, capability versions, and prekey status needed for security development and migration.
• Push notification token: A platform-issued opaque device token (FCM / APNs) used to request notification delivery. Current push payloads are not end-to-end encrypted. Depending on the active path, Firebase and the platform push provider can receive notification title and body text plus routing metadata such as chat and sender identifiers. Encrypting message content does not make the provider-visible notification envelope E2EE.
• Routing metadata: recipient and conversation identifiers, sender authentication, network address, timestamps, payload size, delivery state, and push-provider observations may be processed where required by the active delivery path.
• Optional profile data: A display name, avatar and header image URLs, headline, biography, website URL, and language preferences can be stored in Firebase services so enabled clients can render them. These profile fields are not currently end-to-end encrypted. Do not place sensitive information in public or discoverable profile fields.
• Optional diagnostic data (opt-in): Remote diagnostics are off by default. You can enable or disable sharing in Settings → Privacy → Share Anonymous Diagnostics. When enabled, Arc can send crash reports, performance data, and aggregate usage metrics to Firebase. When disabled, provider collection is turned off and unsent crash reports are deleted. Arc does not attach an Arc account ID, peer or conversation identifier, message identifier, message plaintext, cryptographic secret, or access token to these reports. Firebase can still process pseudonymous installation and session identifiers, device and operating system characteristics, network information, timestamps, and technical stack traces when diagnostics are enabled.

3. Information We Do NOT Collect

Arc does not intentionally request the following categories for its ordinary account flow; platform permissions and enabled features can change what a device processes locally:

• Arc does not intentionally collect message plaintext for advertising, behavioral profiling, or optional diagnostics. Enabled delivery paths can still process the content and metadata described elsewhere in this policy, and not every current path has passed Arc's complete E2EE release gate.
• Your reactions, read receipts, typing indicators when E2EE is active — these travel as encrypted payloads.
• Your contact list — Arc does not request or upload your phone contacts.
• Your location — unless you explicitly enable the Mesh Network feature (see section 7).
• Your phone number — Arc does not use phone number authentication.
• Browsing history outside of Arc, advertising identifiers, or cross-device tracking signals.

4. Information We Will Never Share or Sell

Atlas Associates Inc. does not, and will not:

• Sell, rent, lease, or trade any user data to advertisers, data brokers, marketing networks, or analytics partners.
• Represent an unfinished security path as verified or silently enable it for a paid plan.
• Use your data to train AI models, recommend ads, or build behavioral profiles.
• Run advertising of any kind that targets you based on the content of your communications.

Third-party infrastructure providers, including Google Cloud and Firebase, process data needed to operate the enabled service paths. Their observable data depends on the active path and can include the metadata described in section 2.

5. Government and Law Enforcement Requests

We respond to lawful, properly-served legal process from competent authorities. However:

• We can only produce data that is actually held by us or our processors when a valid request is received. The scope depends on the live implementation and applicable retention state.
• The metadata categories in section 2 are not an exhaustive claim that no other operational metadata can ever be observed.
• We do not provide bulk data access, real-time message monitoring, or content surveillance to any government, intelligence agency, or law enforcement body. There is no back door. There will be no back door.
• We intend to publish transparency information when a verified, reviewable reporting process is in place.

6. Message Storage and Retention

Arc is implementing expiry-oriented storage through IGF (Intelligent Governance Framework). Each message carries a sender-configured expiry time. Where supported by an enabled client, the user interface can hide an expired device projection at its deadline. Server deletion is asynchronous. The following plan cadence is the target implementation, not a currently guaranteed deletion deadline, until the required Functions and indexes are deployed and their production read-back gate passes:

• Essential target: every 48 hours from 00:00 JST.
• Premium target: at 00:00 and 12:00 JST.
• Intelligence target: every five minutes via Cloud Tasks.

Until a deployed scheduled sweep completes, an expired document may remain on the server. Deployment gaps, service failures, retries, retention controls, or unresolved attachment references can extend the target cadence. Arc does not currently promise the target intervals as maximum physical-deletion times.

Delivery acknowledgment does not create a promise of immediate physical deletion from every cache, backup, queue, or provider.

Mutual Burn (Vanish-on-Read): In 1:1 chats, when both parties tap the mail icon to confirm read, a burn animation overlays the message and the plaintext is hidden from participating device views. Mutual Burn UI is available on all plans for 1:1 chats only; durable server-side retirement remains under verification. Group support is disabled.

Account deletion via Settings → Account → Delete Account initiates the supported deletion workflow. Completion can be delayed by retries, retention obligations, provider behavior, or failures.

7. Mesh Network and Location

Arc's signed direct Mesh, E2EE direct Mesh, group Mesh, and multi-hop relay paths remain disabled for public release until their transport, resource-bound, recovery, background, and physical-device gates pass. No current public guarantee of encrypted relay delivery is made.

8. Children

Arc is not directed to children under 13 (under 16 in the European Economic Area). We do not knowingly collect information from children below those ages. If you believe a child has provided us information, contact us and we will delete the account.

9. Your Choices and Rights

Depending on applicable law, you may have rights to access, correct, delete, or export your account data. You can exercise these rights directly within the app or by contacting us:

• Access / export: In-app Settings → Account → Export Data.
• Correct / update: Edit your profile directly in Settings.
• Delete your account: In-app Settings → Account → Delete Account starts an asynchronous deletion workflow. Access or session revocation can take effect before backend, storage, backup, queue, and provider deletion completes. Once accepted, the workflow can be irreversible from the user's perspective, but this is not a promise of immediate physical deletion.

For inquiries or to exercise rights that cannot be exercised in-app, email support@atlasassociates.io.

10. Service Providers

We rely on a small set of infrastructure providers, including Google Cloud, Firebase, FCM, and platform push services, for enabled service paths. Provider-visible data depends on the path and can include the notification and routing metadata described in section 2. The Phoenix and Cloud Run messaging candidate is staged with zero production traffic and is not represented as a production message authority until the P04 gate passes. BLE Mesh runs locally between participating devices and is not an external data processor. Historical processing for retired features remains subject to the provider terms that applied when it occurred. A current list of sub-processors is available upon request to support@atlasassociates.io.

11. International Transfers

Enabled Firebase, Google Cloud, and platform push services can process data across regions according to their configuration and routing. Some staged services are configured in Google Cloud europe-west1 (Belgium), but Phoenix is not currently represented as the production message authority. Active database and storage paths use Firebase services; FCM and APNs request notification delivery and do not serve as the message-routing authority. Where transfers are subject to applicable law, including the EU and UK GDPR, we rely on the applicable transfer mechanisms and provider terms. Historical processing for retired features remains subject to the terms that applied when it occurred.

12. Changes to This Policy

We may update this Privacy Policy from time to time. Material changes will be notified via the app and via this page. The Effective date at the top of this document indicates when the current version took effect. We do not delete prior versions — historical versions are available upon request.

13. Governing Language

The authoritative language of this Privacy Policy is English. Any translation is provided for convenience; in the event of conflict between the English version and a translation, the English text governs.

14. Contact

For questions or concerns regarding this Privacy Policy, contact support@atlasassociates.io.