Privacy Policy

1. Who is responsible for your data (Data Controller)

The app “Tilt Blocks” (Android package com.luxebyte.tiltblocks, the “App”) is published by Luxebyte Labs (the “Developer”, “we”, “us”).

For the limited processing described in this policy, the data controller is:

• Controller: Matteo Lamarque, trading as Luxebyte Labs
• Contact for privacy matters: luxebytecomp@gmail.com

“Luxebyte Labs” is a trading name of Matteo Lamarque, an independent developer based in Italy. This is a one-person publisher, and the email address above is the contact point for every privacy matter — it reaches the person who can actually act on it. If you need a postal address in order to exercise a right, write to luxebytecomp@gmail.com and it will be given to you.

2. Scope of this policy

This policy applies only to the “Tilt Blocks” Android App distributed through the Google Play Store. It does not cover any other product, website, or third-party service except as expressly described here (in particular Google’s advertising services).

The App is distributed globally and its interface is localized into many languages. This English text is the primary version.

Updates to this policy

We may update this policy, for example if the App changes or if legal requirements change. When we make a material change we will update the “Last updated” date above and publish the new version at the same web address where you found this policy, before or at the time the change takes effect. Where the change concerns advertising consent, you may be asked again through the in-app consent mechanism (see Section 7). Your continued use of the App after an update takes effect means the updated policy applies to you; if you do not agree, you can stop using the App and uninstall it.

3. What data is processed

The App processes six clearly separate categories of data. We keep them separate on purpose, because they behave very differently: one is kept on your device, one is collected by Google and never reaches us, one is a single request that carries nothing about you but cannot help revealing where it came from, one is a small, fixed set of usage statistics that you can switch off, one is a counter we keep for the invite links players share, and one is a record, sent to Meta, that the App was installed and opened, and, when it came from one of Meta’s adverts, the Google Play link that brought the installation, so that our own advertising can be measured (Section 3(g)); it is never sent in the EEA, the UK or Switzerland, and the usage statistics switch turns it off everywhere else. The App sends none of the data kept on your device anywhere, except a few items named in Section 3(a), which are sent with the usage statistics in Section 3(d) where those are permitted, and the invite code described in Section 3(f).

3(a). Data kept on your device

To make the App work, the App stores a small amount of information locally on your device, using Android’s standard SharedPreferences storage (and, for the next daily reminder only, the scheduling library’s own storage, named below). This is the complete list, grouped by what it is for.

Your game

• your best score, and which version of the game’s scoring rules it was set under, so that a score from earlier rules is not carried into a game that plays differently;
• your unfinished game, so a run can be resumed after you close the App: the board, the score, the turn count, your current streak of clears, the pieces in your hand, how many extra lives and second chances that game has used, where it is in its sequence of pieces, and, when the game has them, where Blocky’s tile is and where the gems that sit in place of a block are.

Your settings

• sound on or off, and the language you have chosen;
• your board skin: which one is in use, which skins you have bought with gems, and, for a skin unlocked for 24 hours by a video in an earlier version of the App, the moment it was unlocked, because that unlock lasts 24 hours and has to know when it started;
• your gems, the in-game currency you earn by playing (and by inviting friends, Section 3(f), and from Blocky’s daily gift, below) and spend on board skins (Section 3(b)): how many you have now, how many you have earned in total, how many you have earned in the game in progress, including any doubling by a video (shown to you when it ends), a number that tells one game’s gems from the next, so that a doubling is paid to the game it was for, the day you earned your first one, and whether the App has already paid the one-off credit for achievements and daily goals you finished before gems existed. Gems are kept only on your device and never expire;
• whether usage statistics (Section 3(d)) are switched on;
• a copy of what Google’s consent component last told the App: whether a consent message applies to you and, if it does, whether it has been answered (not what you answered). The App keeps it so it can tell whether usage statistics may be sent without first asking over the network (Section 7).

The tutorial

• whether the tutorial has already been shown to you when the App was first opened, so that it is shown automatically only once;
• whether you have ever played one whole turn (a placement and the tilt after it), in the tutorial or in a game, which is how the App decides whether to keep offering you the tutorial.

Blocky, the App’s guide

• whether Blocky’s welcome has already started, so that it plays only once;
• how many blocks you have placed, in the tutorial and in games, counted only up to 20, after which Blocky no longer shows his “Place a block first!” hint;
• for his greeting on the main menu: the last thing he said there, the day of your last visit to the main menu, and your best score at that visit, so that he does not repeat himself and can tell when your best has risen.

Your daily goal and achievements

• today’s goal: which day it belongs to, how far you have got with it, the last day you finished one, how many you have finished in total (never how many in a row), and the last day the App showed you that you had finished it;
• the last day the App played the short animation that presents today’s goal, so that starting a game does not play it a second time that day;
• which of the 50 medals of the App’s achievements you hold, which of them you have not yet looked at in the achievements list, and which ones you have earned that are still waiting to be awarded, because the App spaces medals out by the turns you play: it keeps how many turns you have played in games and the count when it last awarded one;
• the running totals the medals are measured against, all counted from your games: lines cleared, points scored in all, games that reached the EINSTEIN rung, your longest game in turns, your biggest single clear, clears of four lines or more, your longest streak, boards emptied, turns whose block cleared and whose tilt then cleared again, Blocky tiles freed, how many days you have played on, the first and the last of those days, and the gems earned by playing (never those from a video, from inviting friends or from the daily gift).

The daily gift

• the day you last opened the daily gift Blocky holds on the main menu, so that it adds its gems once a day and never twice, even if the phone’s clock is moved.

The daily reminder

• whether the daily reminder is switched on, and how many times (at most two) and on which day the App last asked Android for permission to post it;
• the day the last reminder was posted, how many reminders in a row have gone unanswered, and when the App was last opened, which is how the App decides whether a reminder is due and stops after three unanswered;
• the next reminder itself, which WorkManager, a scheduling library built into the App, keeps in its own storage on your device until it is due.

The rating request

• how many games you have played to the end, a single number, which the App uses to pick a good moment to ask for a rating;
• how many times the App has asked for a rating, and when it last asked, so that it does not ask too often. The App asks Google Play to show its rating card; Google Play decides whether the card actually appears and does not tell the App.

Where your installation came from

• the words saying which link brought you to the App’s store page, and roughly how long after installation the App was first opened, both described in Section 3(d), together with whether they have been read and sent yet and how many times reading them has failed.

Invite a friend (Section 3(f))

