Draft
The facts on this page come from how the system works, and can be checked against the code. The text has not been reviewed by a lawyer yet — hence this notice.
What is a legal decision — the identity of the data controller, the legal basis, the retention periods — stands in square brackets. Once the crew and their lawyer fill them in, this notice disappears on its own.
Privacy
What we store about you, why, for how long, and who can see it. This page promises nothing — it describes what the system does.
The places in square brackets are for the crew to fill in. Until then the system asserts nothing about them — not because there is no answer, but because the answer is not ours to give.
Who is responsible for the data
The site is run by the PsyRaiderz crew. The data controller is [to be filled in: the name of the data controller], postal address [to be filled in: the postal address of the data controller]. For anything to do with data protection, write to [to be filled in: a contact e-mail address for data protection].
The database runs in the Supabase cloud; the region where the servers stand: [to be filled in: the geographic region of the database].
What we store
Data arises in four places. None of this is an estimate: these are the actual columns, readable from the code.
- Reservation
- The party you booked for, your e-mail address (required), your name (if you gave one), your coupon code, its last three digits, the state of the booking and its timestamps. Of the token in your manage link we store only a digest — never the token itself.
- Account
- Crew members only. The e-mail address, a digest of the password, the role, the tags and — if you filled them in — your display name and your bio.
- Traffic measurement
- A timestamp rounded to the hour, the path, the kind of page, the domain of the referring page, the device class, the country, and an identifier salted with a key that rotates daily.
- Internal log
- Edits made by the crew: who (e-mail address and role), what and when. Only actions belonging to content editing go in.
Why we store it
The reservation, so that you can redeem it at the door and the crew can see how many are coming. The account, so that the crew can sign in and edit the content. The measurement, so that we can see what interests you. The log, so that a change can be attributed to whoever made it.
The legal basis: [to be filled in: the identification of the legal basis].
The measurement has a section of its own below, because that part needs explaining separately.
How long we keep it
Old rows in the tables are cleaned up by the system — but not on their own: the cleanup is a separate command that the operator runs. The periods below are enforced by the same setting this page is built from, so the number and the deletion cannot drift apart. What remains after a cleanup is an anonymous total.
- Reservation
- [to be filled in: the retention period for reservation data]
- Traffic measurement
- 90 days. The detailed rows — path, referrer, device, country, hour — are deleted after that; what stays is the daily total: how many views and how many unique visitors on which day.
- Internal log
- 90 days. Older rows are deleted — except the ones about events that have not finished yet: those stay until the event is over.
What already works today: you can delete your reservation from the manage link at any time, and it really goes — the row disappears from the database, we do not just hide it.
Who can see it
The crew sees the reservation data: at the door and on the booking list. The full coupon code is visible only to you, on the manage link — the list shows its last three digits, so that a door host can check that it belongs to the right row.
From the traffic measurement the crew sees only aggregate numbers. Individual rows can be opened only by whoever runs the system, and even they cannot see the salted identifier.
The internal log is read by the roles that also edit the content.
We do not sell data and do not pass it outside the site. Two outside services are involved: the database and sign-in run at Supabase, and the live stream embed comes from YouTube — the latter loads only once you start playback.
The traffic measurement
We cannot tie a measurement row to a particular person. That does not make it anonymous: the identifier is derived from your IP address and your browser name with a key that rotates daily, and the key is not stored. Anyone holding the key could trace it back to the person — so we treat it as if it were personal data.
Exactly one thing follows from this, and you will see it in the statistics too: a "unique visitor" is only meaningful for a single day. Over a month we can report the sum of the daily uniques — not how many people came here.
The database rounds the timestamp to the hour. A precise timestamp, together with the rest, would be a fingerprint, and it adds nothing to the measurement: the question is when a page gets read, not at which second.
We store no IP address, no browser user-agent string, no cookie and no session identifier. Not because we could not — there are no columns for them.
Your rights
You can ask for a copy of what we store about you; you can ask for it to be corrected; you can ask for it to be deleted; and you can object to the measurement. For any of these, write to [to be filled in: a contact e-mail address for data protection].
Data belonging to an account is at the crew’s disposal. Your reservation, though, you can delete yourself — you do not need to ask anyone.
If you believe we are not handling your data as we should, you can complain to the data protection authority where you live.
If this notice changes
The date at the foot of the page is when we last touched it. If the range of data we store changes, we rewrite this page before we rewrite the code.
We issue this notice in the name of [to be filled in: the name of the data controller].