Privacy Policy

Totem Privacy Policy

Draft — not yet effective. Last updated August 19, 2026. This draft describes the service as it works today. It requires review by Victor and a lawyer before publication.

This policy explains what Totem, operated as Totem Labs Forge ("Totem," "we," or "us"), collects and does with data from creators and players.

Totem does not sell personal data, run ads, or process payments.

1. Data Totem stores

Creator identity and account data

Creators sign in through GitHub OAuth. Totem receives and stores the identity data used by that sign-in, including:

• a GitHub provider account identifier;
• name, email address, whether the email is verified, and profile image when

GitHub supplies them;

• the OAuth account record and tokens returned through the sign-in flow;
• Totem's internal user and owner IDs;
• the creator's public Totem handle, handle history, account creation dates,

and owner membership; and

• authentication sessions, including an opaque session token, expiry time, IP

address, and user-agent value recorded by the authentication library.

Totem uses the verified GitHub email to identify the creator and, where applicable, connect a migrated creator record to the correct GitHub account. Totem does not offer password sign-in and does not store a Totem password for GitHub creators.

For MCP access, Totem stores each API key's hash, short display prefix, name, creation time, last-use time, and revocation time. The complete API key is shown only when it is created and is not stored in plaintext by Totem.

Game and publishing data

For each game and build, Totem stores data including:

• creator owner ID and handle;
• game name, description, slug, orientation, status, listing choice, and score

limit;

• build and lane identifiers, sequence, status, timestamps, file count, byte

size, hash, and validation errors;

• the uploaded build archive in private staging storage; and
• extracted game files and a build manifest in public object storage.

Totem adds its SDK script tag to the published index.html. It also uses game name, description, creator handle, and icon when available to render the play page, install metadata, and social preview.

Anonymous player identity

When someone opens a live game, Totem reads its own session cookie. If there is no valid session, Totem creates an anonymous authentication user, an opaque player ID, an authentication session, and a matching player row. A player may later choose a public player tag. Player tags use a separate namespace from creator handles.

Totem uses the same authentication system for anonymous players and GitHub creators. An anonymous player session does not by itself grant access to the creator Studio.

Play sessions, events, and scores

Totem creates a play-session record containing the player ID, game ID, lane, start and end times when available, calculated duration, referring domain, device class, and whether this was the player's first Totem session.

The SDK automatically sends these analytics events:

• session_start, including device class, viewport information, and referring

domain supplied through the play page;

• heartbeat while the game is visible;
• visibility_change; and
• session_end when the page closes or navigates away, when the browser allows

it.

Totem stores the event type, server timestamp, session ID, game ID, and a small JSON payload. The SDK also sends a limited number of error events when it observes a browser JavaScript error or unhandled rejection. Those events can include a shortened error message, source filename, line number, and first line of a stack trace. A game can explicitly send game_over and custom events through the SDK. Creators should not put passwords, API keys, email addresses, or other free-form personal data in event payloads.

When a main-lane game submits a score, Totem stores the player's best score, the time achieved, and a submission count. Totem produces daily game and platform aggregates such as plays, unique players, median session duration, returns, score submissions, and second-game rate.

Security and operator records

For HTTP responses with security-relevant status codes, the application emits a structured log containing only method, path, and status. It is designed not to include query strings, request bodies, cookies, authorization headers, tokens, or stack traces. Central log retention and alerts are not defined by the application today.

A manual operator suspension creates an append-only record containing the operator identity, time, reason, creator owner ID and handle, game ID and slug, and previous and new status.

2. How Totem uses data

Totem uses the data above to:

• authenticate creators and players;
• let creators claim and maintain a public handle;
• issue and verify MCP API keys;
• validate, publish, serve, and update browser games and lanes;
• create shareable game links, install metadata, and social previews;
• keep one player identity across Totem games;
• calculate creator analytics and platform-level product metrics;
• operate public player tags, scores, and leaderboards;
• apply rate limits and protect the service; and
• investigate, record, and reverse manual game suspensions.

Totem's server does not run an AI model or use creator prose to decide which tools or permissions to grant. A creator's own AI tool is separate from Totem and is governed by that tool's provider.

3. What is public

