Privacy Policy

1. Who we are and what this covers

Omega Software Solutions (“we”, “us”) is a small independent game developer in the United States. This policy covers:

• this website, omegagamesonline.com, including the playable builds we host at /play/;
• our games — Wreck Run, Merge Bastion, Daybreak Factory and Necrowave — in every form we ship them: playable in a browser on this site, embedded on a game portal, and as Android applications (com.omega.wreckrun, com.omega.mergebastion, com.omega.daybreakfactory, com.omega.necrowave);
• the Android build of Necrowave, which carries advertising software and Google Play Billing today whether or not it has reached a store listing yet. Nothing on this site installs it, and Necrowave’s browser version is the one playable here. What this policy says about advertising and purchases is written to cover that build as it is built, so that nothing here has to be rewritten on the day it goes on sale.

It also covers the online leaderboard service we run at omegagamesonline.com/api/v1, which receives and stores the scores our games submit. That service is ours, not a third party’s; section 4 is about it.

Our games are ad-supported, and section 5 describes advertising for the whole catalogue rather than game by game. Where a specific build differs today — the copies hosted on this site, for instance — that difference is stated as a current fact about that build, not as a promise about the game.

It does not cover a third party’s own site or store. When one of our games is played inside a portal such as CrazyGames or Poki, or installed from Google Play, that platform is an independent controller of whatever it collects, under its own privacy policy. The same is true of the advertising networks described in section 5.

Contact for anything in this policy: omegasolutionsbusiness@gmail.com. We have not appointed a data protection officer and are not required to.

2. What we collect

From this website

Nothing that identifies you. The site is static HTML, one stylesheet and one small JavaScript file, all served from our own server. There are no forms, no accounts, no comment system, no newsletter, no cookies, no analytics service, no advertising tags, no social media widgets and no fonts or scripts loaded from another company’s domain.

Like every web server, ours writes ordinary access logs: the requesting IP address, the date and time, the file requested, the HTTP status, the referring page and the browser’s user-agent string. We use these only to keep the server running and to investigate abuse or errors. We do not combine them with anything else, do not build profiles from them, do not sell or share them, and rotate them off the server in the normal course of operating it.

From our games

Our games run no analytics service, send no crash reports and track no events inside a game: there is no third‑party analytics software in any build of ours, and no build opens a connection of its own to report what a player did. In a game with an online leaderboard, the score post described in section 4 carries a small measurement record along with it — how much and how often that copy of the game has been played, how many advertisements it has shown, and the language and time zone the device is set to. That is the whole of the measurement we do, it rides on a request the game was already making, and it goes to our own service and to nobody else. Your save file itself stays on your device and is not uploaded. The advertising software inside an Android build collects diagnostics of its own and shares them with the advertising companies behind it, which section 5 sets out; none of that reaches us either.

One thing does reach us: a leaderboard score. A game with an online board submits, at the end of a run, a player key, a display name, the score, the gameplay numbers behind that score, the time of the submission, and the measurement record described above. We store it and serve the score and the name back as the board. That is the whole of the player data we hold, it is described field by field in section 4, and we share it with nobody.

We never ask you for: your email address, phone number, postal address, date of birth, precise location, contacts, photos, microphone or camera input. No game of ours has a login. The only thing a game may ever ask you to type is a display name for the leaderboard, which is optional, is yours to make up, and should not be your real name if you would rather it were not shown.

Advertising is separate again. The advertising software inside a build reads identifiers and technical facts in order to request an ad, and section 5 sets out what those are and who receives them. We are not one of the recipients, and nothing from the leaderboard goes to them.

3. Progress stored on your device

Each game keeps a small amount of gameplay state so you can pick up where you left off. It is written to your own device and is readable only by the game that wrote it:

• In a browser (this site or a portal embed): to the browser’s own storage for the page’s origin, where the game mounts its save area in IndexedDB. It is not a cookie, is never sent with an HTTP request and is not visible to us or to any other website.
• On Android: to the application’s private storage directory, which Android isolates from other apps and removes when the app is uninstalled.

The gameplay values stored are these:

