Privacy Policy

How brawl-peek.com handles data, written against what this code actually stores.

1In short

You can use the whole site without an account and without giving anything away.
An account needs a username, a password and an email address, which is verified: a six-digit code is sent to it, and the account is only created once that code is entered. Until then no account exists. Section 2 lists everything the account stores.
You can instead sign in with a third-party provider (Google, and Discord where the operator has configured it). That provider tells this site your account id there, your display name and your email address, which is stored on the account the same way. Section 9 covers what the provider sees.
The address is used to prove itself, and for account-security notices. Section 4 lists every message it can ever receive — a list generated from the code that sends them rather than counted by hand, because the last two hand-written counts on this page were both out of date within a release. There is no newsletter, it is never sold or shared with anyone, and deleting the account deletes it.
The bug-report form takes a separate optional address that belongs to that one report and not to any account. Section 3 covers it in full.
The password is never stored; only a salted scrypt hash of it is.
A forgotten password can now be reset, but only to a verified address: the code is mailed to the address on the account and to nothing else, so an account that never proved one still cannot be recovered. Section 4 says what the address is and is not good for.
There is no analytics, no advertising and no third-party tracker in this codebase.
Nothing is shared with other instances of this software. Each one is an entirely separate site with its own database.

2What is stored when you create an account

Everything below lives in this instance’s own SQLite file, and the list is generated from the database tables themselves rather than written out by hand: a table added to this site and not described here fails this project’s own tests. Sections 3 and 5 cover the bug-report form and your browser; between the three of them, this is everything.

Usernameusers table

Your chosen name, 3 to 20 characters of letters, digits and underscores. It is unique regardless of capitalisation, and it is shown publicly next to anything you post on the boards.

Password hash and saltusers table

A 16-byte random salt generated for your account, and a 64-byte scrypt hash of your password computed with it. The password itself is never written down anywhere, and the hash cannot practically be reversed — which also means nobody, the operator included, can look up or be shown your password. The operator’s own account list shows only whether a password is set.

Email addressusers table

The address you registered with, stored trimmed and lowercased, together with the moment it was verified. One address belongs to at most one account. It is used to send the verification code, and afterwards only for the account-security notices section 4 lists in full. No newsletter, no marketing, and it is never sold, shared or handed to any third party. You can change it from the account page, which demands the same proof of identity as deleting the account and verifies the new address before the old one is released.
Accounts created before this site collected addresses have none, and are not required to add one; an account created through a third-party provider carries the address that provider reported, marked verified only if the provider said it had verified it.

An address waiting to be verifiedemail_verifications, password_resets

This row exists before any account does. When someone types an address into the registration form, this site stores that address, the chosen username, a scrypt hash of the chosen password, the language, and a scrypt hash of the six-digit code — never the code itself. If the code is entered, the row becomes an account and is consumed. If it is not, nothing is ever created: the row expires after 15 minutes and is deleted within a day of expiring. The same kind of row is used when an existing account changes its address.
That window is the one time this site holds an address belonging to somebody who has not agreed to anything — including a stranger whose address somebody else typed in. The verification counters described in section 3 are what stop that being used to send mail at people, and they are their own budget, separate from the report form’s: at most 3 codes to one mailbox per day, 3 different mailboxes per browser per day and 5 sends per browser per day; from one caller — a whole IPv4 address, or one IPv6 /48 prefix — 10 sends an hour, 3 different mailboxes an hour and 6 in a day; and across the whole site 40 an hour and 100 a day. Those two site-wide figures are shared with everyone, including anyone abusing the form: once either is used up, no code is sent to anybody until its window ends, so registration and address changes wait. A request this server cannot attribute to both a caller and a browser is sent nothing at all, and “one mailbox” means the mailbox rather than the spelling — a +tag does not buy a second allowance, although a forwarding address or your own catch-all domain is a different mailbox to this server.
A forgotten-password reset keeps its own row, in a second table: the account id, a scrypt hash and salt of the six-digit code — never the code — how many times it has been sent, the timestamps, the moment the account’s address was verified, and — for at most an hour after a reset finishes — a salted digest, never the value, of the single browser session that reset signed in, which the screen confirming the reset clears the moment it shows it. No address at all: the address is on the account row already. The row is consumed the moment the code is used, expires after 15 minutes, goes when the account goes, and is deleted a day after it expires or is used, swept by the next request this form takes for any address at all — so where nobody is asking for reset codes, the last such row waits until somebody does. Wrong codes are not written to it — they are counted in the same throttle table as everything else in section 3, against the network that typed them, so that a stranger guessing cannot take a code out of its owner’s inbox. Reset codes have their own send budget, separate from the verification one above so that neither form can be used to observe the other: at most 8 codes to one mailbox a day, of which only the first 3 may go to a network that has already had one sent there — the rest are kept for a network that has spent none, so one or two networks can no longer take your day; taking all of it needs at least 6 different ones, and if that happens to you the report form on the forgotten-password page is the way back in — and at most 3 from any one network, which may make 5 requests an hour and 15 a day whatever address it types. A request this server cannot attribute to a network is sent nothing at all. The site-wide figures for this form are an alarm in the operator’s log rather than a ceiling: a code only ever goes to an account’s own verified address, so the volume is already bounded by the two numbers above.

