Stack Front

Privacy Policy

Effective date: 19 October 2026

Offline play

Offline modes keep the match and replay in the temporary runtime on your device and do not require an account. Saved map names and layouts remain in local browser or app storage between sessions. When you upload or revise a private catalogue map, Stack Front stores its name, layout, revision, and related catalogue metadata on the service; those entries remain private until you propose them or they are promoted to the official pool. Choosing a map for an online invitation also sends the selected map name and layout to Stack Front for that invitation. Offline gameplay is not sent to the Stack Front server. The app does not use advertising, analytics, or tracking.

Online beta builds use the data described below and the corresponding store disclosures. App stores and operating systems are separate services with their own privacy policies.

The game and these public pages may store your selected language as stackfront.language.v1 in local browser or app storage. It contains only en, es, or ca, stays in the current browser profile or application origin, and is not synced to an account. When registration or password-reset requests include this selected language, it is used only to localize the transactional email and is not persisted as an account locale. An authenticated native device registration separately stores the selected language for that device so push alerts can be localized; this per-device value is not an account locale.

Online beta data

When you register or use online play, the service uses the following information. Offline modes do not send their gameplay to this service.

• Account email data: the service stores a verified email address and an internal account ID. For email-and-password accounts, the email is the sign-in identifier; Google and Apple accounts are identified by the provider’s stable account ID. A new online account requires a verified email, but an already linked Google or Apple identity can sign in without the provider sending that email again. If a later sign-in omits email, the stored contact address remains unchanged. Email is not public or searchable through player HTTP endpoints. It is used for account contact, verification/password messages and necessary service communication, not marketing or contact matching.
• Password credential: for email-and-password accounts, during registration verification and later login or reset, the player enters a password that the client sends over HTTPS for the service to verify. The service stores only a salted Argon2id password hash and never stores or logs the plain password. A separate six-digit reset code can replace the credential and revokes existing sessions after a successful reset.
• Registration, provider-email verification and password setup/reset: six-digit one-time codes are valid for up to 10 minutes, with resend and attempt limits. Raw codes are never stored or logged. Short-lived verification material is cleared after use, expiry, delivery failure or account deletion. Google/Apple accounts can configure a password through the verified email-code flow; a successful setup/reset revokes existing sessions.
• Google and Apple sign-in are available: the service verifies each provider response and stores its stable account identifier and verified email when creating a new account. A new provider account requires a verified email; later sign-ins use the linked stable identity even if the provider does not send email again, and the stored contact address remains unchanged. You may choose an Apple private relay address. The service does not request or store your real name, photo or contacts. A verified matching email can use the same Stack Front account; some external Google email addresses require a code to prove current mailbox access. Apple authorization credentials are encrypted on the server only to manage the authorization and revoke it when the account is deleted. If Apple is temporarily unavailable, minimal encrypted revocation work remains until it can be completed. Google provider tokens are not retained. Firebase Authentication and Steam sign-in are not enabled.
• Profile and social graph: an immutable, public, unique nickname; accepted friendships; pending, accepted, rejected, or cancelled friend requests; and invitations between friends. Nicknames can be searched by prefix so that a player can find a friend. The ranked beta additionally stores persistent matchmaking search slots, competitive challenges and Elo rating changes. Other signed-in players can see the nickname, rating and number of search slots in the matchmaking queue; the ranking shows nicknames, Elo and competitive game counts. Search slots continue while the app is closed until cancelled or matched. Competitive challenges remain until accepted, rejected or cancelled, independently of queue membership.
• Community maps and moderation: private catalogue uploads and revisions are stored on the service with their map names, layouts, and related catalogue metadata while they remain private. Maps you publish or propose also have public names, public map IDs, your public nickname as creator, cycle votes, proposal and official-pool status, and authenticated reports or blocks relating to community content. Private catalogue entries remain private until you propose them or they are promoted to the official pool. Email addresses are not shown as map authors.
• Online matches and events: the two player account IDs, match snapshots, validated command events and responses, rules version, engine release tag, source commit and fingerprint, immutable initial state and digest, turn deadlines, sequence, and outcome. This is the server-authoritative record needed to resume a match and resolve a timeout. It is separate from an offline replay. The server also keeps private canonical turn checkpoints, undo events, durable batch receipts, and stable command identities needed to reconcile the same gameplay. These records do not expose hidden game state to the client and are irreversibly redacted on account deletion.
• Durable local online-turn queue and undo journal: while an online turn is synchronizing, the worker/client may keep a record in local browser or app storage containing the account UUID, match UUID, turn and engine-base identifiers, exact commands, server-proposed paths, and stable request/batch IDs. It contains no hidden game state, password, access token, provider credential, or secret. Pending entries are retained until the server acknowledges them; the worker/client clears the local records on logout or confirmed account deletion. This device-local app-functionality record is not a separate server collection and does not add a tracker or provider.
• Native push device registration: an authenticated account may register one or more devices. For each device the service stores the provider token supplied by Apple Push Notification service (APNs) on iOS or Firebase Cloud Messaging (FCM) on Android, the platform, the APNs environment (sandbox or production) or the Android production environment, and the selected language for that device. The token is used only to address Stack Front transactional alerts and is not used for advertising, analytics, tracking, or contact matching.
• Android Firebase service metadata: the Android push dependency includes Firebase Cloud Messaging and its transitive Firebase Installations SDK. When that SDK initializes, FCM automatically collects the app version and Firebase user agent, and Firebase Installations automatically collects a Firebase Installation ID (FID). The user agent can include the OS version, name, model, brand, form factor, installer, and Firebase SDK versions. Firebase describes the FID as a per-installation identifier that does not uniquely identify a user or physical device. This provider-side metadata is sent to Google/Firebase for FCM service operation; Stack Front does not send the FID to its AWS backend or link it to the Stack Front account. The Android app does not include Firebase Analytics or export FCM delivery metrics to BigQuery. These metadata flows are not used by Stack Front for advertising or cross-service tracking.
• Transactional notification outbox: for invitation, game-started, your-turn, and game-finished events, the service stores a minimal structured event payload, the recipient account, a deduplication key, and a delivery lifecycle such as pending, processing, retry, sent, or dead, with attempt and delivery timestamps/error code. It is used only to deliver gameplay alerts and does not send marketing messages.
• Technical operations data: the service may keep a minimal security and availability log containing an IP address and request time, plus aggregate email-delivery counters. Security logs and aggregate delivery counters are retired by soft-delete after seven days. Notification delivery outcomes remain in the transactional outbox lifecycle described above. These operational records are not player profiles. Logs do not contain device tokens, provider secrets, email, OTP codes, passwords, notification payloads, or request bodies.
• Lifecycle audit metadata: every server-owned row has a lifecycle state and creation, update, and deletion dates, plus actor UUIDs where available. A deleted row remains as a hidden tombstone for audit and integrity work. This limited metadata is pseudonymous but can still be linkable to account history; it is not presented as anonymous data.