Wreck Run	best score, best flip count, coins, number of runs, the skin you have selected and unlocked, mute setting, the last day seen, your per-level records and stars, today’s daily-track score with the seven-day strip and streak behind it, a flag saying the control card has been read, and the debris layout your previous wrecks left on the track
Merge Bastion	best wave, best threat level, best wave at each threat level, which of the towers you have discovered, which codex bounties you have claimed, runs played, the daily siege record and streak, tutorial and hint flags, mute setting, and a local table of your own best runs: wave, hybrids, kills and threat, with no names, stored on your device only and never uploaded
Daybreak Factory	a single saved factory state: cash, machine levels, the live order and crate state, the permanent perks you have earned, your badges and lifetime counters (taps, crates, orders, earnings), mute setting, and the timestamp of the current 24‑hour day
Necrowave	banked gold, the rank of each permanent upgrade bought from Old Moss, which characters, weapons and arenas you have unlocked and which arenas you have cleared, endless mode and your best endless time, curse level, mastery and the lore you have read; a lifetime tally of what you have killed and built; a snapshot of a run in progress, so a field you walk away from resumes where you left it; and your settings — the separate volumes, haptics and their strength, screen shake, damage numbers, reduced flashing, the extra safe-area inset and language

Three more things sit in that same save area in the games that have an online leaderboard: a player key, a random identifier the game generates on your device the first time it submits a score (or, on a platform where you are already signed in, the id that platform gives it); the display name shown beside your entry, if a game has asked you for one; and a measurement record — a handful of running totals about this copy of the game, kept up to date as you play, together with the language and the time zone the device reported the first time the game opened. Those three are not gameplay values. They are the fields that travel to our leaderboard service, and section 4 is about them.

Nothing in the save file identifies you by name unless you typed a name into it, and you can delete all of it at any time. See Your choices and controls — and note that clearing the save clears the copy on your device, not the leaderboard row we hold, which we remove on request. Identifiers used for advertising are separate again: they are stored by the advertising software itself, in the builds that carry one, and are described in section 5.

4. The online leaderboard

Some of our games have an online leaderboard, and a leaderboard has to be somewhere. Ours is a small service we wrote and run ourselves at omegagamesonline.com/api/v1. It is the only place any of our games sends anything, and it is the only player data we hold.

It is live in Wreck Run, Merge Bastion and Daybreak Factory, in every form we ship them: the copies playable on this site, the builds distributed by a game portal, and the Android builds. Necrowave has no online board today. We describe the leaderboard for the catalogue rather than game by game, because a game that gains a board later gains it under this section and not under a new one.

What a submission contains

At the end of a run the game posts a single message to that service, over HTTPS, signed so that the service can tell a real submission from a forged one. It carries:

Player key	The random identifier described above, or the id of the platform account you are already signed into where there is one. It is what makes your next score replace your previous one instead of adding a second row. It is a user identifier in Google Play’s sense, and we treat it as one.
Display name	The name shown beside your entry: a handle you typed, or the name the platform you are signed into gives, or a generic placeholder where there is neither. It is shown publicly on the board. Put nothing in it you would not want a stranger to read.
Score, and the numbers behind it	The score itself and the gameplay values that explain it — how long the run lasted, the wave and threat level reached, distance, tricks, the day count. This is app activity in Google Play’s sense.
Game and board	Which game and which board the score belongs to.
Time and a one-time number	The time of the submission and a nonce, which together stop the same score being replayed at the service over and over.
How this copy of the game has been used	Six running totals, kept on your device and sent as they stand: when the game was first opened, when it was last opened, how many separate days it has been opened on, how many times it has been started, how many seconds of play have been banked in it, and how many advertisements it has shown. They describe the installed copy, not a person, and they are not tied to anything outside your own row. This is app activity in Google Play’s sense.
Your device’s language and time zone	The language setting the device reported — a tag such as es_MX — and the time zone it reported, as an offset from UTC and a zone name such as America/Mexico_City. Both are read once, the first time the game opens, and then left alone, so changing your phone’s language or crossing a time zone later does not change what is sent. They are settings, not a position: we ask no device sensor where you are, and a time zone is a region rather than a place. They are coarse enough to suggest roughly where in the world a player is, which is why we set them out here rather than describe them as nothing.

