Privacy

In short

• There are no third-party ads, and nothing to buy. The one card that plays in the Tower advertises this game and loads nothing from anyone.
• The game counts how it's played — which modes, how long, how a run went — under a random id, not your name.
• Your scores and settings stay in your browser unless you sign in, and your replays never leave it.
• When the game hits a bug it sends a crash report to Sentry — the error, the stack and what the page did just before it, never your name, your email address or your IP address. A visit that goes well sends none.
• Signing in is optional. It keeps your record on every device you play on and gives you a username, which is the only name the Daily leaderboard shows: putting a Daily time on the board needs an account with one. Clerk runs the sign-in, and this game's server never gets your email address.
• To have your data deleted: clear this site's data in your browser, press DELETE ACCOUNT on the Account screen if you signed in, or write to the address in "Asking for it to be deleted" below.

The rest of this page is the full detail. Everything in it was read off the code that's running, not off a plan for it, and checked on 19 October 2026 — the lists of events, stored keys and caps by a test that reads them out of the code on every run, so they can't quietly go stale, and the rest by hand and in a real browser. The browser found one thing reading the code couldn't: the company that serves this site puts an analytics script on every page here, and nothing in this project asks it to (see "Who else sees a request"). And the sign-in form sets cookies, which nothing else on this site does. Nothing on this site sets a cookie since 17 October 2026 — that form is gone, and "If you sign in" has the measurement and what a browser carrying the old ones should expect. "If you are in California" says what all of it comes to under that state's law.

Where the game is about to change, the last section says so rather than describing something that isn't built.

What the game keeps in your browser

The game stores its own state under your browser's localStorage for dicelockgame.com. If that is not writable (Safari's private browsing revokes it), the game falls back to sessionStorage for the tab and says so in the console; if neither works, the game is still playable and simply forgets everything when you leave.

In the iPhone app and the Android app the first two rows below are kept in the platform's own preference store instead — UserDefaults and SharedPreferences, inside the app and readable by nothing else — because a web view's storage is the part the system is free to clear, and losing those two would cost you your scores and make you a new visitor. Everything else in the table is the web view's localStorage, as it is in a browser.

Clearing site data for dicelockgame.com in your browser removes every one of these, and signing out removes everything but the visitor id and the queued play events, which are this device's rather than your account's. Nothing is restored from the server unless you are signed in: for a guest, a cleared browser is a new player. If you are signed in, the slice of the list above named under "If you sign in" — and only that slice — is read back out of your account.

What the game sends to its server

Sixteen events, each one a short object of numbers and fixed words — except for one field on the last of them, which is the only place in the game a sentence can reach the server, and it is described below rather than buried.

