Strideflare Privacy Policy
Strideflare can be accessed as a guest where the relevant distribution and client build permit guest room access. We process only the information reasonably needed to operate the portal client and enabled room, account, communication, reporting, security, moderation, and platform-integration services. We do not sell personal information or use Strideflare service data to build advertising profiles.
1. Scope and responsible operator
This policy applies to Strideflare's portal client and the room, account, chat, security, and moderation services operated for it. The responsible operator is:
Kim Dae Yeong, an individual based in the Republic of Korea, operating under the name Strideflare
Privacy contact: strideflare@gmail.com
You may access Strideflare through a third-party distribution platform. The platform separately controls information it collects for its website, platform account, advertising, consent, analytics, and other platform systems. Its privacy policy applies to that processing. This policy applies to information processed by or for Strideflare.
2. Information we process
The Y8 build uses guest access and the Y8 SDK for advertising. It does not automatically sign in, link a Strideflare account, or use Y8 cloud saves. Settings, personal records, badges, and Wave progress remain in browser storage. Limited operational connection diagnostics and aggregate room-entry statistics are enabled; Strideflare product analytics, Wave analytics, queued product events, and unload delivery are disabled. Y8 independently controls its platform and advertising data.
The Yandex Games build uses guest access and the Yandex Games SDK for advertising, loading/gameplay signals, language detection, and SDK-provided safe storage. It does not request player authorization or cloud-account saves. Strideflare operational analytics and product analytics are disabled; only service data required to run and protect the game is processed. Yandex independently controls its platform and advertising data.
The Playgama build uses guest access and Playgama Bridge for game saves, advertising, and host pause/audio signals. It does not request a linked Strideflare account. Settings, personal records, badges, and Wave progress use Bridge storage, which may be local or cloud-backed depending on the host. A save is complete only when the SDK acknowledges it; keep the game open while a save is pending or being retried.
Strideflare product analytics, Wave analytics, and product-funnel events are disabled in this build, including queued events and unload delivery. Limited operational connection diagnostics and aggregate room-entry statistics are enabled for Playgama and MSN; other execution platforms retain only service data needed to operate the game. Playgama and the host may independently process advertising and platform analytics under their own policies.
| Category | Information and source |
|---|---|
| Connection, session, and security data | IP address, request and connection time, room and session identifiers, a short-lived room-reconnection token, protocol information, authentication and rate-limit events, disconnects, and server-side signals associated with abuse or invalid requests. These are generated when your browser contacts the Strideflare server. |
| Player identity | A chosen or generated nickname; a randomly generated guest identifier stored in the browser and reused until site data is cleared; transient room and player identifiers; an internal Strideflare account identifier; and, for supported platform accounts, a game-specific platform identifier. The guest identifier is not a real name or platform account identifier. It stabilizes a guest callsign and supports room admission, reconnection, reports, and vote-kick enforcement across page reloads. |
| Own-domain account data | If own-domain registration is offered and you choose it: username, salted password hash, account role, creation and last-login timestamps, and signed Strideflare login tokens. We do not ask for an email address and do not store plaintext passwords. |
| CrazyGames-linked account data | For a signed-in CrazyGames player: game-specific CrazyGames user ID, current username, profile-picture URL, game ID, and a signed CrazyGames login token sent for verification, together with the linked internal Strideflare account identifier and Strideflare login token. The CrazyGames token is verified by the server and is not stored by Strideflare. CrazyGames also makes a country code available through its SDK system information whether or not the player is signed in. |
| Chat, reports, and moderation data | Chat messages where chat is available; report reason and details; reporter and reported-player identifiers, names, IP addresses, account identifiers, room information, and recent chat evidence; moderation actions; security events; and ban identifiers, reasons, start times, durations, and expiry times. A signed-in player ban links the Strideflare account with one reliable current connection IP when the server can identify one; if no reliable current IP is available or multiple current IPs make the result ambiguous, the account alone is banned. A live guest ban or direct IP ban uses the IP address only. After a successful team vote-kick, the room temporarily keeps the affected account or guest identifier. For an unauthenticated guest only, it also keeps for a shorter period a room-specific HMAC derived from the connection IP; the vote-kick map does not keep another raw-IP copy, and the random HMAC key is not shared between rooms. Reports and live-player actions use server-held context rather than trusting identity details supplied by another player. |
| Gameplay and progression data | Map and match identifiers, live-room participation, input class, and transient match state needed to run a room. In the current Full Launch build, Strideflare records account experience, levels, daily progression, seasonal K/D, and ranked placement only for a verified CrazyGames-linked account. Guests and own-domain/local accounts do not receive persisted XP or ranking records. Only eligible Quick Play pool matches with at least four human players count; AI Hunt, solo Defuse practice, administrative sessions, custom/private rooms, and other ineligible activity do not create official progression or ranking records. A qualified current-season leaderboard row may publicly display the account's current username, season rank, kills, deaths, matches, K/D, and smoothed rating. The signed-in account holder may also see their own recent seasonal records and earned placement badges in the profile view; this profile history is not a public account-search feature. |
| Live scoreboard country flag | When a player joins or reconnects to a live room, the server may use the current peer IP with its local country-only GeoLite2 database to derive a coarse ISO 3166-1 alpha-2 country code. Only that two-letter code is sent to room clients so the scoreboard can show a country flag beside the nickname; the raw IP is never sent to the browser for this feature. The code is kept with the active room session only, is not used to identify a person or household, is not used for admission, sanctions, ranking, or advertising, and is omitted when the lookup is unavailable or ambiguous. VPNs, mobile networks, proxies, and stale databases can make the result inaccurate. |
| Network and service diagnostic telemetry | Short-lived diagnostic events used to investigate matchmaking, connection reliability, and the first minutes of play, including a random network-session identifier, room and experience identifiers, distribution and client-build labels, matchmaking outcomes and HTTP status, disconnect and reconnect results, close codes and transport error details, page lifecycle state, connection age and bounded message/byte counters, and timing milestones such as first spawn, input, shot, hit, kill, death, 60- or 180-second retention, first match end, second match start, or advertising lifecycle timing where those events occur. These milestones describe events within a random diagnostic session and do not record the keys pressed, aim coordinates, chat content, or raw IP address; telemetry may record only whether the server successfully resolved a peer IP for transport diagnostics. |
| Single-player difficulty and delivery diagnostics | Wave Defense sends random run and launch identifiers, wave starts and clears, deaths and retries, active combat time including failed attempts, game-build/platform/input labels, weapon and upgrade categories, the lethal attacker category, health before the lethal hit, sampled frame performance, and bounded counts of runtime errors. It also records observed menu/PvP transitions, pause/page-lifecycle signals, and telemetry delivery counters. Error messages, stack traces, account identity, chat, and aiming coordinates are not included in these wave-analysis payloads. These observations help identify difficult or slow waves and technical problems; an absent signal does not prove why a player left. Per-run deduplication state is retained for up to six hours after its last update; daily aggregate counters are retained for 30 days. Pending events may be kept in tab session storage to retry after a refresh, bounded to 128 events and about 60 KB of event data. Events older than five minutes are not resent and are removed when the outbox is next processed; browsers may retain a closed tab's session storage under their own session-restoration rules. |
| Aggregate room-entry and capacity-fallback traffic | When a player successfully enters a room, the server first uses the current peer IP with its local country-only GeoLite2 database to derive a coarse ISO 3166-1 alpha-2 country code. For CrazyGames, a validated SDK country code may be used only as a fallback when the local lookup is unavailable; Poki and own-domain entries are recorded as unknown when neither source resolves. The server adds successful room entries and capacity-related rejections to daily totals by country or region and, for capacity rejections, by coarse rejection reason, requested experience, and mode. Unavailable or invalid country values count as unknown. These figures measure entry attempts, not unique people. A random launch-attempt identifier is held in server memory for up to 30 minutes to avoid counting retries twice, and an active fallback-session identifier is held until 60 seconds after its last heartbeat. The same launch-attempt identifier also powers a live count of offline AI matches in progress (voluntary solo AI and capacity fallback alike); that counter entry is held in server memory only and expires 60 seconds after its last heartbeat. Neither identifier is written to the daily aggregate file. The aggregate stores only the daily country code and counts; it does not store an account, guest identifier, session identifier, launch identifier, fallback-session identifier, raw IP address, or an individual country history. The separate live-scoreboard flag feature is described above. |
| Browser or platform storage | The browser's local storage may contain a generated or chosen nickname; the random guest identifier described above; sensitivity, audio, chat, loadout, key-binding, and mobile-control or custom-HUD settings; controls-help and loadout-coach preferences; acknowledgement of the legal notice; and limited portal lifecycle state such as active play counted toward a new-player advertising warm-up. In portal builds, including CrazyGames, Strideflare login tokens are kept only in the active page's memory and are never restored from browser storage. Refreshing or closing the page discards that page's copy. A player still signed in to CrazyGames may be authenticated again through platform verification. Own-domain administrator and account login tokens are kept in browser session storage for the tab session and are removed from that storage when you sign out or successfully delete the account through the client. The browser's session storage may temporarily contain a room-reconnection token together with the room, experience, map revision, guest identifier, mode, and a 12-second expiry time. CrazyGames room-reconnection tokens are kept only in active page memory for in-page connection recovery and are never restored from browser storage after refresh. The server's 12-second reconnection acceptance window still applies. Session storage normally survives a page refresh within the same tab session; browsers may also preserve or restore tab sessions. Session storage is not a guarantee that browser data is never written to disk. Map-editor drafts are stored locally only when an administrator uses the editor. A distribution platform or browser may separately preserve or synchronize site storage under its own rules. Poki's SDK may synchronize localStorage and IndexedDB data for a player signed in to Poki; Strideflare does not currently use IndexedDB or Poki account identity APIs. Strideflare does not currently write progression through the CrazyGames Data module. |
Strideflare does not currently use a separate third-party analytics or crash-reporting service and does not set its own advertising cookies. A distribution platform may perform its own advertising, consent, or analytics processing independently.
3. Why we process information
- to connect clients, create and join rooms, and provide the requested Service;
- to authenticate optional accounts and verify supported portal identities;
- to run live matches and validate gameplay requests; the current Full Launch build persists XP, progression events, seasonal K/D, and ranked placement only for verified CrazyGames-linked accounts and eligible Quick Play matches;
- to derive a coarse country code for the optional live scoreboard flag and aggregate room-entry country counts without exposing the source IP to room clients;
- to publish the current qualified season leaderboard and show a verified CrazyGames account holder their own seasonal history and placement badges;
- to validate requests, rate-limit abuse, secure accounts, and protect service availability and integrity;
- to deliver room chat, investigate reports, enforce restrictions, and handle appeals;
- to measure successful room entries and capacity-related fallback demand in aggregate for capacity, compliance-cost, provider, and advertising-economics planning; and
- to diagnose faults, comply with law, respond to lawful requests, and establish or defend legal claims.
Where the applicable legal framework uses these categories, providing requested rooms, live matches, optional account functions, and enabled communications is necessary to perform our agreement with you or take requested steps before it. Request validation, security, abuse prevention, moderation, appeals, fault diagnosis, capacity planning, and aggregate country or regional measurement rely on our legitimate interests in operating, protecting, understanding, and sustainably planning the Service, balanced against player rights. Processing needed to answer a binding request or preserve a required record relies on the applicable legal obligation, and processing needed for a dispute may rely on establishing, exercising, or defending legal claims. We rely on consent only where a specific interface asks for it; consent may be withdrawn as described at that interface and in Section 7. Equivalent lawful grounds apply where local law uses different terminology.
Automated game rules may reject an invalid result or connection, but you may contact us to contest a material restriction. Strideflare uses its aggregate country information for audience-level planning and does not use it to decide whether a particular player may enter a room, receive a sanction, or receive an individual advertisement. CrazyGames may independently use platform data for its advertising systems under its own privacy policy.Poki may independently use platform data for its advertising and analytics systems under its own privacy policy.
4. Information visible to other players
Your nickname, room presence, and messages sent in available chat channels may be visible to other players. When the server can resolve a coarse country from the current peer IP, the matching country flag is shown beside your nickname in the live scoreboard; the source IP itself is not shown. A missing or uncertain lookup produces no flag. Chat is processed only where the relevant distribution and current client enable that channel, and availability varies by distribution. In the current domain and CrazyGames Full Launch builds, guests and signed-in players can read the public current-season leaderboard. A qualified verified CrazyGames account's current username, season rank, kills, deaths, matches, K/D, and smoothed rating may therefore be visible to anyone viewing that leaderboard. Guests can view those public rows but their own guest matches are not saved to the ranking system. The profile season-history view is limited to the authenticated CrazyGames account holder and is not a public player-search directory. Reports, IP addresses, password hashes, authentication tokens, and internal moderation evidence are not public. Do not include your real name, contact details, birth date, credentials or authentication details, financial or payment information, or other sensitive personal information about yourself or another person in a nickname or chat message.
5. Retention and deletion
Automated expiry runs when the server starts and shortly after each UTC date boundary. Event-based records may therefore be removed at the next scheduled sweep after their period ends. The traffic-aggregate rule below uses UTC calendar dates and is pruned at that date boundary, or on the next server start if the server was offline.
| Information | How long it is kept |
|---|---|
| Live room, presence, and transient session state | Until the room or session ends. The coarse country code used for a scoreboard flag follows the live session and is discarded with it; no individual country history is retained. Limited identity and connection context for a recently disconnected report target may remain in server memory for up to 2 minutes. A capacity launch-attempt identifier is held in memory for up to 30 minutes, an active fallback-session identifier expires 60 seconds after its last heartbeat, and a live offline-AI-match counter entry expires 60 seconds after its last heartbeat; none is written to the daily aggregate file. |
| Room vote-kick cooldown and re-entry records | A vote initiator's cooldown remains in room memory for up to 10 minutes, and a rejected target's protection cooldown remains for up to 5 minutes. After a successful vote, the affected account or guest identifier is restricted from that room for up to 30 minutes. For an unauthenticated guest, a room-specific HMAC of the connection IP is also kept for up to 2 minutes to deter immediate guest-identifier rotation. Expired entries are pruned by the room's recurring sweep even without a later admission attempt, and all remaining entries and the room-specific HMAC key are erased when the room closes. |
| Strideflare signed login tokens | The server accepts a token for no more than 7 days after issue. Portal builds keep login tokens only in active page memory, never restore them from browser storage, and discard the current page's copy on sign-out, refresh, or close. Own-domain administrator and account login tokens remain in the tab's session storage until sign-out, successful account deletion through the client, clearing site data, or the end of the browser's tab session. They normally survive refresh, and browser session restoration may preserve them; the server's 7-day acceptance limit still applies. Deleting the account makes every token for it unusable. |
| Network and service diagnostic telemetry | Up to 7 days from the diagnostic event. The shared Redis telemetry list is pruned by the automated retention sweep and also has a 7-day key expiry as a secondary bound. |
| Chat logs, room kill-event logs, administrator audit logs, and security-event logs | 30 days from the event, then removed from active log files by the automated expiry process. |
| Player reports and attached evidence | An open report is kept for 90 days from submission and is then automatically removed if it has not been resolved or dismissed. A resolved or dismissed report and its evidence are kept for 180 days from the status change for appeals, repeat-abuse review, safety, and dispute handling. |
| Ban records | An active temporary ban is kept through its restriction period, which the server limits to no more than 365 days. The minimum active record for a permanent ban is kept while that restriction remains in force because it is required to enforce the ban. Metadata for an expired or manually removed temporary or permanent ban is kept for 30 days and then automatically removed. |
| Own-domain Strideflare accountCrazyGames-linked Strideflare account and external identity mapping | Until the player deletes the Strideflare data or the account has been inactive for 24 months, whichever occurs first. Inactivity is measured from the last login, or creation if there has been no later login. Administrative accounts are excluded from automatic inactivity deletion while needed to operate the Service. |
| Account-linked gameplay, leaderboard, profile-history, and progression data | Current Full Launch builds create these records only for verified CrazyGames-linked accounts and eligible Quick Play matches. Monthly season rows, earned placement badges derived from those rows, and the account's recent season-history view remain linked to the Strideflare account until the account is deleted or automatically removed after 24 months of inactivity. The public leaderboard exposes only the current qualified season row fields described in Section 4; prior-season rows are not published there. Account deletion removes linked experience, level, daily-combat, progression-event, match-statistics, seasonal-ranking, and profile-history records. Guests and own-domain/local accounts do not create new records in this category. Separate moderation or security evidence follows its own period below. |
| Browser local-storage settings, guest identifier, control layouts, acknowledgements, and lifecycle data | Until it is removed through browser site-data controls, removed through an available platform control, deleted by the browser or platform, or otherwise expires under the platform's rules. |
| Browser session-storage room-reconnection record | The reconnection token is accepted for 12 seconds. The browser copy is removed when it is consumed, found invalid or expired during a later read, site data is cleared, or the browser tab's session storage ends. A stale browser copy is rejected after 12 seconds even if the tab has not yet physically removed it. |
| In-page room-reconnection token | CrazyGames keeps this token only in active page memory for in-page connection recovery. Refreshing or closing the page discards that page's copy; it is not restored from browser storage. The server's 12-second reconnection acceptance window still applies. |
| Daily room-entry and capacity-fallback aggregates | The recording UTC date and the following 29 UTC dates: 30 UTC dates in total. At the next UTC date boundary, that first day's row is removed. If the server is offline at the boundary, it removes the expired row on its next start. Persisted aggregate records contain only bounded country codes and counts; they do not contain account, guest, session, launch-attempt, fallback-session, or raw-IP identifiers. |
| Container operational logs | The standard production configuration keeps at most five rotating files of 10 MB each for the game server and five for the web proxy. Oldest files are overwritten as the limit is reached, so the time represented varies with service activity rather than a fixed number of days. |
| Host authentication, firewall, and system-service logs | The production host limits its persistent system journal to 30 elapsed days and a bounded disk budget. Text authentication, system, kernel, and firewall logs rotate daily and are limited to 30 rotated files and 30 elapsed days. Expired records are removed by the next daily rotation or journal vacuum. A restricted record may be kept longer only under the exceptional legal, fraud, safety, or security grounds described below. |
| Server data backups and restore-safety archives | The bundled backup tool defaults to no more than the newest 30 game-data archives and a maximum age of 30 elapsed days for game-data, restore-safety, and superseded deployment-environment archives. Production may use a shorter count or age; the current production schedule uses no more than 30 archives and 30 elapsed days. Because pruning runs with the daily backup schedule, removal after the configured age may occur during the following 24 hours. A deleted live record may remain in a restricted backup until that backup expires and is not restored except for disaster recovery. |
Deleting an account does not automatically delete separate moderation, security, report, or ban records. Those records follow the periods above and may be kept longer only where reasonably necessary for an active legal claim, a binding legal duty, fraud investigation, or a serious safety or security incident. When the reason ends, the restricted record is deleted or de-identified.
6. Service providers, platforms, and international processing
We do not sell or rent personal information. The following providers support the current Service:
| Provider | Role and information involved |
|---|---|
| CrazyGames / Maxflow BV, Belgium | Distributes the CrazyGames version and provides the SDK, country code in SDK system information, platform account verification token, advertising and consent systems where enabled by CrazyGames, and related platform functionality. Strideflare receives the country code described above and the verified game-specific identity fields when account linking is enabled. CrazyGames independently controls its platform account, advertising, consent, analytics, and other platform data. Strideflare does not currently write player progression through the CrazyGames Data module. See the CrazyGames Privacy Policy. |
| Poki B.V., the Netherlands | Distributes the Poki version and provides its SDK, advertising, platform analytics, consent, optional platform account, and cloud-gamesave systems. The current Strideflare Poki build does not request Poki account identity or authentication tokens. Poki's SDK may independently preserve or synchronize browser localStorage and IndexedDB data for a player signed in to Poki. Poki controls those platform systems under its own privacy policy. See the Poki Privacy Center. |
| netcup GmbH, Germany | Provides hosting and network infrastructure for the Strideflare multiplayer and account server and may process the server-side categories described in this policy on our behalf. See the netcup Privacy Policy. |
| Google (Gmail) | Provides the Gmail mailbox used for support and privacy requests. If you email us, Google may process your email address, message, attachments, and communications metadata to deliver and secure the message under Google's terms and privacy policy. See the Google Privacy Policy. |
These providers do not all have the same role. CrazyGames independently controls its platform systems, Poki independently controls its platform systems, netcup supplies hosting infrastructure and processes hosted server data for Strideflare, and Google provides the support mailbox under its own service terms.
Because the operator is in the Republic of Korea, providers operate in the European Economic Area and the United States, and players may connect from other countries, information may be processed outside the country where you live. We limit provider access to what is needed for the purposes above and rely on the protections required by applicable law and the relevant service arrangements.
We may also disclose limited information to professional advisers, courts, regulators, law-enforcement authorities, or emergency services where reasonably necessary and lawful, or to a successor as part of a genuine reorganization or transfer of the Service subject to continued protection and any required notice.
7. Your choices and privacy rights
Subject to applicable law, you may request access to, correction or deletion of, or a copy of your personal information; request suspension or restriction of certain processing; object where a right to object applies; withdraw consent without affecting earlier lawful processing; and complain to a competent privacy authority.
An own-domain account deletion request requires the current password. Successful requests delete the Strideflare server account.
A CrazyGames-linked Strideflare account deletion request requires fresh CrazyGames verification. Successful requests delete the Strideflare server account and external identity mapping.
Strideflare deletion and CrazyGames account deletion are different. Deleting Strideflare data does not delete your CrazyGames platform account, CrazyGames account profile, advertising or analytics data controlled by CrazyGames, or data that CrazyGames controls through its platform data module. Use CrazyGames' own account or privacy controls for those requests. Deleting a CrazyGames account through CrazyGames is not the same as a request to delete separate Strideflare server data.
Strideflare data and Poki platform data are different. The current Poki build uses guest access and does not create a Poki-linked Strideflare account. Clearing Strideflare browser data or asking Strideflare to delete server-side records does not itself delete Poki-controlled account, advertising, analytics, consent, or cloud-gamesave data. Use Poki's own privacy controls for Poki-controlled processing.
If you later access Strideflare while signed in to the same CrazyGames account, the verified platform identity flow may automatically create a new, empty Strideflare account. Previously deleted Strideflare records are not restored.
Browser-stored information can be removed through browser site-data controls. Moderation and security records are not part of the account deletion cascade and remain only under the retention rules in Section 5.
For any other privacy request, email strideflare@gmail.com and describe the platform used, nickname, account identifier if known, and the request. Do not send a password or platform token. We may request limited information needed to verify control of the relevant account or record and will explain any lawful refusal or limited retention.
8. Age and younger players
Strideflare is intended for people who are at least 13 years old or the higher minimum age required to use the Service where they live. We do not ask for a date of birth. If we learn that personal information was provided by someone below the applicable minimum age, we will investigate and delete or restrict it as required. A parent or guardian may contact us and exercise the child's applicable privacy rights after reasonable verification.
9. Security
We use measures appropriate to this Service, including salted password hashing, signed Strideflare authentication tokens, server-side verification of CrazyGames tokens and game IDs, role-based moderation access, request-size and rate limits, server-side admission and message validation, restricted administrative access, and bounded container logs. No online service is completely secure. We will provide notices required by applicable law if a security incident creates a legally reportable risk.
10. Changes to this policy
We may update this policy when the Service, providers, or legal requirements change. We will update the date above and provide additional notice where required. We will not use previously collected information for a materially incompatible new purpose without an appropriate legal basis and any required notice or consent.
11. Contact
Operator and privacy lead: Kim Dae Yeong, an individual based in the Republic of Korea, operating under the name Strideflare
Email: strideflare@gmail.com
You may also contact the privacy authority available where you live. In the Republic of Korea, privacy guidance and complaint routes are available from the Personal Information Protection Commission and the Personal Information Portal.
See also the Strideflare Terms of Use.