Privacy Policy

Review draft — not yet effective. Prepared 18 October 2026. Effective date: [EFFECTIVE DATE]. Controller/operator: [LEGAL NAME], [ADDRESS]. Privacy contact: [PRIVACY EMAIL / REQUEST CHANNEL]. These details must be completed before publication.

Scope and current product

This notice describes the current Codexgram development/beta application and its static information site, operated by [OPERATOR]. The app has live cloud profiles, photo posts, likes, comments, follows, search and feeds. Messaging, local reports and several privacy/safety controls remain prototypes. A screen's presence does not mean information entered there is delivered to another user or reviewed by a moderator.

This notice distinguishes our application behavior from our providers' independent practices. Actual production providers, deployment regions, retention and rights-handling arrangements must be confirmed before release.

Information processed

Account and sign-in information. When you register or sign in, the app sends your email/password or verification/reset inputs to Clerk, our authentication provider. If you choose Google or Apple sign-in, that provider and Clerk process the sign-in exchange and any account information made available through it. Available methods depend on configuration. The app uses Clerk identity/session information to recognize you and restore your session. Its Convex profile stores the token-derived identity reference, not an application password or email field.

Your profile. We store your username, display name, optional bio and an optional HTTPS profile-image reference, along with account status and social counts. A normalized name/username search field supports discovery. The app also keeps a local copy of profile fields. Existing HTTPS profile images can be retained; the live profile editor currently does not upload a new local avatar to Convex.

Photos and interactions. We process selected post photos, captions, authorship, creation times, comments, likes, follow connections, relationship counts, upload ownership records and retry identifiers. The uploader crops/re-encodes photos on your device before sending the resulting JPEG to Convex. Photo processing can involve local temporary files. Search queries are sent to Convex to retrieve results; the authored backend has no separate search-history table. That does not establish that provider diagnostic logs never contain request metadata.

Device-local prototype data and preferences. The app can store prototype text/photo conversations, read markers, report reasons and targets, blocked-account preferences, saves and other sample interactions, profile copies, theme and private-account preferences on the device. Prototype conversation entries are not sent to another person. Notes in the prototype messaging screen last only for the current screen session. Local photo attachments are copied into the app's document area.

Connection, support and diagnostic information. Clerk, Convex, image hosts and development delivery services receive network requests and associated metadata, such as the connecting IP address and protocol/client information. Their exact retained logs and retention are not established by the repository. If you contact [SUPPORT/PRIVACY CHANNEL], we will process what you send and information needed to handle the request [CONFIRM CHANNEL, ACCESS AND RETENTION BEFORE ACTIVATING IT].

The authored app does not request contacts, GPS location, advertising identifiers or camera/microphone capture, and has no payment collection or push-notification registration. A location string in a sample/prototype is not a GPS reading. We do not infer that uploaded photos contain no identifying or location information; do not include sensitive details you do not intend to disclose.

Why information is used

Information is used to authenticate accounts, create and display profiles, host/display chosen photos, provide search and feeds, manage likes/comments/follows, remember local preferences, validate uploads, prevent duplicate retry operations, apply implemented ownership/status/access rules and carry out available post/comment cleanup.

Operational information may also be needed to troubleshoot failures and respond to verified requests through the approved contact process. [CONFIRM THE ACTUAL OPERATIONAL/SECURITY LOGGING AND REQUEST PROCEDURE.]

Where a law requires a specific lawful basis, [INSERT PURPOSE-SPECIFIC BASES AFTER CONFIRMING APPLICABLE LAW: FOR EXAMPLE CONTRACT NECESSITY, DOCUMENTED LEGITIMATE INTERESTS, LEGAL OBLIGATIONS OR VALID CONSENT WHERE REQUIRED]. Using a feature or an OS picker is not described here as blanket privacy consent or an implemented consent-management system.

Who can see community information

Eligible signed-in users can see profiles, posts, comments, counts and connection lists through the app. Your posts are not limited to followers: Explore, profiles and post-detail access can expose them to other eligible signed-in people. Likes are shown as counts and your own like state; a public list of everyone who liked a post is not currently provided.