• session_start — the page was loaded, and five words about it: whether this is a phone, a tablet, a desktop or unknown; which site it was opened from (jiolab, dicelock, or dev for anywhere else); whether the page was inside a frame on another site (none if it was the page in your address bar, portal if it was framed by one of this game's own sites, other if it was framed by anybody else, unknown if your browser would not say whose frame it was, ios if you were playing in the iPhone app, android if you were playing in the Android app — the address of the page framing it is never recorded, only which of those six it was); whether the game is running as an installed app or in a browser tab; and whether the window is portrait or landscape. The size of your window is never recorded — only which way up it is. The first word is derived from the pointer and the window size; the browser's user-agent string is never read for any of them. It also carries your settings, listed below.
• game_start — a run began, in which mode, and for a puzzle which board. On the first run of a visit it also carries how many milliseconds passed between the page loading and that run starting, and whether you had opened Help or the Tutorial first. In a shared match against a friend it also carries that match's id, described below.
• game_end — that run ended, how, and how many milliseconds it lasted; which flavour of the mode it was (the Endless speed, the computer opponent's difficulty, or the puzzle's level — a shared match has none of those and sends the match clock instead), and a bundle of counters from the run: how many matches of each size and face you made, how deep your chains went, what your score was made of and what it was at every 30 seconds, which abilities came up and which you used, how many times you paused and for how long, and how many inputs arrived by keyboard, touch and gamepad. Every one of those is a whole number. A run interrupted by the tab being hidden or the page closing sends this too, marked abandoned, with the counters it had so far — and if you come back and finish the game, it is sent again and the second one replaces the first.
• puzzle_attempt — an attempt at a puzzle ended without the board clearing.
• puzzle_solved — the board cleared, on which attempt, and for the Daily the time the clock stopped at.
• tutorial_step and tutorial_end — this version of the game sends neither. They belonged to the old step-by-step tutorial, which has been removed: tutorial_step said which step was finished and how long it took, and tutorial_end how the tutorial ended and the last step reached. The server still accepts them from an older copy of the game that has not updated yet.
• settings_changed — one setting changed: which one, and its value before and after, in the same fixed words as the snapshot below.
• replay_viewed — you opened one of your own recorded runs on the History screen. Which run it was is not sent: the recordings never leave your browser.
• daily_posted — a Daily time was accepted by the leaderboard.
• nickname_set — no longer sent. It said you chose a name for the leaderboard, back when a guest could post under one; a copy of the game loaded before 29 September 2026 may still send it, and it carries nothing but the fields every event has.
• tower_step_clear — you cleared a step of the Tower: which floor and which step, how many stars it graded, how much clear space was left above your dice, what the step was worth in total, and which attempt it was. It carries no time and no board.
• tower_guardian_clear — you beat a floor's Guardian: which floor, and which attempt it was.
• tower_floor_reward — a floor was finished and handed over its rank. Which floor, and which rank word — apprentice, keyholder and so on. This one is about the floor rather than about a run, so it is the one Tower event that is not tied to a game.
• achievement_earned — the game gave you an achievement: which one, by its id (basics-complete, battle-ready). Like tower_floor_reward it is about you rather than about a run, so it is not tied to a game. If you finished the tutorial before achievements existed, the game works that out the next time you load it and sends this then — so the date on it is the day you came back, not the day you finished the lesson.
• first_visit_choice — you answered the sheet the game shows once, on your very first visit: which of its four lines you pressed — take the tutorial, read the rules, just play, or sign in — or that you closed it. Nothing about you is on it.
• account_screen_open — you opened the Account screen, and which way in you used: the name chip on the main menu, that first-visit sheet, the card on Settings, or the SIGN IN on the sheet a solved Daily raises when you are not signed in. It is here so the game can tell whether anybody finds the screen, and it is sent whether or not you are signed in.
• account_linked — a sign-in finished. This event has no fields at all: not who you are, not which provider you used, not your email. It says that somebody signed in, on this browser, at this moment, and that is the whole of it.
• power_up_drawn — a Tower floor dealt you one of its twelve power-ups: which floor, and which power-up by its id (slow-rise, charged). The draw is free and you never choose it, so this says which gift a floor handed out and nothing about what you then did with it.
• power_up_redrawn — you pressed REDRAW on that card and took a different power-up: which floor, the one you now hold, and the one you handed back. Both ids are on it because the one you gave up is the only thing that says a gift was not worth keeping, which is what the numbers behind those twelve are tuned from.
• power_up_stacked — you pressed STACK on that card and kept what you held with one more added: which floor, the power-ups you already held, and the one that was added. It is here so the game can tell whether the ad is spent on STACK or on REDRAW.
• ad_shown — the placeholder advertisement played, and how it ended: completed if it ran out, skipped if you pressed SKIP, or shared if you opened the share flow on it. The floor and the power-up it was played over ride with it. Nothing is sent about what the card said, how long it took, or whether anything was fetched for it — there is no advertiser and no network behind it; the card advertises this game.
• client_error — the game hit a bug in your browser. This is the one event carrying text rather than fixed words: the error's own message, and the single top line of its stack trace saying which file and line it came from. These are written by the game's code and by your browser, not typed by you. At most ten of them are sent per visit, each is cut to a single line of at most 200 and 300 characters, and the rest of a run of errors is counted and discarded. It is here so a bug that only happens on real devices can be found at all. Since 19 October 2026 the same error is also sent to Sentry, in more detail and through this site's own address — the section "Who else sees a request" says what that is and what goes in it.

A shared match against a friend sends these two events as well, in a mode of its own — pvp, never filed under Vs Computer. It sends the same counters any other game does, and it carries the match id the server minted for that match: a random id belonging to the match and not to either player, already stored on the server's record of it. What that id lets us ask is "what happened in this game", with both boards in one answer — which is the whole reason the mode is counted apart from the games against the computer. It says nothing about who you played: the other player's name is not something the game has, their visitor id is not on your events, and a shared match is never given the name of a computer opponent it did not have.

A shared match is still not stored on your device. The record of one lives on the server, which is where the History screen reads it from; the recordings your browser keeps and can replay are your own games only.

The settings sent with a page load are the seventeen that say how the game should behave: the theme, whether sound is muted, the volume to the nearest ten percent, whether the phone's haptics are on, whether a double tap rerolls a die, whether a drag swaps or slides a die, reduced motion, each of the five marks the board can put on a die (the corner numeral, the risk strip, the cursor's risk frame, the risk named in words, and the mark left where a move was refused), whether the first-visit prompt has been shown, whether the opponent's window is shown on a phone, the Endless speed, the Vs Computer opponent and the match clock. Each is one of a handful of fixed words, and what they are for is questions like "does anybody turn the opponent's window off" and "does anybody switch the die numerals on".

What you have done is not a setting, and no event carries any of it. Your high scores, which puzzles and Dailies you have solved, how far through the tutorial you are and which achievements you have earned, are in the same stored blob as the settings above and are left out of that snapshot on purpose. It is sent as your profile, when and only when you are signed in — that is the whole of what an account is for, it is the list under "The account routes" below, and a browser that has never signed in never sends it anywhere.

