Privacy Notice
Last updated 7 September 2026
This explains what personal data probability.media collects, why, where it is kept, and the rights you have over it under the GDPR.
Who is responsible
The data controller is the Systems Geometry Group, an independent research project based in Croatia. Contact: contact@probability.media.
What is collected, and why
| Data | Why | Legal basis |
|---|---|---|
| Email address | To create your account, confirm it, and let you reset your password. | Performance of a contract |
| Username, and any display name, bio or affiliation you add | To attribute your submissions. Your username, display name and picture are visible to everyone; your bio and affiliation require an account to read. None of these fields may contain links. | Performance of a contract |
| A profile picture, if you add one | To identify you beside your submissions. It is reduced to 32×32 pixels in your own browser before it is sent, and stored on your profile row. It is public. The moderation team can take a picture down, and while a ban is in force your picture is held back and the default shown in its place, returning when the ban ends; in either case a copy of the picture goes into the staff record described below, with the reason. | Consent, given by uploading it |
| Submissions, replies and votes | They are the content of the forum. Submissions and replies are public; individual votes are not shown, only totals. | Performance of a contract |
| Notes you write for yourself | A private notebook on your account: up to twelve notes, each with a name and a body. They are yours alone. The database returns them only to the account that wrote them, to nobody else, including moderators and administrators, and nothing in them is ever rendered as a link or run as code. They are erased with your account. | Performance of a contract |
| Presence status | To show whether you are online, if you choose to share it. Not stored historically. | Performance of a contract |
| When you were last here | So your peers can see roughly when you were last active. Only ever set to the current time by the server, never to a value your browser supplies, and shown to others in vague terms such as "about 12 days ago". | Performance of a contract |
| Peer links: who you are connected to, and when the link was made | To show connections between members. Your list of peers is visible to you, to the people you have accepted as peers, and to an administrator reviewing an account for abuse, not to moderators, not to other members and not to visitors without an account. The number of peers you have is visible to any signed-in member. Requests that are still pending are visible only to the two people involved. See What other people can see below for the one case in which a single connection becomes publicly visible. | Performance of a contract |
| A record that you agreed to these documents: which version, and when one row for each version you have accepted | To show what you were shown at the moment you agreed. Kept for every version rather than only the latest, because showing what you agreed to in 2026 needs the record from 2026. The timestamp is taken from our database, not from your browser, and no IP address or device details are recorded with it. | Legal obligation, and legitimate interests |
| A record that you declared you are 16 or over | Accounts are limited to people aged 16 and above. Only the fact of the declaration and its date are kept: we do not ask for or store your date of birth. | Legal obligation |
| Moderation records (mutes, bans, their reasons, and the record of what the moderation team did) | To enforce the Terms of Use and keep discussion usable, and to make every staff decision reviewable afterwards: each ban, mute, lift, removal, purge, picture removal and hiding of a submission is written to a record naming who acted, when, and the reason given. Readable only by moderators and by you. Other members cannot see them. | Legitimate interests |
| Notices sent to you when your account is restricted, including a copy of the reply the restriction was applied for | So that you can see what was objected to and by whom, and answer it. Readable by you and by moderators only, never by other members and never by visitors. This is the one place a redacted reply is kept, and it is kept for your benefit. | Legitimate interests, and legal obligation |
| Technical logs, including IP address, kept by our hosting and database providers | To deliver pages, prevent abuse, and diagnose faults. | Legitimate interests |
Mentions
Writing @name or >name in a submission or a
reply places a notice in that member's inbox. Only somebody who is already
an accepted peer of yours can do this, and you can switch it off entirely
on your account page, in which case the text still appears and simply
notifies nobody. The site reads the text you posted to work out who was
named; it does not read anything you have not published.
Presence
The time of your last visit is recorded, so that a peer list can say whether somebody has been here recently. You also choose a status, online, do not disturb, or invisible. Invisible means exactly that: other members are told nothing, including by the peers list, which treats you as away.
A submission you choose to show
You may pick one of your own submissions to stand at the top of your card. It is a reference to something you already published; nothing new is stored, and clearing it or withdrawing the submission removes it.
What is not done
- Your data is never sold or rented.
- There is no advertising, no advertising network, and no tracking pixels.
- There is no analytics package and no behavioural profiling.
- There is no automated decision-making with legal effects.
- There are no fonts, images, widgets or tracking pixels loaded from anybody else, and no analytics. Two third-party files are used. The Supabase client library is fetched from the jsDelivr network, so your browser contacts jsDelivr, which can see your IP address and that a page on this site was opened; it is sent nothing about you, your account or what you read. Cloudflare Turnstile is loaded on the sign-in, sign-up and password-reset forms only, to tell them apart from an automated flood; Cloudflare can see your IP address and that the form was opened, and processes that under its own privacy policy. Following a link is the only other way your browser reaches another company, and you are shown where a link goes and asked to confirm before that happens.
Who processes data on our behalf
| Processor | Role | Location |
|---|---|---|
| Supabase | Database, accounts and authentication | EU (Ireland) |
| Hostinger | Web hosting for the pages themselves | EU |
| Resend | Sending confirmation and password-reset emails | EU (Ireland) |
| Cloudflare | The Turnstile check on the sign-in, sign-up and password-reset forms. It sees the request and your IP address for the moment the check runs, and nothing from your account. | Global network; EU users are generally served from within the EU |
| GitHub (Microsoft) | Storing the weekly database backup in a private repository. That backup contains everything in the table above, including email addresses, and for that reason it is encrypted before it is sent, and GitHub holds no key that would let it be read. | United States |
Each acts only on our instructions. The weekly backup held with GitHub is stored outside the EEA, in the United States, and that is the only place your data leaves Europe.
Two things make that transfer lawful, and we would rather set out both than lean on either alone. GitHub, Inc. is certified under the EU–U.S. Data Privacy Framework, the adequacy decision the European Commission adopted in July 2023; should that decision ever be withdrawn or annulled, Microsoft separately incorporates the European Commission's standard contractual clauses into its data protection terms, and the transfer would continue on that basis.
Neither of those is a technical protection, so we do not rely on them for the actual confidentiality of the file. The backup is encrypted before it leaves our own infrastructure, and the key that would decrypt it is never sent to GitHub, never stored in the repository, and never held by any of the processors listed above. What GitHub stores is a file it cannot read. The repository is private and the backup is never published or shared.
How long it is kept
- Account data: for as long as your account exists, and erased immediately when you delete it.
- Your notes: for as long as you keep them, or until you delete the note or the account. They are in the weekly backup like everything else, encrypted, and age out of it with the rest.
- Submissions and replies: indefinitely, because the forum is a research record and removing one side of an exchange makes the rest unreadable. See below for what happens on deletion.
- Vote totals on a deleted reply: kept. When a reply is deleted its words and its author go, but the counts it had received are frozen and remain visible. They record how the forum received a claim, not who made it or what it said.
- Moderation records: up to two years after a restriction ends. A separate record of what the moderation team itself did, who acted, what action they took, when, and the reason they gave, is kept indefinitely, because it exists to hold staff to account rather than to hold anything about you. If your account is deleted, your name and any copy of your words are removed from that record immediately and only the staff side of it remains.
- A copy of content acted on: when a reply or a submission is removed or purged by staff, the text is copied into that record so the decision can be examined afterwards, since a purge destroys the original. The same is done with your profile picture when staff remove it or ban the account. It is visible only to the moderation team, at the tiers described below, and it is erased if you delete your account.
- Notices about a restriction: kept for as long as your account exists, and erased with it, so that a decision can still be questioned long after the restriction itself has lapsed.
- The public mark on a redacted reply: permanent. It records that a restriction was applied and never what was written. See below.
- The record of agreement: for as long as the account exists, and erased with it.
- Backups: each weekly backup is kept for 90 days and then destroyed, which is about the last twelve. An encrypted copy of your data may therefore persist for up to three months after deletion. They are held where that expiry happens automatically rather than by hand, so it does not depend on anyone remembering. Backups exist only to restore the forum after a failure, and are never used to look anyone up.
- Technical logs: according to each provider's own retention period, typically days to a few weeks.
Your rights
Under the GDPR you can ask to:
- see the personal data held about you (access);
- correct anything inaccurate (rectification);
- have your data deleted (erasure);
- restrict or object to processing;
- receive your data in a portable format.
Deleting something you posted
You can delete your own submissions and replies at any time, from the … menu beside them. The two work differently, and the difference matters:
- A reply is redacted, not removed. Its text is replaced with *Deleted*, your name is detached from it permanently, and the votes cast on it are deleted. The empty reply stays in place so the answers other people wrote underneath it are not destroyed along with it. The totals it had received are frozen and shown as a historical note. None of this can be undone or edited afterwards.
- A submission removes you from it, not the thread. Your claim and your name go, and every reply you wrote in that thread is redacted at the same moment, so nothing of yours remains in it. The submission stays in place as *Deleted*, no new reply can be added, and its vote totals are frozen. Replies written by other people are unchanged — they are their authors' words, not yours. You are shown all of this before it happens.
- Only you can do it. A moderator cannot withdraw your submission on your behalf. If something has to be removed that you can no longer reach yourself, an administrator can erase it, and that is a separate decision recorded as such.
Deleting your account
You can delete your account yourself at any time: sign in, open Settings from the cog beside your name, and use Delete this account. You will be asked to type your username to confirm, because the action cannot be undone.
Deleting erases your email address, username and profile immediately and permanently. Submissions and replies you wrote remain on the forum but are no longer attributed to anyone, so discussions other people took part in stay readable. If you want the text of a particular submission removed as well, email contact@probability.media and we will remove it.
Deletion takes effect on the live forum immediately. Older weekly backups will still contain your data, in encrypted form, until they age out, which takes up to about three months. We do not open a backup to remove one person from it doing so would mean decrypting a complete copy of everybody's data to serve one request, which is worse for everyone. Instead the backups holding you are allowed to expire, and are destroyed.
Moderator and admin accounts cannot be self-deleted, to prevent the forum losing everyone able to moderate it. Contact us and the account will be demoted first.
Complaints
If you think your data has been mishandled, please tell us first. You also have the right to complain to your national supervisory authority. In Croatia that is the Personal Data Protection Agency (AZOP), azop.hr.
What other people can see
Reading the forum needs no account. Opening somebody's research identity does. This is enforced by the database, not only by the page.
Without an account
A visitor who is not signed in can read every submission and reply, and can see the author's username, display name, profile picture and presence dot beside them. That is all. Bios, join dates, the list of somebody's submissions and replies, peer counts and peer lists are not available without an account, and the database will not return them.
With an account
Any signed-in member can see your username, display name, profile picture, bio, affiliation, role, join date, roughly when you were last active, your presence status, your submissions and replies, vote totals, and the number of peers you have.
A signed-in member can also look you up by username in order to send you a peer request, without having to find something you wrote first. That search matches the beginning of a username, needs at least two characters, and returns at most eight people, so it is a way to reach a name somebody already has rather than a directory of the membership. Nothing is revealed by it that a signed-in member could not already see beside one of your submissions, and a search never tells the person searching anything about who you are connected to.
Only your peers
Who you are connected to is visible only to you, to the people you have accepted as peers, and to an administrator. Administrators can open a peer list for one reason: a set of accounts connected to one another and to nobody else, or a peer count nobody accrues honestly, is the shape of a botted network, and the list is the only place it shows. That is done under legitimate interests, by the smallest circle that can act on it; a moderator who suspects it reports it and cannot open the list. A pending request is visible only to the two people involved.
The one public exception: the thread connector
When two members who are peers reply to one another in a public thread, the line joining those two replies is drawn differently, and that mark is visible to everyone, including visitors without an account. It is a statement about that exchange rather than about either person: it appears only where two people are already answering each other in public, and it names nobody and lists nothing.
We would rather state the limit of this than leave you to discover it. Someone determined could read every public thread and note each connector, and so work out which members have replied to one another in public while being peers. That is bounded by what is already public, it cannot reveal a connection between two people who have never interacted where everyone can see it. If you would prefer a particular connection not to be inferable, ending the peer link removes the mark.
The second public exception: a moderated reply
When a moderator restricts an account for something written in a thread, they may redact that reply at the same time. The thread then shows it as *banned* or *muted* rather than the usual *Deleted*, and that mark is visible to everyone, including visitors without an account. It is permanent, and lifting the restriction does not remove it.
We would rather state its limit than let you discover it. The mark says that a restriction was applied and nothing else. Your words and your name are destroyed by exactly the same redaction as any other deletion, and the moderator's reasons are never published, a reader learns that something was moderated, not what was said, not why, and not by whom. The account itself is not named: what is shown is a reply with no author.
The full account, the text, the grounds, the moderator, the expiry goes to you privately, in the inbox on your research identity. Nobody but you and the moderation team can read it.
A closed circle, if you want one
Three switches on your account card, all off unless you turn them on. Keep my peer list to myself closes your peer list to everyone but you and an administrator reviewing for abuse; while it is on, you cannot open anyone else's peer list either. Submissions viewable by peers only and replies viewable by peers only close the two tabs on your identity card to your accepted peers and administrators. They close the card, not the forum: a submission stays where it was published and a reply stays in its thread, readable by anyone, because the forum is public writing.
A hidden submission
An administrator can take a submission out of the forum's listing without redacting it. It then appears in none of the lists, and only the moderation team has a folder that shows it, but it is not made secret: anyone who has its link can still open it, and its replies and votes stay as they were. You are told when this is done to something of yours, and told again when it is listed once more. The decision, the reason and who took it are on the staff record.
Never shown
Your email address is never shown to anyone: it is held by the authentication service and is not part of your profile. Individual votes are private; only totals are displayed. Your moderation record, the record of which version of these documents you agreed to, your age declaration, the notices in your inbox and your account history are readable only by you and by moderators other members cannot retrieve them at all, and a visitor without an account has no access to them of any kind.
The moderation record includes any restriction in force, the reason recorded for it, and the notices sent to you, including a notice recording that a restriction was lifted. A moderator considering whether to lift one can read that record, which is the reason it is kept: reversing a decision means being able to see what the decision was. It is not readable by other members, and the columns holding it are ones the database will not return to an ordinary account at all.
What the moderation team can see
Staff can read the notices sent to a member and the record of actions taken against them, which is what makes a decision reviewable. Access is by tier: a moderator can see an ordinary member's history and another moderator's, an administrator can see everything, and an administrator's own history is visible only to another administrator. A member sees nothing about anybody else, and always sees what was done to them.
Children
Accounts are for people aged 16 and over. If you believe a younger person has created an account, contact us and it will be removed.
Security
Passwords are hashed by Supabase Auth and never visible to us. They must be at least eight characters and contain a lower-case letter, a capital, a digit and a symbol.
Access to the database is restricted row by row and column by column. A visitor without an account cannot retrieve a bio or a join date at all, and a signed-in member cannot retrieve anyone's moderation record, consent record or age declaration, not merely because the page does not show them, but because the database refuses to return those columns. Your own values are returned only to you.
Confirmation and password-reset links are single use: following one consumes it, and it expires after an hour. Connections use HTTPS. No system is perfectly secure, and we will tell affected users and the supervisory authority about any breach that is likely to present a risk.
The weekly backup
Once a week the database is copied in full so that the forum can be restored after a failure. That copy includes the account records held by the authentication service, email addresses and hashed passwords among them. This is deliberate: without those records a restore would bring back the discussions but not the accounts of the people who wrote them, and the registrations themselves would be lost.
Because the backup contains everything, it is the one place where the column-by-column restrictions described above do not apply. We treat it accordingly.
The backup is encrypted at the moment it is made, before it is written anywhere it will be kept. It exists in readable form only in memory, for the seconds it takes to produce, and is never stored or sent anywhere in that state.
The encryption is one-way by design. The job that makes the backup holds only the key needed to write one; the key that would read it is held offline, is never given to GitHub or to any other processor, and is used only to perform a restore. That is deliberate, it means nothing is stored alongside the backup that could decrypt it, so neither a mistake on our part nor a breach at GitHub can expose what it holds.
Changes
If this notice changes materially, the date at the top will change and the change will be announced in the Forum.
Data protection queries: contact@probability.media