The service does not request a full name, contact list, personal identity document, or payment information for the online beta. The first online rollout does not use a Firebase database or Firestore, advertising identifiers, an ad SDK, an analytics SDK, or cross-service tracking. Offline practice replays stay in the local runtime.

We do not use this information for advertising, cross-service tracking, marketing, or selling or sharing contact data. The online service does not include an ad SDK or analytics SDK. The Android app does not enable Firebase Analytics or FCM delivery-metrics export to BigQuery.

Use and hosting

A one-time code verifies email ownership for email-and-password registration. Email-and-password sign-in requires the verified email and password; the client sends the password over HTTPS for the service to check against the salted hash without storing the plain password. With Google or Apple sign-in, the service verifies the provider response and uses the linked stable identity. A new online account requires a verified email from the provider, but an already linked account can sign in without the provider sending that email again. Reset codes recover an email-and-password credential and invalidate existing sessions. Email is not displayed or returned by player search.

All Stack Front game-backend components are hosted in AWS in Europe (Ireland), eu-west-1. The online beta uses a fixed AWS Lightsail host with PostgreSQL on the same machine. PostgreSQL is private. A cron job creates a logical pg_dump, uploads it over TLS to encrypted S3 storage, and removes its temporary local file; the encrypted copy is kept for seven days. Amazon SES sends transactional email. Apple Push Notification service (APNs) handles iOS delivery and Firebase Cloud Messaging (FCM) handles Android delivery. APNs and FCM are delivery providers, not Stack Front authentication or database services, and Stack Front does not enable advertising, analytics, or tracking features in them; FCM’s documented automatic service metadata remains provider-side.

