Privacy Policy

Our privacy policy and how we use your data

Last updated: 11 September 2026

Draft. Not yet in effect.

This page is a draft prepared ahead of the formation of Kirobyte, LLC. The company does not exist yet, so there is nobody for this notice to bind, and it is not in force. It takes effect on a date that will be published here once formation completes. Until then, read it as a description of how the site is built, not as the operator's published privacy notice.

Who is responsible

xerobytes.net is operated under the name Kirobyte, LLC (in formation). Once the company is formed, it will be the data controller for the personal data described on this page.

The company has not been filed yet. It will be a limited liability company organised under the law of Texas. Kirobyte, LLC's registered office address will be on public record with the Texas Secretary of State once the company is filed. For anything to do with privacy or your data, write to privacy@kirobyte.com. Mail sent to that address is forwarded through Cloudflare Email Routing to the inbox we read.

What we collect, and why

The site collects as little as it can function with. You can create an account with an email address, a password and a username you choose, or by signing in with a Google account. An administrator can also create an account for you, with your email address, a password they choose and, optionally, a username. There is no phone number, no address, and no profile questionnaire. Google is the only outside sign-in provider the site offers; there is no sign-in through Discord or any other service.

  • Email address, and a password if you use one. Used to create your account, sign you in, and send you account emails such as address confirmation and password reset. Your password is handled by Supabase Auth; this site never stores it. An account created by signing in with Google has no password unless you later set one, for example through a password reset. If an administrator created your account, they chose the password and could see it, and they marked your email address as confirmed without sending you a confirmation email; change the password after you first sign in. Legal basis: performance of our contract with you.
  • Your Google account details, if you sign in with Google. Your Google account's name, your email address and whether Google has verified it, the web address of your Google profile picture, a permanent identifier for your Google account, and, when Google includes it, the domain of the organisation that manages a Google Workspace account. What each is used for is set out under Signing in with Google, below. Legal basis: performance of our contract with you.
  • Username. The name you type when you sign up with an email address, the name an administrator entered if they created your account, or your Google account's name if your account was created by signing in with Google, shown as your display name. Accounts created before the sign-up form asked for a name started with the part of the email address before the at sign. It is public once you write a build. How that works, and how to change it, is set out below. Legal basis: performance of our contract with you.
  • Profile picture. Optional. If your account was created by signing in with Google, the web address of your Google profile picture was saved as your profile picture automatically; the image itself stays with Google. You can replace or remove it in account settings. Legal basis: performance of our contract with you. A picture you upload is stored in a public bucket, which is covered below.
  • Two-factor secret, if you turn on TOTP. Optional. Legal basis: performance of our contract with you, and our legitimate interest in keeping accounts secure.
  • Event notification preferences, if you set them. Optional. Which event families you asked to be told about, how far ahead you want telling, and whether you ticked the box asking for those notices by email. Legal basis: your consent, which you give by ticking that box and can withdraw at any time.
  • Builds you write and builds you heart. Includes the free-text summary you type. Legal basis: performance of our contract with you.
  • Map sightings. Both the ones you submit by hand on the live map and the ones uploaded by the eagle-eye scanner if you run it. Each row carries a free-text reporter string: your display name for a manual report, and whatever name you typed into the scanner's configuration for an upload. Legal basis: performance of our contract with you.
  • Node status updates. Marking a node cleared on the live map writes your display name into a separate node-status table, as free text. Legal basis: performance of our contract with you.
  • Role grants. A record of what you are permitted to do on the site and who granted it, and, if you joined through an invite link, which link you used and when. Legal basis: our legitimate interest in administering access.
  • When you were last active. While you are signed in and a page on the site is open and visible, your browser records a last-active time on your account about every two minutes. Administrators see it as online or as a last-seen time. Legal basis: our legitimate interest in administering the kingdom tools — the Rise of Kingdoms live map and the kingdom pages around it.
  • Organisation and kingdom records. Recorded by an administrator: which alliance or kingdom organisation you belong to, your role in it and who added you; which kingdoms you are assigned to on the live map and who assigned you; and whether your account is recorded as the payer for an organisation's access to the kingdom tools, with the number of seats and an administrator's note. Set by you: the home kingdom the live map opens on. An administrator who changes how the live map assigns kingdoms is recorded against that change. Legal basis: performance of our contract with you.
  • Map-source records. The database can record that an organisation has linked an account on Lilith's Rise of Kingdoms toolkit so that its kingdom maps can be fetched: a label for that toolkit account, which account here linked it and when, and its sync status. The toolkit's session token would be stored encrypted in a separate table that only our server can read. Members of the organisation and administrators can see the record, but not the token. Nothing on the site creates these records yet, and we will describe the linking here before anything does. Legal basis: performance of our contract with you.
  • A cross-site request forgery token. Held in a cookie. Legal basis: our legitimate interest in protecting you and the site from forged requests.

