HackerAI Privacy Policy
HackerAI is a fictional cyber strategy game published by Elysra. This policy explains what data the online version of HackerAI collects, how that data is used, and how players can request deletion.
HackerAI's hacking systems, IP addresses, targets, modules, malware names, regional conditions, markets, threat campaigns, and network activity are fictional gameplay content. The game does not scan, attack, or interact with real third-party devices, networks, accounts, providers, or servers. Credits, loot, recurring services, and market values are fictional game resources with no real-cash value. HackerAI does not support deposits, withdrawals, cash-out, or real-money trading.
Email Trust and account email
HackerAI has a limited Email Trust capability for transactional account onboarding and email-safety notices
from [email protected]. It is not a newsletter, advertising, gameplay offer, or behavior-based
marketing program. Status at publication: the delivery capability is controlled and automatic welcome-email
enqueue has not yet been enabled. This policy update does not itself queue or send a message to any existing
player.
When the separately controlled welcome lane is enabled, it is limited to a newly registered Google account or to a player who deliberately converts a guest account to Google sign-in. In either case, HackerAI uses only the current email address verified by Google and matching the player's HackerAI account. A player who remains a guest, a password-only account, and an already existing Google account are not eligible for this future welcome flow merely because it is activated. A guest-to-Google conversion is treated as a newly verified registration for this limited purpose; it is not a historical-user campaign.
For this capability, Elysra processes the current Google-verified email address, eligibility and verification provenance, template/version, message and deduplication identifiers, a keyed recipient fingerprint, queue/delivery state, attempt timestamps and count, and a bounded failure or suppression reason. The email-hosting/delivery provider processes the recipient address, message headers and body, routing data, and acceptance, delivery, bounce, or rejection metadata needed to transmit the message.
Account email has no sign-in or verification link and never asks for a HackerAI or Google password, one-time password, verification, 2FA, recovery, or backup code, API key, or private key. It uses no tracking pixel, remote image, open tracking, click tracking, or marketing profiling. The recipient fingerprint is pseudonymous, not anonymous. Account deletion or loss/change of the eligible Google email cancels unsent work, and permanent delivery failures are suppressed.
Historical account messages are separate from the future-welcome flow. No historical welcome or security campaign is released by this policy, and any such campaign requires a separately controlled, authenticated Owner release. Automatic email-retention cleanup is also not enabled at publication, so HackerAI does not represent its technical retention ceilings as an active deletion schedule.
Data We Collect
The online version of HackerAI may collect and store:
- Account identifiers, including the current public operator handle; private records of retired operator-handle claims kept solely to prevent reuse; email address for password accounts; and session identifiers.
- Guest account identifiers when a player chooses to continue as guest.
- Google account identifier, verified email, and profile details returned during Sign in with Google. The backend stores the provider subject/email and may use the name only to derive an initial operator handle; changing an operator handle does not change the Google profile/name, provider subject, or email. The native profile image URI is not uploaded to HackerAI.
- Email Trust delivery data for the narrowly eligible account-email flow: current Google-verified email, eligibility/verification provenance, template and version, message and deduplication identifiers, pseudonymous recipient fingerprint, queue/delivery state, attempt times/count, and bounded failure or suppression reason. The application outbox does not store a second plaintext recipient address or rendered message body.
- Play Games player identifier and profile details such as display name, title, and profile image URLs returned while checking the secondary platform identity. The backend links the verified player ID and does not currently persist the returned PGS profile images.
- Gamer identity (such as gamertag/avatar), analytics, diagnostics, and enabled achievement activity that Play Games Services processes for game-service functionality and stability.
- Game progress, reputation, rig inventory, modules, defenses, simulated targets, rewards, and trade activity.
- If Fence's Back Room is activated in the Play-only
0.3.21/code 46 release, casino gameplay and app-interaction records such as spins, blackjack actions, fictional-credit wagers and payouts, receipts, hands, rounds, settlements, awards, and shared progressive-pool transactions. - Living-world game state associated with the account, such as fictional resource reservations and samples, operation commands and receipts, threat observations, recovery state, and the account's simulation-feed cursor. Regional public conditions and market/network history are shared fictional world state rather than real-world telemetry.
- Forum posts, thread activity, public in-game handle, and fictional in-game IP address shown in forums.
- Forum abuse reports, including the selected reason, optional context, and a point-in-time snapshot of the reported post or thread (such as its body, title, identifiers, and timestamp) used by authorized moderators to review the case even if the live content is later hidden or deleted.
- Optional player-submitted feedback and issue reports (a category, a short subject, and a message) sent to Elysra for support and moderation. The backend may apply automatic personal-data redaction when the privacy filter is enabled; otherwise the submitted text is stored verbatim for operator review and then deleted according to the retention window below.
- Session tokens, trusted-device records, device public-key fingerprints, install identifiers, platform, app version, client type, timezone bucket, and related security challenge data.
- Notification preferences, local-notification state, and, when a player opts in and push is configured, an FCM device token and bounded push-delivery ledger.
- With separate opt-in on a supported Android build, an approximate foreground location converted on the device to a coarse sector. Raw latitude/longitude is not sent to HackerAI. The server holds the coarse sector in memory for no more than 60 seconds and stores only the consent setting, not a location history.
- If you additionally turn on the optional "Proximity PvP" setting, your coarse sector is used in memory to match you with other consenting nearby players for in-game PvP. Matching is pooled and mutual; no player is shown another player's location, distance, movement, or count. A matched opponent sees only your public in-game operator handle and your fictional in-game RIG address (both already visible in forums and ordinary PvP), never your real-world location or a real network address. Only the consent setting is stored, not a match history.
- Limited first-party usage events such as app opens, successful logins, screen views, session activity, and tutorial completion, recorded with a hashed installation identifier and/or player identifier, platform, app version, client type, timestamp, and bounded event properties.
- Play Integrity signals for sensitive Android actions, such as hack completion, forum posting, and market actions.
- Age-access data used to apply age-appropriate handling. A birthday entered in the app and raw Google Play age bounds stay on the device. HackerAI may privately bind only a derived account band (
unknown,under 18, oradult 18+), a source category, an assurance status, and server receipt timestamps to the signed-in account. This data is not part of a public profile. - Standard backend logs and abuse-prevention data such as IP address, user agent, request time, error data, hashed network-prefix audit records, rate-limit events, and security risk events.
Data We Do Not Collect
HackerAI does not request or collect a date of birth, exact age, raw Google Play age bounds, real device contacts, precise location, background location, IP-derived geolocation, camera, microphone, SMS, calendar, phone state, provider telemetry, local network scans, unrelated device sensor readings, live weather, or external storage data. Approximate location is collected only through the foreground, opt-in Nearby feature described above. The Android app requests internet access so it can connect to the HackerAI backend and Google services. It also declares Android's normal VIBRATE permission for optional haptic feedback, the opt-in POST_NOTIFICATIONS permission for background alerts, and ACCESS_COARSE_LOCATION for Nearby. Denial does not block the rest of the game. Google Play services may separately process device, account, and game-service data under Google's own terms when its platform features are available.
Local Sound, Haptics, And Preferences
Theme, accent, scanline, guide, sound, ambience, volume, and haptic preferences are stored locally on the device and are not currently synced to the HackerAI account. (Player-submitted feedback is handled separately and stored server-side — see Data We Collect above.) Interface sounds and ambience are synthesized and played on the device. Optional haptic feedback uses vibration. HackerAI does not open the microphone, record voice or gameplay audio, or upload recordings.
How We Use Data
We use data to:
- Operate online sessions and authenticate players through their selected primary identity.
- Optionally associate an authenticated Play Games platform profile with the player's Google operator.
- Sync progress across sessions and devices.
- Keep public operator handles unique, enforce the annual handle-change interval, and prevent retired handles from being reused.
- Run in-game forums, review abuse reports, enforce forum rules, and operate trading, rankings, PvP, and multiplayer simulation features.
- If the Play-only casino is activated, settle and recover casino play, conserve shared progressive pools, prevent duplicate payouts, and protect the fictional economy through security and fraud controls.
- Operate the separately opted-in Nearby feature, and — only if Proximity PvP is separately enabled — use the coarse sector to match consenting nearby players for in-game PvP. Deliver opted-in local or push notifications.
- Apply age-appropriate access handling across sessions and devices using the minimized account band described above.
- Protect accounts, detect abuse, enforce rate limits, and validate trusted-device or Play Integrity checks.
- Debug service issues, monitor reliability, and provide support.
- When separately activated, send a narrow transactional welcome to eligible future Google registrations and guest-to-Google conversions, and operate, secure, suppress, and reconcile that delivery flow.
- Understand, in aggregate, which features and onboarding steps players use so we can improve future updates.
Authorized Elysra operators may review existing account, forum moderation, support, security, feedback, and aggregate usage data through an internal console for the purposes listed above. That console adds no player-side telemetry or new categories of player data, and it does not use third-party analytics.
Operator Handle Changes
A saved, non-guest account can change its public HackerAI operator handle from Settings > Account > Change operator handle. The first successful change is available immediately; later successful changes are limited by a server-enforced rolling 365-day period. This changes only the public HackerAI handle, not a Google, Play Games, password, or other sign-in-provider identity or profile name. HackerAI may require a fresh sign-in or trusted-device verification before confirming a change.
HackerAI does not offer a public former-handle lookup. Current ownership and access references use the current handle, while immutable audit records and player-authored/free-text history may retain text recorded earlier.
Android Authentication Behavior
On Android, Credential Manager may automatically return one previously authorized Google account when the player has not explicitly signed out and Google permits auto-select. This silent request restores existing HackerAI operators only and cannot create a new operator. Creation requires a deliberate Continue with Google selection or another explicit account-creation action. Play Games Services v2 may separately recognize the device's platform gaming profile at launch. HackerAI treats that Play Games profile as secondary and links it only after the server verifies the platform proof.
Sharing
Elysra does not sell personal data. Data may be processed by backend hosting providers, database providers, Google identity services or Credential Manager, Google Play services used for Play Games, Play Integrity, Play Age Signals, or Firebase Cloud Messaging, an email-hosting/delivery provider for the limited Email Trust flow, and security infrastructure needed to operate the service. These providers process data only as needed to provide the relevant service. Firebase Cloud Messaging processes a device token and routing/delivery information needed for opted-in push notifications. Play Games Services automatically processes gamer identity, analytics, and diagnostics; its handling is also governed by Google's policies and the player's Google/Play Games settings.
Retention
Account and gameplay data is retained while an account remains active so the game can restore progress. A derived age-access band and its minimized provenance are retained only with that account for access enforcement and are deleted with the account; HackerAI does not retain the birthday or raw platform bounds. The current public operator handle and retired handle claims are retained to enforce unique handles and the annual renewal rule. When an account is deleted, its final handle and any previously retired handles remain privately and permanently as ownerless reservations only to prevent reuse; they do not preserve a public profile, former-name history, or public link to the deleted account. By default, pseudonymous device/security events and orphaned install hashes are bounded to 7 days, expired or revoked sessions to 30 days, action logs to 30 days, and push-delivery rows to 30 days; deployment settings may shorten those windows. A current FCM token is kept while the device is enrolled for push and is removed or revoked when the player removes that device, disables enrollment, deletes the account, or Google reports the token invalid. Nearby consent is retained until the player changes it or deletes the account; the coarse sector itself remains in memory for no more than 60 seconds and is not kept as location history. First-party usage events are retained in raw form for up to 90 days; aggregated statistics that no longer identify an installation or account may be kept longer. Player-submitted feedback is retained for up to 365 days for operator review and then automatically deleted. HMAC values are pseudonymous, not anonymous, because the service can correlate them while it holds the secret. Open forum abuse reports are retained until a moderation decision is recorded. Resolved or dismissed reports and their internal case notes are retained for up to 365 days after their last update and are then automatically deleted. Public forum records are handled as described below.
Fence's Back Room is planned only for the 0.3.21/code 46 Google Play release and is not activated
by this policy text. If activated, player-linked casino receipts, hands, rounds, settlements, awards, client
request IDs, and account/player linkage are kept with the account so play can be settled and recovered. Account
deletion deletes those records. A progressive-pool event remains after it is de-linked and minimized to a UTC
calendar day plus transaction, game, and fictional-economy facts needed for security, fraud prevention, shared-pool
conservation, and economy integrity. The remaining event contains no player token, client request ID, request
fingerprint, settlement linkage, or other account/player linkage. It is a minimized, de-linked record; Elysra does
not treat or describe it as anonymous.
The current casino design would retain that minimized pool event permanently; no shorter casino retention period has been approved. The casino must remain unavailable until Elysra's privacy/legal owner explicitly approves or changes that permanent retention, approves the final policy effective date and in-app notice, and verifies the matching Google Play Data Safety answers.
Email Trust records have a different status. At this policy's publication, automated Email Trust retention cleanup is disabled, so the technical maximums for queued, terminal, and campaign records are not an active public retention schedule. Player-linked email records are removed when the account is deleted where the database relationship applies. A minimal, non-recipient campaign-key receipt may remain to prevent reuse of a historical campaign key. HackerAI will publish an updated effective date and actual enforced periods before enabling automated Email Trust cleanup.
Data Deletion
Request account deletion
You can permanently delete your HackerAI account and the data described below at any time. The deletion cannot be undone. Two ways to request it:
- In the HackerAI app: sign in, then open Settings > Danger zone > Delete account and enter your exact operator handle to confirm. A recently authenticated session is accepted; an older session may require a signed device challenge or a fresh sign-in.
- If you cannot access the account: email [email protected] with the subject “HackerAI account deletion” and include your operator handle or account email. Elysra may require reasonable verification so another person cannot delete the account.
Full step-by-step instructions, including what happens to shared and public data, are on the public account deletion page.
Signed-in players can permanently delete their HackerAI account from Settings > Danger zone > Delete account. The player must enter the exact case-sensitive operator handle. A recently authenticated session is accepted; an older session requires a signed device challenge or fresh sign-in. Successful deletion signs the player out and removes the account identity, gameplay progress, sessions, linked sign-in identities, derived age-access record, device trust links, inventory, and private account spaces. The final handle and any previously retired handles remain only as private, ownerless, permanently retained reservations used to prevent reuse. They are not public profiles, a public former-name history, or public links to the deleted account.
If casino play has been activated, deletion also removes the casino account/player linkage, client request IDs, receipts, hands, rounds, settlements, and awards. Only the de-linked progressive-pool event described in Retention remains: UTC-day time and transaction, game, and fictional-economy facts, with no player token, request ID or fingerprint, settlement linkage, or account/player linkage. It is retained for security, fraud prevention, shared-pool conservation, and economy integrity and is not treated as anonymous. Permanent retention of this minimized record requires explicit privacy/legal owner approval before the Play-only code 46 casino is activated.
Step-by-step instructions are available on the public account deletion page. A player who cannot access the account can email [email protected] with the subject "HackerAI account deletion" and include the operator handle or account email. Elysra may require reasonable verification so another person cannot delete the account.
Private forums owned by the player and their contents are deleted. Public forums owned by the player become
read-only archives so other players do not lose their contributions. The deleted player's public threads and posts
remain only as generic [deleted] tombstones; the handle, simulated IP, audit identifier, title/preview,
and original body are removed. Abuse reports submitted by the deleted account are removed; snapshots, reporter
context, and internal notes for reports about that player's contributions are removed or cleared, while a generic
case record may remain until the retention period ends. Active PvP jobs and attack sessions are canceled, counterpart references are removed
or anonymized while earned numeric outcomes remain, and shared organizations transfer to an eligible remaining member
or dissolve. Security records required for fraud prevention or legal obligations may be retained only for the applicable disclosed period.
Children
HackerAI is not directed to children under 13. Players under the age required by their country or region should not create an account or use online features without appropriate permission.
Security
HackerAI uses HTTPS for production network traffic and account-security measures such as session tokens, trusted-device checks, and Play Integrity checks for selected sensitive actions. No method of transmission or storage is completely secure, but we use these measures to reduce unauthorized access and abuse.
Changes
This policy will be updated before adding ads, additional third-party analytics, crash reporting, purchases, marketing, material changes to the limited Email Trust flow, or new third-party account providers. HackerAI's first-party usage events, approximate-location feature, opted-in push handling, and Play Games Services automatic analytics, diagnostics, and enabled achievement activity are disclosed above and must remain represented in the Play Console Data safety form.
Contact
For privacy questions, contact [email protected].