Third-party sign-inoauth_identities table

If you sign in with Google (or Discord, where the operator has configured it), this site stores which provider it was, the account id that provider uses for you, the display name and the email address it reported, and when the link was made. It is refreshed each time you sign in that way, and it is removed when you unlink the provider or delete the account. Access tokens from the provider are used once, in memory, and never stored or logged.

Provider sign-in still in progressoauth_reauth, oauth_link, oauth_confirm

Short-lived server-side rows that exist only mid-flow. One records that you have just proved yourself at a provider, which is what the change-email, set-password and delete-account forms accept from an account that has no password; one holds a pending “connect this provider to the account I am signed into” request; one records that a trip to the provider was started by you clicking the button here rather than by a link somebody sent you. Each holds a random token, your account id, which provider, and an expiry a few minutes out. They are spent on first use, expire on their own, and go with the account.

Language preferenceusers table

The site language you last saved in your account settings.

Timestampsusers table

When the account was created, and when it was last used to sign in.

Avataruser_avatars table

The picture you chose for yourself, if you uploaded one, stored as image bytes plus its type and the time you set it. It is shown next to your name wherever you post. There is no avatar unless you upload one.

Bound player tagusers table

One Brawl Stars player tag you can claim as “your” account, so that your profile is one click away. Nothing the game API publishes can prove you own that player, so the claim is unverified and the account page says so; the only guarantee is that two members cannot claim the same tag. Optional, and you can change or clear it.

Profile settingsuser_profile_meta table

Housekeeping for the two actions that are rate-limited per account: when you last renamed yourself, and how many times you have tried to bind a player tag in the current window. No content, and nothing anyone else sees.

Notification preferencenotify_prefs table

One flag: whether you asked to be told about new direct messages. It exists only once you turn the switch on — off is the absence of a row — and it holds no message text, no device token and nothing about what you were sent. Browser notifications themselves are permission your browser grants and this site never sees.

Operator flagsusers table

Whether the operator has disabled the account, and whether it is an operator account. Both are null or off on an ordinary account. Section 6 covers what disabling does.

Sessionsessions table

A random 32-byte token, the account it belongs to, and its expiry, 90 days after sign-in. Signing out deletes the row; an expired row is deleted the next time it is looked up.

Bookmarksbookmarks table

Up to 25 players and the same number of clubs: the tag, the display label, an optional note and when it was added.

Viewing historyview_history table

The most recent players and clubs you opened while signed in — tag, label and timestamp — trimmed automatically to the newest 25 of each kind. You can clear it yourself from the account page.

Board posts and repliesboard_posts, board_messages

Your username as the author, the title and body you wrote, any player tag you attached, the filters on a recruitment post, and the timestamps.

Images you uploaduploads table + files on disk

The picture itself is stored as a file on the server, not in the database; the database keeps its id, your account id, its size and dimensions, a checksum, the timestamps, and which post or message it is attached to. Every upload is re-encoded before it is stored, which removes all EXIF metadata — including the GPS coordinates most phones write into a photo — and the original file is never kept. Images are served from an address that cannot be guessed, but anyone who has that address can open it, so treat a link you share as public. Pictures attached to direct messages or chat are deleted 180 days after upload; pictures on a board post live as long as the post. You can delete your own at any time, deleting your account removes all of them, and every image carries a Report link that anyone — signed in or not — can use to ask for it to be taken down.

Public chat messageschat_messages, chat_archive

The display name you posted under, the message text, the time it was sent, and — for a message sent without an account — the random browser key described in section 5, which is how “this is my message” is decided when there is no account. The room shows the newest 500 messages; older ones, and every edit, unsend, moderator removal and automatic trim, are kept in an archive that only the operator can read.

Direct messagesdm_messages table

The sender, the recipient, the message text as written, the time it was sent, and whether and when the recipient read it.

Friendsfriends table

Who sent a friend request to whom, whether it was accepted, and when.

Direct messages are private between you and the person you send them to, in the sense that no other user can read them. They are not encrypted, they are stored as written in this site’s database, and the operator can read them. Do not put anything secret in a direct message.

There is no screen on this site that lists everybody’s conversations. Opening one account’s direct messages requires all three of the admin key, an account the operator has flagged as theirs, and that account’s own password re-entered within the last fifteen minutes; the operator must name the account and type a reason before anything is shown. Every such access is written to an append-only log — who looked, at whose messages, when, and the reason given — and that log records the access, never the content.

Everything above exists only once you have an account. What follows does not: it is recorded about anyone who loads a page here, signed in or not.

That this browser visited todayvisitor_days table

One row per browser per day, so the operator can see how busy the site is without an analytics service. It holds the date, the random bp_vid id from section 5, how many pages that browser opened that day, the site language it was reading, the two-letter country the CDN reported, and — if that browser signed in — the account id, which is how the share of visitors who are members is worked out. No IP address and no page titles. Which individual pages you opened is not recorded; the row below records the SHAPE of the first one only. These rows are written only for a browser that pressed Accept on the cookie banner (section 5): a browser that declined, or has not answered, is not counted and nothing is written for it. Counting starts after the click, so the page you first landed on, and the site that sent you there, are not recorded.

Whether that visit looked like a person or a crawlervisit_class_days table