Creating an account yourself needs either an email address, a password and a username, or a Google account. An account an administrator creates for you needs an email address and a password. Without an account you cannot sign in, publish a build, or heart one. Everything else on the list above is generated by the site, recorded by an administrator, supplied by you when you choose to use a particular feature, or sent by Google because you asked it to sign you in.

There is no automated decision-making and no profiling. Nothing here evaluates you by automated means in a way that produces a legal effect or similarly significant effect. Roles are granted by administrators and super administrators. Administrator access needs a second administrator to approve it, unless a super administrator grants or approves it. The cartographer, enumerator and Enumerator+ roles take effect as soon as they are granted, and can also be granted through an invite link an administrator issues: anyone who redeems a live link while signed in receives the role it carries.

Consent is the legal basis for one thing only: event notices by email. Nothing else on this site asks for your consent, and nothing else relies on it. That box is off until you turn it on, ticking it is the whole of the asking, and you can untick it whenever you like under Settings, then Notifications. Withdrawing is as easy as giving, it takes effect from the moment you save, and it does not affect anything we did while it was on.

No IP address and no user-agent string is recorded by this site's own code. Our hosting and database providers see them as an unavoidable part of serving requests, which is covered further down. One such record is kept with your account: Supabase Auth stores the IP address and browser user-agent string of each signed-in session. Those records are kept until the session ends and is cleaned up, or until your account is deleted. How long a session can last depends on our Supabase session settings. Supabase Auth can also keep an audit log of sign-ups, sign-ins and linked sign-in methods, and some of its entries can include an IP address.

Where your display name comes from

If you sign up with an email address, your display name is the username you type on the sign-up form. If an administrator creates your account, it is the name they entered. If your account is created by signing in with Google, a database trigger sets it to the name on your Google account, which is often a real full name, and the site does not ask you to choose another. If the Google name, or the name an administrator entered, is blank or contains an at sign, the trigger uses the part of your email address before the at sign instead, and the site asks you to choose a username when you next use it signed in. Adding Google sign-in to an account you already have leaves its display name as it was. Accounts created before the sign-up form asked for a name also started with the part of the email address before the at sign, and are asked the same question.

That name becomes public as soon as you create a build. It appears as the author byline on every build you publish, and the public profile view that serves those bylines covers you from the moment you save your first build, whether or not you publish it. Until then, nobody who is not signed in can read your display name at all. The name is also attached to map sightings you submit by hand and to nodes you mark as cleared, though those are visible to a narrower audience, described under Who can see map data. Your email address itself is never published. For an account that still carries the name taken from its email address, the part before the at sign is.

If your username is your real name, your real name is what other people will see. You can change it yourself at any time: sign in, open your account settings, and edit it under Your Name. Change it before you post anything if you would rather not show it. If your account was created by signing in with Google and you would rather not publish the name on your Google account, change it before you write your first build. Changing it here does not change your Google account, and signing in with Google again does not change it back. If you would prefer us to correct it for you, that is the right of rectification, covered under Your rights below.

Signing in with Google

Signing in with Google is optional. When you choose it, your browser goes to Google, you sign in there, and Google sends you back to this site through Supabase, which runs our sign-in system. We ask Google for its basic email and profile permissions and nothing else. We do not request access to Gmail, Google Drive, Contacts, Calendar or any other Google service, and we do not ask for offline access, so Google gives us no long-lived token for your account.

What we keep from what Google sends:

  • your Google account's name;
  • your email address, and whether Google has verified it;
  • the web address of your Google profile picture;
  • a permanent identifier for your Google account, which is how we recognise you the next time you sign in with Google;
  • the domain of the organisation that manages a Google Workspace account, when Google includes it.