The six totals and the two settings are there for one purpose, and we would rather say it plainly than leave it to be guessed: they tell us whether the people who start a game come back to it, and whether a game earns back what it costs to put in front of a player. They are never used to choose an advertisement, never sent to an advertising network or a portal, and never shown on the board.

Our server also records the IP address the submission arrived from. It is written in two places, and in neither of them is it shown on the board or attached to your board row. The first is a submission log, one entry per accepted score, which the database deletes automatically thirty days after the submission. The second is the service’s ordinary request log — the same line any web server writes for any request: what was asked for, what the answer was, how long it took, and the address it came from. That one is kept with the machine’s other system logs and rotated off it in the normal course of running the server rather than on a schedule of its own. Both exist to rate‑limit the service and to investigate cheating and abuse, and we use them for nothing else.

What is not in a submission: your save file — the progress, the unlocks and the choices you have made inside the game — your email address, your real name, your age, your position from any device sensor, any advertising identifier, and anything a third party put on your device. No game of ours asks a phone or a browser where it is, and no build of ours declares a location permission.

Who sees it

We collect this data. We do not share it. It goes to a server we operate, and it is not sold, not licensed, not passed to an advertising network, not given to a portal, and not used to build a profile or to target an advertisement. The public board itself is public by design: your display name, your score and its gameplay numbers are visible to anyone who opens the board in that game. Your player key, the measurement record and the IP address are not shown to anyone: a board read gives back a rank, a name, a score and the gameplay numbers behind it, and nothing else off the row.

How long we keep it

Your board row — key, name, score, numbers, and the measurement record that came with the best of them — is kept until you ask us to remove it, or until we retire that board. Removing the row removes the measurement record with it; there is no second copy of it anywhere else. The submission log that carries the IP address is deleted automatically thirty days after the submission; the service’s ordinary request log is rotated off the server as described above. The one-time numbers are discarded within minutes.

The country a score arrived from

Our leaderboard service also records the country a submission arrived from. Our own server works that out from the internet connection the score came in on: we buy no data about anybody, and we ask no other company where a player is. It is the country and nothing finer — never a region, a city, a postcode or a position on a map — and it is worked out once, the first time, and then left alone, so a holiday or a VPN does not relabel a player. It is kept with the measurement record above, on your row, and like the rest of that record it is never shown on the board. The address it was worked out from is not kept on the row: what the row holds is the country, not the address.

Having your entry removed

There is no delete button inside the game and no self-service page for this. Removal is a manual request that a person handles: write to omegasolutionsbusiness@gmail.com with “Leaderboard” in the subject line and tell us the game, the name shown on the board, and roughly the score and the date, so we can find the right row. We will delete it and confirm. Because there is no account, we cannot verify that a row is yours beyond what you can tell us about it; where a request is too vague to identify one row we will say so rather than delete somebody else’s. Clearing your save on the device also makes the game forget its player key, so a later run starts a new row — but the old row stays on the board until we remove it.

5. Advertising, and the third-party software involved

Our games are ad-supported. Advertising is part of how every Omega game is funded, in every form we ship it.

On Android, advertising is served through AppLovin MAX, a mediation SDK, and through Unity Ads, which is an advertising network in its own right and is asked for an ad directly rather than through a mediator. Both are part of the application. On a game portal such as CrazyGames or Poki, advertising is served by that portal’s own SDK, which the build we submit there carries. Whichever SDK is in play, the ad is requested from and delivered by that company’s servers, not by us; we run no ad server, and the only service we run at all is the leaderboard in section 4, which no advertiser touches. Our games have no age gate, so the advertising in them is configured to be non-personalised for every player rather than only for children: no behavioural or interest-based targeting, and no advertising profile built from play. The Children’s Privacy Policy sets that commitment out in full.

Unity Ads is configured for non‑personalised advertising for every player of every game that carries it, on every start, without an age gate and without asking: we tell the software the player has not consented to targeted advertising under European, Californian and Chinese privacy law, and we tell it the player is to be treated as age‑restricted, so the advertisement it chooses is based on the game being played and on nothing else. We do that in code, at every initialisation, rather than relying on a prompt. Unity remains an independent controller of what its software collects, under Unity’s own privacy policy, and its software offers a data‑privacy icon during an advertisement through which a player can reach, opt out of, or ask for the deletion of what it holds.