A second row per browser per day, beside the one above and keyed the same way, added so that the operator’s own dashboard stops calling crawlers visitors — most of the traffic to this site is automated, and counting it as people was making the site look busy while nobody was reading it. It holds, for that browser on that day:

One word for what the visit looked like — human, crawler or suspect — and, when the client announced itself as a bot, one word for the kind: search engine, AI, link preview, or other. Those words are worked out from your browser’s User-Agent header and from the standard Sec-Fetch-* headers every browser sends. The User-Agent string itself is never stored, and is never passed to the part of the server that writes this row. Only the one word is. It is a guess about a request, not a judgement about you: reading the site normally produces human, and nothing on the site behaves differently for any of the three.
The host of the page you arrived from — google.com, discord.com — and nothing else from it. Never the full address, never its path or its query string, and never recorded at all when you arrived from another page on this site, so this cannot become a record of what you read here.
A campaign tag, only if the link you clicked carried one — the utm_source, ref or utm_campaign value in the URL. This site does not add those to its own links; it keeps one when somebody else’s link has it.
The shape of the first page you opened, not the page. A visit to one player’s profile is stored as /players/:tag — the tag itself is dropped, and so is a support ticket’s reference code, which is the only credential for reading that ticket. The stored value is checked against a fixed list of this site’s own routes: anything that is not on it — a mistyped address, a link that no longer exists, a probe from a scanner — is stored as /other and not as you typed it.
The site language, the two-letter country and how many pages were opened, and — if that browser signed in — the account id, exactly as in the row above. The two rows are keyed the same way and hold the same answers to those four questions; this one adds the classification.
Counts used to spot automation: a rolling count of how many pages that browser opened in the most recent minute it was active, the clock time that minute-long window started, and how many different site languages it asked for together with which ones — kept as 23 yes/no bits, one per language, so it records that the browser read in Chinese and English but not in what order or at what time. A browser that opens more than 30 pages in one minute, more than 60 pages in one day however slowly, or reads in more than 3 languages in a day, is recorded as suspect for that day. The minute counter is not a per-day maximum: it is reset whenever a minute passes with no page load, so by the end of a quiet day it usually reads 1.

Rows written before this was added carry no classification, and none was invented for them; the dashboard shows them separately as unclassified.

And the operator keeps records that are about you but are not part of your account. They are listed here because section 6 deliberately does not delete them, and a policy that only describes what deletion removes would be describing half the truth.

Operator action logadmin_audit table

One row per operator action on an account — deleting it, disabling it, resetting its password, revealing its address in full — with the account id, the username at the time, and when. Deliberately kept after the account is gone: it is the record that the operator acted, and an accountability log that a deletion could erase would be no log at all. It holds no address and no IP address.

Direct-message access logadmin_dm_access, admin_dm_proof

An append-only record of every time the operator opened somebody’s direct messages: who looked, whose messages, which range, the reason they typed, when, and a one-way hash of the network they connected from (the whole IPv4 address, or the first 48 bits of an IPv6 one) mixed with a secret this installation generated for itself — never the content. Rows written before that rule held an unsalted hash of the whole IP address instead; those values were not deleted, because this log is the record that the operator looked, but each was replaced by a hash of that old hash mixed with the same secret — so it still shows which of those older reads came from the same address, and no longer says anything about the network. Beside it sits the short-lived proof row that says the operator re-entered their own password within the last fifteen minutes, keyed by a hash of the session that made the claim.

Reports about an imageupload_reports table

If somebody reports an image, this stores which image, the reason chosen and any note typed, when, and whether it is still open. If the reporter was signed in, it also stores their account id and a one-way hash of the network the report came from (the whole IPv4 address, or the first 48 bits of an IPv6 one) mixed with a secret this installation generated for itself: that pair is what lets reports from established accounts on different networks count as agreement when an image is hidden automatically for spam, violence or the like. A report sent without signing in stores neither — nothing about who sent it is kept on the row. Reports filed before this rule held a hash of the reporter’s whole address instead; those hashes have been erased from them. Not every report gets a row of its own: a repeat report of a serious reason (illegal, involving a minor, or non-consensual) that is already on file for that image — from the same network (or, if signed in, the same account) on the same day, or once the site has stored its daily number of such reports — is counted without storing a new row, so its note is not kept; the reporter is told so. The first report of each serious reason on an image is always stored, with its note, and the operator reads the notes.

Image moderation recordupload_audit, upload_blocked_hashes, upload_target_changes

What the operator did about an image and when, and the checksum of anything taken down, so the identical file cannot simply be posted again. The checksum is of the re-encoded picture; no copy of the image is kept in it.

Upload suspensionuser_upload_bans table

If the operator suspends one account’s ability to upload, this holds that account id, until when, and the reason. There is no row for an account that has never been suspended.

3What is stored when you send a bug report

The report form at /support works without an account and without an email address. What it stores is the report itself, plus the little that makes a reply findable and keeps the form from being abused.

The reporttickets table

The type (bug, idea or other), the subject and the text you wrote, the status, and when it was sent and last updated. Whatever you type into those boxes is stored as written — so do not put passwords or other secrets in them.

Reference codetickets table

A random 8-character code minted for the report. It is the address of the report’s own page, and anyone holding it can read that thread, which is why the page says not to post it publicly.