• once you have pressed Invite a friend: your invite code; how many friends the App has already paid you gems for (at most 10); how many newly counted friends Blocky has still to tell you about; when you last shared your link; when the App last checked your counter and how many times it checked that day; and when it last paid you for a friend;
• if you installed the App from a friend’s invite link: your friend’s code, read from that link, and where the App’s one report of it stands (waiting, sent, refused or given up), with how many tries it has made, when it first tried and when it may try next;
• the last Firebase App Check token (Section 3(f)) and when it expires, and, after a failed attempt to get one, when the App may ask again, kept in a separate file so that the token can be reused until then.

The advertising switch

• the last copy of the file described in Section 3(c), and when it was fetched, so that the App does not fetch it again for 24 hours and can use the last copy when it cannot reach the internet.

The optional videos

• while a video you chose to watch is on its way or playing, which of the four offers in Section 3(b) it was for, removed as soon as the App records how it ended, so that a video interrupted by the phone closing the App can still be counted once, at the App’s next start (Section 3(d));
• while a video you chose to watch to unlock a board skin is on its way or playing, which skin it is for, removed when the video ends, so that a skin whose video was interrupted by the phone closing the App is unlocked at the App’s next start;
• while a video you chose to watch to double a game’s gems is on its way or playing, which game it is for and how many gems it adds, removed when they are added or when it ends without them, so that a video interrupted by the phone closing the App still adds its gems once, at the App’s next start;
• for the video that adds gems in the skins gallery, how many have paid their gems today and which day that is, so that no more than three are offered in a day; and, while one you chose to watch is on its way or playing, which day it was pressed on and which of that day’s three it is, removed when its gems are added or when it ends without them, so that a video interrupted by the phone closing the App still adds its gems once, at the App’s next start.

Two kinds of stored data are not on this list because the current App does not write them. Older versions of the App may have left a few entries that this version no longer writes (an old light or dark theme setting, for example). And Google’s own components described in Sections 3(b), 3(d) and 7 keep their own records on your device, such as your consent answer and the usage statistics identifier; those Sections describe them.

This on-device data:

• is never transmitted to the Developer, who has no servers to receive it, except an invite code, which reaches the invite counter we keep in Google Cloud Firestore (Section 3(f));
• is never sold or shared with anyone;
• contains nothing that identifies you by name: there is no account, no login, no name, no email address and no device or advertising identifier in it. The one identifier it can hold is an invite code (Section 3(f)): a random string the App draws itself, made from nothing about you or your phone, but which names one entry in our invite counter and is written into the link you share. We treat it as pseudonymous personal data;
• is not sent anywhere by the App, except the invite codes Section 3(f) describes, which are sent whatever your advertising and statistics choices, and what Section 3(d) describes, only where usage statistics are permitted: the words about where your installation came from and how soon it was first opened, sent once; the board skin in use; when you buy a board skin, which one, how many you now own, and roughly how many days have passed since your first gem, as a band; which kind of daily goal you finished, when you finish one; that you opened the daily gift, when you open it; the name of each achievement medal the App awards you, when it awards it; that the App asked Google Play for its rating card, and at which of two moments; that a daily reminder was posted, which goal it named, and whether you opened the App from it; your answer to Android’s notification question; and the new value when you change the sound, the language or the daily reminder. Your scores, your unfinished game, your count of finished games, your gems (how many you have, or earned in a game, or earned in total), the running totals behind your achievements, Blocky’s records and the tutorial records are never sent, and the rating records only as the one fact above;
• may be included in your phone’s own backup: if backup is switched on in your phone’s settings, Android can copy the App’s stored data to your Google account, as it does for most apps, and put it back when you reinstall the App or move to a new phone. That copy is kept by Google under your account, and the Developer cannot see it;
• is fully under your control: uninstalling the App, or clearing the App’s storage/data in Android Settings → Apps → Tilt Blocks → Storage, deletes it from your phone.

The App itself declares five permissions:

• Vibration (VIBRATE), to make blocks feel like objects in your hand;
• Internet access (INTERNET), used by the advertising and consent components described in 3(b), by the single request described in 3(c), by the usage statistics described in 3(d), by the invite requests described in 3(f), by the Meta component described in 3(g), and by nothing else;
• Advertising ID (com.google.android.gms.permission.AD_ID), which is what allows Google to read the resettable advertising identifier described in 3(b), and Meta’s component to read it where Section 3(g) says it is active. It is declared explicitly rather than inherited silently, so that what the App can reach is written down rather than guessed at;
• Notifications (POST_NOTIFICATIONS), for the daily reminder described below. On Android 13 and later Android asks you first, and the App posts nothing unless you allow it. The App shows Android’s question by itself when you first open it (or, if it cannot then, on the main menu), and again only on a later day; pressing the reminder switch in Settings can also show it. In all, the App shows it at most twice. On older versions Android does not ask, and the reminder is on unless you switch it off, in the App’s Settings or in Android’s;
• Run at startup (RECEIVE_BOOT_COMPLETED), so that a reminder already scheduled is not lost when the phone restarts. It lets the App’s scheduling library put the reminder back; it starts no game and reads nothing.

The libraries built into the App, all named in this policy, declare these as well, and only those libraries use them:

• Network state (ACCESS_NETWORK_STATE), so the advertising, analytics and scheduling libraries can tell whether the phone is online before they try;
• Keep awake (WAKE_LOCK) and Foreground service (FOREGROUND_SERVICE), which WorkManager and Google’s components use to finish short pieces of work in the background, such as the daily reminder;
• Ad services (ACCESS_ADSERVICES_AD_ID, ACCESS_ADSERVICES_ATTRIBUTION and ACCESS_ADSERVICES_TOPICS), Android’s Privacy Sandbox interfaces, declared by Google’s advertising and analytics components, which may use them for the advertising purposes in Section 3(b) under the consent described in Section 7;
• Install referrer (com.google.android.finsky.permission.BIND_GET_INSTALL_REFERRER_SERVICE), which lets the App ask Google Play, once, which link brought you to it (Section 3(d)), and lets Meta’s component ask the same, once, where Section 3(g) says it is active;
• an internal permission named after the App (com.luxebyte.tiltblocks.DYNAMIC_RECEIVER_NOT_EXPORTED_PERMISSION), declared by Android’s support library so that only the App itself can send messages to its own components.

Those are all the permissions the App as published contains, and there are no others.

The daily reminder. The App can post at most one notification a day, about today’s goal, and only on a day you have not opened the App yet. It is scheduled on your device by WorkManager, a library built into the App; there is no push service and no server, and nothing is sent to anyone to make it happen. It never contains an ad, and tapping it opens the App’s main menu, which shows none either. After three reminders in a row go unanswered it stops until you next open the App. You can switch it off at any time in Main menu → Settings → Daily goal reminder, or in Android’s notification settings for the App.