Google also issues a short-lived access token at sign-in, described below. Anything else Google sends is discarded.

What we use it for. Creating your account and signing you in; linking Google sign-in to an existing account that has the same email address; keeping your email address on your account and sending you account emails; and setting your starting username and profile picture. We do not use it for advertising, we do not sell it, and we do not use it to build a profile of you. Apart from completing sign-in, nothing on this site calls a Google service or reads anything else from your Google account. Our use of information received from Google follows the Google API Services User Data Policy.

Who else sees it. Supabase stores it and runs our sign-in system. Cloudflare hosts the site, so the session cookie that carries a copy of these details passes through Cloudflare with each request your browser makes, and Cloudflare Email Service delivers our account emails to your address. Neither uses it for purposes of its own. Your username and the address of your profile picture become public once you write a build, as described under What becomes public. Administrators can see the account details listed under How your data is protected, people holding the census or map roles can see your username where those sections say so, and members of an organisation you belong to can see that your account belongs to it. It is not passed to anyone else for purposes of their own.

Where it is kept. Supabase Auth keeps a copy of everything in the list above, in the user and identity records for your account, and refreshes that copy each time you sign in with Google. That copy stays until your account is deleted, even if you change your username or remove your profile picture here. When an account is created by signing in with Google, your Google name, picture address and email address are also copied once into your profile; changes you later make to your Google account do not reach your profile here.

The access token. Google issues a short-lived access token at sign-in. Supabase holds it until sign-in finishes, then returns it to this site's server along with your new session. If sign-in is abandoned part-way, Supabase deletes it in routine cleanup, which removes sign-in attempts once they are more than 24 hours old. The server does not use it, but it can be stored with the rest of your session in the session cookie described under Cookies, which your browser sends back to the site with each request until the session next refreshes. Nothing on this site reads it or uses it.

If you already have an account. Signing in with Google, when Google reports your email address as verified and that address already has an account here, adds Google sign-in to that account instead of creating a second one. If you had confirmed that email address, your password keeps working too. An account an administrator created for you counts as confirmed, so the password they set keeps working until you change it. If you had never confirmed it, the password can be removed, because nobody had yet proved they controlled the address. The username and profile picture already on your account stay as they are.

How it is protected. Sign-in happens over HTTPS between your browser, Google, Supabase and this site, and Supabase states that it encrypts stored data at rest. Other people can see only the parts described under Who else sees it, above. A copy of the same details is also in the session cookie described under Cookies, which JavaScript served by this site can read and which is not currently marked Secure. The safeguards that apply to all account data are described under How your data is protected.

Stopping and deleting. You can stop using Google sign-in for this site at any time from your Google account: go to myaccount.google.com/linkedapps, choose Sign in with Google, choose this site, and select Stop using Sign in with Google. That stops Google signing you in here. It does not delete your account on this site or the Google details stored with it; to remove those, delete your account as described under Deleting your account. Deleting your account here does not remove the connection from your Google account, so remove it there too if you want it gone.

What becomes public

Public here means readable by anyone on the internet, including people who are not signed in and people who are not using the site through a browser.

  • Your profile, once you have written a build. Your account id, display name, and profile picture URL are exposed through a public database view. That view is limited to accounts that have authored at least one build, so registering an account does not by itself publish anything about you. Your email address is deliberately excluded from the view and is never published. If your account was created by signing in with Google, that name is the name on your Google account unless you have changed it, and the picture URL is the address of your Google profile picture unless you have replaced or removed it.
  • Builds you publish. The whole build, including the free-text summary, with your display name as the byline.
  • Which builds you have hearted. The hearts table is readable by anyone. It is a public record of which account hearted which build. If you would rather nobody could see what you heart, do not heart things.
  • A profile picture you upload. The storage bucket holding avatars is public. Avatar URLs are unauthenticated and derived from your account id, so anyone holding or guessing the URL can open the image directly, without signing in and without visiting the site. Treat anything you upload as a photo published on the open web. A Google profile picture is not in that bucket; only its address is stored here, and the image is served by Google.

The KvK census, and data about people who are not users

