Legal
Privacy Policy
What Asbern holds about you, where it is kept, who can see it, and what you can erase.
Last updated 2026-09-07
This page describes two separate things, because they hold different data and run in different places:
- The bot — the Discord application that runs in your server. It runs on a machine, keeps files on that machine, and is what stores your levels, your balance and your activity counts.
- This website — what you are reading. It is a read-only window onto what the bot already holds, plus sign-in and, where a subscription exists, billing. It cannot change your levels, your balance, your inventory or your progress in any game. That is not a promise about intent; it is a property of the code, and there is a test that fails if it ever stops being true. What this site writes is short: the live tour's own throwaway sandbox — a scratch copy that is not, and cannot be, any real server — and, where a subscription exists, the record of that subscription's state when the payment processor reports a change. If the operator has switched on the traffic counters described below, it writes those too. All three are described in full further down, and none of them touches your levels, balance, inventory or game progress.
Who is responsible
This deployment is operated by Asbern LLC, who runs the machine the bot and this website run on and holds the files described below. You can reach them at support@asbern.gg.
Asbern identifies you by your Discord user ID — a number your Discord account already publishes. It never asks you for your email address, your phone number or your real name, and it never sees your Discord password. The card details that pay for a subscription are typed on Stripe's own pages and never reach us — see Billing, below.
Signing in with Discord
Signing in to this website is optional. Without it you can read the site, take the live tour, and see one pair of network-wide totals — no server's own figures and no member's.
When you do sign in, we ask Discord for exactly two permissions — identify and
guilds — and nothing else. In particular we do not ask for your email address and we
do not ask for your roles.
Discord then tells us:
- your user ID, your username or display name, and your avatar image reference;
- the list of servers you are a member of.
What happens next:
- The access token Discord issues is used once and discarded. It is never written to disk, never stored in a database and never put in a cookie. A credential we keep is a credential we can leak, and we do not need one after the two calls above.
- Your server list is intersected with the servers this deployment actually holds data for, and only the overlap is kept. If you are in two hundred servers and Asbern is in one of them, one ID is kept.
- If the server-list request fails, we treat it as an empty list rather than failing your sign-in. That means you can see less than usual, never more.
Signing out deletes the cookie. There is no server-side session record to delete, because there is not one to begin with.
Cookies
This site sets exactly two cookies. Both are strictly necessary — one is your session, the other stops a forged sign-in — so there is nothing here to consent to and no banner to dismiss.
| Cookie | What it holds | Lifetime |
|---|---|---|
asbern_session |
Your Discord user ID, your display name, a link to your avatar image, the intersected list of server IDs above, and an expiry time. | 7 days |
asbern_oauth_state |
A random value used once to prove that a sign-in you started is the sign-in that came back. It holds nothing about you. | 10 minutes. It is deleted the moment a sign-in completes; a sign-in that fails, or that you abandon, leaves it in place to expire on its own |
Both are HttpOnly (JavaScript on the page cannot read them) and both are SameSite=Lax.
⚠ The Secure flag is set from the build mode, not from the address bar. Both cookies are
marked Secure — meaning your browser will only ever send them back over HTTPS — whenever the
site is running with NODE_ENV=production, which is how the shipped container runs it. A
developer running this site locally in development mode gets them without that flag. We say it
that way round because that is what the code actually checks; it does not inspect the scheme of
the request.
⚠ The session cookie is signed, not encrypted. The signature stops anyone editing it — adding a server you are not in is the attack it prevents — but it does not hide the contents from whoever holds the cookie. Nothing secret is put in it for exactly that reason.
There is no advertising, no tracking pixel, no third-party script and no fingerprinting, and the site stores nothing in your browser's local storage or session storage. The site can keep two anonymous counters about itself, which are off unless the operator switches them on and are described in What this website logs below; they set no cookie and hold nothing about you.
What your browser sends elsewhere
One outside host receives requests directly from your browser: cdn.discordapp.com, which
serves Discord's own images. What it is asked for is an avatar:
- On every example bot card on this site, the avatar drawn on the card is Discord's own
default, anonymous avatar (
cdn.discordapp.com/embed/avatars/0.png). Those cards are canned screenshots of the bot, so that image is the same for everybody and the request happens whether or not you are signed in. - On the live tour, if you are already signed in, your own avatar is drawn instead, so the demo looks like yours. That is the one case where the address of the image identifies you.
Loading an image from Discord's CDN discloses your IP address and browser to Discord, as loading any image from any site does. Discord's own privacy policy covers what they do with it.
⚠ A card can also draw a server's custom emoji as an image from that same host. As this version ships, none of them does: every emoji in the example cards carries a placeholder ID, and a placeholder ID is drawn as plain text rather than fetched. If a future card carries a real emoji, it becomes a second image request to the same place.
No other outside host is loaded by this site's pages at all — no web font, no third-party script, no tag manager, no tracking pixel. Everything else comes from this site's own server.
Our own server talks to Discord (discord.com) on your behalf, for the sign-in described
above.
It also talks to Stripe (api.stripe.com) when a subscription is started — see Billing,
below.
⚠ The live tour runs the bot's own code inside this website, so it is fair to ask what that code can reach. It reaches nothing further, and the reason is that the website is handed none of the bot's integration credentials: no media-server token, no download-client keys, no statistics-provider key. A tour sandbox also starts with nothing configured in it, so those parts of the bot have nothing to contact.
⚠ The bot itself is a separate program on a separate network path, and it does contact other things — everything its operator has switched on, plus one address nobody configures. All of that is set out under Who your data is shared with, below.
What this website logs
Nothing in this site's own code records an IP address or a user agent — anywhere, in any mode, including in the counters described below. There is no request log and no access log in it. It writes a server-side error trace when a live-tour interaction fails, which records what broke and is never shown to the visitor.
The optional traffic counters
The site can count two things about itself: that a page of some kind was viewed, and that a live-tour session was opened. They exist to answer one question — whether the tour is reached and opened at all — and they are the only thing this site counts about the people who visit it.
They are off until the operator names a directory for them to go in. Left alone, which is what a fresh install does, nothing is recorded and no file is created.
⚠ And as this version ships, no page on this site reports to them, so a deployment that switches them on gets an empty file until a future version starts sending. They are described here as a capability the operator can switch on, not as something happening to you now.
When they are on, one line is written per event, and a line can hold only these four things:
| Field | What it is |
|---|---|
| The time | The UTC date and hour. Not the minute, not the second. |
| A version number | Which shape the line is in, so an old line can still be read. |
| The event | One of exactly two words: a page was viewed, or a live-tour session was opened. |
| Which kind of page | For a page view only, and only one word from a fixed list: home, tour, pricing, features, docs, blog, stats, legal, other or unknown. It is worked out from the address you arrived from by comparing it with this site's own; the address itself is never written down, and an arrival from anywhere off this site is simply other. |
That is the entire record. No IP address, no user agent, no cookie — none is set and none is read — no visitor or session identifier, no Discord ID, no display name, no avatar, no referring hostname, no screen size, no language, no country. Nothing in a line can be tied to a person, and no two lines can be tied to each other: a "visit" is not a row here, it is a tally.
The counters can be read back over the web only if the operator separately sets a secret for it, and that address answers "not found" to everyone — including the operator — until they do.
Your web host or reverse proxy in front of this site may keep its own access logs. That is outside this software and is the operator's to configure.
What the website can show, and to whom
The site reads the bot's data through a single query layer with a fixed list of readable things. Every one of them is checked against one of three levels of access before it runs.
Anyone, signed in or not, sees two numbers: the total messages and total voice minutes across every server on this deployment. No server is named, no member is named, and no server count is published. That is the whole of the public view, by construction — the query cannot return anything else.
A signed-in member of a server sees that server, and only the servers Discord says they are in. That covers the server's message and voice totals, its activity over time, its growth, its leaderboards, its per-channel breakdown, its heat map, its hour-of-day and weekday profiles, its active-member counts, and the individual profile, standing and hour-of-day pattern of any member of that same server.
⚠ That last part is deliberate and you should know about it. A leaderboard is a table with other people's rows in it; a board where every row but yours is hidden is not a board. So another member of your server can open your activity profile, and you can open theirs. Rows are labelled by a shortened Discord ID rather than by name, but the full ID is in the page address. Nothing about you as an individual is visible to anyone who is not in a server with you — the only thing a stranger can see that you contributed to is your share of the two anonymous network-wide totals, which name nobody and no server.
Membership is asked of Discord, never of our own files. Our files know which servers the bot is in; that is a different question, and answering with it would hand a stranger any server we hold data for. When you are refused, the refusal deliberately does not say whether the server exists.
The live tour
The tour on this site runs the real bot against a throwaway sandbox created for your visit: a temporary directory whose identifier cannot be a Discord server ID, so a tour press can never reach a real server's data. It starts empty and is seeded with an invented member.
How long it lasts. A sandbox is deleted within 30 minutes of your last press. That is enforced by a sweep running on a timer inside the website — once a minute — as well as on every tour press, so the last visit of the evening is cleared like any other instead of waiting for somebody else to arrive and trigger it. No more than 200 sandboxes exist at once; past that, the oldest is removed early to make room.
⚠ One honest limit, so you are not told more than the code does. The index of live sandboxes is held in the website's memory. If the website process is restarted before the sweep reaches one, that directory is left behind in the machine's temporary folder for the operator's own housekeeping to clear. What is in it is the invented member and whatever you pressed — never any real server's data, because a tour sandbox structurally cannot be a real server.
The tour sets no cookie and needs no account. If you happen to already be signed in, your display name and avatar are drawn on the card so the demo looks like yours — that reads the session cookie you already have and writes nothing new. Anything the bot writes while you press buttons goes into the throwaway directory and is deleted with it.
Billing
Payments are processed by Stripe. Card numbers, expiry dates and security codes are entered on Stripe's own pages and never reach us — that is the entire reason for using a processor.
When a subscription is started, we send Stripe the Discord server ID the subscription is for and the Discord user ID of the person starting it, so that a payment event arriving months later can be matched back to the right server. Stripe is a payment processor in the United States and has its own privacy policy.
What we store on our own disk for a subscribed server is exactly this, and nothing else:
- the subscription's state (active, in grace, read-only, or lapsed);
- the Stripe customer ID and subscription ID;
- when it last changed;
- a rolling history of the last 20 billing events — and for each of those, four things: the time it was recorded, the event type, the reason, and the resulting state.
Never a card number, never a token, never a secret. Those live at Stripe.
A subscription record is kept for as long as the server exists in our files, including after a subscription lapses, because it is the record of what a server bought.
What the bot stores about you
Which of these exist depends on what the server's administrators have switched on. Everything is keyed by your Discord user ID.
⚠ This list covers the main stores and is not exhaustive: a feature an administrator switches on can keep its own small record — a suggestion you posted, a ticket you opened, a poll you voted in — keyed the same way and erased by the same request described under What you can erase.
- Progression — your level, XP, rank, prestige tier and achievements.
- Your display name in that server, kept alongside the activity archive so old statistics can still be labelled after a rename.
- In-server currency — your balance, your items, and your lifetime earnings. This currency has no real-world value and cannot be bought or cashed out.
- Activity counts — per day, how many messages you sent and in which channels, how many minutes you were connected to a voice channel, how many of those minutes you were actually engaged, how many reactions you gave and received, how many messages you edited or deleted, how many carried an attachment, and (only if the server has switched that counter on) how many contained a link. These are counts: what you said and which links you posted are not stored by any of them, and neither is the name of a file you attached. The one place a filename can be held at all is the staff delete log described below, which is off in every server by default.
- Who you were in voice with — for each minute you share a voice channel with somebody, a counter for that pair, and a counter for who replied to or reacted to whom. This is what lets the statistics describe a community rather than a list of individuals.
- Game progress — your Pokémon, Pokédex, items, battle record, casino and tycoon state, and anything else you have earned by playing.
- Watch history — what you watched through the screening room, for how long, and where you got to, so it can offer to resume. The "where you got to" markers are dropped 90 days after you last watched that title; the history itself is kept until you clear it.
- Media requests — if the server runs the screening room and you ask for a title the library does not have, the bot records that request: the title, its year, whether it is a film or a show, and — for each person who asked — your Discord ID, the channel you asked in, and the server. It also holds a per-member "DM me when it lands" preference, which is off unless you switch it on yourself. Making the request also puts the title on the operator's own Plex watchlist; what leaves this deployment when it does, and what does not, is set out under Who your data is shared with.
- The counting game — how many valid counts you have made and whether you counted last.
- Game servers — how many times you have started each one.
- Moderation records — warnings and cases raised against you, including the reason a moderator typed. A case never contains the text of your messages. A moderator can void a case, which marks it withdrawn and stops it counting against you; the record itself is kept, deliberately, so that a moderator's action stays answerable.
Message content
The bot holds Discord's Message Content privileged intent. Here is every way it uses message text. The server-wide half of that list is held in place by a test rather than by this paragraph: the link counter must stay explicitly opt-in, and a new read of message text in the bot's message handler fails the build until somebody declares it deliberately.
- The counting game. In the one channel an administrator nominates for it, the bot reads each message to find a number at the start. It stores the number and nothing else — that integer is the game's state, and it is the single deliberate exception to the rule that content is never recorded. In every other channel the counting code stops before it looks.
- A "links posted" counter, and only if the server turns it on. It is off by default and has to be switched on deliberately; when it is on, the bot checks whether a message contains a web address and increases a counter. The address itself is not stored and neither is the message.
- Moderator clean-up. An administrator can ask the bot to remove recent messages in one channel — all of them, or only one member's, only bots, only those with a link or an attachment, only those matching text they type, or only those older than a number of days. The bot reads those messages to decide which match, deletes them, and keeps nothing.
- Automatic moderation, mostly without reading anything. Most of Asbern's automatic moderation rules are compiled into Discord's own AutoMod and evaluated inside Discord before a message ever reaches the bot. The handful of rule types that do need the bot to read a message are off by default and each has to be switched on by the server deliberately.
Beyond those, the bot does not log message content, does not archive chat, does not read direct messages, and never writes the text of a message to disk. There is no edit or delete content log: what a message said before it was edited, and what a deleted message said, are recorded nowhere and no setting can make them be. That was refused deliberately, in writing, rather than left undone.
⚠ What the bot can hold, when a server switches it on, is message metadata — including who posted and what a file was called. It is a different thing from content and it is not nothing, so it has its own section immediately below.
Support-ticket transcripts, where a server uses tickets, contain the ticket's own record — who opened it, when, who handled it, the answers you typed into the ticket form, and the staff member's closing note. They contain no message text from the ticket channel, in any mode.
The staff delete log, and the message metadata behind it
⚠ This is off in every server by default, and in this version there is no button anywhere in the product that turns it on. It is written up here anyway, because it exists in the software and a policy that only describes the switched-on features is a policy that goes stale the day somebody flips one.
When Discord tells a bot that a message was deleted, it usually sends only the message's ID and the channel — no author, no time. A staff delete log that cannot say who is close to useless, so the software can keep a short-lived note about recent messages purely so that it can answer that one question.
What a note can hold, per message: the message's ID, the channel's ID, the author's Discord ID, whether that author is a bot, when the message was posted, when the note was taken, how many times the message was edited afterwards, and — for each attached file — its name, its size and its type. Up to 10 files per message; each name is cut to 120 characters and scrubbed first, so a bot token, a webhook address, a server invite or an email address pasted into a filename is replaced before anything is kept.
What a note never holds, in any configuration: one character of what anybody typed. The record even has a slot for a message's length and the bot deliberately leaves it empty, because the only way to measure a message is to read it.
Where it lives and how long: in memory, and never on disk. It is therefore in no backup and no export, and restarting the bot erases every note completely. A note expires 6 hours after it is taken; at most 200 are held for one channel and at most 5,000 for one server. Those are the shipped figures, and all three of them are clamped by a hard ceiling that no configuration can pass: a note's life can never be set beyond 24 hours, one channel can never hold more than 1,000 notes, and one server never more than 20,000. So nothing held here outlives a day, in any server, in any configuration.
Who can see it: nothing anywhere lets a person browse the notes. Only one field is ever drawn out of one — the author's Discord ID — and it goes to two places: the "who deleted what" card in whichever channel a server has chosen for its staff moderation log, and the reply counter described further up, so that "who replied to whom" can be tallied when Discord did not say. In this version nothing displays the filenames at all; they are held against a bulk-delete report the software can build but that no button currently opens.
Whether it is running in your server: almost certainly not. It is off by default, and the settings screens that used to switch it on were removed, so the only way to enable it today is for whoever runs the deployment to hand-edit that server's settings file on the machine itself. If nobody has done that, nothing above is happening and no note exists.
Diagnostic logs
The bot writes two logs on the machine it runs on. Both obey the same rule about their contents — message text and secrets are never recorded, with the counting game's parsed number as the single stated exception — but they are kept for different lengths of time, and it would be misleading to give you one number for both.
The structured event log is the record of what the bot did: which action ran, whether it succeeded, which rule refused a request, and how in-server currency moved. Its raw log files are deleted after 90 days. On the way there they are compressed at the 14-day mark, by a housekeeping pass the bot runs shortly after start-up and once a day after that. Daily summaries, which contain counts and no content, are kept.
The plain application log (app.log) is the running commentary an operator reads when
something breaks. It is kept by size rather than by age: when the file reaches 10 MB it rolls
over, three previous files are kept beside it, and the fourth-oldest is deleted. So how long a
line survives there depends on how busy the server is and not on a number of days — months on a
quiet deployment, days on a loud one. Nothing deletes it on a schedule, and we would rather say so
than quote you a retention period the code does not enforce.
How long things are kept
| What | How long |
|---|---|
| Progression, currency, game progress, achievements | Indefinitely — including if you leave and rejoin |
| Activity counts and voice co-presence | Indefinitely; this is the server's own long-run history |
| Display name held with the activity archive | For as long as that archive is kept |
| Watch history | Until you clear it |
| Resume points (where you got to in a title) | 90 days after you last watched it, or until you clear them |
| Media requests, where the screening room is in use | Until the title arrives and everyone who asked has been told; a request for something that never arrives stays queued until the operator clears it |
| The "DM me when it lands" preference | Until you switch it off |
| Counting tallies | Indefinitely |
| Moderation cases | Indefinitely. Voiding one withdraws it; it is not deleted |
| Message metadata notes, where a server has switched them on | 6 hours; in memory only, and erased outright by a restart |
| Diagnostic logs — raw files | 90 days |
| Diagnostic logs — daily summaries (no content) | Indefinitely |
Application log (app.log) |
Kept by size, not by age: 10 MB a file, three older files beside it, then dropped |
| Live tour sandbox | Deleted within 30 minutes of your last press |
Sign-in session cookie (asbern_session) |
7 days, or until you sign out |
Sign-in security cookie (asbern_oauth_state) |
10 minutes. Deleted as soon as a sign-in completes; a failed or abandoned one is left to expire |
| Subscription record | For as long as the server exists in our files |
⚠ A lapsed subscription erases nothing. Every subscription state the software models —
active, grace, read-only and lapsed — retains the server's data, and there is deliberately no
state that deletes it. A server that stops paying loses access to /menu; it does not lose its
history, and if it comes back the history is unbroken. That is a property of the code, not a
policy we could quietly change.
What you can erase
From the bot, yourself, today: open /menu, go to the Profile tab, press Settings,
and open the screen headed Clear My History. It offers two rows — your watch history
(titles watched, watch parties, resume points, favourites and most-watched live channels) and your
server history (your own game-server start counts). Each takes two presses: the first arms
that row and deletes nothing, the second erases. It is a real deletion, it takes effect
immediately, and it touches only your own record — each game server's overall start total stays.
What has no self-service eraser, and why we say so instead of implying otherwise:
- Currency balances and levels. These stores are written with strict correctness guarantees that protect everybody's balances at once; there is no per-member deletion path and inventing one would bypass those guarantees.
- Activity counts. They are stored as monthly files of aggregate cells covering every member at once. There is no per-member deletion path, and rewriting a month to remove one person risks the whole month.
- Administrators cannot delete them for you either, and that is on purpose. Asbern refuses, at startup, to load any administrative control that writes a member's XP, level, money, inventory, game progress or progression — because a leaderboard an administrator can edit is a leaderboard nobody can trust. The consequence is honest and worth stating plainly: there is no button anywhere in this product that erases one member's progression record.
What can be erased is a whole server's data. The bot keeps each server's files in their own directories, named for that server, and whoever runs the deployment can delete them.
To ask about, or ask for the deletion of, what is held about you, write to support@asbern.gg.
Who your data is shared with
Asbern does not sell data, does not share it with advertisers, does not use it for profiling or advertising, and does not use it to train any model. There is no telemetry and no usage reporting: nothing about you or your server is sent to the people who wrote the software on a schedule, in the background, or by any automatic process at all. The one route that reaches them is a door you have to open and press, and it is described at the end of this section.
That is not the same as saying the bot talks to nothing. It talks to whatever its operator has switched on. These are the outbound addresses in the shipped code:
- Discord, continuously, because that is what a Discord bot is.
- Whatever the operator configured, and only that. A media server, a download queue, a game
server, a statistics provider, a fantasy-league feed. Several of those run on the operator's own
machine and never touch the public internet. Some are outside services: Plex's own catalogue
(
plex.tv) when somebody searches the screening room for a title the library does not have, StatBot's API (api.statbot.net) where a server uses it as its statistics source, and Sleeper's public API (api.sleeper.app) where an administrator has bound a fantasy league. Every one of them is off until it is configured, each has its own terms, and each is the operator's responsibility rather than ours. - ⚠ What leaves in those requests is the server's own identifiers and the operator's own credentials, not yours. A title you typed into the screening-room search goes to Plex's catalogue so it can offer you candidates, and a title you request is added to the operator's Plex watchlist; your Discord ID is not sent with either. The statistics provider is asked about the server, by server ID, and picks your row out of the answer here rather than being told who is asking.
- The weather service,
api.open-meteo.com, where an administrator has given the Pokémon world a real-world place. It needs no key and no account, which is why it is the default. The request carries the coordinates of the place the administrator chose and nothing else — no member is named in it, and it does not fire at all until a place has been set. - One address nobody configures:
api.ipify.org, a public "what is my IP" lookup. The bot asks it when a member starts a game server, or opens the list of running ones, because the answer is the address you connect to. The request carries nothing but itself — no member data, no server data — and the answer it brings back is the operator's public IP address, not yours. It is cached for ten minutes so a busy evening asks once.
One thing leaves because you pressed it, and only if the operator has set up somewhere for it to
go. /menu has a Send Feedback door that forwards what you type to the people who write
the software, rather than to your own server's staff. It sends what you typed (the box holds
up to 1,000 characters), the name and ID of the server you sent it from, and the bot's version
number. It does not send your name, your Discord ID or your avatar, and the form says so above
the box before you type a word. Nothing is sent unless you open that door and press send, and if
nobody has configured an address the door tells you so rather than taking what you wrote. The
separate Community → Feedback door goes to your own server's staff and never leaves the
server.
Beyond the list above and that one door, the only recipient outside this deployment is Stripe, and only the identifiers named in the billing section.
Children
Asbern is not directed at children. You must meet Discord's own minimum age for your country in order to use Discord at all, and therefore to use Asbern.
Changes to this page
When this page changes, the date at the top changes with it. It is kept in the same version control as the software, so its history is reviewable rather than assertable.