Advertising software of this kind reads the device or browser identifiers it needs to request and measure an ad. On Android that includes Google’s advertising ID, which is why an Android build carrying that software declares the advertising‑ID permission (com.google.android.gms.permission.AD_ID). It is not the only permission the software brings with it: internet access, network state, the two Android ad‑services permissions (ACCESS_ADSERVICES_TOPICS, ACCESS_ADSERVICES_ATTRIBUTION), a wake lock, a foreground service and a run‑at‑startup permission all arrive from the advertising software’s own manifest and from the scheduling library it depends on, which is how it queues the reports it sends when a device is offline. The game itself asks for none of them and does no background work of its own.

Which of our builds carries that software, and what each of them declares, is set out under Google Play Data safety alignment below. On the web the portal’s SDK stores its own identifiers in the browser alongside its own cookies. The advertising SDK also receives ordinary technical facts about the request — device or browser type, operating system, language, coarse country, and the ad slot being filled.

We do not receive any of it. The ad networks, and the portals that host our games, are independent controllers for what they collect, under their own privacy policies. We hold no advertising identifier and build no advertising profile. The one player record we do hold is the leaderboard row in section 4, and it goes to no advertiser; the game’s saved progress reaches neither us nor them.

Where a game offers you an ad in exchange for a bonus, declining it costs you only that bonus — nothing else in any game depends on it. We do not describe the shape an advertisement takes on screen here, because that is a product decision that can change in an update; what does not change is the description above of what advertising software reads and who receives it.

The copies hosted on this site

The web builds we submit to a game portal carry that portal’s SDK script. The copies of Wreck Run, Merge Bastion and Daybreak Factory we host at /play/ are the same export with that script tag removed, by the sync step that publishes them. Necrowave’s browser build was never a portal export and carries no portal SDK at all; its advertising code selects an ad provider only when it is running on Android with an advertising plugin present, and in a browser neither is true, so it falls through to a provider that requests nothing. While you play any of the four on omegagamesonline.com, every file the page loads comes from our own server: no request goes to a portal, no ad is requested, no portal storage is used, and your save is written to this browser’s own storage for this origin.

Stripping the portal SDK removes advertising, not the leaderboard. The copies of Wreck Run, Merge Bastion and Daybreak Factory hosted here submit a score to our own leaderboard service exactly as the portal and Android builds do, and section 4 describes what that submission contains.

That is a description of how these copies are built and published, not a commitment about what this site will always host. If a build served here ever requests an ad, this page and the Cookie Policy will say so before it goes live, and the date at the top of the page is the record.

Necrowave

Necrowave is playable in a browser on this site, and that build requests no ad, for the reason given just above. The Android build is a different artifact and the difference matters, so it gets its own paragraphs here. Nothing on this site installs it. We set its position out ahead of publication rather than after the fact, and the description above applies to it in full.

Necrowave is built for Android with the AppLovin MAX mediation software compiled into it. Because that software is present, its application manifest declares Google’s advertising-ID permission (com.google.android.gms.permission.AD_ID), internet access and network state, and with them the further permissions the ad software, the billing library and the game engine bring along. There are fourteen in all, among them the Android ad-services permissions (ACCESS_ADSERVICES_TOPICS, ACCESS_ADSERVICES_ATTRIBUTION), an attestation permission belonging to one of the mediated ad networks (com.amazon.privacypass.ATTEST), Google Play Billing (com.android.vending.BILLING), Wi‑Fi state, wake lock, foreground service, boot-completed and vibrate. AppLovin and the ad networks it mediates are independent controllers for whatever they collect, under their own privacy policies; it does not come to us.

Necrowave’s Android build carries Unity Ads alongside AppLovin MAX. It asks for no permission the build did not already declare: the advertising ID, internet, network state, the two ad‑services permissions, the wake lock, the foreground service and the run‑at‑startup permission are all ones AppLovin MAX brought with it, and Unity Ads uses the same ones. Its manifest still declares fourteen permissions and not fifteen.