Email addresstickets table, only if you type one

Optional, and blank unless you volunteer it. This is a different address from the one on your account (section 2), even if you type the same characters into both. It belongs to this report; it is not copied to the account, changing one does not change the other, and deleting the account does not delete this one. It is used only for notices about that one report — section 9 lists every one of them, generated from the code that sends them — and not one of them carries the text of the report or of the reply. The receipt carries the reference code and no link whatsoever, because the address was never verified and a link would lead a stranger to a page showing text somebody else wrote; the reply notice, which exists only once the operator has read the report and answered it, does carry the link to the report's page. It is never used for anything else, there is no newsletter, and it is never sold, shared or handed to any third party. The address is not verified, so the operator can delete it from a report on request; deleting the report deletes it too, and once it is gone no further notice is sent. Reporting anonymously, with the box left empty, works exactly as it always did.

Where it came fromtickets table

The browser id below, the site language you were reading, the two-letter country your CDN reported, the path on this site you were on if the form was opened from a page link or you typed one, and your browser’s user-agent string. Your account is linked only if you were signed in when you sent it.

Repliesticket_messages table

What the operator writes back, and when. Replies appear on the report’s page.

Abuse counterssupport_rate table

Counts of recent submissions and notifications. Every key is a one-way hash, salted with a secret this installation generated for itself — of the network your request came from, of your browser id (bp_vid, below) and, where one was given, of the destination email address — never the values themselves. On IPv6 only the first 48 bits of your address, the network prefix, go into that hash; the rest of the address is never hashed or stored. On IPv4 it is the whole address. What the limits actually do: one caller — a whole IPv4 address, or one IPv6 /48 prefix — can make this site mail at most 2 different strangers in an hour and 4 in a day, and crossing the daily figure stops every receipt from that caller for the next 24 hours; one destination mailbox receives at most 4 messages a day — counted against the mailbox itself rather than the exact spelling, so adding a +tag (or, at Gmail, extra dots) does not buy a second allowance, although an alias this server cannot see, such as a forwarding address or your own catch-all domain, is a different mailbox to it; the site as a whole sends at most 60 an hour and 200 a day, and that ceiling is shared with everyone, including anyone abusing the form — once it is used up, no receipt and no reply notice goes to anybody until its window ends. A prefix is shared by real people, so those ceilings are shared too: on a busy network you may not get the emailed copy of your reference code. The form also limits the reports themselves — 3 an hour from one browser, 8 an hour from one caller — and that one refuses the report, not just the mail; it is the same limit everyone behind carrier NAT has always had. There is a tighter per-browser limit on top of those, but because that cookie is sent by your browser and can be replaced at will it is never the only check — and a submission this server cannot attribute to a caller is refused outright, so nothing is stored or mailed. Each counter is deleted two days after the window it counts began, swept the next time the form is used.

The same counters, behind the other formsverify_rate, upload_counters, auth_throttle

The same shape of counter sits behind the other forms that can be hammered: the verification mail behind registration and address changes, image uploads and image reports (including how many images each account has helped hide automatically that day, how many images a network or an account has flagged for priority review that day, and whether a network — or, for a signed-in report, an account — has already reported a given image for a given serious reason — illegal, involving a minor or non-consensual — that day), failed sign-ins, a wrong current password typed when changing your password, deleting your account or — for the operator — reopening direct messages, the chat room (for visitors who are not signed in, and edits and unsends by signed-in members), the player search page’s requests to load the profiles of results this site has not fetched yet, and the Refresh now button on a player or club page. Every key there that stands for a person, a browser or a network is a one-way hash — of a mailbox, a username, a browser or session id, an account id, or the network a request came from (the whole IPv4 address, or only the first 48 bits of an IPv6 one), on its own or together with an image id and a report reason — mixed with a secret this installation generated for itself; the row holds a count and a window, never the value it counts. A few counters are site-wide totals shared by everyone (for example how many images were hidden automatically today); their keys are fixed names, not hashes, and say nothing about who was counted. That secret is kept in the same database, so it stops a leaked table or export being tested against a list of guesses, but not somebody holding a copy of the whole database. These counters are what makes a per-address and per-browser ceiling possible without keeping a list of addresses or browsers, and each is deleted once it is stale — section 10 gives the periods.

Mail is sent through Cloudflare’s email API, which therefore sees the address and the message. What can be sent to that address is the list in section 9, and nothing there is added by hand. The mailbox those notices come from is not monitored: replying to one reaches nobody, which each of them says, and the report’s own page is the place to answer.

4What the address on your account is for — and what it is not for yet

Registration used to ask for nothing that identified you off this site. It now asks for an email address and verifies it, because an account that can post on the boards, send direct messages and upload pictures needs a way for its owner to be warned when somebody else takes it over. That warning is the whole point of the address.

A forgotten password can now be reset, and only through a verified address. The forgotten-password page mails a six-digit code to the address on the account — never to the address typed into the form, and never for an account whose address was never verified or which the operator has disabled. The page answers the same way whatever the address is, and decides that answer before it has looked the address up, so it cannot be used to find out who has an account here. Finishing a reset replaces the password, signs the account out on every device, and sends a notice to that same address. An account with no verified address still has no way back in, and neither does anyone who has lost access to that mailbox; the way to ask for help in either case is the report form.