It has no access to your camera, microphone, location, contacts, files, or phone state, and no permission that identifies you personally.

3(b). Advertising data — collected and shared by Google (AdMob)

The App offers one kind of advertisement, a rewarded video ad, which you may choose to watch in exactly four places:

1. An extra life, when a game ends. The Keep playing button carries the line “Watch a short ad”, so the button says what it starts before you press it, and pressing it is the choice. A video clears space and continues that run. At most two per game, a limit built into the game’s rules and not adjustable by us at runtime.
2. A board skin, in the skins gallery (opened from the main menu or from the game’s header). Skins are bought with gems, which you earn by playing (Section 3(a)), from Blocky’s daily gift on the main menu, or by inviting friends (Section 3(f)); gems cannot be bought with money. When you have enough gems for a skin, pressing it opens an unlock step that shows its price, with a button reading Watch an ad to unlock and the skin’s name, and Not now the same size beside or under it; nothing plays until you press the button. When the video has played, the gems are spent and the skin is yours to keep. If you close the video early, nothing is spent and nothing is unlocked. If the video cannot be shown (no video available, no connection, an error), or the phone closes the App while it is playing, the skin is unlocked and the gems are spent all the same (in the second case, at the App’s next start). Where ads are switched off (Section 3(c)) or advertising consent has been refused, the unlock step names no video and the skin unlocks without one. There is no per-game limit, because a skin changes only how the board looks. A skin unlocked for 24 hours by a video in an earlier version of the App keeps the rest of its 24 hours and then ends; you can buy it with gems at any time, including while those hours run.
3. Double a game’s turn gems, when a game ends. At any game over where that game’s turns have earned gems, including one that also offers Keep playing, a small button at the end of the line showing the game’s gems reads “×2” with the gem, Double the gems (left out on narrow screens where it does not fit) and the same video mark as Keep playing, so it says it starts a video before you press it. Screen readers read it as Double the gems · Watch ad and the exact number of gems it adds now, which is the number that game’s turns have earned so far (on all but the shortest screens also shown under that line as “This run”). Nothing plays until you press it, and not pressing it is the way to decline (Play again, Keep playing and the Home button are on the same screen). When the video has played, those gems are paid a second time at once, and if you then take an extra life, every turn of the same game after it also earns its gems twice, until the game ends. Gems from the daily goal and from achievements are never doubled. If the video cannot be shown once you have pressed the button, or the phone closes the App while it is playing, the gems are doubled anyway (in the second case, at the App’s next start); if you close it early, nothing is added. Starting a new game while the video is on its way never moves the bonus onto the new game. It is used at most once per game: after it, later game overs of that game show “Turn gems doubled” and no button. While its video is still loading, the button is greyed, shows three dots in place of the video mark and cannot be pressed; with no video ready or on its way, it is not offered. It has its own video, separate from the extra life’s, so taking one never uses up or hides the other.
4. Gems for a video, in the skins gallery. Under the gallery’s title, a button reads Watch ad with the video mark and +150 with the gem, and beside it how many of today’s videos are left; the same button also appears in the short message the gallery shows when you press a skin you do not yet have enough gems for. Nothing plays until you press it, and not pressing it is the way to decline. When the video has played, 150 gems are added. At most three a day, counted on your phone’s own calendar day; once they are used, the button is greyed, reads “Back tomorrow” and cannot be pressed. If the video cannot be shown once you have pressed the button, or the phone closes the App while it is playing, the gems are added all the same (in the second case, at the App’s next start), and that counts as one of the day’s three; if you close it early, nothing is added and it does not count. While its video is still loading, the button is greyed, reads “Loading ad…” and cannot be pressed; with no video ready or on its way, it is not offered. It has its own video, separate from the other three offers’, so taking one never uses up or hides another.

In all four places the ad is:

• opt-in — nothing plays until you press a button that names the video or carries its video mark;
• never auto-played, never shown on the board, and never shown in a notification;
• fully declinable — after a game, Play again and Home are free, always present and cost nothing, and the offers there need no answer; Not now in the gallery is free and always present, and the gallery’s gem video needs no answer; the free board, Gloss, is always available;
• never a loss to you when no video is ready — after a game, the extra life is offered only when a video is ready, and the doubling of a game’s gems can be pressed only when its video is ready (while it loads, its button is greyed); with no video ready or on its way, neither offer is shown at all; in the gallery, a video that is not ready or cannot play never costs you the skin, which unlocks without it, and the gem video can be pressed only when its video is ready (while it loads, its button is greyed) and is not shown at all with no video ready or on its way.

To serve this ad we use the Google Mobile Ads SDK (Google AdMob). When an ad is requested and shown, Google and its advertising partners collect and process the following categories of data for the purposes of serving ads, measuring ad performance, and preventing fraud and abuse:

• the Android Advertising ID (AAID) — a resettable advertising identifier;
• the app-set ID — an identifier scoped to apps from the same developer;
• your IP address;
• device and diagnostic information (such as device model, operating-system version, language/region, and similar technical data);
• your interactions with ads (such as whether an ad was shown, viewed, or clicked).

This advertising data is collected by and shared with Google and Google’s advertising partners. The Developer does not receive it. Because Google’s advertising infrastructure is global, this data may be processed on servers located outside the European Union / European Economic Area, including in the United States (see Section 6).

No score, no game progress and no setting is ever sent with an ad request. Your best score and your saved game stay on your device.

3(c). One request to a static file, so ads can be switched off without an update

When the App starts it fetches a single small text file from a fixed address:

The whole content of that file is a line saying whether advertising is switched on. It exists so that ads can be turned off without publishing a new version of the App.

The App sends nothing with this request: no identifier, no advertising ID, no score, no setting, nothing about you or your game. But as with any request to any web server, the server that answers it necessarily sees the IP address the request came from, together with ordinary connection information such as the time, the file requested and the type of client. That server is GitHub Pages, operated by GitHub, Inc., which hosts the file as a plain static document. We run no server for it, and we never see a log of these requests.

The App keeps the last successful response on your device. For 24 hours after it was fetched the App uses it without asking again, so a returning player usually makes no request at all; after that the App fetches the file again, and if that fails it keeps using the last copy, however old, until a new fetch succeeds.