Kingdom leadership can issue a census link. Anyone holding that link can fill in a form describing a governor: in-game name and governor ID, alliance, city hall and VIP level, power, kill points, troop counts by tier, march and commander setup, battle role, time zone, the in-game hours they are usually active, their Discord handle, their language, and free-text notes. Every one of those is typed in by whoever fills the form.

One thing is recorded that is not typed in. When the person filling the form is signed in to a leadership account here, the submission also records which account entered it, and the census roll shows that entry as submitted by that person. This exists so that an answer entered on a governor’s behalf is never presented as the governor’s own words. The same applies when leadership corrects an alliance tag on a submission: the correction records which account made it. Submissions made by governors themselves, who do not have accounts, record no submitter.

This, and the kingdom forms described next, are where we hold information about people who may never have visited the site. A governor described in a census does not need an account here, may not know the form exists, and cannot sign in to see or remove what was submitted about them. We are recording that plainly because it is unusual and because it changes what you should expect: if you fill in a census about somebody else, you are the person who decided to give us their details.

Census submissions are not public. The table is restricted at the database level to signed-in administrators and the census enumerators leadership appoints, no anonymous access is granted to it at all, and there is no page on this site that renders a census entry to anyone else. Submissions are append-only: a new submission never overwrites an earlier one, so a correction adds a row rather than replacing it, and the older row remains until the data is deleted.

A census link can be revoked, which closes the form immediately for everyone holding it. If you are named in a census and want the entries about you removed, write to us using the contact address above and say which governor you are; you do not need an account to ask, and we will not require you to make one.

Kingdom forms

Administrators and holders of the Enumerator+ role can build forms in the kingdom tools and issue a link to each one. Anyone holding a link can answer the form without an account. A form can ask free-text questions, so an answer can contain whatever the person filling it in chooses to type, including details about somebody else.

Answers are not public. Only administrators and Enumerator+ holders can read them, and no anonymous access is granted to them. The site stores the answers, the link they came through and the time they were sent; it does not attach an account or an IP address to them. Answers are append-only: they cannot be edited or deleted through the site, and a form that has been answered cannot be deleted.

If you answered a form, or are named in an answer, and want it removed, write to us using the contact address above and say which form and roughly when. You do not need an account to ask. We remove answers directly in the database.

Who can see map data

Map sightings and node status are not public. Both tables are restricted at the database level to signed-in accounts holding the admin or cartographer role, and the live map itself returns a not-found response to anyone else. Visitors who are not signed in receive no sighting or node status content from either table. A client that subscribes to the live feed by hand, signed in or not, is still told when a row is deleted, with that row's internal id and nothing else.

Inside that group, your display name is visible as the reporter on sightings you submit by hand, and as the last person to update any node you mark as cleared. Sightings uploaded by the scanner instead carry whatever reporter string was configured on the machine that sent them.

An administrator can also switch the live map so that each cartographer sees sightings and node status only for the kingdoms they are assigned to, or belong to through an organisation. Administrators still see every kingdom. A home kingdom you set decides only where the map opens, and only you can see it.

Minimum age

You must be at least 13 years old to create an account. The Rise of Kingdoms tools published here are companions to a game with a large younger player base, but the site is not directed at children under 13 and accounts are not knowingly created for them. Where the law where you live sets a higher age for using an online service without a parent's authorisation, that higher age applies instead.

If we learn that an account belongs to someone below the minimum age, we delete the account and the data attached to it, and we will not ask for more identifying information than is needed to find the account. If you are a parent or guardian and believe your child has created an account here, write to privacy@kirobyte.com.

One point matters more for younger account holders than for anyone else. Your username is published as the byline on anything you post. If your account was created by signing in with Google, it starts as the name on your Google account, which is often a real full name. Change it in account settings before posting.

Cookies