Necrowave’s Android build also has Google Play Billing compiled into it, which is why its manifest declares com.android.vending.BILLING. That is the machinery for selling something, present in the build. Nothing in Necrowave is on sale today, and we are not describing here what it will sell or what any purchase would grant, because that is not settled; this page and the Refund Policy will name it before anything can be bought. A purchase made through Google Play is a transaction between you and Google: Google is the merchant of record, we never see a card number, and the purchase record does not come to us.

What does not change for Necrowave, on either platform: we ask for no account, it has no online leaderboard, and the game’s own progress is written to the device you are playing on and stays there — the browser’s own storage here, the app’s private directory on a phone.

Google Play Data safety alignment

Google Play asks a developer to declare what an app collects, what it shares, and what the listing is marked as. This is that declaration, written here so it can be checked against the build it belongs to. It is written to match the artifact actually submitted, and the catalogue is not in one state today.

Every Android build of Wreck Run, Merge Bastion and Daybreak Factory submits scores to our leaderboard and carries advertising software, so each of them declares:

• User IDs — collected and shared. Our leaderboard collects the player key, and the display name where a player has set one, to attribute a score; that much goes to a service we run and to no other company. The advertising software in the Android build collects an identifier of its own and shares it with the advertising companies behind it, which is why the answer for the build as a whole is “shared”.
• App activity — collected and shared. The score, the gameplay numbers behind it and the measurement record described in section 4 — how much and how often that copy of the game has been played, and how many advertisements it has shown — reach our leaderboard and nothing else. The advertising software separately collects the views and taps inside an advertisement, and app usage times, and shares those; they are not the same data and they do not meet.
• Where a row says “shared”, it is the advertising software doing the sharing, never us. We pass nothing we hold to an advertiser, a portal or anyone else.

Any Android build of ours that carries advertising software additionally declares Device or other IDs — collected, shared with third parties, used for advertising, answers yes to “uses advertising ID”, and its listing is marked Contains ads. That is also not user-controllable within the game, because it is how an ad is requested at all.

The advertising software in an Android build declares more than the advertising ID. Unity publishes the answers its Ads SDK requires of a developer, and we declare them: device or other IDs, personal identifiers, approximate location, purchase history, app activity — the views and taps inside an advertisement, not inside the game — and app diagnostics. Each is collected by that software, shared by it with the advertising companies behind it, and used for advertising, analytics, app functionality and fraud prevention. None of it is transient: it all appears on the Data safety card of any build carrying the software. We receive none of it, store none of it and combine it with nothing. Beyond those categories our builds collect nothing: no name or email address, no financial information collected by us, no precise location, no messages, no photos or video, no audio, no files, no contacts, no health data and no crash logs.

Where each build stands today. The Android build of Necrowave has AppLovin MAX, Unity Ads and Google Play Billing compiled into it. Its manifest declares fourteen permissions, among them Google’s advertising ID (com.google.android.gms.permission.AD_ID), com.android.vending.BILLING, the Android ad‑services permissions and an attestation permission belonging to one of the mediated networks. So Necrowave answers yes to “uses advertising ID” and is listed as Contains ads, and it declares no leaderboard data, because it has no online board.

The Android builds of Wreck Run, Merge Bastion and Daybreak Factory carry Unity Ads, one of the two pieces of advertising software in Necrowave. Each of their manifests declares nine permissions: Google’s advertising‑ID permission (com.google.android.gms.permission.AD_ID), internet access, network state, the two Android ad‑services permissions (ACCESS_ADSERVICES_TOPICS, ACCESS_ADSERVICES_ATTRIBUTION), a wake lock, a foreground service, a run‑at‑startup permission, and one permission the build defines for itself so that its own components can talk to each other. They answer yes to “uses advertising ID” and are listed as Contains ads. Nothing in any of the three is on sale, so none of them declares billing.

The browser build of Necrowave, which is what this site hosts, loads no ad SDK and requests no ad: it carries the game’s own advertising code, because it is one codebase, but that code selects an advertising provider only on Android with an advertising plugin present, so in a browser it falls through to a provider that requests nothing and contacts no ad network.