So this is everything the address is used for, in full — every message this site is capable of sending to it:

the six-digit code that registration sends, without which no account is created
the six-digit code sent to a new address when the address on an account is changed
a warning to the old address once the change is done, so it cannot happen quietly
a heads-up to you when somebody else types your address into the registration form
a heads-up to you when somebody tries to move your address onto a different account
the six-digit code the forgotten-password page sends, and only ever to an account's verified address
a notice once that code has been used to reset the password, so it cannot be replaced quietly

Two things are worth spelling out about that list. Changing the address demands the current password (or a fresh provider sign-in), because whoever controls the address is in a position to control the account. And the two notices about somebody else using your address are why neither the registration form nor the change-address form can be used to ask this site whether an address already has an account here: both answers cost the same message and the same time, so there is no difference to measure.

What it is not used for: marketing of any kind, newsletters, announcements (those are published on the site), or anything at all about other people’s accounts. It is not shown to other members. The operator’s own account list shows addresses masked, as ***@example.com, and every time one is revealed in full the reveal is written to an operator log.

An address volunteered on a bug report is a separate thing entirely. It is attached to that one report, not to your account: it cannot be used to sign in, and nothing about the account is ever sent to it.

5Cookies and browser storage

bi_sessioncookie

Set when you sign in, so the server knows who you are. HTTP-only, so page scripts cannot read it, SameSite=Lax, marked secure whenever your browser reached the site over https, and valid for 90 days. Deleted when you sign out. Over https your browser stores it under the host-locked name __Host-bi_session, a rule that stops any other host — a sibling subdomain included — writing a session cookie into your browser; over plain http, which browsers refuse that name on, the bare name is used. Without it you are simply anonymous — the site works.

bi_localecookie

Set in your browser when you pick a language, so that visiting the site without a language in the URL sends you to the one you chose. It holds a language code and nothing else, lasts a year, and is readable by page scripts. If it is absent, the language is negotiated from your browser’s Accept-Language header instead.

bp_vidcookie

A random id with no meaning outside this site, set only after you press Accept on the cookie banner, so the operator can count visitors without an analytics service, and so a bug report you send without an account can be listed back to you on the report page. HTTP-only, SameSite=Lax, and it lasts 400 days. Without it the report form still works - the report is stored and its receipt mailed - but it is not listed back to you, and the reference code is the way to find it again. Pressing Decline, then or later from the Cookie settings button in the footer, deletes the cookie; visit rows already recorded under it are kept (section 10). What is counted with it is the two visit rows described in section 2 — the daily count, and the classification row that says whether the visit looked like a person or a crawler. It is not an analytics profile and it never leaves this server — but it is not unconnected to you either: a bug report sent from this browser stores this id on the report, alongside your account id if you were signed in. On that row the two are linked, and the operator sees it when they open the report.

bp_consentcookie

Your answer to the cookie banner: 1 if you pressed Accept, 0 if you pressed Decline. Strictly necessary - without it a refusal could not be remembered and the banner would ask again on every page. HTTP-only (the page’s scripts cannot read it), SameSite=Lax, and it lasts 400 days from the last time you answered; it is written only when you answer, never on an ordinary page view.

bi_themelocalStorage

Dark or light. Stored in your browser only and applied before the first paint so the page does not flash. It never reaches the server.

bp_chat_keycookie

A random id minted by the server the first time you post in the public chat room without an account. It is how the room knows a later message is from the same person, so that you can take back something you wrote. HTTP-only, SameSite=Lax, and it lasts a year. Over https your browser stores it under the host-locked name __Host-bp_chat_key, so that no other host can write one into your browser and adopt what you posted; over plain http, which browsers refuse that name on, the bare name is used. It is never sent to other visitors. Two things follow from it being a browser cookie rather than an account: clearing it loses control of anything you posted before, with no way to recover it, and anyone else using this browser profile inherits that control. That is why a message posted without an account can be taken back but not edited, and only within fifteen minutes. Reading the room sets nothing.

bi_verifycookie

Set only while a registration is waiting for its six-digit code. It holds a random handle for the pending signup and nothing else — not the address, not the username, not the password — and it is how the code screen knows which pending signup is yours, because no account exists yet. HTTP-only, SameSite=Lax, marked secure whenever your browser reached the site over https, and it expires with the code, 15 minutes after the last one was sent. Entering the code or cancelling deletes it.

bi_oauth_state, bi_oauth_verifier, bi_oauth_next, bi_oauth_mode, bi_oauth_linkcookie

Flow state for a Google or Discord sign-in, set when you press the button and wiped by this site the moment the provider sends you back. They hold the one-time values that make the round trip tamper-proof and the page you should land on afterwards. HTTP-only, SameSite=Lax, short-lived — ten minutes — and never set if you never use a provider button. Over https the first four go out host-locked, as __Host-bi_oauth_state and so on, which is why they are scoped to the whole site rather than to /api/auth: that prefix is a browser rule and it requires it. The link cookie is the one left unprefixed, deliberately; the reasoning is written at its declaration in the source.

bi_oauth_reauthcookie