The site sets three cookies, one of which the browser may split across numbered chunks. All three are strictly necessary. There are no analytics cookies, no advertising cookies, and no tracking or cross-site identifiers of any kind.

  • sb-<project-ref>-auth-token, where the project reference is visible in your browser's cookie list (plus its .0 and .1 chunks). Your Supabase session: the access token, the refresh token, and a copy of your account details, including your email address and, if you signed in with Google, the details Google sent. Straight after a Google sign-in it can also hold Google's short-lived access token until the session next refreshes; nothing on the site uses it. Strictly necessary. Max age 400 days, path /, SameSite Lax. It is not HttpOnly, because the Supabase browser client has to be able to read it, and it is not currently marked Secure, so your browser does not limit it to HTTPS connections.
  • sb-<project-ref>-auth-token-code-verifier. A single-use PKCE verifier that proves a sign-in exchange started in this browser. The Supabase client writes one when you start signing in with Google, and also when you sign up, ask for a password reset or change your email address. It is removed when a Google sign-in completes or you sign out; otherwise it can last up to 400 days. Strictly necessary.
  • csrfSecret. Cross-site request forgery protection. A session cookie, HttpOnly, SameSite Strict, and Secure in production. Strictly necessary.

There is no cookie banner on this site and no consent is collected, because all three cookies are strictly necessary: without them you cannot sign in, stay signed in, or submit a form safely. An earlier build also set a sidebar:state cookie, which was an interface preference rather than a necessity and so would have needed consent. Nothing ever read it back, so it was removed instead.

Three cookie names inherited from the underlying starter kit (layout-style, lang, theme) are read if they happen to be present, but this build never sets them. If your browser still holds one from an earlier version of the site, it will not be recreated once it expires or you delete it.

Browser storage is not used to hold personal data. The in-browser inventory scanner is the one place it might otherwise be: its text recognition runs entirely in your browser against files served from this domain, and it deliberately disables the recognition engine's own cache so that nothing is written to IndexedDB.

No analytics and no tracking

There is no analytics on this site. No telemetry, no error reporting, no session replay, no heatmaps, no advertising or conversion pixel, no fingerprinting, and no third-party tracker of any kind. The codebase contains no Google Analytics, Tag Manager, PostHog, Plausible, Umami, Fathom, Mixpanel, Amplitude, Segment, Hotjar, Clarity, Sentry, or Vercel Analytics.

The one activity record the site keeps for itself is the last-active time described under What we collect. It is for administrators running the kingdom tools, is not analytics, and is not passed to anyone else.

The Inter typeface is bundled into the site at build time, so your browser makes no request to Google to load fonts. Your browser only goes to Google from this site if you choose to sign in with Google or follow a link to one of Google's pages, and, after you have signed in with Google, when it shows your own Google profile picture in your account menu and account settings. Other visitors' browsers never load it.

Cloudflare Turnstile protects the sign-in, sign-up, magic link and password reset forms. It is there to tell a person from a script, not to identify you: it receives your IP address and browser characteristics, issues a token that Supabase verifies, and is not used to build a profile or to track you between visits. It runs only on those forms.

A small worker at dl.xerobytes.net keeps one aggregate counter per day of downloads served from origin, held for 48 hours. Repeat downloads are served from the edge cache and are never counted, so it is a cost guardrail rather than a download figure. It records no IP address, no user agent, and no per-download entry, and it sets no cookies.

The in-browser inventory scanner keeps your screenshots on your device

The inventory scanner on the calculators page reads your screenshots inside the web page itself. The image is never uploaded. Text recognition runs in your browser, against files served from this site, and the picture you select is not sent to us, to Supabase, or to anyone else. Nothing about it reaches a server and nothing about it is stored. Close the tab and it is gone.

The eagle-eye scanner, which is a separate download

eagle-eye is an optional Windows program, downloaded from dl.xerobytes.net and run on your own PC. It is not part of the website, nothing on the site requires it, and it is only relevant if you have chosen to install it. Unlike the in-browser scanner described above, it can send data to this site.

  • What it reads. Screenshots you take yourself, or, in its optional live mode, a periodic capture of the game region of your own screen. It identifies resource nodes by template matching and reads the in-game coordinate display by optional text recognition. All of that happens on your machine.
  • What it transmits. If you configure sync, it uploads derived sighting records only: the node label, its map coordinates, the kingdom number, a detection score, the node level, whether the node appeared to be under gathering, a source string, a free-text reporter string, and a timestamp. No image is uploaded to this site, no screen contents, no account identifier, and nothing about your machine.
  • The source string can be a filename. When the scanner reads a screenshot file, or watches a folder, it sets the source to that screenshot's own filename and uploads it with the sighting. In its live and manual modes it sends a fixed word instead. If your screenshots are named in a way you would rather not share, rename them or use live mode.
  • The reporter string is whatever you type. You set it in the scanner's own configuration. It does not have to be your display name or your real name, and the site does not check it against anything.
  • How the upload is authenticated. Uploads go to /api/rok/sightings and are authorised by a shared machine token sent in a request header, not by a signed-in user session. The upload is therefore not tied to any account on this site.
  • Who can see the result. The same audience as every other sighting: signed-in accounts holding the admin or cartographer role, and nobody else. Gathering markers written by the scanner are recorded against the fixed string scanner rather than a person's name.
  • Discord, if you set it up, sends the picture. If you supply a webhook, the scanner posts a text summary and, unless you turn it off, the annotated screenshot itself as an image attachment. The shipped example configuration has that attachment switched on. This is the one path on which a picture leaves your machine, and it goes to Discord under Discord's own terms, not to us. We do not operate that channel and never see it. Set attach_annotated to false in the scanner's configuration to send text only, or leave the webhook unset to send nothing.