Every one of them also carries the schema version, the visitor id above, a session id minted fresh for the page load and never stored, a random id for the event itself, a random id for the run it belongs to, the timestamp, and a small number saying whether the page looks automated — the browser reporting navigator.webdriver, reporting no pointing device at all, or clearing a board faster than the animation allows. That last set is there so that a script hammering the game can be left out of the counts rather than counted as players.

The Daily leaderboard shows one name: your username. Putting a time on it needs an account with a username — a guest who solves the Daily is offered SIGN IN instead, and nothing is posted. A post carries the date, the device id, your time and your account id; the name on the row is the username on that account, read by the server, and nothing you type goes up with the post. Your streak follows you to a new device, and your email address never goes up, because this server never had it.

A posted time and this browser's play events share one id. Until 16 September 2026 they deliberately did not, so that a name on the leaderboard could not be joined to the events that browser sent. That changed on purpose: the two ids became one so that a question like "do the people who post Daily times play differently" can be answered at all. What it means in practice is that if you post a time, your username sits beside a random id which is also on the play events listed above. If you would rather it did not, do not post a time — the game is fully playable without ever touching the leaderboard, and a browser that has never posted has no name attached to anything.

The server refuses anything outside that list. A field it does not recognise is an error and not a column stored "just in case", and a rejected event is reported back to the page rather than quietly repaired.

That includes the counters. They are sent as one nested object, and it would have been easy to let it carry whatever the game felt like putting in it — which is exactly the free-text field the rest of this page promises does not exist. So every name inside it is listed in the code that checks it, every value has to be a whole number inside a stated range, and a name the list does not have is refused like any other. There is no key you or the game could invent, which is what makes the promise above checkable rather than a matter of trust.

The account routes, which nothing but signing in touches

Seven more requests exist, and none of them is an event. Six of them carry the game's own session token, so a browser that has never signed in never makes them at all; the seventh is a question with nothing about you in it, asked when you press SIGN IN. Who Clerk is and what it sees is the next section but one; this is what reaches this server.

• Starting a sign-in, when you press one of the three doors and not before. For Continue with Google or Continue with Apple your browser asks this server where the provider's page is, and is sent there; for the email door it sends the address you typed, which this server passes to the sign-in service in one call and keeps nowhere (the next section but one). Nothing about you is read off this browser for it — not your ids, not a token — and it is the one of these seven a signed-out browser makes. (Until 17 October 2026 this request instead asked which company's script to load; no script is loaded now.)
• The session exchange, once, when the provider or the emailed code has said who you are. Your browser sends back what it was handed — a one-time code from the provider, or the six digits from your inbox — and this server trades it with Clerk for a sign-in token, checks the signature against Clerk's published keys and reads exactly one thing out of it, the random user id it carries; the token itself is thrown away and never stored. Beside that id it writes a fingerprint of a fresh random token of its own, which is what your browser carries from then on — the token is never written down either, so what is in the database can verify your browser and cannot pretend to be it. There is no email address and no name in any of it. Signing out deletes that row.
• The visitor link, once, immediately after. Your browser tells the account which visitor id it has been sending play events under, and the two are written down together — so the events this browser already sent are counted as yours rather than as a stranger's. Nothing new about you is recorded by it. A visitor id already attached to somebody else's account is refused rather than moved, and your browser mints itself a fresh one instead.
• The username, when you choose one and each time you change it. This is the one thing in this game you can type that reaches a server, and the only name another player is ever shown: it's the handle friends find you by, and the name on the Daily leaderboard. (The die you pick beside it, in the profile below, is the one other thing another player sees of you — a face and a colour, and nothing you typed.) You type it; it is never read from your sign-in. Nothing about it comes from Clerk, and choosing one is not choosing to be called by your name — a handle is exactly as much about you as you decide to make it, and 3 to 20 characters is the whole of what the rule says. It has to be unique, so a name somebody else already has is refused and you are told nothing about who has it. Deleting your account deletes it and frees the name. A browser that never signs in never has one.
• The profile, on every page load and about two seconds after a settings change. This is the one request that carries what you have done, it goes nowhere but this game's own server, and it is exactly these keys:

• The climb, on every page load and after a Tower result, and only if you have played the Tower. It is a request of its own rather than part of the profile above, because the two are kept differently: a profile is replaced by whichever of your devices wrote last, and a climb is only ever added to. Everything both sides know is merged and the merged record is what comes back, so a step you cleared on your phone and a Guardian you beat on your laptop cannot take each other away, whichever device syncs next. What it carries is tower — which steps and Guardians you have beaten, the best score, star grade and fastest clear on each, the highest floor you have crowned, the worlds it paid out, and how many times you have restarted the climb. Restart the Tower, in Settings, is the one thing in this game that takes something out of a record rather than putting it in: it clears every step and Guardian from this device and, next time each of your other devices syncs, from those too. The floor you have crowned, your rank, your worlds and your place on the Tower leaderboard are not touched by it. A browser that has never played the Tower never sends it.
• What your account has been given, when you sign in and each time you come back to the game after leaving it. This one sends nothing about you — it is a question, not an upload — and what comes back is a list of the things your account holds. Today that list is always empty: this version of the game is free, sells nothing and has no way to buy anything, and the list exists so that the version which does can be built without moving your record around. Your browser keeps a copy of the answer, so the game can tell what you hold while you are offline; signing out deletes that copy. No price, no receipt and no payment detail is sent to this server or stored by it, and the row this server does keep is your account's random id and the name of the thing — never a card, never an address, never an email.