Hosting

This site runs on a virtual server we rent from DigitalOcean, which processes traffic to the site as our hosting provider. There is no content delivery network, no tag manager and no A/B testing service in front of it.

6. What we never do

• We do not sell personal information for money, and we have not done so in the preceding twelve months.
• We do not build a profile of you as a person, do not score you, and make no automated decision about you. We hold no advertising profile, nothing we hold is used to choose an advertisement, and nothing we hold is passed to anyone who chooses one. A leaderboard row carries, besides the score and the name, the measurement record set out in section 4: how much and how often that copy of the game has been played, how many advertisements it has shown, and the language and time zone the device is set to. We read those to see whether players come back and whether a game pays for itself, which is a purpose beyond showing the board and one we would rather name than hide. We do not combine a row with data from any other source, we buy no data about anyone, and nothing on a row is matched to a person outside it.
• We do not send marketing email, because we have no email addresses.

Each of these describes what we do. Advertising in our games is served by third-party software, and what an ad network does with the identifiers it reads is governed by its own policy, not by this list. We ask for advertising to be non-personalised, but identifiers still leave the device for the ad network, so where a law such as the California CPRA treats advertising of this kind as a “share” of personal information we take the conservative position: assume that serving ads in our games is such a share, made by the advertising SDK rather than by us.

7. Children

Our games are rated for players of 13 and over. They are not designed for children, they are not in the Google Play Families programme, and we do not direct them at a child audience. The only data we collect from anyone of any age is a leaderboard entry, and the advertising in our games is configured to be non-personalised for every player, so there is no behavioural or interest-based advertising to children. That second commitment applies to every game we publish, including Necrowave, and the children’s policy says how. Full detail, including our COPPA and Google Play Families position, is in the separate Children’s Privacy Policy.

8. Legal bases (UK/EU)

Where the UK GDPR or EU GDPR applies, the personal data we process is: the leaderboard entry described in section 4, and the IP address and request metadata in our server and submission logs. For the leaderboard entry our legal basis is legitimate interests (Article 6(1)(f)): running the scoreboard the game exists to put you on, which is what a player submitting a score expects to happen. For the logs the basis is legitimate interests too: keeping the website and the service available, secure and free of cheating and abuse. You may object to either, and section 10 says how. On-device game progress is not transmitted to us and so is not processed by us; storing it on your device is strictly necessary to provide the game you asked to play. Personal data processed by the advertising software in a build, or by the portal hosting it, is processed by those companies on their own legal bases and under their own policies, including any consent they are required to collect from you.

9. Your rights

UK GDPR and EU GDPR

You have the right to access, correct, erase, restrict or object to the processing of your personal data, and the right to data portability and to complain to your supervisory authority (in the UK, the Information Commissioner’s Office).

We want to be straightforward about what those rights amount to here. There is one record we might hold about you, and it is your leaderboard entry: a player key, a display name, a score and the numbers behind it. We will export it, correct it or delete it on request, by hand, at the address below — there is no automated route and no button in the game, so tell us enough to find the row. Because we run no accounts we cannot verify identity in the usual way; we act on what you can tell us about the entry, and we will not delete a row we are not reasonably satisfied is yours.

Beyond that entry we hold no account and no profile, so there is usually nothing else to export or correct. If you believe a specific server log entry relates to you, write to us with enough detail to find it (the approximate date, time and IP address) and we will search for it and delete it where we can. We cannot invent a record we never kept, and we will tell you plainly when that is the answer rather than pretend otherwise. A request about data held by an advertising network or a portal has to be made to that company; we can pass on what we can, but we cannot reach their records.

California (CCPA/CPRA)