The backend excludes suspended profiles and checks existing bidirectional block records. However, current device-local block/private/report controls are not connected to those backend records. Turning on the current Private Account preference does not restrict cloud visibility. A saved local report has not been sent to a moderation team. Do not rely on prototype read receipts, online indicators, message delivery or safety controls as real assurances.

Anyone who can see information can potentially capture it outside the app. Removing content or access cannot recall independent copies or screenshots.

Providers and other recipients

• Clerk: account authentication, verification, identity-provider integration and sessions. Clerk privacy information. Its public policy distinguishes its own customer information from customer-app end-user data; our provider contracts and this app notice govern the latter relationship as applicable.
• Convex: social records, reactive queries, uploaded photo storage and scheduled cleanup. Convex privacy information.
• Google or Apple, if you choose that sign-in method: authentication through that provider under its applicable settings and notices. Google privacy, Apple privacy.
• Expo/EAS and development tunnel services: building/distributing the application and connecting development versions to Metro. A tunnel relays development traffic; this is not an app advertising partner. Expo privacy, ngrok privacy.
• Profile-image hosts: when an HTTPS avatar is displayed, your device requests it from its host, which may receive request metadata. [CONFIRM ALLOWED HOSTS AND THEIR POLICIES.]
• Information-site hosting: [HOSTING PROVIDER AND RELEVANT NOTICE]. The supplied static site has no forms, third-party scripts or external font requests, but the eventual host may process connection logs.

[CONFIRM ANY ADDITIONAL SUPPORT, SECURITY, PROFESSIONAL-ADVISER, LAWFUL-DISCLOSURE OR BUSINESS-TRANSFER RECIPIENTS AND APPLICABLE CONDITIONS. NO UNDISCLOSED ACTUAL RECIPIENT IS AUTHORIZED MERELY BY THIS PLACEHOLDER.]

Telemetry, advertising and local storage

No app-owned advertising, cross-app tracking, analytics or session-replay pipeline was found in the authored runtime. This is not a claim that no provider receives technical data. The installed Clerk SDK includes optional development-instance SDK telemetry. Its collector can send SDK/framework/event metadata and an instance identifier, and the app does not explicitly disable it. No runtime traffic capture was performed. See Clerk's telemetry description. [CONFIRM THE PRODUCTION/DEVELOPMENT TELEMETRY DECISION AND VERIFY ACTUAL TRAFFIC.]

The app uses local storage for sessions and preferences as described below. There is no in-app advertising-consent preference or general telemetry opt-out. The supplied static landing site itself sets no cookies and uses no browser local storage, tracking pixels or analytics scripts. This does not describe cookies or logging on separately opened identity-provider, Expo installation or future hosting pages.

The current product plan is free and ad-free, and no application data-sale or targeted-advertising mechanism was found. [OPERATOR MUST CONFIRM ANY BROADER SALE/SHARING PRACTICES AND LEGALLY REQUIRED SIGNAL HANDLING BEFORE MAKING AN UNQUALIFIED STATUTORY “NO SALE/SHARING” CLAIM.]

Storage and security

Cloud social records/photos are stored with Convex; account/session services are provided by Clerk. HTTPS endpoints and authenticated requests are configured. Backend functions derive identity from verified tokens and check implemented ownership, suspension and access restrictions.

Native session tokens use Clerk's configured Expo SecureStore cache. Profile copies and prototype/preferences are stored separately as JSON in AsyncStorage; prototype media is stored in app documents. The app does not add encryption to those social JSON/media files. Device and OS security are therefore relevant; token protection does not imply all local data is equivalently protected.

Post photos are returned through authenticated HTTP actions rather than exposing permanent direct-storage URLs. Responses request private/no-store handling, and the current photo component disables its own disk cache. These safeguards do not provide end-to-end encryption, prevent screenshots, revoke independently saved copies or guarantee that no transient/device/provider copy exists. No system can be guaranteed completely secure.