Five things are left out because they are about one browser or one moment, and the server drops them even if a browser sends them. helpSeen, gamepadSeen and keyboardSeen are facts about one browser rather than about you — a laptop that has never had a gamepad plugged into it must not grow a page of gamepad buttons because your desktop has, and a phone must not grow a page of keys because your laptop pressed one. A Daily clock that is still running and the result of a Daily post belong to the browser that was playing. Your match history and your replays are not in it at all and never leave your device.

A fifth is dropped for the opposite reason. The copy your browser keeps of what your account has been given — the one in dicelock.settings.v1 above — is sent along with the rest of that blob and thrown away unread, because that list is this server's own answer and a browser is never allowed to tell it what you hold. Nothing else in the storage table above is uploaded.

When you play somebody else

Creating a room, or entering the code a friend read out to you, is the only part of this game that is not just you and a server. There is another player, and the server sits between you as a referee — so a little more is written down than a game against the computer writes, and this is the whole of it.

The link is a row, and it holds both ids. Creating one records the link's own random slug, the visitor id of the browser that made it and the match clock it was made with; opening it writes your visitor id into the empty seat. That row is the record of who played, and it is what the head-to-head below is counted from.

What makes the seat yours is a key, not your id, since 17 October 2026. Taking a seat — creating the room, typing the code, or opening the link — gets your browser a random key from this server, kept under dicelock.lobby.seatKeys.v1 above. That row is what makes the seat yours. The key is how the game gives you your seat back if your connection drops and you return inside ten seconds, or if the page reloads, instead of handing it to whoever arrives next. Your visitor id will not do it any more: it names you, it does not admit you, and a browser that has lost the key for a table is told that seat is not its own.

Each game played at that link is a row of its own — the two ids, when it started, when it ended, who won, and whether the other player left rather than lost. The head-to-head record you see at the end of a match is counted from those rows and from nothing else.

Your board crosses the server and is not written down. While the match runs, each page sends the other a picture of its own board fifteen times a second, and a number when an attack lands. The server passes them to the other player and keeps none of it: nothing about how you played a shared match reaches the database except the result above.

The other player's browser is handed nothing that names you, since 17 October 2026. Both screens show the running score between the two of you, and that count arrives keyed by the ids in it, so each page can tell which side is its own. Both screens still show that score, and each page is now told its own side of it by the server; what a page learns about the other player is which end of the table they are sitting at. Until that date the count arrived keyed by the two visitor ids — and that is also the id this browser posts a Daily time under, which made it more than a scoreboard needs. Giving the seat a chosen name instead is decided and not yet built; the last section of this page is where that is written down.

If you sign in

Signing in is optional, and nothing on the way to a board asks for it — it's one ACCOUNT card in Settings. What you get is your own record on every device you play on — your scores, puzzles, Tower climb and settings follow you — and a username that's yours when you play friends. What it carries is the profile listed above, and nothing else. This section is what changes about this page when you use one.

Clerk holds the sign-in, and it is Clerk that sees your email address. Clerk is Clerk, Inc., an American company whose business is signing people in to other people's sites. The screen you sign in on is this game's own, on every platform since 17 October 2026 — nothing of Clerk's is drawn and none of Clerk's code runs in your browser — but what you type there goes to Clerk: your email address, and your IP address as seen from this server, are processed on Clerk's own servers, under Clerk's own privacy policy, which is the link above and not this page. Continue with Google or Continue with Apple sends you to that company's own page and back; what Clerk and that company see of each other is theirs. Nothing in this game can promise anything about what happens there. (Until 17 October 2026 your browser loaded Clerk's script and the form was theirs; your name, if you gave one, went with it. The game asks for no name now.)

What this game's server gets back is a random id and no more. Clerk signs a short-lived token; this server checks the signature and reads one thing out of it, an id like user_3JVT… that means nothing outside Clerk. Your email address and your name are never sent to this server and are nowhere in its database. Where the Account screen greets you by name, that name was read out of Clerk's script in your own browser and drawn on the screen — it does not travel. The username on your account is not an exception to that, and the difference is worth being exact about: it is a handle you typed into this game, for other players, and no part of it is read from Clerk or from anything Clerk knows about you.

Your visitor id is attached to that user id, which joins the play events this browser had already sent to your account: two of your browsers count as one player rather than two. It records nothing new about you, and it is one-way — a visitor id that belongs to one account is never moved to another, so a shared browser gives the second person a fresh id rather than the first person's history.

