Privacy

# X2 Social Privacy Policy

This Privacy Policy describes how X2 Social processes information when you use the X2 Social mobile application.

X2 Social is an anonymous video social application. Anonymous product architecture does not mean that operation of the service involves no data processing.

## 1. No customer account required

The current X2 Social product does not require a customer account, username, profile, password, social-provider identity, or durable creator identity for ordinary use of the anonymous product.

X2 does not create a persistent customer or device identity merely to remember launch consent, measure ordinary product use, preserve reported-Post suppression, or operate anonymous Posts.

The absence of a customer account does not prevent technical, content, safety, operational, or aggregate data from being processed where required to operate X2.

## 2. Information processed when you use X2

Depending on how you use the product, X2 may process information such as:

- video and caption content that you choose to submit; - Post and publication workflow identifiers and state; - public Post content and canonical content identifiers; - report records and report reasons; - provider and processing state required to operate video publication and playback; - aggregate product interaction information; - application, platform, request, and bounded technical metadata; - operational logs, error information, and service-health information; and - limited device-local state required for specific product functions.

X2 does not authorize this information to be combined into a hidden durable customer profile or persistent device-interest profile.

## 3. Submitted videos and Post content

When you choose to create a Post, X2 processes the content and information needed to receive, validate, process, review, publish, deliver, and operate that Post.

Selected or uploaded content is not necessarily public.

A video may be uploaded and processed before X2 determines that the Post is eligible for publication.

Published captions and videos are public Post content when the applicable X2 publication, safety, availability, and eligibility requirements have been satisfied.

Draft, failed, abandoned, unpublished, or safety-processing content is not made public merely because it was selected or uploaded.

## 4. Mux video processing

X2 uses Mux as its managed video provider.

After X2 authorizes an upload, video bytes may be sent directly from the application to Mux.

Mux may process video for ingestion, validation, transcoding, asset preparation, managed playback, delivery, and related provider operations.

X2 may process provider identifiers and provider lifecycle information needed to correlate uploads, video assets, playback resources, and verified provider events.

A Mux upload, asset, processing result, or playable resource does not by itself make a Post publicly available on X2.

Privileged Mux credentials are not customer data and must not be exposed through the X2 mobile application.

## 5. Video safety processing

X2 applies safety requirements before content may become publicly available.

X2 uses Sightengine as part of the current video-safety processing architecture.

Video or media information required for that safety evaluation may be made available to Sightengine so that X2 can receive trusted safety-processing evidence.

X2 may retain bounded safety evidence, provider status, correlation information, and operational information needed to enforce the X2 publication-safety rules.

Provider classifier scores, internal thresholds, provider configuration, enforcement logic, credentials, and other protected moderation internals are not ordinary customer-facing Post information.

Safety-provider processing does not create a customer moderation profile, account strike history, follower restriction, or durable creator identity.

## 6. Product Supabase processing

X2 uses its Product Supabase backend for server-authoritative application functions.

Product Supabase may process canonical Post state, publication workflow state, reporting records, aggregate product data, provider correlation information, and other server-side information required by the implemented X2 product.

X2 does not use Supabase customer authentication to create an account for ordinary anonymous product use.

Video bytes are not routed through Product Supabase merely to reach the managed video provider.

## 7. Reports and local Post suppression

If you report a Post, X2 may process the report reason and bounded information required to submit, validate, review, retry, and operate that report.

Submitting a report does not automatically remove a Post globally.

When a report is confirmed, the application may also store the reported Post identifier locally so that the Post remains suppressed on that installation.

This local suppression state is safety state, not an interest profile or customer identity.

Local reported-Post suppression may persist across ordinary app restarts.

Because X2 does not create a cloud customer identity merely to synchronize local suppression, reinstalling the application may clear that local suppression state.

Minimum retry information may also be retained where needed to complete a report submission after local suppression has already occurred.

## 8. Launch age confirmation and consent

Every new application launch begins with X2's Age & Consent page.

Age confirmation and launch consent are held for the current running application launch so that X2 can determine whether ordinary product entry is permitted.

X2 does not persist launch consent merely to skip the Age & Consent page on a later launch.

A later application launch requires fresh age confirmation and fresh launch consent.