Retention and deletion

There is no automatic expiry period in the authored backend for profiles, published posts, comments, likes, follows or account status. These records remain unless removed through implemented functions or an operator procedure. [CONFIRM THE OPERATOR'S CATEGORY-SPECIFIC RETENTION SCHEDULE, LEGAL EXCEPTIONS AND ACTUAL DELETION PROCEDURE.]

You can delete your own comments and posts. Post deletion hides the post from normal reads and schedules batched deletion of its comments, likes, uploaded photo and related upload record. Completion depends on scheduled cleanup succeeding; no fixed completion deadline or backup-erasure guarantee is implemented. Registered uploads not used for a post are scheduled for cleanup after about one hour. Retried/interrupted work, provider backups and logs have separate operational limits that need confirmation.

Local social data is not automatically purged on sign-out, and copied prototype images have no application cleanup schedule. Device storage removal may remove these local copies, subject to OS backup/restore behavior, but it does not erase cloud data or your original library photos. Exact device backup settings and restoration behavior were not audited.

The actual Settings route currently disables coordinated account deletion. No self-service cloud export or full Clerk/Convex account-erasure workflow is implemented. Contact [VERIFIED PRIVACY REQUEST CHANNEL] for a request [CONFIRM A WORKING PROCEDURE AND RESPONSE/DELETION TARGETS]. Do not treat signing out, uninstalling or a disabled delete control as deletion of your account.

Provider-side logs, backups, recovery copies and authentication records: [CONFIRM RETENTION, DELETION/ANONYMIZATION SCHEDULES, LEGAL HOLDS AND PROVIDER CONTRACTUAL LIMITS]. The app's post cleanup alone does not establish their removal.

Your choices and applicable rights

You can edit your profile text, choose whether to post a photo or comment, unlike a post, unfollow an account, remove your own posts/comments, sign out, change the local theme and manage device photo access through OS controls. Denying or canceling photo selection can prevent uploading that photo; it does not require providing the rest of your library.

Depending on applicable law, you may have rights relating to access, correction, erasure, restriction, objection, portability, consent withdrawal or complaints to a competent authority. These are conditional legal rights, not a claim that every jurisdiction or every right applies to every user. The app currently has no automated export, general consent dashboard or complete account-erasure workflow. Use [REQUEST CONTACT]; [CONFIRM VERIFICATION, RESPONSE TARGETS, AUTHORIZED-AGENT PROCEDURE AND APPEAL/COMPLAINT CONTACTS IF REQUIRED]. Requests remain subject to applicable law and legitimate verification/retention requirements.

Audience and international processing

[PROPOSED AUDIENCE — CONFIRM: Codexgram is intended for people aged 18 and over.] The app does not collect a date of birth or verify age. If you believe a child has provided personal information, contact [PRIVACY/CHILD-SAFETY CONTACT] so the operator can assess the request under an approved process. Do not imply an implemented automated child-detection/deletion system.

Providers may process information in countries different from yours. Actual deployment/storage locations and contractual transfer arrangements are [CONFIRM COUNTRIES, PROVIDER REGIONS AND APPLICABLE TRANSFER SAFEGUARDS]. This draft does not certify GDPR, Indian DPDP, California or other legal compliance, or claim a particular data-residency guarantee.

Changes and contact

Policy updates will be identified by an effective date. [CONFIRM HOW MATERIAL CHANGES WILL BE NOTIFIED AND WHEN THEY TAKE EFFECT; NO PUSH/EMAIL LEGAL-NOTICE SYSTEM IS CURRENTLY AUTHORED.]

Controller/operator: [LEGAL NAME]. Postal address: [ADDRESS]. Privacy requests: [EMAIL / WORKING REQUEST CHANNEL]. [INSERT REQUIRED REPRESENTATIVE, DPO OR GRIEVANCE OFFICER DETAILS ONLY IF APPLICABLE AND APPOINTED.]