Published game bytes are public. They are served from a separate per-game origin and can be downloaded by anyone who knows or discovers the URL. Build files are stored at versioned object paths and are sent with long-lived cache headers.

An unlisted game or lane is omitted from public discovery, but it is not password-protected or private. Anyone with the link can play it. Creators must not publish secrets, private source files, personal data, or assets they do not have the right to distribute.

The following can also be public:

• creator handle, game name, description, orientation, icon, and play link;
• listed games in Totem's public game index;
• player tag, player ID, score, rank, and score time in public leaderboard

responses; and

• game metadata used in install files and social previews.

Creator email, OAuth tokens, authentication cookies, API keys, raw play-event rows, and creator-only analytics are not intentionally made public by Totem.

4. Service providers and disclosure

Totem uses GitHub for creator sign-in and Cloudflare services to host frontend pages, store game files, cache content, and deliver public game bytes. Those providers process the data needed to provide their part of the service under their own terms.

Totem may disclose data when necessary to operate the service, respond to a security incident or valid legal demand, protect users or the service, or carry out a creator's verified deletion request. Totem does not sell data to data brokers or advertisers.

A creator's game is creator-supplied code. It may connect to services chosen by that creator. Those connections and any separate collection by the game are the creator's responsibility, not a collection by Totem covered by this policy.

5. Current retention

Totem has no general automatic expiry job for account, game, player, analytics, or score records. The current retention behavior is:

Data	Current retention
Creator account, GitHub account link, OAuth records, owner membership, and API-key metadata	Kept while the creator account remains active, unless manually deleted. Revoked key records retain their prefix and revocation metadata.
Authentication session	The current authentication configuration gives sessions and their cookie a seven-day expiry. Signing out deletes the current server session. The underlying creator or anonymous user record does not expire with the session.
Creator handles and handle history	Kept while the creator account exists. Retired handles remain reserved and are not automatically released.
Game metadata, build rows, lane rows, private staging archives, and deployed public files	No automatic expiry. Kept until Totem completes a verified manual deletion request or removes them for service or legal reasons.
Player rows, player tags, play sessions, raw events, scores, and daily aggregates	No automatic expiry. Kept until related data is manually deleted.
Operator suspension records	Append-only, with no automatic expiry. These records are deliberately independent of the game row so the takedown history can remain after a game changes or is deleted.
Security logs	The application emits the limited records described above, but the current repository does not define a central retention period.

Deployed files use a one-year immutable browser/CDN cache instruction. After a game is deleted from Totem's storage, a copy already held by a browser or cache may remain until it expires or is purged.

6. Cookies

Totem uses a session cookie for both anonymous player identity and GitHub-signed in creators. The cookie is HttpOnly and SameSite=Lax, and is marked Secure on the production HTTPS service. It is scoped across Totem's platform subdomains so the play page, API, and Studio can recognize the same Totem session.

Totem does not use an advertising cookie or a third-party advertising tracker. A creator's game may run its own code; see section 4.

7. Security

Totem separates creator game content from the platform origin, serves games in a sandboxed iframe, validates uploaded archives, hashes MCP API keys, applies request and upload limits, restricts credentialed browser origins, and avoids putting secrets in its structured security logs.

These are specific engineering measures, not a certification or a promise that the service is risk-free. Totem does not claim compliance with a named privacy or security certification in this policy.

8. Access, correction, and deletion

Totem's creator API supports changing a public handle, revoking API keys, changing a game's listing choice, and suspending or restoring an owned live game. Players can view their opaque player ID and claim or change a player tag through Totem's player API.

Totem does not yet provide a self-service account-delete or game-delete control. To request a copy, correction, or deletion of account or game data, contact Totem through https://x.com/vikgmdev. Identify the GitHub account, creator handle, or player record involved, but do not send an API key, password, OAuth token, or private game file. Totem will verify control before acting on creator data.

Manual deletion may require removing related games, builds, sessions, events, scores, account links, and storage objects in dependency order. Public cache copies can persist as described in section 5. Operator suspension records may be retained as an append-only history.

9. Changes to this policy

Totem will update the date at the top when this policy changes. A material new collection or use—such as payments or advertising—must be described before it begins.

10. Contact

The current public contact for Totem Labs Forge is https://x.com/vikgmdev. Do not send passwords, API keys, OAuth tokens, or private game files through X.