Pixel Port privacy notice

Pixel Port works with analytics turned off. Refusing optional purposes does not remove core catalogue, install, or play functionality. Data needed to complete an action you request—such as signing in, fetching the catalogue, requesting a game, contacting support, or starting a privacy job—is service data and is not reused as analytics.

Starting positions

Two rules apply, and the difference matters.

Analytics are consent-first. Compatibility telemetry, rich diagnostics, experience analytics, and commercial research all start off in every version of Pixel Port. Nothing about how you play is collected for a purpose until you turn that purpose on and the server acknowledges that exact choice.

Account personalization is opt-out from Pixel Port 0.4.5. It starts on, and you turn it off on the first-run screen or in Settings. In Pixel Port 0.4.4 and earlier every purpose started off, account personalization included.

Account personalization connects activity you separately allowed to your signed-in account, so while every analytics purpose is off it has nothing to connect. Updating Pixel Port does not change a decision you already made: a choice recorded on an earlier version is kept as it was recorded.

The first-run screen offers "Continue with minimal data", which turns every purpose off, account personalization with them. The other path shows each switch at its shipped position before anything is recorded, so a default-on purpose is seen rather than assumed.

Compatibility telemetry is not mandatory for any tier of Pixel Port. It stays a consent-first purpose, not a condition of use.

Optional purposes

You can grant or withdraw each purpose independently:

• Compatibility telemetry: coarse install, launch, render, outcome, duration, app ID, chip family, macOS major version, runtime major version, and recipe hash.
• Rich diagnostics: structured failure facts. A panic excerpt, full log, filenames, or support attachment always has a preview and separate confirmation for that upload.
• Experience analytics: app opens, browse transitions, game views, and install-funnel events. Pixel Port does not collect session replay, keystrokes, or viewed content.
• Account personalization: connects activity already permitted under another purpose to your signed in account. Signing in does not change this purpose's setting either way. From Pixel Port 0.4.5 it starts on; turning it off stops the linking at once and starts the unlink, and the purposes you left on continue unlinked.
• Commercial research: lets eligible opted-in contributions be used in reviewed, thresholded aggregates. It adds no collection fields and does not permit raw or pseudonymous records to leave Pixel Port. The production feature is disabled pending a separate legal and release review.

Optional telemetry is pseudonymous, not anonymous. Pixel Port uses separate random subjects for each primary purpose. Subjects expire after 30 days and rotate after consent-scope changes, linking, unlinking, account changes, sign-out, reset, or deletion. Installation security credentials and account-device identifiers are independently generated and are not analytics identifiers.

Recipients and processing

Cloudflare provides the Worker, D1, KV, R2, Access, rate-limiting, and delivery infrastructure. Apple, Google, and Valve/Steam process data when you choose their sign-in, distribution, or game services. GitHub distributes releases. Other processors are not enabled unless the processor inventory, contract, deletion path, retention, manifest, and notice impact are approved first.

Operational logs contain route templates, status/reason codes, latency buckets, policy/schema versions, and aggregate job health. They must not contain bodies, query strings, raw IP addresses, subjects, account/provider/device identifiers, contact text, filenames, crash excerpts, credentials, cookies, authorization headers, or exact external URLs. Worker/application error logs expire after 7 days. Short-lived rate-limit material is a keyed digest, not raw IP, and expires after 2 minutes.

Retention

Navigation events expire after 30 days; compatibility outcomes and feedback after 90 days; rich diagnostics after 30 days; unfulfilled requests after 180 days; fulfilled requests and personal notices 90 days after fulfillment/dismissal; generated export archives after 24 hours; account and device records on account closure; and consent evidence 730 days after withdrawal or closure by default. The complete engineering schedule is in RETENTION.md. Retention can be shortened by an approved change. A legal hold must be named, time-limited, scoped, owned, and reviewed.

Eligible raw rows may be rolled into privacy-reviewed daily aggregates before deletion. External cells require at least 100 distinct opted-in contributors, contribution bounding, sparse-cell suppression, no stable contributor key, and a release review. Previously delivered de-identified aggregate releases generally cannot be adjusted per person; raw or pseudonymous downstream copies are prohibited.

Choices and rights

Withdrawal is effective locally as soon as your choice is saved. Pixel Port then cancels queued work, rotates/deletes the affected local subject, and reconciles with the server. If offline, the UI shows cleanup as pending and does not claim the remote link or data was removed.

Every recorded choice carries its origin. A value you set yourself is recorded as "your choice"; a shipped starting position you left alone is recorded as a "Pixel Port default". Settings shows the origin beside each purpose, and your privacy export includes it. A default is therefore never presented to you—or counted by Pixel Port—as something you asked for.

The Privacy Center provides local inspection, export, telemetry deletion, account closure, link status, and privacy-job status. Server exports and deletions are authenticated, idempotent jobs that cover current and historical subjects, requests/notices, diagnostics, support, account devices, provider identities, links, object storage, and affected unreleased aggregates. A deletion tombstone is installed before the job is acknowledged so retries cannot resurrect deleted data.

Unlinking and deletion are different. Unlink removes the active account bridge and identified derivatives; deletion erases the selected historical data. Sign-out alone does not imply deletion and does not silently disconnect the separately disclosed Steam connector.

Email and marketing

Pixel Port runs no mailing list and sends no marketing email. There is no email-sending system at all. Signing in with Apple or Google may pass Pixel Port an email address, often a private relay address; it is stored only to identify your account and is not marketing data. If marketing contact is ever added, this notice is revised and re-approved before that ships.

Tracking and external sale

Pixel Port does not track people across other companies' apps or websites, declares no tracking domains, and sets NSPrivacyTracking to false. It does not sell or license raw, row-level, pseudonymous, linked-account, diagnostic, contact, request, or security-credential data.

Changes

A material change to fields, purpose, linkage, recipients, or retention advances the policy major version and returns affected choices to unknown/off. Copy-only clarification may update the notice version without changing a grant. Change history:

• privacy-2026-08: states the starting position of each purpose, including account personalization starting on from Pixel Port 0.4.5; adds the origin ("your choice" or "Pixel Port default") recorded with every decision; states that no email or marketing system exists.
• privacy-2026-07: v2 purpose choices, rotating purpose subjects, signed ingestion, data-rights jobs, retention, admin controls, processor inventory, and macOS privacy manifest.

The privacy-2026-08 revision keeps the policy version at privacy-policy-2.0. It changes no field, purpose, linkage, recipient, or retention period; it describes a shipped starting position and adds two disclosures. Advancing the policy major version would return every choice to unknown and re-ask everyone, and re-asking is how a recorded refusal turns into a fresh grant. A decision you have already made survives this revision unchanged.