Amazon SES sends registration-verification and password-reset messages from the verified play@stackfront.oalfonso.com domain over SMTP with STARTTLS. The application has a global hard cap of 500 OTP messages per day, independent of AWS account quotas and budgets. DNS and the HTTPS backend are deployed. SES production access and delivery to a real recipient were verified on 15 October 2026. Each app store displays its own privacy notice for the version distributed there.

Google and Apple sign-in are enabled for online accounts; Firebase Authentication and Steam sign-in are not enabled. The hosting provider, encrypted backup service, SES, APNs, and FCM process only what is needed to operate this beta; Lightsail, PostgreSQL backups, and SES are configured in Ireland. APNs receives the native push data needed for iOS delivery. FCM receives the native push data needed for Android delivery and its SDK may collect the Firebase service metadata described above.

Account deletion

To delete an online account, use Settings → Account → Delete account in the app. The server action is DELETE /v1/accounts/me.

When deletion is confirmed, the service soft-deletes the account and all of its owned or dependent rows; it does not physically delete those rows. It revokes sessions, sanitizes the verified email, nickname, password hash, pending login or reset code material, and provider identity fields, releases the nickname, tombstones social and match rows, redacts match snapshots, command or event payloads, stored command responses, private canonical turn checkpoints and undo events, durable batch receipts, and command payloads, revokes native device registrations, replaces provider tokens with redacted values, clears notification payloads and deduplication keys, and tombstones device and notification rows.

Hidden tombstones retain limited pseudonymous integrity metadata: row UUIDs and structural references between accounts, social rows, matches, and push rows; lifecycle dates and actor UUIDs; and operational status, sequence or digest, and match-outcome fields. These rows no longer contain email, nickname, usable credentials, provider tokens, notification payloads, move payloads, checkpoint state, undo state, or batch receipt payloads. The live opponent receives a finished or removed-match notice for the client to show.

Retained tombstone metadata is pseudonymous rather than anonymous and can outlast the deletion request. The seven-day operational-log window and seven-day encrypted-backup lifecycle can also outlast the request while those systems expire. Undelivered notification outbox events expire after the configured delivery window, currently 24 hours; the dispatcher marks expired rows dead. Account deletion clears the event payload and deduplication key and tombstones the row in the same transaction, regardless of its current delivery status. OTP and password-reset records retain no usable code after use, expiry, failed delivery, or deletion. The transaction revokes Stack Front’s device registration and redacts the FCM token in its AWS database, but it cannot directly delete provider-side Firebase Installation IDs or service metadata handled by Google/Firebase.

For community maps, names and layouts are removed from private catalogue uploads and revisions. Public or official technical map snapshots may be retained for match, rotation, and integrity history with the creator attribution removed. Active proposals are withdrawn, and their votes are invalidated and no longer count; the invalidation remains in the audit history.

Read the account deletion instructions. The HTTPS deletion backend and this public page are deployed; transactional delivery to a real recipient has been verified. Do not email a personal ID to request deletion.

Offline practice data is discarded with the local runtime on reload and is not covered by the server deletion endpoint. The local online-turn queue and undo journal are device records; logout or confirmed account deletion clears them.

Store declarations

The original offline iOS submission declared “Data Not Collected.” Apple App Store and Google Play provide privacy notices for the versions distributed through each store. Offline and online builds may use different data; this policy describes the online beta data flows and the separate offline behavior above.

Contact and changes

For privacy questions, write to oriol.sty@gmail.com. Do not include passwords, provider credentials, tokens, or personal identity documents.

We will update this policy before enabling any new online-beta collection and will show a new effective date for material changes.