Sync sends the profile, exactly the keys listed under "The account routes" above, when the game page loads and after you change something — and the climb beside it, in a request of its own, if you have played the Tower. Your match history and your replays stay on the device.

Clerk's usage reporting never gets the chance since 17 October 2026: no script of Clerk's runs here, so the form that used to post to clerk-telemetry.com from your browser (switched off by this game while it was drawn, measured 18 September 2026) is not drawn at all. Signing in still means this server talking to Clerk, which is unavoidable — that is who holds the sign-in — but nothing is told that you opened the screen.

Nothing on this site sets a cookie since 17 October 2026. The sign-in form sets cookies, and it is the only thing on this site that does. Measured on dicelockgame.com itself on 18 September 2026, in a browser that started empty, that form left five on pressing SIGN IN — three of Clerk's, __client on clerk.dicelockgame.com and __client_uat on the game's own address, written a second time with the instance's id on the end, and two of Cloudflare's own on Clerk's address — plus Clerk's settings under __clerk_environment, and signing in added __session, that name again with the instance's id, and clerk_active_context, which signing out took away. That form is gone. The sign-in screen is the game's own, the exchange is this server's, and a browser that still carries those cookies from before keeps them until they expire or are cleared; this site writes nothing new to them. The one visit to Clerk's own address a browser makes now is on the way through Continue with Google or Continue with Apple — the provider's page hands you back through clerk.dicelockgame.com for a moment, and whatever that host sets on itself in passing is Clerk's and on Clerk's address, not this game's.

In the app — iPhone or Android — none of the above is set, and no page of this website is shown. The Account screen there offers three ways in — Continue with Apple, Continue with Google, and an email address typed into the game's own screen, which is then sent a code — and none of them loads the sign-in service's script or opens a page of this site. A browser offers the same three on the same screen since 17 October 2026; the two provider doors there are a visit to the provider's own page and back, and the email door is exactly the one described here. An email address no account holds makes one, by the same code. Apple's is the system's own sheet: what it hands the app is the identity token Apple signed and, on the first sign-in only, the name and email you chose to share — the app sends the token and the name to this server once, which creates your Clerk user from them and mints the game's own session; the server keeps neither the name nor the email, and the app never sees them again. Google's is Google's own sign-in page, opened in a private system-browser sheet that shares no cookies with Safari and keeps none when it closes, so iOS asks no permission and nothing lands in your browser; what crosses back into the app is a one-time code that this server trades for the game's session.

On Android the two providers are the other way round, because the phone is. Google's is the system's own account sheet — the one Android draws listing the Google accounts already on the phone, with no browser and no page of anybody's in it; what it hands the app is a token Google signed for this game's sign-in service, which that service verifies. Apple has no such sheet on an Android phone, so Apple's is Apple's own sign-in page opened in a browser tab over the game, exactly as Google's is on the iPhone, and it comes back the same way: a one-time code, traded here for the game's session. If your phone holds no Google account at all, Continue with Google opens Google's page in that same tab rather than an empty sheet. Dismissing the sheet or closing the tab cancels the sign-in and nothing else happens. The email door is identical on both. The email form sends your address to this server, which sends it straight on and keeps nothing. It is read out of one request, passed to the sign-in service in one call and dropped: nothing writes it to a file, a log line or the database, and a refusal has it removed from its message before it is sent back. The sign-in service then emails you a six-digit code, which you type into the same screen; there is no password (since 17 October 2026 — before that the form asked for one and the code came anyway, as a second step). Your address is not sent back to the app, even though the service offers it: what comes back is a token for the sign-in in progress and a yes-or-no about the code. The app cannot CREATE an account this way — only sign in to one made on this website.

However you sign in, the app greets you as SIGNED IN rather than by name, because it holds no name to greet you with. Dismissing a sheet, closing the tab, or leaving the form cancels the sign-in and nothing else happens. Signing out in the app removes the game's session on this device and on the server; there is nothing at Apple, at Google or at the sign-in service for it to clear, because the server ended that session the moment it minted the game's.

Signing out deletes both ends of it — the token this browser holds and the row on the server — and puts this device back to a first launch: your settings, marks, scores, boards, climb, match history, replays and any saved game go with the token, after anything not yet sent has been sent, and the account's copy on the server is what signing in again restores. The visitor id and the queued play events stay, because they are the device's. A session that simply expires, or is ended from another device, is not a sign-out and removes only the token and the entitlements.

Deleting your account from inside the game deletes both records. There is a DELETE ACCOUNT button on the Account screen, under SIGN OUT: pressing it and confirming removes your Clerk user — the email address and the sign-in itself — and every row this server holds under the id Clerk issued you, which is the username, the profile, the Tower climb, the session rows and anything the account has been given. Your posted Daily times are the one thing it does not delete: they stay on the leaderboard as the device's, under the username they were posted with, because they are rows other players read and a board that silently reordered itself when somebody closed their account would be a board nobody's rank was a fact about. What ends is the link, exactly as it does for the play events below; your streak goes on counting on the device that earned it. It happens in that order, so if the second half fails the button still works and pressing it again finishes the job. The username goes free: once the account is deleted, the handle it held can be claimed by anybody.