Separately from this file, the App asks Google’s consent component at every start whether a consent message is required for you (Section 7). It does so whether advertising is switched on or off, because the answer also governs the usage statistics in Section 3(d). Outside the EEA, the UK and Switzerland that check shows nothing and asks you nothing.

3(d). Usage statistics (Google Analytics for Firebase)

Why this exists, plainly. Tilt Blocks is made by one person, and the only thing that person can otherwise see is a star rating. This Section describes the small, fixed set of facts the App can send so that we can learn whether people find the tutorial, how far their games get, whether the four optional video offers are understood, which board colours are used, how often the App asks for a rating, and whether the game draws smoothly enough on people’s phones. Nothing here changes the game: the pieces you are dealt, the difficulty ramp and the offers you see are decided by rules that cannot read any of this data, and that separation is enforced by automated tests in the App’s source.

We describe this data as pseudonymous, and deliberately not as “anonymous”. Each installation is identified by a random identifier generated by Google’s SDK, and Google sees the IP address the data arrives from. That is enough for the data to count as personal data, so it is treated as personal data throughout this policy.

Where this is active, and where nothing is sent at all

In the EEA, the UK and Switzerland, nothing is sent unless you say yes. The consent message described in Section 7 includes a purpose for these statistics. If you consent to that purpose, the App collects what this Section describes; if you decline it, or do not answer, nothing is sent at all — not a reduced set, nothing. You can change your answer at any time from Main menu → Settings → Ad and privacy settings; a withdrawal takes effect immediately and discards the identifier described above. Whether a consent message is required for you at all is decided by Google’s consent system, from the message we publish for those regions — the same mechanism that already decides whether the advertising in Section 3(b) is personalised there. The App does not work out your location itself, and does not try to.

Everywhere else, it is on unless you turn it off. The switch at Main menu → Settings → Share usage statistics starts in the on position. Turning it off stops the collection immediately and completely, and also discards the identifier described above, so that switching it back on later starts a new one rather than resuming the old. Section 4 sets out the legal basis, which outside those regions is our legitimate interest in understanding how the game is played, with that opt-out always available.

What is collected, where it is active — every fact, in plain words

Every item below is one of a fixed list of words chosen in advance by the App, or a band. Nothing is free text, nothing is a precise time, nothing is recorded per move, and your score is never sent.

Your games

• that a game started, and through which of four doors: the main menu, the “Play again” button after a game, finishing the tutorial, or skipping it;
• that a game ended, with: roughly how many turns it lasted, as one of six bands (under 20, 20–49, 50–99, 100–199, 200–399, 400 or more); the rank band the game showed you at that moment (one of fourteen fixed values such as “top 30%” — an estimate from simulated games, not your score); which of the App’s named difficulty rungs you had reached; how many extra lives you had taken in that game (0, 1 or 2); and whether the game had given you its one “second chance”;
• that a second chance was used, and roughly how many turns into the game, in the same bands;
• that you reached a new difficulty rung, and which one — once per rung per game;
• that you set a new personal best, with the rank band at that moment — once per game, and never the score itself;
• that you finished today’s goal, once a day, and which of its three kinds it was: clearing lines, playing turns, or clearing on turns in a row;
• that you opened the daily gift Blocky holds on the main menu, at most once a day, and nothing else with it: not the gems it added, and never your gem balance;
• that the App awarded you an achievement medal, and which of its 50 medals it was, by a fixed name (for example the silver medal of “Line clearer”), once each. When one medal brings the lower medals of the same row with it, each of them is reported. Medals awarded all at once, the first time the App counts medals, for play already recorded on your device are not reported.
• that the App asked Google Play to show its rating card, and at which of two moments: a game that set a new personal best, or one that finished today’s goal (a game that did both counts as a new best). It is counted when the App asks, because Google Play does not tell the App whether the card appeared; whether you rated the App, and how, is never known to the App and never sent. At most four times per installation, at least 30 days apart.

How smoothly the game runs

• how smoothly the game drew, at most once each time the App is started (not each time you come back to it), and early: after about 15 seconds of moving pieces in the tutorial or a game, or when you leave the App if it had drawn enough by then. It carries the share of the App’s screen updates that took longer than 34 thousandths of a second, and the share that took longer than 50, each as one of four bands (under 5%, 5–24%, 25–49%, 50% or more), and whether most of them were drawn in the tutorial or in a game. It also carries three whole numbers about those same screen updates: the percentage that took longer than one refresh of a 60 Hz screen (about 17 thousandths of a second), and how long the typical update took and how long nine in ten of them took at most, each in whole thousandths of a second and never more than 999. It is worked out by the App from its own drawing: no count of updates, no date or time of day, and nothing about your phone’s hardware is read for it or sent (the device model Google records with every event is described below). On Android 6 and earlier, and on Android 12 and 12L, it is neither measured nor sent.

The tutorial and the rules

• that the “New here?” offer was shown, and how it was answered: play, skip, or closed;
• that the tutorial was opened, and from where: by itself, the first time the App is opened; that offer; “How to play” on the main menu; or “How to play” inside a game;
• that the tutorial ended, how (finished or skipped), at which of its five numbered steps, and, for that one step, how many times you started dragging and how many times you tapped, each as one of four bands (none, one, two, three or more);
• that “How to play” was opened, from the menu or from inside a game.

The four optional video offers

• that an offer was put on the screen — the extra life after a game, a board colour unlock, doubling a game’s gems after it, or gems for a video in the gallery;
• that you accepted an offer by pressing the button that names the video or carries its video mark;
• that the feature was handed over, and why: the video played through; the video could not be shown and the feature was given anyway; or no video was available and the feature was given anyway. For a board colour unlock, which colour it was;
• how each accepted offer ended, once per press, with which of the four offers it was and one of eleven fixed words: the video was watched; it was closed early; it could not be shown; no video arrived in time; another video was already playing; the App’s screen was closing; ads were no longer allowed; the press came while an earlier one was still waiting; no video player was available; the video’s end was never reported and the App recovered on its own; or the phone closed the App while the video was on its way or playing, recorded at the App’s next start;
• that you were offered an extra life and chose “Play again” instead, and how many extra lives you had already taken in that game.

Your settings

• that you changed a setting, which of three it was, and the new value: sound on or off, the language you chose from the App’s own list (or “follow the phone”), or the daily reminder on or off. Versions of the App before the light/dark theme was removed could also report that theme; this version does not;
• which board colour you selected from the gallery — one of the gallery’s names;
• that you bought a board colour with gems, once per colour, with: which colour it was (one of the names of the colours that can be bought); how it was unlocked, as one of four words (after the video was watched; the video could not be shown and it was unlocked anyway; no video could be offered; or the phone closed the App during the video and it was unlocked at the next start); how many colours you now own, from 1 to the number that can be bought; and roughly how many days after you earned your first gem, as one of five bands (under 7, 7–13, 14–27, 28–55, 56 or more). Either of the last two reads “unknown” when the App cannot work it out, for example when the phone’s clock was set back. Your gem balance and the gems you earn in a game are never sent.