Set for five minutes after you sign in again through a provider, as proof that the person at the keyboard just passed that provider’s own check. It is what the change-email, set-password and delete-account forms accept instead of a password from an account that has none, and it is spent on the first such action. HTTP-only, SameSite=Lax, and marked secure whenever your browser reached the site over https. It is only ever handed out when you take the “Confirm with” trip from your own account page deliberately: an ordinary sign-in, and any sign-in someone else’s page sends your browser on, comes back without it.

bp_chat_namelocalStorage

The display name you chose for the public chat room without an account. Stored in your browser so you are not asked again; it is sent to the server with each message you post.

bi_recent_viewslocalStorage

The players and clubs you opened, kept for the “recently viewed” list a signed-out reader sees on the home page. Your browser only — it is never sent to the server, and signing in replaces it with the account-side history described in section 2.

bp_skin_col:<tag>localStorage

The skins you ticked off yourself in the collection tool, per player tag. The game API publishes no owned-skin list, so this is your own declaration and it never leaves your browser.

bp_mascot_hiddenlocalStorage

Whether you dismissed the mascot. Your browser only.

bp_dm_notify_leaderlocalStorage

A short-lived marker so that, with several tabs open, only one of them polls for new direct messages. Your browser only.

bp_chat_ball_poslocalStorage

Where you dragged the floating chat button. Your browser only.

bp_chat_viewlocalStorage

Whether the chat was left minimised, open or expanded, and when. Your browser only, and an “expanded” setting older than half an hour is ignored.

bi_tab_url:<tab>sessionStorage

The last page you were on inside each section of the top navigation, so that tapping “Stats” again returns you to the stats page you were reading rather than the index. Session storage, so it is gone when the tab closes, and it never reaches the server.

That is what this site puts in a visitor’s browser, and it is the whole of it — not because somebody checked, but because the page is generated from the same list the build checks against the code. The only other names this software sets are the operator’s own, in the site owner’s browser after they enter the admin key:

bp_admincookie

The site owner’s own sign-in to the admin screens, set only in their browser after they enter the admin key. HTTP-only, and over https host-locked as __Host-bp_admin.

bp_admin_revealcookie

A 30-second ticket the site owner’s browser is given to unmask one account address at a time. Every use is written to the operator log described in section 2.

There is no third-party cookie, no advertising cookie and no cross-site identifier here: every item above is either required to keep you signed in, a step in something you started yourself, a preference you set, or a first-party counter that is read by nobody but this server. The one item that is not strictly necessary is the visitor counter, bp_vid, and it is optional: a banner asks on your first visit, and until you press Accept it is not set and your visits are not counted. Your answer is kept in bp_consent, which is strictly necessary - without it a refusal could not be remembered. You can change your answer at any time with the Cookie settings button in the footer.

6Deleting your account

The account page has a delete button. It asks for your current password first (or, for an account that signs in only through a provider, a fresh sign-in there), because deletion is immediate and permanent and a stolen session cookie must not be enough to trigger it.

Deleting the account removes the users row and, with it, your email address and the moment it was verified, your bound player tag, every session, every bookmark, your whole viewing history, any third-party sign-in link, your avatar and profile settings, every direct message you sent or received, every friendship and pending request, every image you uploaded, and any verification code still waiting to be used. The database rows for your uploads go immediately; the image files themselves are unlinked from disk by the sweeper that runs on a schedule, normally within the hour.

Your public chat messages are taken out of the room at the same moment and stop being shown to anyone: the text is cleared and your name is replaced with a neutral placeholder, exactly as if you had taken every message back yourself. A copy stays in the operator-only archive for up to 30 days, so that a report filed about a message shortly before you left can still be answered, and the text is then deleted. Two things are kept longer, deliberately: the record that a message existed and was withdrawn, which holds no text and no name, and any message a moderator had already removed, which keeps its text and the name it was posted under because it is the operator’s record of a moderation decision. Deleting an account is not a way to erase a moderation record.

Board posts and board replies are not deleted. The link to your account is cleared, but the post text and the author name recorded on the post stay visible, so that conversations do not collapse when one participant leaves. If the operator deletes an account — see below — the author name on those posts is replaced with a neutral placeholder as well.

Bug reports are kept and become anonymous: the report stays readable by its reference code, with no account attached. The separate address you may have typed on a report (section 3) belongs to the report, not to the account, and is not removed by deleting the account — ask the operator to delete it, or delete the report.

The operator can also delete an account, and can disable one without deleting it. A disabled account cannot sign in and its sessions are ended, but nothing it owns is destroyed and it can be enabled again. Operator deletion destroys exactly the same things the list above describes. Both actions, and every time the operator reveals an account address in full, are recorded in an operator log.

If you want your posts gone, delete them from the boards before deleting your account, or ask the operator at [email protected].

7Game data this site indexes

Separately from anything about site visitors, this instance keeps an index of public Brawl Stars game data retrieved from Supercell’s developer API: player and club profiles and their raw API payloads, name history and club history reconstructed from successive polls, hourly progression snapshots, equipped skins, and archived battle logs.

That data is about game accounts, not about the person reading this page, and it is indexed because someone looked the account up here, because the account appeared on an official leaderboard, or because it appeared in a battle log or club roster this site indexed — not because its owner has any relationship with this site. An account indexed only from a battle log or a club roster starts as its tag and name alone; its full profile and raw API payload are fetched and stored when the refresh queue reaches it, or sooner when it appears in someone’s name-search results here, which fetches the profile of each such account scrolled into view. It is retained whether or not anyone here has an account, and an account that the API reports as deleted is dropped from the index.