This device goes back to a first launch, exactly as signing out leaves it: your settings, marks, scores, boards, climb, match history and replays are removed from it — and the server's copy is gone with the account, so nothing restores them — and you can carry on playing as a new guest. The play events this browser has already sent stay too, because they are filed under the random visitor id in "What the game keeps in your browser" above rather than under your account — what deleting the account ends is the link between the two, so the browser counts as a stranger's again.

Deleting your account at Clerk directly doesn't delete anything here — it's the button above that deletes both. They're two records: Clerk holds your email address, and this server holds rows filed under a user id Clerk once issued. Removing the first doesn't reach the second, and nothing here is notified.

What is never collected

• Your IP address. It arrives on the connection, as it must for any web request, and no part of the game writes it down. Clerk sees it too, on the one screen that loads Clerk's script, and that is above rather than here because it is Clerk's collection and not this game's.
• Your language, your referrer, your screen contents. Your user-agent string is not read by the game either — not one of the words it sends about your device comes from it — but the Cloudflare script described below does report your browser engine, its major version and your operating system's version, which is most of what a user-agent string would have said. Your language is the one of those three a crash report breaks: the reporting code described under "Who else sees a request" puts the language and time zone your browser reports on every report it sends, and that is a request a page that has thrown makes and a page that has not never does. Your referrer and what was on your screen are on neither.
• The size of your window. Whether it is portrait or landscape is recorded; how many pixels wide it is never reaches the server.
• Your name and your email address, by this server. Nothing this game runs asks you for either, nothing it stores holds either, and no route accepts either. If you sign in, you type an email address into Clerk's form and Clerk collects it, which is the section above. The username you may choose for your account is the only piece of text you can type that is sent anywhere by this game. Nothing asks for it until you want a Daily time on the board, it is refused rather than stored if it holds a blocked word, and it is not your name unless you make it one. The error messages described above are the only other text of any kind — written by the game and your browser, capped at ten a visit, and never something you entered.
• Cookies — none at all, from any part of this site. The game sets none, and neither does the Cloudflare script below. Measured on 18 September 2026 in a browser that started empty: a full load of the front page, the game, this page and jiolab.dev/dicelock ended with an empty cookie jar, document.cookie an empty string, and not one response from any of them carrying a Set-Cookie header. The exception is the sign-in form, which sets five the moment it is drawn and three more once you are signed in. That form is gone since 17 October 2026 and the sign-in screen is the game's own, so there is no longer an exception to state; "If you sign in" has the old measurement and what a browser still carrying those cookies should expect. That is why this site has no cookie banner, and "If you are in California" below is where that is argued rather than just asserted.
• Anything at all for advertising. There is no ad, no pixel and no tag manager on any page, and nothing about you is handed to anybody selling anything. There is one third-party analytics script, though: Cloudflare's own, on every page of this site. Cloudflare puts it there, not this project, which is why reading the code didn't find it. What it collects is below.

Where it is stored, and for how long

The site runs on a server rented from Railway, and the events are written to one Postgres database in the same Railway project, reachable only from that server.

• The play events are kept indefinitely. Nothing deletes them on a schedule: the counts on the stats page are computed from them when asked, which is what lets a question about a month ago be answered at all. What is kept is exactly the list above, filed under a random id and a date.
• A posted Daily time is kept indefinitely. The date, the device id, the username, the time and which account it came from stay on the leaderboard: a streak is a claim about every day before today, so a board that forgot last month could not make it.
• A shared match's rows are kept indefinitely. The link, the two visitor ids in it and every game played at it stay: a head-to-head record is a claim about every game before this one, so a table that forgot last week could not make it. Nothing sweeps old links on a schedule.
• An account's profile is kept indefinitely — one row per account, replaced rather than added to each time it syncs, and removed only by the same by-hand request as everything else below. An account's climb is kept the same way, in a row of its own, except that it is only ever added to: a sync can put a cleared step into it and the only thing a device can send that takes one out is a Restart the Tower, which clears every step and Guardian in the row and leaves the crowned floor, the rank and the worlds in it. Its sign-in sessions are the one thing here with an expiry: a session unused for 180 days stops working and its row is deleted the moment anything presents it. Signing out deletes that row there and then.

A copy of the whole database is taken every night and kept for 30 days, on a computer run by the person who runs this site rather than on Railway. It holds exactly what the database holds, nothing more, and a copy older than 30 days is deleted. Your scores, your puzzle marks and your recorded runs are in your own browser, not in either.

Who else sees a request

Four parties. The first two are there whether the game likes it or not; the third is handed a crash when the game has one; the fourth is the only one anything about you is deliberately handed to, and only if you ask for it:

• Cloudflare sits in front of the site and every request passes through it, so it sees the connection — the address it came from, the URL and the headers. It also asks browsers to report network errors back to it. And it adds a script of its own to every page here, which is the next section.
• Railway runs the server and so holds the same connection data in its own logs.
• Sentry, since 19 October 2026, when the game hits a bug — and only then. Sentry is Functional Software, Inc., an American company whose business is collecting other people's crash reports, and what it does with one is under its own privacy policy, which is that link rather than this page. What a crash report holds is the error's message; its whole stack trace rather than the single line client_error carries; a trail of what the page did in the seconds before it — which buttons were pressed, which addresses it fetched and what it wrote to the browser's console; which build of the game was running and which of the three surfaces it was, a browser or either app; the address of the page with its query string cut off, because /play carries the key to a shared table in one; and the language and time zone your browser reports, which the reporting code puts on everything it sends. What it never holds is you. No name and no email address is ever sent, because this server has neither to send — and the reporting code's own collection of a signed-in person, of your cookies, of the headers and the body of a request, of a page address's query string, of the text of a database query and of the variables that happened to be in scope where the error was thrown is turned off one category at a time, by name, in the browser and on the server. (The single switch every version of Sentry's documentation calls sendDefaultPii is passed as false and does nothing at all in the version running here, which is why each category is refused instead of trusted to it.) Your IP address is not stored. In a browser the report is posted to dicelockgame.com and this server forwards the bytes with nothing of your connection on them, so Sentry is never handed it; the two apps report their own crashes to Sentry directly, where the connection is the phone's, and storing an address is switched off in the Sentry projects themselves — which is a setting in that account rather than a line of this code, as the retention is. Your browser fetches nothing from Sentry either: the reporting code is a copy of Sentry's own, committed to this project and served from this site like the two typefaces below, so no part of the page is loaded from them and the report is the only request there is. A report is kept for 90 days and is then deleted, which is Sentry's own event retention on the plan these projects are on. At most ten per visit, the same ceiling as the event. Nothing is sent on a visit that does not hit a bug, and a browser extension that blocks the reporting simply means none is sent: the game plays identically either way. The page, the server and each of the two apps report to a project of its own, so a browser never touches the one the server's own faults go to.
• Clerk, through this server, once you press one of the three sign-in doors on the Account screen. Nothing before that press loads a byte of Clerk's script — since 17 October 2026 no script of Clerk's runs here at any point: your browser never talks to Clerk's API, never loads its form and never fetches img.clerk.com. What reaches Clerk is what this server sends it on your behalf — the email address you typed, or the one-time code a provider handed back — and the only visit your browser itself makes to a Clerk address is the moment Continue with Google or Continue with Apple hands you back through clerk.dicelockgame.com to this page. (Measured on 18 September 2026, a browser that opened the game and played it asked Clerk for nothing at all; that is still so, and now holds for a browser that signs in as well.)

No font service sees a request. The two typefaces on the front page and in the game are files this site serves itself, so your browser fetches them from dicelockgame.com along with the rest of the page and asks Google — or anybody else — for nothing. This page asks for no font at all and uses your system's.

The script Cloudflare adds, which nothing in this project asked for

Every HTML page this site serves comes back with one extra <script> at the end of it, loaded from static.cloudflareinsights.com. It is Cloudflare Web Analytics — visitor counting, of the same general kind the game already does for itself. Nothing in this project puts it there. It is switched on for the account the domain sits in, and Cloudflare inserts the tag into the page on its way out to you, after this project's code has finished with it.

This is what it sent, read out of a real browser on 18 September 2026. One POST per page load, to this site's own address rather than to Cloudflare's, carrying: the address of the page you loaded; a random id for that one page load, minted fresh each time; the name and major version of your browser's engine and the version of your operating system; how much memory the page's scripts were using; how long each stage of the load took, in milliseconds; and a fixed token naming this site. No part of it is anything you typed.

What it does not do is the half worth stating. It sets no cookie, writes nothing into your browser's storage, and carries no id that outlives the page load — checked the same day in a browser that started empty and finished with an empty cookie jar. So it cannot say that two visits came from the same browser, which is the one thing the game's own visitor id above can say.

It's easy to miss. Cloudflare only inserts the tag when the request asks for HTML: curl with no Accept header — the check anybody would reach for — gets the page exactly as this project wrote it, with no script in it and nothing to notice. It takes Accept: text/html to see the tag at all, or a browser.

Blocking static.cloudflareinsights.com stops it, and costs this game nothing: no page here needs it to work, and nothing on the site behaves differently when it never loads.

If you are in California

California's privacy law — the CCPA, as amended by the CPRA — gives residents of that state rights over what is collected about them. This section is what those rights come to here, written in the law's own words about the lists above. It describes what this game does; it is not legal advice, and nobody who wrote it is a lawyer.