California residents have the right to know what personal information is collected, used, disclosed or sold; the right to delete it; the right to correct it; the right to opt out of sale or sharing; and the right not to be discriminated against for exercising those rights. The personal information we collect is the leaderboard entry in section 4, plus server and submission logs; we disclose it to no one and we sell no personal information for money. Because the advertising in our games is served by third-party SDKs, and the CPRA treats targeted advertising as a “share”, the effective controls are the platform ones: on Android, Settings → Privacy → Ads → Delete advertising ID (or opt out of ad personalisation); in a browser, your browser’s cookie and site-data controls together with the ad choices offered by the portal you are playing on. To exercise a right of knowledge, correction or deletion over your leaderboard entry — the one record we do hold — write to omegasolutionsbusiness@gmail.com; we will also pass on what we can to a network or portal. We verify a request only to the extent we can, which given the absence of accounts means we rely on what you can tell us about the entry.

Other United States privacy laws

Residents of Virginia, Colorado, Connecticut, Utah, Texas and other states with comprehensive privacy laws have comparable rights of access, deletion, correction and opt-out, including opt-out of targeted advertising. The same answer applies: we hold no targeted advertising profile of our own, run no sale of personal data and perform no profiling; a leaderboard entry is deleted on request at the address above; and the controls that actually govern advertising are the platform ones listed above.

10. Your choices and controls

• Delete browser game data: clear site data for omegagamesonline.com (or for the portal you played on) in your browser’s settings, or use a private window. This erases your saved progress permanently; there is no backup, so it cannot be restored.
• Delete Android game data: Settings → Apps → the game → Storage → Clear data, or uninstall the app.
• Delete your leaderboard entry: clearing the save does not do this — the row stays on the board. Email omegasolutionsbusiness@gmail.com with “Leaderboard” in the subject line and the game, the name on the board and roughly the score and date. A person reads it and removes the row. Section 4 explains why it works this way.
• Stay off the board: play offline. A submission that cannot reach the service is given up on, the run is kept on your device’s own board instead, and nothing else in the game depends on it.
• Advertising controls: on Android, Settings → Privacy → Ads lets you reset or delete your advertising ID and turn off ad personalisation. In a browser, clearing site data for the portal you are playing on clears the identifiers its advertising has stored.

11. Retention

Leaderboard rows, and the measurement record each one carries, are kept until you ask us to remove one, or until we retire that board. The submission log behind them, which carries the IP address the score arrived from, is deleted automatically thirty days after the submission; the one-time numbers that stop a score being replayed are discarded within minutes. Server access logs, and the leaderboard service’s own request log, which carries the same IP address, are kept only while they are useful for security and troubleshooting and are then rotated and discarded. Game progress on your device is kept until you clear it or uninstall the game — we cannot delete that for you, because we cannot reach it. We hold no other records about players. Data held by an advertising network or a portal is retained under that company’s own policy, not ours.

12. Security

The website itself is served over HTTPS with a valid certificate and is entirely static: no database, no login, no user upload, no server-side code behind the pages.

The leaderboard service is the one piece that does hold player data, and it is built small on purpose. It answers three requests and no more: a health check, a read of a board, and a score submission. There is no route that deletes, edits or exports a row, which is why removal is a manual job for us rather than something a request can be made to do. Submissions travel over HTTPS and are signed, so the service can reject a forged or replayed one, and both reads and writes are rate-limited. The row it stores is a name, a score, some gameplay numbers, a key and the measurement record described in section 4 — there is no password, no email address and no payment detail in the database, because we never collect one.

The server is kept patched and administrative access is restricted to key-based authentication. No system is perfectly secure, but the surface here is deliberately as small as we could make it.

13. International transfers

Our server is located in the United States, and so is the leaderboard database on it. If you play from elsewhere, your request reaches a server in the United States and your board entry is stored there. That is the whole of the transfer on our side: one small record, held in one country, disclosed to nobody. Advertising networks and portals operate internationally and make their own transfers under their own policies.

14. Changes to this policy

If we change what our software does — including adding an online leaderboard to a game that has none, or changing what a submission carries — we will update this page and the date at the top before the change ships, and update our Google Play Data safety declaration to match. Our games are ad-supported by design, so a change in which networks serve them, or in what a build requests, is a change to this page rather than a surprise. We do not have your email address, so we cannot notify you individually; the date at the top of this page is the record.

15. Contact

Email omegasolutionsbusiness@gmail.com with any privacy question, request or complaint. Write “Privacy” in the subject line and we will answer as quickly as a small team can, and within any period the law that applies to you requires.

All policies