How The Multiverse School collects, uses, and protects your information.
Last updated: August 2026
Information We Collect
There are two different kinds of information here, and we think it is
clearer to keep them apart: the things you type and send us, and the
record of how you move around the site.
Things you type and send us
Your account — your name, email address, and timezone. If you fill them in, your profile can also hold things like pronouns, social and portfolio links, and a résumé.
Enrollment and participation — which classes you are in, attendance and join records, and feedback you leave on a class.
Payments — handled by Stripe. We never see or store your card number. We do store a record of the purchase, including the email address on it and the amounts.
Forms — scholarship applications, mutual-aid intake, contact forms and similar. The forms that ask the most personal questions have their answers encrypted before they are written to our database, so the answers are not readable by simply looking at the data: the scholarship application, the unmet-needs (mutual aid) intake and the Pricing Bench. The scholarship form asks about your safety, housing, food, employment and identity and demographics, and those answers are encrypted at rest — staff reviewing your application can read them, but they are not sitting in the clear in our database. Other, less sensitive forms are stored unencrypted. Whichever form it is, the email address you submit with is stored unencrypted so we can reply to you, and encryption at rest is not the same as secrecy from us: the people who review applications can read what you wrote.
Reader submissions — if you suggest a link or leave a note on one of our research pages, we store your note, the link, any name and email you chose to give, the page you submitted from, your browser's user-agent string, and a one-way fingerprint of your IP address (used to stop one person flooding the queue). Name and email are optional there.
Community resource contributions — if you contribute to the resource library, we store your contributor details, what you submitted, and the IP address it came from.
Email you send us — if you write to us, we keep the correspondence, including the full message, so that whoever picks it up can see the history. Software helps us sort and categorise it.
Audio you send for transcription — transcribed on our own server and the audio file is deleted straight afterwards. We do not keep the recording.
How you use the site
Page analytics — we run our own copy of Umami, an open-source analytics tool, on our own hardware. It is loaded on essentially every page of the site, including pages you see when signed in. On curriculum pages it also tags the visit with your membership level and whether you are a scholarship student, so we can tell whether the material is reaching the people it is meant for. It is not given your name, email address, or account number. The one exception is a purchase: when one completes, our analytics receives the product, the amount, the purchase and charge IDs, and a scrambled version of the email address used — not the address itself, but a fixed code that could be recomputed by anyone testing a list of addresses against it.
A visitor ID — when you look at a class page we set a first-party cookie (mv_visitor) with a random ID that lasts a year, and log which class pages that ID looked at on which day. If you later sign in, that ID is linked to your account — which means browsing you did before signing in can be connected to you afterwards. We use this to understand which pages lead to enrollments.
Where you arrived from — campaign tags in the link you clicked (utm_source and friends) are kept in your browser's local storage and attached to analytics events for 30 days.
Tool and curriculum engagement — on our interactive tools and curriculum pages we record which sections you opened, how long you stayed, how far you scrolled, and which controls you used. See the section below, which is the important one.
Class links and attendance — when you follow a link into a classroom, and when you join a live class, we log it along with your IP address and browser user-agent, so we can tell who made it into a session and debug it when someone cannot.
Curriculum reading history — which curriculum pages you opened and when.
Errors — when something breaks in your browser or on our server, we record the error and its technical details so we can fix it.
Sign-in records — authentication events, each with the IP address and browser user-agent used, plus the IP address of your last login.
Experiments — we sometimes test two versions of a page, and record which version your visitor ID was shown.
What our tool analytics never record
Some of the tools we build hold genuinely private material. The Pricing
Bench holds your household finances. The Social Budget holds your
relationships with named people. We want to be exact about what leaves
your browser when you use them.
We record that you used a control. We never record what you
entered into it.
Concretely, for each interaction we store the tool, the page, which
section you were in, what the control was for, what type of control it
was, whether a text field had anything in it at all, and a rough size
band for how much you wrote (empty, 1–20, 21–100, or over 100
characters). We store how long you spent and how far you scrolled.
We do not store the values you type. There is no column in our database
that can hold them, and the code that runs in your browser is limited to a
fixed list of things it is allowed to send. Beyond that:
Checkboxes, radio buttons, dropdowns, sliders and number fields report only that they changed. No value, no length, not even whether a box ended up ticked — on a checklist tool, the ticks would be the answer.
Password and hidden fields are ignored entirely.
If you copy something out of a tool, we record only how long it was — never the text itself. If you export a file or save a draft, we record that it happened, not its contents.
On the Pricing Bench and the Social Budget, control names are never read from what is on the screen. Those two tools can build a label out of something you typed — the name you gave a person or a group — so they are configured so that names come only from labels we wrote ourselves in the page's code. This is switched on for those tools specifically.
When you click a link out to another site from one of these pages, we record only the destination host — arxiv.org, for example — and never the full address. The rest of a link is where a tracking ID or an email address would hide, so we cut it off both in your browser and again when it reaches us.
If you are signed in, these records include your account ID. If you are
not, they carry a scrambled code made from your IP address and browser
details, mixed with a secret only our server knows. It cannot be turned
back into your IP address, but it is stable enough to tell that one
person visited twice rather than two people visiting once.
One honest exception, because it works differently: on curriculum
pages (as opposed to the interactive tools), clicking an external link
does send the full address of the link you clicked to our analytics, not
just the host.
How We Use Your Information
To provide and manage your access to classes, curriculum, and school resources.
To send you enrollment confirmations, class schedules, and calendar invitations.
To process payments and manage memberships via Stripe.
To communicate important updates about your classes or account.
To decide who receives scholarships and mutual-aid support, and to route requests to the right person.
To work out which classes, tools and pages are actually being used, which ones people give up on, and which ones to build or retire next.
To understand which pages lead people to enroll, so we know where to put our effort.
To find and fix things that are broken.
To keep the site up and stop abuse.
We do not use any of this to set your price. Location questions on the
scholarship form exist to work out where support should go, never what to
charge you.
Cookies, sessions and browser storage
Signing in — a session cookie holds a random ID; the session itself lives on our server in Redis. It is HTTP-only (JavaScript cannot read it), sent only over HTTPS, and lasts 7 days. It is set on .themultiverse.school so that signing in here also signs you in to Campus.
Magic links — a sign-in link contains a random token stored on your account record and valid for 24 hours. It is cleared once used.
The visitor ID — mv_visitor, described above. Random, lasts a year, readable by JavaScript, and linked to your account if you sign in.
Timezone and theme — to show class times correctly and remember the look you picked.
Browser storage — campaign tags, some tool drafts, and an experiment ID are kept in your browser's own local storage rather than in a cookie. Drafts you save in a tool stay in your browser unless the tool explicitly sends them to us.
We run no advertising cookies, no ad networks, and nothing that follows you
to other websites. We do run our own analytics on our own hardware, which
is not the same as running none. We are not able to confirm here whether
the analytics software itself sets a cookie in your browser; if you want a
definitive answer, ask us and we will check the running system.
An honest note about the cookie banner: the banner currently
on the site names an analytics provider we stopped using, and dismissing it
does not currently switch anything off. Nothing on this site is withheld
pending your consent to it. That banner needs fixing.
Who else receives your data
Run by us, on our own hardware
These are not third parties. The data stays on servers we rent and administer.
Our database and website — hosted on our own server in Helsinki.
Umami — the analytics described above, self-hosted.
GlitchTip — error reports, self-hosted.
Our AI inference server — mutual-aid intake text is summarised and stripped of identifying details by a model running on our own hardware, not sent to an outside AI company.
Matrix — our chat homeserver, if you use community chat.
Outside companies
Stripe — payments. They handle your card details; we never see them.
SendGrid — sending email. They receive your email address and the message.
Google Calendar — calendar invitations, which carry your email address.
Cloudflare — sits in front of the website, so your requests pass through it.
Sentry's CDN — your browser downloads the error-reporting library from browser.sentry-cdn.com. The error reports themselves come to us, but that download means your browser contacts their server.
OpenRouter and Tavily — an AI provider and a search service, used for some features including checking links submitted to the community resource library. Neither is used for mutual-aid intake.
We do not sell your data, and we do not share it with advertisers.
How long we keep things
We would rather tell you the truth than a comforting number.
Error reports are set to be deleted after about 90 days.
Sign-in sessions expire after 7 days; magic-link tokens after 24 hours.
Campaign tags stop being used for attribution after 30 days, but the value stays in your browser until you clear your site data.
Everything else — your account, enrollments, form submissions, analytics and engagement records — is kept indefinitely. We have no automatic deletion schedule for it. If you want something gone, ask us or use the deletion process below.
Data Security
We take reasonable measures to protect your information, including:
Secure, HTTP-only session cookies, with sessions held server-side.
Encryption at rest for the two sensitive forms named above.
Sign-in primarily by magic link, so there is usually no password to steal.
Automatic redaction of passwords, tokens and similar values from our error reports.
Two limits worth stating rather than glossing over. That redaction works on
named fields, so an email address written into an ordinary log line can
still end up inside an error report. And the fingerprint we store instead
of your IP address on reader submissions is a plain hash without a secret
— it hides your address from casual reading, but someone determined,
with a list of addresses to test against, could work it out. The visit code
used by the tool analytics does use a server-side secret and does not have
that weakness.
Your Rights
You can ask us for a copy of what we hold about you, ask us to correct it,
ask us to delete it, or opt out of emails. Email
liz@themultiverse.school and a
person will answer. Our emails include an unsubscribe link, and you can
change which kinds of email you receive from your profile.
Deleting your account
You can start this yourself from your profile page at
/edit_profile. You confirm by typing your email
address, and there is a 7-day grace period before anything
happens, which you can cancel during. Any active subscription is cancelled
and you are signed out immediately.
Be aware of what deletion actually does: it anonymises your
account rather than removing every row. Your name and email are replaced
with placeholders, and personal details, contact links, notes, résumé,
chat identity and sign-in credentials are erased. Form answers, CRM records,
your reading history and your contributor details are erased or unlinked.
Purchase and payment records are kept — we are required
to hold financial records — with the email address on them replaced.
Tool engagement events are unlinked from you, leaving them in the same
shape as an anonymous visitor's — they never held anything you typed.
To be straight with you about the gaps: some of the usage records described
on this page are not currently covered by that automated
process, including our page-visit and visitor-ID tables, classroom-link
clicks, class attendance, experiment assignments, terms-acceptance records,
a backup copy of form submissions, and reader submissions. If you want those
removed too, email us and ask, and we will do it by hand. We would rather
tell you that than let you believe one button clears everything.
Changes to This Policy
We may update this policy from time to time. Material changes will be communicated via email or a notice on the website.