Opening a player or club page while signed in records that visit in your own viewing history, and it also refreshes that account’s entry in the shared index. The index itself does not record who looked at what.

Asking for your account to be removed. Write to [email protected] with your player tag. Once the operator removes it, the site stops indexing that tag for good and deletes what it holds under it: the profile and its stored API data, name and club history, progression snapshots, equipped and previously seen skins, and the battle log archived under that tag. Its page, share card and preview image then say only that the player asked to be removed, and nothing is fetched for it again.

What is kept: the tag itself on the removal list, with the date and an optional short operator note - that entry is what stops the account being indexed again - and an entry in the operator log saying the removal was made. Other players’ records that include you are theirs, so they stay, but you are shown in them as “Removed player” with no name, tag or link: a battle archived under a teammate’s or opponent’s tag (the stored raw data of an archived battle is blanked after 30 days and the battle is deleted after 90), and a club roster until the club is next fetched after you leave it. Anonymous totals already computed (tier-list counts, skin usage) carry no tag and stay. Backups taken before the removal still contain what they held then.

The removal is immediate on the site. A link-preview image made before it can be served from a cache for up to a day, and copies already held by others - chat-app previews, search engines - are outside this site’s control; the removed page tells search engines not to index it. The operator can undo a removal, which only takes the tag off the list: nothing deleted comes back, and the account would be indexed afresh only the way any new account is. Removing an account from this site does not affect the game or Supercell’s own leaderboards.

8What this site does not do

No analytics service, no telemetry, no session recording, no heatmaps.
No advertising, no ad network, no tracking pixel, no advertising identifiers.
No third-party JavaScript of any kind — every script on the page is part of the app.
No profiling, no automated decisions about you, and nothing sold or shared for money.
No phone number, payment detail or precise location is collected, ever, and this site never asks you for your real name. The one name-like thing it can hold that you did not type here is the display name your sign-in provider reports, if you use one — which for many people is their name there. It is stored on the provider link described in section 2, and on an account that a provider sign-in created it is what the username was made from.
Every email address this site holds sits in one of these columns, and that is the whole of it — not because somebody counted, but because the list is generated from the schema:
- users.email — the verified address on an account (section 2)
- tickets.reporter_email — the optional address volunteered on one bug report (section 3)
- email_verifications.email — an address waiting on a registration or an address change, held for fifteen minutes at a time before it becomes the account's or is deleted (section 2)
- oauth_identities.email — the address a sign-in provider reported, kept on the provider link. Usually the same address as the account's, because a new account takes it from there — but if you link a provider to an account that already had a different address, both are held (section 2)
No email address is ever sold, rented, shared with another site, used for marketing, or used to contact anyone about anything other than the account or report it belongs to.
No password is ever shown to anyone, the operator included — there is no plaintext password stored anywhere to show, and the operator’s account list deliberately has no way to reveal one.

9Third parties involved

Supercell developer APIserver to server

Game data is fetched by this server, not by your browser. Supercell sees this instance’s server making requests; it does not see you.

Brawlifyserver to server

Map and event metadata is fetched by this server. The artwork Brawlify publishes is a separate matter — your browser loads it directly, and it is listed with the other image hosts below.

Image hostsyour browser, on ordinary pages

Images are not copied onto this server. Each one is requested by your browser from the host that publishes it, so that host sees you the way any third-party image host does:

cdn.brawlify.com — Brawler portraits, profile icons, club badges and map images — the artwork on nearly every page of this site. On the skin pages, a skin the Fan Kit has no render for shows its brawler's portrait from here.
media.ffycdn.net — Official Supercell Fan Kit art: the skin renders on the skin pages, and the small icons beside trophies, ranked divisions and fame tiers. This is Supercell's own Fan Kit CDN, hotlinked as the Fan Kit asks; nothing from it is copied onto this server.
i.ytimg.com — Video thumbnails on the Brawl videos tool, and only on that page. YouTube's terms require the thumbnail to be shown from the address their API returns, so the image is loaded from Google's thumbnail host rather than copied here.

Nothing is sent to any of them beyond an ordinary image request: the address of the image, your IP address, your browser’s user-agent, and — as with any image on any site — the fact that the request came from this site. No cookie this site set, no account id, nothing you typed and nothing about the page you were reading goes with it. They are plain image requests, not scripts and not embedded frames; there is no third-party JavaScript anywhere here, as section 8 says. Whether one of those hosts already holds a cookie of its own in your browser — because you have been to YouTube yourself, for example — is between you and them: this site cannot set, read or see it. What each host does on its own side is outside this policy and outside this site’s control.

flagcdn.comthe operator's browser only

A small flag image beside each country on the operator's own admin dashboard. No page a visitor can reach requests it.

Google, and Discord where configuredsign-in, in your browser

Only if you choose to sign in with one of them. You are sent to that provider, you authenticate there — this site never sees the password you use with them — and the provider hands this server your account id there, your display name and your email address, plus whether it considers that address verified. The provider therefore knows you signed in to this site and when. This site asks for nothing else, uses the access token once in memory, and never stores or logs it. Unlinking the provider on the account page removes what was stored; a provider with no credentials configured is not offered at all.