How your data is protected

  • The site and Supabase are served over HTTPS, which encrypts traffic between your browser and them. Supabase states that it encrypts stored data, including account data, at rest with AES-256.
  • Who can read what is enforced by row-level security rules inside the database, not only by the pages that display data. Visitors who are not signed in can read only the personal data described under What becomes public. A signed-in account can read its own account details. Members of an organisation can read its membership list and its payer record, including the seat count and the administrator's note; those identify accounts by an internal account id rather than by name, although for anyone who has written a build that id can be matched to their public username. People holding the census, form or map roles can read the data those sections describe. Administrators and super administrators can see the username, email address, sign-up date, roles, number of builds and last-active time of every account, and whether it has been disabled. Administrators can also see which kingdoms each account is assigned to or belongs to through an organisation, and which invite link each account joined through.
  • Passwords are handled by Supabase Auth and never stored by this site, and two-factor authentication is available.
  • Roles are granted by administrators, directly or through invite links they issue, as described under What we collect.

Two limits are worth stating. The session cookie can be read by JavaScript served by this site, because the Supabase browser client needs it, and it is not currently marked Secure, so your browser does not limit it to HTTPS connections. The Cookies section explains both.

Who else processes your data

  • Supabase (Supabase, Inc.) hosts the database, the authentication system, and the avatar storage, and generates the account emails such as address confirmation and password reset. Your browser also connects to Supabase directly for live updates, so Supabase sees your IP address.
  • Cloudflare (Cloudflare, Inc.) hosts and serves the site. It terminates the TLS connection, so it processes request metadata including your IP address, and the session cookie your browser sends with each request. Cloudflare Email Service also delivers our account emails from accounts@xerobytes.net, so it handles your email address and those messages.
  • Google (Google LLC), only if you sign in with Google. Google confirms who you are and sends us the details listed under Signing in with Google. Google learns that you signed in to this site and handles that under its own privacy policy, not ours. We send Google nothing about you.

That is the entire list. Nothing is sold, rented, or shared with advertisers or data brokers, and no third party receives your data for purposes of its own. Google knows that you signed in with it, under its own privacy policy, and information we receive from Google is used only as described under Signing in with Google. We would disclose data if we were legally compelled to.

Where your data is processed

Supabase, Cloudflare and Google are United States companies running global infrastructure, so your data may be processed outside the country you are in, including in the United States. Where that involves personal data leaving the United Kingdom or the European Economic Area, transfers to Supabase and Cloudflare rely on the data processing terms and standard contractual clauses those providers make available to their customers. Google handles your Google sign-in under its own privacy policy.

