Privacy policy

Who is responsible

xerobytes.net is operated under the name KiroByte LLC. 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.
• Crucible matchups you save. The Crucible is the Rise of Kingdoms battle simulator, and its fights run in your browser. Saving one stores the title you give it, the commanders, equipment, troops and bonuses you set for both sides, a summary of the result, and whether you have shared it. Legal basis: performance of our contract with you.
• Battle reports you upload. On a PC, Rise of Kingdoms keeps the mail it downloads in a folder on your computer. The battle reports page reads that folder in your browser and sends us only the battle reports in it; every other mail stays on your device. A script can send reports too, with an upload token you issue on that page. If you send screenshots instead, the page reads them in your browser and never sends the pictures: only the commanders, their levels and the numbers on each pairing card, as you confirm them, reach us; player names, alliance tags and map coordinates on the screenshots are not read into anything sent. Our server reads each report and keeps only the fight: both sides' commanders with their levels, stars and skill levels, the lead commander's equipment and armaments, the troops each side brought, what each lost and how, kill points, how long it lasted, the game's verdict on each pairing, your troop count over the fight, and the day it was fought. Governor and alliance names, tags and ids, player, account and device ids, kingdom and server numbers, report and mail ids, avatars, map coordinates, the mail's title and the time of day are left behind and never stored, and neither is the file itself. To recognise a report sent twice, the server also stores a one-way fingerprint made from the game server, the report's number and the uploader's player id, without keeping any of the three. Each report is linked to the account that sent it, and to the upload token it came with, if any. Legal basis: performance of our contract with you. Administrators, and the After-Action Reviewers the owner appoints, read the reports to check them and to calibrate The Crucible against real fights; each reviewer's approve or reject verdict is kept with the report. Legal basis: our legitimate interest in making the simulator accurate.
• Upload tokens and upload counts. A token you issue for battle reports is shown to you once and never stored. We keep a one-way hash of it, its label, its last four characters, and when it was issued, last used and revoked. To hold uploads to a rate limit, the server also keeps one row per account counting the requests and files sent in the current minute, with when, and how many times, it has held uploads back. Legal basis: performance of our contract with you, and our legitimate interest in keeping the service available.
• 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, and the KvK season The Crucible starts new fights in. An administrator who changes how the live map assigns kingdoms is recorded against that change. Legal basis: performance of our contract with you.
• What the xeroBytes Manager Discord bot handles, if you use it. Your Discord ids, the governor ids and in-game names you verify, the profile screenshot you post, title requests and player lookups. This does not need an account here. It is set out under The xeroBytes Manager Discord bot, below, with the legal basis for each.
• 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 owners. Administrator access needs a second administrator to approve it, unless an owner 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.
• A Crucible matchup you share. Anyone holding its link can read it without signing in: its title, both sides' setup and the result, but not your name or your account. Stop sharing it, or delete it, and the link stops working.

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 third-party 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.

When a page fails because of a fault on our side, the site emails its operator a short alert: the time, the page's address without anything after a question mark, the kind of failure, and the error message with anything that looks like an email address, token, password or IP address removed. It never includes your IP address, cookies, account or browser details. Cloudflare Email Service sends it, and it arrives in the operator's Gmail inbox. The filtering works by pattern, so in rare cases an error message could still contain a name.

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 site's typefaces are 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.

The xeroBytes Manager Discord bot

xeroBytes Manager is a Discord bot we run to set up and look after the Discord servers of Rise of Kingdoms alliances and kingdoms. It is separate from the website: you do not need an account here to use it, and using it does not create one. It is private for now, so only we can add it to a server. It runs on a server we rent from Amazon Web Services, and talks to Discord, and to this site, from there.

What it never asks for. The bot never asks for your Rise of Kingdoms password, your Discord password or any other password, and it has no way to sign in to your game account. It holds no Supabase key and cannot read this site's database. It can only make a fixed set of requests to this site, each about one Discord server, with a token of its own.

