probability.media
Legal

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

DataWhyLegal 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

Who processes data on our behalf

ProcessorRoleLocation
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

Your rights

Under the GDPR you can ask to:

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:

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