Gizlilik Politikası

Template privacy policy for a self-hosted instance, written against what this code actually stores.

Template, not legal advice. The technical description below is accurate to this codebase, but the legal framing has not been reviewed by a lawyer and is not adapted to any particular jurisdiction. Whoever runs this instance must read it, fill in every highlighted placeholder, confirm it matches what their deployment really does, and take proper advice before running a public site.

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.
There is still no password reset: an address on file does not yet recover a forgotten password. Section 4 says why, and 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 table

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

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 have it 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, no URL, no page titles: which pages you opened is not recorded anywhere.

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 hash of their IP — never the content. 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 — plus who reported it: the account id if they were signed in, and otherwise a one-way hash of their browser id, never the id itself.

Image moderation recordupload_audit, upload_blocked_hashes

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. 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 mailed nothing at all. 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 failed sign-ins. Every key there is a one-way hash — of a mailbox, of a browser id, of the network a request came from — mixed with a secret this installation generated for itself, so that a copy of the database cannot be tested against a list of guesses; the row holds a count and a window, never the value it counts. They 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.

There is still no password reset, and no account recovery. A forgotten password is still a lost account. Having an address on file makes such a feature possible later; it does not mean one exists. If this page ever stops saying so, it is because one was built.

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

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 on your first visit so the operator can count visitors without an analytics service, and so a bug report you send without an account can still be listed back to you on the report page. HTTP-only, SameSite=Lax, and it lasts 400 days. What is counted with it is the visit row described in section 2. 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.

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. [operator: the visitor counter (bp_vid) is the one item that is not strictly necessary — confirm whether your jurisdiction lets you set it without consent, and add a banner if it does not]

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 [contact address].

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 or because the account appeared on an official leaderboard — not because its owner has any relationship with this site. 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.

[operator: if your jurisdiction treats game account data as personal data, say so here and describe how a player can ask you to remove their account from this index]

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.
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.
static.wikia.nocookie.net — Skin artwork from the Brawl Stars Wiki, used where the Fan Kit has no render for that skin, plus two fame badges the Fan Kit does not export. The wiki is run by Fandom, which funds itself with advertising on its own pages; what this site loads from it is image files.
brawlstars.fandom.com — The wiki's own file-path redirect, the last fallback when a computed artwork address misses. Your browser follows it to the wiki image host above.
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 the wiki or to YouTube yourself — 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, which is worth knowing for the wiki host in particular, since Fandom funds the wiki with advertising.

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
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

Whoever hosts this instance can see ordinary web-server request logs. The application itself does not write visitor IP addresses to its database; it logs sync activity and the last API error only.
[operator: name your host and say what its logs retain, and for how long]

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 and behind verification: two days from the start of the window each one counts. The failed sign-in throttle: a day after the last failed attempt. They hold one-way hashes, never addresses or IP addresses — and for an IPv6 caller the report-form counters and the verification counters alike hash only the 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.

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.

[operator: state which framework applies to you, how someone contacts you about a request, how quickly you will respond, and which supervisory authority a complaint goes to]

12Unofficial fan content

Bu içerik resmî değildir ve Supercell tarafından onaylanmamıştır. Daha fazla bilgi için Supercell'in Hayran İçeriği Politikası'na bakın. Hayran İçeriği Politikası

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 Duyurular page.

Questions go to [contact address]. This policy is effective from [effective date], and the operator of this instance is [operator name and legal form].

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