What it sees. Discord sends a bot the messages posted in the channels it can see, and tells it when someone joins the server. The bot acts only on the things listed below: the Verify button and its form, a screenshot posted in the verification channel, a title word in the titles channel, and the ?queue and ?player commands. It ignores every other message and keeps nothing from it. It does not act on direct messages.

• Discord server and user ids. The permanent numbers Discord gives each server and each person, used to know which server and which member a request is about. Legal basis: our legitimate interest in running the bot for the servers that added it.
• Your governor id and in-game name. When you press Verify, the bot asks for them. It checks them against the kingdom's latest roster scan on this site and, once you are approved, links that governor to your Discord user. The first governor you verify becomes your main; any you verify after it are linked as farms. A governor already linked to someone else is refused, never moved. Legal basis: our legitimate interest, and the alliance's, in knowing that the people in its server are its members.
• The screenshot of your governor profile. You post it in the verification channel. The bot accepts a PNG, JPEG or WebP picture of up to 8 MB, files it with this site as evidence for an officer to look at, and then deletes your message from Discord. The bot keeps no copy. On its own server the bot reads the governor id off the picture, only to fill in or check the id you give; what it reads is not kept, and the id you then verify with and the roster are the check. The picture is for a person. Legal basis: the same legitimate interest.
• The officer card. If the roster does not have your governor id, or its name does not match the one you typed, the bot posts a card in the server's officers' channel. It shows your Discord user, the name and id you typed, what the roster says, and a link to the screenshot on this site, which only signed-in officers can open. An officer approves or rejects you, and their Discord user id is kept as the person who decided.
• Your nickname. Once you are approved, the bot sets your nickname in that server to your in-game name and governor id, as Name | 12345678, and gives you its Verified role. Everyone in the server can see both. Verifying a farm leaves the nickname as it is. Discord does not let a bot rename the server's owner, who sets their own.
• Title requests and queue positions. A title word you type in the titles channel is sent to this site as a request for your main governor, and the bot answers in the channel with your place in the queue and an estimate. ?queue shows only how many people are waiting for each title. ?queue followed by a title also shows your own place in it, and never anyone else's. Legal basis: our legitimate interest in running the title queue the kingdom asked for.
• Player lookups. ?player followed by a governor id asks where that governor's city is, on the kingdom's home map or the KvK map. The answer is the map, the tile coordinates and when the city was seen there, and it is posted in the channel where it was asked, so anyone who can read that channel can read it. If this site has no recent position, it can ask the kingdom's game instances to look. The kingdom decides on this site who may ask; by default it is the kingdom's officers. Each lookup is for one governor, by an id the asker already has; the bot cannot list members or governors. The governor looked up may not be in the server and may not know they were looked up. Legal basis: our legitimate interest, and the kingdom's, in coordinating its own players on the map.
• The bot's own records. The bot keeps a small database on its server: verifications in progress and how they ended (the server, your Discord user, the governor id and name you typed, the kingdom, what the roster said, the evidence reference, which officer decided and why, and when); the ids of the messages it posted itself, such as the Verify button, the status panel and queue posts, with each channel's posting schedule; and the ?player lookups still waiting for an answer (the server, the channel, the message to answer, the governor id asked about, and when). It holds no token of yours, no password and no screenshot. The service log on that server records server ids and errors, not message text, typed names or screenshots. Legal basis: our legitimate interest in running the bot.

What reaches this site. The bot sends this site the Discord ids, the governor id and name you typed, the screenshot, the Discord id of an officer who vouches for you, title requests, role requests an officer decided, and player lookups. The site keeps the link between each governor and your Discord user, with whether it is your main, how it was verified, who verified it and when, and which kingdom it was verified in. Which kingdom a governor is in now is read from the latest scan, not stored on the link. It keeps each title request (the governor, the title, when it was asked for, given and released, and which officer gave it) as the kingdom's title ledger, and a record of what officers did through the bot: bindings and unbindings, title settings, role decisions and queue post switches. Your kingdom's officers and this site's administrators can see your links and screenshots. The screenshot is stored in a private storage bucket that only this site reads, and is opened only by a signed-in officer of your kingdom or an administrator.