Launch consent does not create a customer account, durable customer identity, verified civil identity, or verified-age record.

The age control is a self-attestation that the viewer is at least 18 years old.

## 9. X2-owned aggregate analytics

X2 uses X2-owned product analytics to operate and improve the product and to support approved aggregate product and ranking functions.

The analytics architecture is designed to be content-centric and aggregate-oriented rather than customer-centric.

The initial product does not authorize third-party behavioral analytics SDKs or customer-event platforms such as Firebase Analytics, Amplitude, Mixpanel, or equivalent behavioral customer-tracking systems.

X2 analytics do not require an account ID, profile ID, username, email address, phone number, Supabase Auth user ID, social-provider identity, or durable anonymous-user identifier.

X2 does not authorize long-lived analytics that create a persistent device category history, hashtag preference graph, Post preference history, interest vector, or equivalent behavioral profile.

Provider operational or playback information must not silently redefine X2's canonical product metrics.

## 10. Device, application, and network information

Technical device and application information may be processed where reasonably necessary for product operation, integrity, compatibility, security, or aggregate diagnostics.

This may include platform information, application version or build information, bounded technical request context, and related operational metadata.

Internet infrastructure necessarily receives transport information when the application communicates with X2 services. This may include information such as IP addresses and ordinary network request metadata.

Incidental network metadata is not automatically treated as behavioral analytics.

The current architecture does not authorize a general-purpose persistent advertising-style device identifier or durable installation identity.

## 11. Operational logs and diagnostics

X2 may process bounded operational information needed to diagnose service health, errors, latency, provider failures, server failures, security issues, and reliability problems.

Operational telemetry and product analytics have different purposes and must remain appropriately separated.

Logs should use bounded identifiers and sanitized context where practical.

X2 does not intend operational logs to become a substitute warehouse of unnecessary fine-grained customer behavior.

Provider credentials, database secrets, private keys, authentication tokens, and other privileged secrets must not be exposed as customer-facing data.

## 12. Public and non-public information

Published Post content and explicitly approved aggregate public metrics may be visible through X2's public product surfaces.

Internal impressions, partial-watch information, progress distributions, ranking values, safety evidence, report-review information, provider state, abuse diagnostics, operational logs, and private workflow information are not automatically public.

X2 controls public product availability independently from the technical existence of provider media.

## 13. Data minimization and retention

X2 aims to process and retain only information that is reasonably required for the applicable product, safety, legal, integrity, operational, or aggregate purpose.

Different categories of information may have different retention requirements.

Bounded retry, idempotency, and operational records should not become indefinite device-keyed behavioral histories.

Safety, reporting, provider, legal, and operational information may require purpose-specific retention that is separate from ordinary product analytics.

Where X2 no longer has a legitimate product, safety, legal, security, integrity, or operational need for information, later production retention procedures should remove or minimize it according to the applicable authority.

## 14. Advertising and cross-app tracking

The current X2 product does not establish advertising analytics, advertising identifiers, cross-app behavioral tracking, retargeting audiences, or data-broker enrichment.

A future advertising or cross-app tracking model would require separate explicit product, privacy, platform, and legal review.

## 15. Geography

The current X2 Social runtime does not use device location or the preserved Geography project to construct a customer analytics or ranking profile.

The current analytics architecture does not create a country, subdivision, city, or GPS-based viewer-interest profile.

## 16. Security and provider secrets

Privileged credentials used by X2, Product Supabase, Mux, Sightengine, or other protected server infrastructure are not customer data and must remain outside public application state.

X2 applies server-authoritative boundaries so that privileged provider operations do not depend on secrets embedded in the mobile application.

## 17. Changes to this Privacy Policy

X2 may update this Privacy Policy when the product, processing activities, providers, legal requirements, safety requirements, or operating arrangements change.

Because X2 requests fresh launch consent on every new application launch, a later launch provides another opportunity to present the then-current Privacy Policy.

Additional re-consent behavior for a material change during an already-running application process may be introduced if later legal or product policy requires it.

## 18. Legal review

This Privacy Policy describes the current X2 product architecture and processing model.

The production version remains subject to final legal review and approval before release, including jurisdiction-specific privacy requirements, retention language, data-rights procedures, provider disclosures, and store privacy declarations.