A small site.
A small data footprint.

Optional beta updates

When you sign up, we store your email, the update permissions you selected, and when you signed up. We use this to manage beta updates and send only the updates you choose. An optional article subscription is separate from beta updates. We do not sell this list.

Signup requests are deduplicated. Email confirmation and delivery are not active in this local release; accepted requests are retained for that workflow. No marketing campaigns are being sent.

Practice accounts and drafts

When account sign-in is enabled, GitHub or Google supplies your account identity, name, email, verification status and optional profile image. We use secure session cookies to keep you signed in. Authentication records and session metadata are stored separately from your practice account. Signing in grants no staff permissions.

Browser-only drafts stay on your device. After verified sign-in, account drafts autosave after you edit. They include your source, problem, language and revision. Recovery copies for signed-in practice stay in this tab until it closes; browser-only copies persist separately. Importing a browser draft requires an action. Signing out hides account drafts but does not erase tab recovery.

Optional private development execution sends your saved source to a disposable runner and saves its result. OAuth credentials, sessions and saved drafts are not sent to analytics. Public launch still requires verified provider setup, access controls and a working account-data deletion/retention process.

Devices and account access

Settings lists your active sign-in sessions using coarse browser and operating-system hints, the recorded trusted sign-in IP, and recent session activity. These describe browser sessions, not a fingerprint of a physical device. You can revoke one session or sign out everywhere. Revocation blocks future authenticated requests; it does not sign you out of Google or GitHub.

Administrators can search account records and review session IPs and activity for support and abuse prevention. Account and exact-IP restrictions are reversible and record an administrator, reason and time. These audit records are private; their final retention and account-erasure policy remain part of the public-launch work.

Community contributions

Publishing an approach, discussion or reply makes its text, optional code and chosen public handle visible to other visitors. Your private editor draft is never published automatically. Votes are associated with your account; public pages show totals. Reports and moderation records are restricted to administrators. Your OAuth email is not used as your public handle. You can change your public username in Settings or choose Anonymous for an individual post or reply. Anonymous hides your username from visitors; your account remains linked internally for moderation. Renaming a username does not reveal it on posts published as Anonymous.

Deleting your contribution removes its text and code from the active community record. Structural references, votes, reports, moderation history and retry records may remain; backups are separate. This tab keeps retry identifiers and intent hashes for up to a day without storing contribution text or code. Account-wide deletion and the final retention schedule are not available yet.

Practice feedback

When you send feedback on a completed run, we store your chosen response, optional note, run reference and account actor. Code and diagnostics are not attached automatically. Feedback is not public; please leave secrets out of notes.

Account security

Signed-in accounts have a stable internal actor ID for attribution. We record the first observation of each verified session, including that actor ID, the time and the connection IP supplied by our trusted ingress. These security records follow a seven-day retention policy with hourly cleanup. For costly requests, short-lived counters use a keyed hash of the trusted connection IP rather than a raw address. They do not contain your code, OAuth tokens or request bodies, and are not sent to analytics.

Optional analytics

Analytics are off until you allow them using the control in the footer. When configured, PostHog receives explicit page and sample and practice-interaction events with public route names, language, problem identifier and result category. A random browser identifier is stored locally after you opt in, so returning browsers can be counted. Events are tagged with this app and its development environment. We do not send email addresses, form values, code, problem inputs, execution outputs, query strings, or full referrers. Session replay and automatic click capture are disabled. The analytics service can receive network information such as your IP address when you connect.

Your analytics preference is stored on this device. You can turn collection off in the footer; using the site and requesting beta updates do not require it.

Retention and access

Access to signup records is restricted to the site operator. Local synthetic test records are removed by their tests. Before public launch, the operator must publish a working contact address, finalize the retention schedule, and enable confirmation, unsubscribe, deletion, and suppression handling. The optional updates form stores interest only; confirmation and delivery remain inactive.

Practice materials

The guided example is simulated. Private development exercises can execute source only when explicitly requested; analytics do not record code or keystrokes. The practice pilot has a separate consent and data-handling process.