Your Discord user and an account here. Your links are tied to an account on this site only when you show the site that the Discord user is yours: by signing in to this site with Discord, by linking Discord Linked Roles while signed in here, or by running /link in the server and confirming the private link it shows you while signed in here. From then on your governors appear under that account, and if your account is an owner or officer of a kingdom here, the bot treats you as that kingdom's officer. A Discord role never makes anyone an officer on this site.

Discord and the people in the server. Everything the bot posts, and everything you post, is also held by Discord under its own terms and privacy policy, not ours, and can be seen by the people who can read that channel. The server's owner and moderators run the server, not us. Messages the bot posts stay until someone deletes them.

Removing it. To have your governor links, your screenshots or the bot's records about you deleted, write to privacy@kirobyte.com and say which server and which governor ids. You do not need an account here to ask. A server's owner can remove the bot at any time; that stops it acting in the server but does not delete what it has already recorded, so write to us for that too.

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. A battle report can be read by the account that sent it and by administrators, and a saved Crucible matchup by its owner and, once shared, by anyone holding its link. Administrators and owners 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. Cloudflare R2 stores the xeroBytes Manager bot's verification screenshots in a private bucket.
• Google (Google LLC). If you sign in with Google, Google confirms who you are and sends us the details listed under Signing in with Google, and learns that you signed in to this site, which it handles under its own privacy policy, not ours. Separately, the error alerts described under No analytics and no tracking arrive in the operator's Gmail inbox, so Google holds those. Beyond that, we send Google nothing about you.
• Discord (Discord Inc.). If you use the xeroBytes Manager bot, Discord carries everything between you and the bot, and holds the messages in the server under its own terms and privacy policy, not ours.
• Amazon Web Services (Amazon Web Services, Inc.) hosts the server the xeroBytes Manager bot runs on, so the bot's own records and service log are stored there.

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, Google, Discord and Amazon Web Services 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, Cloudflare and Amazon Web Services rely on the data processing terms and standard contractual clauses those providers make available to their customers. Google handles your Google sign-in, and Discord your use of Discord, under their own privacy policies.

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 and KvK season are kept for as long as your account exists.
• Saved Crucible matchups are kept until you delete them or your account.
• Battle reports are kept until you delete them, which you can do one at a time on the battle reports page or through the API, or until your account is deleted.
• Upload tokens are kept for as long as your account exists, including revoked ones, which can never be used again. The upload counter is kept for as long as your account exists; its counts start over each minute you upload.
• 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.
• Discord bot screenshots are kept for as long as the governor they verified stays bound, and deleted when an officer unbinds it, within minutes of the unbinding. A screenshot sent for a verification that never completes is deleted seven days after it was sent. They are evidence for an officer, not a profile picture.
• Discord bot governor links are kept for as long as the link exists, until an officer unbinds it or you ask us to remove it. The kingdom's title ledger and its record of what officers did through the bot are kept for as long as the kingdom uses the site; ask us and we will remove the entries about you. A /link that is not confirmed lapses after fifteen minutes.
• The Discord bot's own records. A verification that is waiting for a screenshot expires after 15 minutes, but the record of each verification stays in the bot's database, and there is no deletion routine for it yet; we delete them when you ask. A waiting player lookup is removed once it is answered, or after 30 minutes. The ids of the bot's own messages are kept until the message or its posting schedule is removed. The service log is kept until the server's system log rotates it out.
• 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.
• Error alerts are deleted from the operator's mailbox 30 days after they arrive.
• 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, home kingdom and KvK season, your saved Crucible matchups, your battle reports, upload tokens and upload counter, 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.