The daily reminder

• how you answered Android’s notification question for the daily reminder: allowed, or not allowed (a refusal, or the question closed without an answer);
• that a reminder was posted, and which of the three daily goals it named. It is sent from the phone in the background, through the same switch and consent rules as everything else in this Section;
• that you opened the App from a reminder, and which goal it named.

Where your installation came from

• which link brought you to the App’s store page, once per installation, as three words from a fixed list: whether the link was in our torch app, Shake to Enable Torch, was a friend’s invite link (Section 3(f)), or was Google Play itself; the name of our one promotion; and which of the torch app’s four buttons it was, or “friend” for an invite link; and, for the torch app, a short code the torch app writes into its own link, naming which version of the torch app and which design of the promotion you saw (for example “1043_swipe”). Two more words are on the list: “google_ads”, when Google Play’s record of the link carries a Google Ads click identifier, and “meta”, when it carries the encrypted campaign block Meta adds to links from its adverts. Only the word is sent: the click identifier and Meta’s block themselves are never kept or sent. Any other link, and any code of a different shape, is recorded only as “other”, and a missing one as “none”. The link’s own text is never sent with this event, and neither is the code in a friend’s invite link. Google Play supplies this to the App once, after installation; the App keeps these words on your device until the statistics are permitted to be sent, sends them once, and never again. Google’s SDK records the same fact by itself (see below); this is the App’s own copy of it;
• with the same event, roughly how long after installation the App was first opened, as one of five bands (under a minute, 1 to 10 minutes, 10 to 60 minutes, 1 to 24 hours, a day or more), or “updated” when the App had been updated since it was installed. It is worked out on your device from the installation time Android keeps; the times themselves are never sent.

A few facts about the current state of your installation are kept alongside these events rather than sent with each one: the board colour in use, and where your installation came from (the same source, button and promotion code as above), so that we can tell whether people who arrive through the torch app keep playing.

Devices used for testing are left out: nothing is sent from Google’s automated test devices (Firebase Test Lab, which runs the pre-launch checks for Google Play), and nothing from our own development builds unless we are deliberately checking the statistics on that device.

Collected automatically by Google. Once the switch above is on, Google’s SDK also records, on its own: the first opening after installation; each opening; the start of a session and roughly how long it lasted; an App update; an operating-system update; that the App was removed, or its data cleared; a screen view each time the App’s single screen comes to the front; where Google Play tells the SDK that your installation came from a campaign link, that campaign’s name, source and medium; that an advert was shown, and that a rewarded video paid its reward, where Google’s advertising SDK reports those to the same system; and an approximate country or region derived by Google from the IP address. Google also records the device model, operating-system version, App version and language with each event.

What is deliberately not collected. No advertising identifier is used for this purpose — the App switches that off explicitly, and the advertising identifier described in Section 3(b) is used by the advertising SDK alone. No free text of any kind. No precise timestamps as data fields. No record of individual moves, placements or tilts: the tutorial’s two counts above are bands of how many drags and taps there were on one step, not what any of them did or where. No score, no saved game, no best score, no gem balance, no achievement totals. Nothing about your phone’s hardware (memory, processor, screen) is sent by the App; the device model Google records by itself is described above. No setting other than the four named above. No contacts, no location from the device, no account.

The identifier. Google’s app-instance identifier is random, scoped to this App on this device, and resettable: turning the switch off discards it, and clearing the App’s data or uninstalling removes it. It is not the Android advertising ID, and no advertising identifier is collected for this purpose; the link between our AdMob account and this analytics property, described in Section 5, carries advertising revenue totals into our reports and does not make these statistics available for personalising advertising.

One exception to “discards it”, stated for accuracy: if you switch the statistics off in a session where nothing had yet been sent, the analytics component was never started, so there is nothing for the App to reset — the identifier stays dormant on your device, unused for as long as the switch is off, and could be resumed if you switch the statistics back on; clearing the App’s data or uninstalling removes it in every case.

The provider. Google Analytics for Firebase (GA4), supplied by Google. The data is encrypted in transit by Google’s own TLS. Retention is described in Section 8, and the countries it may reach in Section 6.

3(e). What the App does NOT do

For the avoidance of doubt, the App contains no crash-reporting SDK, no social login and no in-app purchases. Its only attribution component is the Meta SDK described in Section 3(g), used for install and open events alone. Invite a friend (Section 3(f)) counts installs from a friend’s link with the App’s own code, not with Meta’s SDK. Apart from the Google advertising and consent components named in 3(b), the analytics component named in 3(d), the Meta component named in 3(g), the single static-file request described in 3(c), and the invite requests described in 3(f) (together with the integrity check that Google Play services makes for them), the App makes no network requests of any kind.

3(f). Invite a friend: a counter for the links you share

Your link. The App has an Invite a friend button. The first time you press it, the App creates a random 12-character invite code on your phone. The code is drawn at random and made from nothing about you or your phone. The App keeps it (Section 3(a)), puts it into a Google Play link to the App, and opens Android’s share sheet; you choose whether to share the link and with whom. Nothing is sent over the network when the code is created or when you share.

When someone installs from your link. Google Play hands the referral part of the link to the newly installed App once, as Section 3(d) describes. If it contains an invite code, that person’s copy of the App, once opened, sends that code to a database we control: Google Cloud Firestore, in our Firebase project “tilt-blocks”, stored in Google’s European Union multi-region (eur3). The database adds one to the counter for that code, up to 10, and stores the time of that request. That is the whole record: one entry per code that at least one friend has reported, holding a number from 1 to 10 and the time of the last friend counted. Nothing about the person who installed is stored by us: no name, no account, no device or advertising identifier, and the database keeps no IP address. Their copy sends the code once; if it cannot get through (no connection, for example), it tries again later, for at most 30 days. If the database refuses the report, that copy reads the counter once, by the same code, to tell a full counter (10 friends: the report is dropped) from a refusal that may pass (it tries again a day later). It sends nothing if the code is its own, as when a phone restores its own backup. The person who installed receives nothing for being counted and is asked nothing.