The personal information here is random numbers. The visitor id and the older leaderboard device id in the table above are "unique identifiers", which makes them personal information, and everything filed under them — the play events, a posted Daily time, a shared match's rows — is personal information along with them, even though nothing in it is a name. A third one joins them if you sign in: the user id Clerk issues, and the profile filed under it. That is still a random number, and this server has no email address, no phone number, no location and no payment anywhere in it, because nothing it runs asks for one. The only name in it is one you typed on purpose: the username on an account, which nothing asks to be your real one. Your email address is Clerk's, collected by Clerk on Clerk's own servers when you sign in — under Clerk's privacy policy, linked above, and not under this page.

No sensitive personal information is collected at all, so the right to limit how it is used has nothing here to act on.

Nothing is sold, and nothing is shared for advertising. Both of those words are narrower in this law than in ordinary use and the answer is no under either reading: nothing from this game is handed to anybody in exchange for anything, and nothing is passed to anybody for advertising to you elsewhere. That is why there is no "Do Not Sell or Share My Personal Information" link on this site. The absence is the answer rather than an omission — a link that opted you out of nothing would say less than this paragraph does.

There is no cookie banner because nothing here sets a cookie, and the measurement is in "What is never collected" above rather than in a promise: an empty cookie jar after a full load of the game, on 18 September 2026. A banner asking you to accept cookies that do not exist would collect your agreement and change nothing about what happens, which is worth less to you than the list on this page. One thing does set cookies, and it is the sign-in form: five when it is drawn and three more once you are signed in, all written by Clerk's script, none of them written by this game, and none of them reachable without pressing SIGN IN. That form is gone since 17 October 2026, and with it the one thing on this site that ever set one — the sign-in screen is the game's own and the exchange is this server's, which is measured and listed under "If you sign in". A browser that met those cookies before that date still carries them until they expire or are cleared, and nothing here writes to them again. The game's own session token for an account is a value in local storage and not a cookie, and it is the one line in the table above.

The one thing here a consent banner would properly have been for is the Cloudflare script above, and this page cannot switch it off. It is added after every page leaves this project's code, so no button drawn by this site could stop it arriving. What can be done honestly is to say what it collects and what it does not, which is the section above, and to say that your browser can block it outright.

Your rights, and what each one actually gets you:

• To know what is collected. This page is the whole answer, and it is written out of the code rather than about it.
• To know what is held about you. The two ids below are the only keys anything here is filed under, and this page prints yours — a third, if you have signed in, is the user id in dicelock.account.v1.
• To delete, and to correct. Clearing this site's data does the first immediately, for everything in your browser, without asking anybody. What is on the server needs somebody to read those ids off a request, and the next section names the address to send one to. It is a mailbox that receives and is read, not one that writes back, so what it promises is the deletion and not a reply.
• Not to be treated differently for using any of them. There is nothing to treat differently with: no payment, nothing held back from a guest, and an account that is optional in both directions — the whole game is playable without one, and what signing out clears from the device the account keeps and signing in restores.

An authorised agent may make any of those requests for you. It arrives in the same place, which is the next section.

Asking for it to be deleted

One thing you can do yourself, immediately and without asking anybody: clear site data for dicelockgame.com. Both ids and every setting, score and recording go with it, and nothing new can be attached to them.

What stays on the server after that is the play events filed under your visitor id, the shared-match rows that id sat down in, and a Daily time filed under your device id. Those can only be removed by hand, by somebody reading the ids off a request, which is why this page shows you yours:

An account is a fourth thing, and it is the one you can delete yourself. Open Settings, then ACCOUNT, and press DELETE ACCOUNT under SIGN OUT. It removes your Clerk user — the email address, and the sign-in with it — and every row this server holds under the id Clerk issued you. You are not asked to type anything, no email is sent, and nothing is queued for somebody to action: the account is gone when the screen says "Account deleted." The other three things above still need a request.

Deleting it at Clerk instead does not touch the rows here. Two records, in two companies, with nothing between them that would carry a deletion across — which is why the button is inside the game rather than a link out to Clerk.

Everything else on this list is still a request, and it goes here:

Send both ids — or whichever of them your browser has — to privacy@jiolab.dev, and the rows filed under them are deleted. There is nothing else to prove and nothing else to fill in: the ids are the whole request.

What is about to change

One thing is decided and not built. It's named here rather than in the lists above, which describe the game that's running today.

A shared match gets a name you choose. When this lands, a name you type is stored on the server against the same random visitor id above — one name for this browser, not one per match — and it is the name the other player sees and the same one the Daily leaderboard already shows, kept in one place rather than in two. Typing one stays optional: decline and the match still starts. It also takes something away, which is the point of doing it: the name replaces the visitor id the other player's browser is handed today. That half of it is already done: since 17 October 2026 the other player's browser is handed no id of yours, so a name you choose would put a label on a seat rather than take a leak away. No rating of yours becomes public — the score between two people in a room stays between them, and the Daily board stays the only public ranking in this game.

When it lands, this page changes with it — the point of the lists above is that they are short enough to keep true.