Cloudflare Email Sendingserver to server

Every message this site is capable of sending goes through it, and this is all of them:

the six-digit code that registration sends, without which no account is created
the six-digit code sent to a new address when the address on an account is changed
a warning to the old address once the change is done, so it cannot happen quietly
a heads-up to you when somebody else types your address into the registration form
a heads-up to you when somebody tries to move your address onto a different account
the six-digit code the forgotten-password page sends, and only ever to an account's verified address
a notice once that code has been used to reset the password, so it cannot be replaced quietly
a receipt when the report arrives, carrying the reference code and deliberately no link
a notice each time the operator replies, which does carry a link to that code's page

Cloudflare receives the destination address and the message it is sending. No address is passed to it for any other purpose, and there is no mailing list of any kind. With no mail credentials configured, the site simply sends nothing — registration then stores the address without being able to verify it, and says so on the form.

The operator's hosting providerinfrastructure

This site is served from the operator’s own computer in Taiwan and reached through a Cloudflare Tunnel, so Cloudflare, Inc. carries every request between your browser and the site and handles what it sees under its own privacy policy. The application itself does not write visitor IP addresses to its database. On the operator’s computer, the server’s process log records service notices, sync activity and errors, and no visitor IP addresses; it starts over each time the server restarts and keeps at most the run before it. The tunnel’s log records connection events and, for a request that fails to reach the server, its time and the address it asked for (path and query) — again with no visitor IP address — and is kept until the operator clears it.

10Retention

Account data, bookmarks and board posts: until you delete them, subject to section 6.
Public chat, the visible room: the newest 500 messages. Everything older moves to the operator-only archive rather than being thrown away.
Public chat archive: kept until the operator prunes it, with one exception. When you take back your own message, the copy in the archive keeps its text for at most 30 days so that a report about it can still be investigated, and the text is then deleted; the record that a message was taken back, by whom and when, remains. Messages a moderator removed are kept as evidence for as long as the operator needs them. Deleting your account withdraws your messages from the room immediately and puts their text on that same 30-day clock; the moderator removals keep their text, as section 6 sets out.
Direct messages: until either participant deletes their account, which deletes every message between them.
Admin direct-message access log: kept indefinitely. It holds no message content.
The email address on an account: until you change it or delete the account. Changing it replaces the old address; it is not archived.
An address waiting to be verified, and the pending registration or change it belongs to: 15 minutes, after which the code stops working, and the row itself is deleted within a day of expiring. Nothing is kept from a signup that was never completed.
Bug reports and their replies: kept while the operator still needs the defect on record. An email address volunteered on one is deleted when the report is deleted, and can be deleted from it on request before then — see section 3.
Abuse counters behind the report form, behind verification and behind image uploads and image reports: two days from the start of the window each one counts. The failed sign-in throttle, the wrong-current-password counters, the chat room’s counters, the search page’s profile-loading counters and the Refresh now button’s counter: a day after the last attempt they counted. Their keys are one-way hashes (or, for site-wide totals, fixed names), never addresses or IP addresses — and every one of them that counts a caller hashes only an IPv6 caller’s network prefix, not the address.
The operator log of account deletions, disables, password resets and address reveals: kept indefinitely. It records the action, the account id, the username and the time — no addresses and no IP addresses.
Sessions: 90 days, or until you sign out.
Viewing history: the newest 25 players and 25 clubs, older entries dropped automatically.
Archived battles: pruned after 90 days.
Daily battle aggregates: pruned after 120 days.
Player progression snapshots: pruned after a year.
Indexed player and club records: kept while they exist in the game, or until the player asks for the account to be removed (section 7).
The removal list: kept for as long as the site runs, since it is what stops a removed account from being indexed again.
Visit rows (section 2): kept until the operator deletes them; there is no automatic sweep. Declining the cookie later stops new rows but does not erase earlier ones.

11Your rights and how to exercise them

Depending on where you live you may have rights to access, correct, export or erase data held about you. In practice, most of what this site holds about an account holder is visible and editable from the account page, and deleting the account removes it.

The email address on the account can be changed or replaced from the account page, and it is erased with the account. It is shown back to you masked, as ***@example.com, which is also how the operator’s account list shows it.

A bug report is visible in full on its own reference-code page. The address you may have typed on it is separate from any account address, and the operator can delete that address from the report, or the whole report, when you ask.

For anything else about your data — to see what is held, to have it corrected, or to have it deleted — write to [email protected], from the address on your account where you have one so the request can be matched to it, and the operator will answer as soon as possible.

12Unofficial fan content

This material is unofficial and is not endorsed by Supercell. For more information see Supercell's Fan Content Policy. Fan Content Policy

Brawl Stars is a trademark of Supercell Oy. Data about game accounts shown here originates from Supercell’s public API; this privacy policy covers only what this instance does with it, and not Supercell’s own handling of player data.

13Changes and contact

This policy changes when the software changes. The version on this page is the current one, and material changes should be announced on the Announcements page.

Questions go to [email protected]. This policy is effective from 2026-09-24, and this site is run by an individual, operating the site as “BrawlPeek 站長” (the BrawlPeek site owner).

The technical claims on this page can be checked against the source; the Technology page describes the same pipeline from the engineering side.