Your gems. While you have a code, your copy of the App reads your code’s counter from time to time: at most four times a day, only for 30 days after you last shared your link or were last paid for a friend, and never again once 10 friends have been paid. The request carries your code, and the answer is the number. For each friend counted that it has not paid yet, the App adds 1,000 gems on your phone, up to 10 friends per code. The gems themselves are kept only on your phone (Section 3(a)).

Who can see a counter. The database’s rules let a request read an entry only by its exact code, never list the codes it holds, change a count only by adding one, and never delete an entry; only we, from the Firebase console, can correct or delete one (Sections 8 and 9). The code is in the link you shared, so anyone you gave the link to could in principle read your counter: how many friends, and the time of the last one.

The integrity check. To keep the counter honest, each request to the database carries a short-lived token from Firebase App Check, a Google service that confirms the request comes from a genuine copy of the App installed from Google Play. To obtain that token, the App asks Google Play, through Google Play services on your phone, for an integrity check, and passes the result to Firebase App Check, which returns the token. The App keeps the token and reuses it until it expires (Section 3(a)). Google Play carries out the integrity check under the Google Play Terms of Service, not on our behalf. Google states that for each check it collects: the request’s own content (a one-time challenge), the App’s identity (package name, version and signing certificate), the App’s Google Play licence status for the Google accounts signed in on the phone, and device attestation information generated by Google Play services; that the data is used to verify the App, its licence and the device; and that it is deleted after a fixed retention period (Google’s description). We do not ask Google Play for its optional “environment details”. We never see the check or its result; the Firebase console shows us only totals of verified and unverified requests. The two requests to Firebase App Check that obtain the token also name the App by its package name and the fingerprint of its signing certificate, which are the same for every copy of the App; the requests to the database carry only the code and, when the App has one, the token. Google, which runs these services, sees the IP address each request comes from. If the check fails, the request goes out without a token and may be refused; nothing is shown and play is not affected.

Not tied to your consent choices. All of this happens whether or not you have given advertising consent (Section 7) and whether or not usage statistics are switched on, because it is neither advertising nor statistics. The App never puts an invite code into an ad request or into its own usage-statistics events. If you never press Invite a friend, the App creates no code and reads no counter; if you installed from a friend’s link and do not want to be counted, Section 9 says how to object.

3(g). Measuring our own advertising (Meta App Events)

Why this exists, plainly. We may pay for small advertising campaigns on Meta’s services (Facebook, Instagram, and Meta’s ad network in other apps) to find new players. Meta can only tell us whether such an advert led to an installation, and can only show the advert to people likely to install, if the App tells Meta that it was installed and opened. For that, the App contains Meta’s App Events SDK (the “Facebook SDK for Android”, core component only: no Facebook login, no sharing, no Meta advertising inside the App).

Where this is active, and where nothing is sent at all.

• In the EEA, the UK and Switzerland, never. The consent message described in Section 7 is Google’s, and we have not found a way for your answer to it to cover Meta, so in these regions the Meta component is never started, whatever you answer. Nothing is sent to Meta.
• Where a US state privacy message applies to you (the row at Main menu → Settings reads “Ad and privacy settings” rather than “Share usage statistics”), also never, for the same reason: that message is Google’s, and you would have no switch in the App to stop Meta.
• Everywhere else, it follows the usage statistics switch. The switch at Main menu → Settings → Share usage statistics (Section 3(d)) also controls this. While it is on, the component starts once the App has checked with Google’s consent component that no consent message applies to you. Turning it off stops the App’s collection of the advertising identifier at once and stops the open events no later than the next time the App starts (Meta’s SDK still sends one last note that its settings changed, which carries no advertising identifier); while it is off, the Meta component is never started at all.
• Never from Google’s automated test devices, and never from our development builds unless we are deliberately checking it on that device.

What is sent, where it is active. The App itself logs nothing to Meta: no game event, no score, no setting, no screen. Meta’s SDK, once started, sends by itself:

• that the App was installed (once per installation) and that it was opened and closed, with how long a session lasted, how many times it was interrupted, and roughly how long it had been since the last one;
• the Android advertising identifier and whether you have limited ad tracking, and a random identifier the SDK generates for this installation;
• the Google Play link that brought the installation, as Google Play reports it, only when that link contains the letters “fb” or the word “facebook”, as the links in Meta’s adverts do (this is how Meta recognises an installation that came from one of its adverts). Meta’s SDK asks Google Play for the link once, keeps it on your device, and sends it whole with the installation record and with each later batch of events; a link without those letters is not sent. A friend’s invite link (Section 3(f)) never contains them, so neither it nor its code reaches Meta, with one exception: a code made by a version of the App from before the Meta component was added may contain “fb” (about 1 code in 93), and a friend’s installation from that link sends it to Meta with the rest of the link. A link from anyone else’s advert, such as a Google Ads link, is sent whole, any click identifier included, if its text happens to contain those letters;
• technical facts about the device, as Meta’s SDK collects them: the App’s package name and version, which app store installed it, the Android version, the device model, the language and region setting, the time zone, the name of the mobile network, the screen size and density, the number of processor cores and the device’s total and free storage;
• if Meta’s SDK itself fails, a report of that failure, where Meta has switched such reports on.

Meta, like any server, also sees the IP address the data comes from.

The recipient. Meta Platforms Ireland Limited (Block J, Serpentine Avenue, Dublin 4, Ireland), which Meta’s Business Tools Terms name as the Meta company where the business using them is subject to the GDPR, as we are, being based in Italy. Meta processes this data for measuring and delivering advertising, and for its own purposes as described in its privacy policy: https://www.facebook.com/privacy/policy. We do not receive this data ourselves; we see only Meta’s totals, such as how many installations a campaign led to.

4. Why we process data, and the legal basis for each purpose (GDPR)

Where the EU/UK GDPR applies to you:

If you refuse consent, the game plays in full. The extra life, the doubling of a game’s gems and the gallery’s gem video are offered only when a video can be shown, so where no ad can be requested none of them appears (the doubling’s and the gem video’s buttons show greyed only while their video is loading); a board skin you have the gems for unlocks without a video.

5. Who receives data (third parties / recipients)