How long we keep things

  • Account data (email address, display name, profile picture) is kept for as long as your account exists.
  • Google sign-in records (your Google account identifier, name, email address, profile picture address, Workspace domain if Google sent one, and when you last signed in with Google) are kept for as long as your account exists, and refreshed each time you sign in with Google.
  • Builds, hearts, role grants and invite redemptions are kept for as long as your account exists.
  • Last-active time is kept for as long as your account exists, and is overwritten each time it is recorded.
  • Session records, including the IP address and user-agent string of each signed-in session, are kept until the session ends and is cleaned up, or until your account is deleted.
  • Sign-in audit records. Supabase Auth can keep an audit log of sign-ups, sign-ins and linked sign-in methods, and some entries can include an IP address. Nothing on this site deletes those entries, and we have not confirmed how long Supabase keeps them or whether it removes them when an account is deleted.
  • Organisation, kingdom assignment and map-source records are kept until an administrator removes them. Deleting your account removes your organisation memberships and kingdom assignments, and removes your account from the records of who added, assigned, linked or changed something.
  • Your home kingdom is kept for as long as your account exists.
  • Form answers are kept until we remove them by hand. There is no deletion routine for them.
  • Map sightings are hard-deleted 90 days after the time they were spotted, which is not the same as 90 days after they were uploaded. The shorter window you may see on the map itself is only a display filter, not a deletion rule. The deletion runs as a scheduled job once a day, so a row can outlast the 90 days by up to a day, and for longer if the job fails to run.
  • Node status is deleted by the same daily job once a node's status has gone 90 days without an update. That table holds the display name of whoever last marked each node, in a free-text field.
  • Backups. Depending on our Supabase plan, Supabase may keep backups of the database. Data you delete, including a deleted account, can remain in any such backup until it ages out.
  • Cookies expire as set out in the cookies section above.
  • Infrastructure logs held by Cloudflare and Supabase are kept according to their own retention periods, which we do not control.

Deleting your account

Deleting your account removes the underlying authentication record, and that cascades: your profile row, your builds, your hearts, your role grants and invite redemptions, your event notification preferences, your organisation memberships, kingdom assignments and home kingdom, your Google sign-in link with the Google details stored alongside it, and your session records are all removed. We delete your uploaded avatar file first; if that fails, the account is still deleted and we remove the leftover file by hand. It is a real deletion, not a hidden flag. Copies can remain in database backups until they age out, as set out above. The list does not include Supabase Auth's audit log, if it is kept: nothing on this site deletes its entries.

Three consequences are worth knowing. Builds you published disappear from the site along with the account, so anyone reading them loses them. Map sightings you submitted by hand carry your display name in a free-text field that is not linked to your account, so the cascade does not catch them; they are removed on the 90-day cycle described above, or sooner if you ask us. Node status rows carry your display name the same way; they are removed once the node's status has gone 90 days without an update, or sooner if you ask us.

Deleting your account does not touch your Google account. This site does not tell Google you have left, so it can stay listed among the apps linked to your Google account until you remove it at myaccount.google.com/linkedapps. A profile picture that came from Google was never stored by us, so deletion removes our copy of its address, not the picture.

Your rights

If you are in the United Kingdom or the European Economic Area, data protection law gives you the rights below. We will honour them for everyone, wherever you are.

  • Access. A copy of the personal data we hold about you.
  • Rectification. Correction of anything that is wrong. Your display name is the common case, and you do not need to ask us: sign in, open your account settings, and edit it under Your Name. Write to us for anything you cannot change yourself.
  • Erasure. Deletion of your account and the data attached to it. You can start this yourself from your account settings. If your account is recorded as the payer for an organisation's access to the kingdom tools, an administrator has to move that to another account or release it first; until then the site refuses the deletion.
  • Portability. Your data in a structured, commonly used, machine-readable format.
  • Objection. You can object to any processing we carry out on the basis of legitimate interests.
  • Restriction. You can ask us to pause processing while a question about accuracy or lawfulness is resolved.

To exercise any right you cannot exercise yourself in account settings, write to privacy@kirobyte.com. We will reply within one month. There is no charge, and we will not ask you for more identifying information than we need to be sure the request is yours.

Complaints

If you think we have handled your personal data badly, write to privacy@kirobyte.com and we will reply within one month. You also have the right to complain to a data protection supervisory authority. In the United Kingdom that is the Information Commissioner's Office. In the European Economic Area it is the authority for the country where you live, where you work, or where the problem happened.

Payments

Supporter memberships are not live yet. No payment provider is connected to the site, and no payment or card details are collected or stored today. An administrator can record an account as the payer for an organisation's access to the kingdom tools, as described under What we collect; that record names an account and a number of seats, and no money moves through the site. When memberships launch, payments will be handled by our payment provider, card details will go to them rather than to us, and this policy will be updated to describe that before any payment can be taken.

Changes to this policy

This policy will be updated as the site changes. The current version is always the one published on this page, and the date at the top tells you when it last changed.