• Google Ireland Limited / Google LLC — as the provider of Google AdMob and the Google User Messaging Platform (the consent tool). Google’s own privacy policy: https://policies.google.com/privacy. How Google uses data from apps that use its services: https://policies.google.com/technologies/partner-sites.
• Google Ireland Limited / Google LLC again, in a separate role — the same two companies, operating Google Analytics for Firebase, which receives the usage statistics described in Section 3(d) where they are switched on. We decide what is collected there and why; Google acts as our analytics provider, and processes the data additionally for its own purposes as described in the policies linked above. Our AdMob account and this analytics property are linked, which is what lets the advertising revenue totals Google already holds appear in our analytics reports, as a total earned from a coarse group of players, never from any one of them. That link runs in one direction only: the usage statistics are not used to personalise advertising — the setting that would allow it is switched off for every region, and Google signals, the feature that would associate this data with a signed-in Google account, is off — and the analytics component collects no advertising identifier, so the identifier described in Section 3(b) remains the advertising SDK’s alone. The consent rules in Section 7 are unchanged by the link: in the EEA, the UK and Switzerland nothing is sent for this purpose unless you consent to it in the consent message, and everywhere else the switch described in Section 3(d) decides.
• Google Ireland Limited / Google LLC a third time, as our processor for Cloud Firestore, which holds the invite counter, and Firebase App Check, which issues the tokens described in Section 3(f). Both are governed by the Google Cloud Platform Terms of Service and its Cloud Data Processing Addendum (https://firebase.google.com/terms), under which Google processes this data on our instructions.
• Google Play (Google Ireland Limited / Google LLC), for the integrity check described in Section 3(f). Google Play makes that check under the Google Play Terms of Service and on its own account, not as our processor; what it collects is set out in Section 3(f) and in https://developer.android.com/google/play/integrity/terms#data-safety.
• Meta Platforms Ireland Limited — only outside the EEA, the UK and Switzerland, only where no US state privacy message applies, and only while the switch in Section 3(d) is on: the install and open events described in Section 3(g). Meta’s privacy policy: https://www.facebook.com/privacy/policy.
• Google’s advertising partners, where you consent to personalized ads. The current list of partners is presented to you inside the consent message and can be reviewed there at any time.
• GitHub, Inc. — only as the host of the one static text file described in Section 3(c). It receives the IP address that request is made from, and nothing else. GitHub's privacy statement: https://docs.github.com/en/site-policy/privacy-policies/github-general-privacy-statement.

The Developer discloses your data to no one else. We do not sell data — see Section 9.

6. International data transfers

The Developer stores one thing itself, the invite counter described in Section 3(f), and it is kept in Google Cloud Firestore in Google’s European Union multi-region (eur3); we do not move it anywhere else. Apart from that counter, the Developer neither receives nor stores any of this data, and so transfers none of it. That is not the same as saying nothing leaves your device: the App is designed to cause requests to the recipients named in Section 5, and those recipients may process what they receive outside Switzerland, the EEA and the UK.

For the invite requests in Section 3(f), Google may handle the requests themselves (for example the IP address they come from) and the Firebase App Check tokens wherever it operates, including in the United States, under the Cloud Data Processing Addendum and the safeguards Google states below. Google Play’s integrity check is made by Google Play under its own terms, and Google may process it in the same places.

The static file described in Section 3(c) is served by GitHub, Inc., a company based in the United States, so the IP address that request is made from is received there.

The usage statistics described in Section 3(d) are sent to Google Analytics for Firebase, and Google may process and store them outside Switzerland, the EEA and the UK, including in the United States, under the same safeguards Google states below. In the EEA, the UK and Switzerland this happens only where you have consented under Section 3(d); otherwise nothing is sent for that purpose, so there is nothing to transfer.

The install and open events described in Section 3(g) are sent to Meta Platforms Ireland Limited, which may share them with Meta Platforms, Inc. in the United States. They are never sent from the EEA, the UK or Switzerland, so no transfer from those regions takes place.

Google, as an independent controller for advertising data, may transfer that data outside Switzerland, the EEA and the UK, including to the United States. Google states that it relies on the European Commission’s Standard Contractual Clauses and, for transfers to the US, on the EU-US Data Privacy Framework, its UK Extension and the Swiss-US Data Privacy Framework, where applicable. Details are in Google’s own privacy documentation linked in Section 5.

If you are in Switzerland. Swiss data protection law (the Federal Act on Data Protection, FADP) asks us to name the countries your data is sent to and the safeguard for each. From Switzerland, the data described in this policy may go to:

• Ireland, and other countries of the EU and the EEA, where Google Ireland Limited is the Google company responsible for users in Switzerland. The Swiss Federal Council recognises these countries as providing an adequate level of data protection (Annex 1 of the Swiss Data Protection Ordinance).
• The United States, where Google LLC and GitHub, Inc. are based. Both companies are certified under the Swiss-U.S. Data Privacy Framework, and since 15 September 2024 the Federal Council recognises the United States as providing an adequate level of protection for certified companies (Annex 1 of the Swiss Data Protection Ordinance).
• Other countries where Google or its partners operate. Google lists its data centre locations at https://datacenters.google/locations/, and the advertising partners are listed in the consent message described in Section 7. Where no adequacy decision covers a transfer, we and Google rely on standard contractual clauses, which the Swiss Federal Data Protection and Information Commissioner (FDPIC) recognises under Art. 16(2)(d) FADP.

7. Consent and how to change or withdraw it

In the EEA, the UK, and Switzerland

Before the App requests any ad, it shows a consent message provided through the Google User Messaging Platform. No ad is requested until you have answered it.

You can change or withdraw your choice at any time:

That row appears in the App only where a standing consent entry point is required, which is exactly the region where you have the right to withdraw. Opening it reloads the same consent message so you can change any choice, including withdrawing consent entirely.

The same consent message governs the usage statistics in Section 3(d): it carries a purpose for them, nothing in Section 3(d) is collected in these regions until you consent to that purpose, and withdrawing it here stops the collection at once. Outside these regions, the control is the switch at Main menu → Settings → Share usage statistics, which appears only where no consent message is required, and which also controls the Meta measurement in Section 3(g). That measurement is never active in these regions, whatever you answer. The App asks Google’s consent component whether a message is required at every start, including when advertising is switched off remotely (Section 3(c)); outside these regions that check shows nothing.

Not covered by these choices: Invite a friend

The invite requests described in Section 3(f) are not advertising or statistics, so neither the consent message nor the usage statistics switch turns them on or off. Section 4 gives their legal basis, and Section 9 says how to object or have an entry deleted.

Everywhere — controlling your Advertising ID at the Android level

Independently of the App, Android lets you control the advertising identifier:

There you can delete or reset your Advertising ID, and on Android 12 and later you can remove it entirely, after which apps receive a string of zeroes instead.

Children

See Section 10. The App is not directed to children.

8. Data retention — how long data is kept

• On-device data (Section 3(a)): kept on your phone until you delete it, by clearing the App’s storage or uninstalling the App. If backup is switched on in your phone’s settings, Android may also keep a copy in your Google account, as Section 3(a) describes; that copy is governed by Google, not by us, and Android can put it back when you reinstall the App or move to a new phone. Apart from an invite code that names an entry in the invite counter (below), we have no copy and therefore no retention period of our own.
• Advertising data (Section 3(b)): retained by Google according to Google’s own retention schedules, which are described in Google’s privacy documentation. The Developer holds none of it and cannot delete it on your behalf; requests concerning it should be directed to Google, and we will help where we can.
• The static-file request (Section 3(c)): whatever server log GitHub keeps is subject to GitHub's own retention schedule. We receive no such log and hold nothing from it.
• Measurement of our advertising on Meta (Section 3(g)): retained by Meta according to Meta’s own retention practices, described in its privacy policy. We hold none of it and cannot delete it on your behalf. The random identifier Meta’s SDK generates is removed from your device when you clear the App’s data or uninstall.
• Usage statistics (Section 3(d)): event-level data is kept by Google for 2 months — the shortest period Google offers, and the value a new property carries by default. It is a setting in the Google Analytics console, applied to the whole property, and if we ever lengthen it this policy will say so before we do. The random app-instance identifier is discarded when you turn the switch off, when you clear the App’s data, or when you uninstall.
• The invite counter (Section 3(f)): each entry is kept while the Invite a friend feature exists, and the whole counter is deleted when the feature ends. An entry is deleted earlier when you ask and send us its code (Section 9). There is no automatic expiry. The integrity check is kept by Google Play for its own fixed retention period, as Section 3(f) describes.

9. Your privacy rights

If you are in the EEA or the UK (GDPR / UK GDPR)

You have the right to access, rectify, erase, restrict, and object to processing of your personal data, the right to data portability, and the right to withdraw consent at any time without affecting the lawfulness of processing before withdrawal.

Practically:

• For the on-device data, you can exercise all of these yourself, instantly, by clearing the App’s data or uninstalling it. We cannot access it, so we cannot act on it for you.
• For the advertising data, the controller in practice is Google. Requests should be addressed to Google using the contacts in Google’s privacy policy. Write to luxebytecomp@gmail.com as well and we will do what we can to assist and to point you to the right place.
• For the invite counter (Section 3(f)), we are the controller and we act ourselves. Send us the code to luxebytecomp@gmail.com: your own code is in the link you shared, and if you installed from a friend’s link, it is that friend’s code. We will tell you what the entry holds, delete it (erasure), or, if you installed from that link and object to being counted, take your count off it. The code is random and nothing in the counter links it to you, so we cannot find an entry for you without it, and we keep no other information to identify you (Art. 11 GDPR). If you cannot give the code, write anyway and we will explain what we can and cannot do.

You also have the right to lodge a complaint with a supervisory authority in your country of residence, place of work, or place of the alleged infringement.

If you are in Switzerland (Swiss Federal Act on Data Protection, FADP)

You have the same choices described above, and the FADP gives you these rights:

• to ask whether personal data about you is processed, and to receive the information the FADP lists, free of charge and in general within 30 days (Art. 25 FADP);
• to receive data you gave us, in a common electronic format (Art. 28 FADP);
• to have inaccurate data corrected, and to object to processing or ask for it to stop or for the data to be deleted (Art. 32 FADP);
• to withdraw your consent at any time from Main menu → Settings → Ad and privacy settings in the App.

Apart from the invite counter, which we handle ourselves as described above when you send us its code, we hold none of this data on any server, so for most requests we will tell you that, and help you take the request to Google, which holds it. Write to luxebytecomp@gmail.com.

You can also report a concern to the Swiss Federal Data Protection and Information Commissioner (FDPIC), Feldeggweg 1, 3003 Bern, Switzerland, https://www.edoeb.admin.ch.

The App makes no decision about you based solely on automated processing that has a legal consequence for you or a considerable adverse effect on you.

If you are in California (CCPA/CPRA) or another US state with a privacy law

We do not sell your personal information. The only data we keep ourselves is the invite counter in Section 3(f), and it is not sold or shared.

We do not claim that no “sharing” takes place. Showing a personalized ad means advertising data is made available to Google and its partners for cross-context behavioural advertising, and that is capable of being “sharing” as the CCPA and CPRA define it, whether or not the Developer ever holds the data. Rather than argue that point, the App gives you the opt-out:

• Meta (Section 3(g)): sending the advertising identifier and install events to Meta, which uses them for advertising, is capable of being “sharing” too. It never happens where a US state privacy message applies to you, and elsewhere the Share usage statistics switch in Main menu → Settings turns it off.
• In the App: Main menu → Settings → Ad and privacy settings, which opens a US state privacy message where you can opt out of that use. As in the EEA, the row appears where such a message applies to you.
• On the device: the Android Advertising ID controls described in Section 7, which apply wherever you are.

You may also request access to, or deletion of, personal information we hold about you. Apart from an entry in the invite counter, which we can find only from its code (see above), we hold none, and we will tell you so.

10. Children’s privacy

The App is not directed to children and its Play Store target audience is declared accordingly. We do not knowingly collect personal data from children.

We are aware that a colourful puzzle game can attract younger players. If you believe a child has used the App in a way that resulted in personal data being processed, contact luxebytecomp@gmail.com and we will help you direct the request to Google, who holds the data, or, for an entry in the invite counter (Section 3(f)), delete it ourselves once you send us its code.

If the App’s declared target audience ever changes to include children, the advertising configuration will change with it — child-directed treatment will be signalled to the ads SDK and the advertising identifier permission will be removed — and this policy will be updated before that release ships.

11. Security

The App stores its data using Android’s standard app-private storage, which the operating system isolates from other apps. We hold no servers and no accounts. Our one database is the invite counter in Section 3(f), in Google Cloud Firestore, which Google encrypts in transit and at rest. Its rules let a request read an entry only by its exact code, never list the entries, only add one to a count, up to 10, and never delete. It holds random codes, numbers and times, so a breach of it would expose nothing that names anyone.

No method of electronic storage or transmission is completely secure, and we cannot guarantee absolute security of data handled by third parties such as Google.

12. Changes to this policy and how you are notified

Material changes are published at the same address as this document, with an updated “Last updated” date, before or when they take effect. Where a change concerns advertising consent you may be asked again through the in-app consent message.

13. How to contact us about privacy

luxebytecomp@gmail.com

Write to us with any question, any request, or to tell us this policy is wrong about something. We would rather fix it than defend it.