Privacy policy

This page describes, in plain English, what data signups_SA6thward collects and how it is used. We keep it in line with what the code does, and the code is open: you can read it, database schema included, at github.com/richshaw/OpenSignup. If you find something this page gets wrong, tell us at pierson.jarvis@gmail.com so we can correct it.

The OpenSignup project is an open-source coordination tool released under AGPL-3.0. This page applies to this instance, the deployment you are using now, which Pierson Jarvis runs. “We” and “us” on this page mean Pierson Jarvis.

Who is responsible for your data

We are the data controller for organizers' accounts, and for what this instance does with anyone's details to run the service and keep it safe: sending the emails described below, preventing abuse, and keeping the records this page lists.

When you sign up for a slot, you are giving your details to the organizer who runs that signup. The organizer decides what their signup is for and what they do with the list of people on it, such as contacting you about it, sharing it with others, or downloading it. They are responsible for those choices, and for telling you about any use beyond running the signup. We store your details and run the signup for them.

The organizer can see your name and email address, and can download them along with your note. People who open the signup's page see how many spots are taken, not who took them.

What we collect from organizers

Organizers (people who create signups) sign in without a password — either via a magic link sent to their email or, where the operator has enabled it, an optional third-party sign-in such as Google. We store:

• Email address (used to send magic-link sign-in emails).
• Optional display name and organization name.
• If your account was created by signing in with a third-party provider such as Google, the web address of the profile picture that provider returned.
• The signups, slots, and settings you create.
• An append-only activity log of organizer actions (sign-ins, creating and editing signups, sending magic links, copying a signup’s link, or from the share panel sending it by your phone’s share menu, choosing Email it, or showing or saving the QR code, a publish or an AI draft that didn’t go through, and whether AI drafting asked you questions and how you answered them, in counts only, never what you or the AI wrote), which of your own pages you open and whether on a phone or a computer (never the browser’s full identifying string), participant commitments on your signups, and reminder dispatches. For a copy or a share it records only which button it was and the signup’s status: never the message, and nothing about who the link went to. This exists so an organizer can audit what happened in their own workspace, so the operator can investigate abuse, and so the operator can count, in aggregate, where organizers get stuck between starting a signup and sharing it. The same log records anonymous view telemetry on the marketing home page and on your public signup pages (see “Logs and rate-limiting” below).
• After a sign-in email is sent, the sign-in link's token (stored as a hash, next to your email address), kept until the link expires (an hour by default, or as long as the operator sets it). For up to 15 minutes, the six-digit code printed in the email (stored as a keyed hash) with the encrypted sign-in link it stands for, so you can finish signing in from the window you started in. Both are single use. A used or expired one cannot be redeemed, and an hourly cleanup deletes any that are left.
• If you connect an app or AI assistant to your account, a record of that approval and the tokens that keep it working. See “Connected apps and AI assistants” below.

No password is ever stored — sign-in is passwordless.

What we collect from participants

Participants (people signing up for a slot) never create an account. When you commit to a slot we store:

• Display name.
• Email address, if you give one. The organizer decides whether a signup requires it. We use it to send you a confirmation with your link to change or cancel, and, if the organizer has reminders on, reminders and an email when your slot moves to a new date or time. If you leave it blank where that is allowed, we send you no emails. Your link is then shown on screen after you sign up, and only that browser remembers it: for 60 days, or until a week after your slot if that is later.
• Your slot selection, quantity, and any optional notes. The organizer sees your note, so put in it only what they need to know.
• Whether you have opted out of reminder emails for that signup, and when.

A browser cookie keeps your link to change or cancel, so you can come back to your own commitment from the same browser. See the cookies page for details.

After you sign up, your browser also keeps the name and email address you entered, so the form is filled in for you the next time you sign up for anything on signups_SA6thward. That copy stays in your browser and is not sent to us on its own. On a shared or public computer, the next person to sign up in that browser will see your details filled in, so clear this site's data in the browser when you have finished; that removes it.

Logs and rate-limiting

To prevent abuse, the server keeps short-lived rate-limit records. They hold request IP addresses, the email address a sign-in link, sign-in code or sign-up is for (so a participant's address too), and, for some organizer actions such as creating a signup, the organizer's account identifier. An hourly cleanup deletes each record, normally within a few hours of it being written. These rows are scoped to individual buckets and are not joined to your account or commitment for analytics. Server-side application logs are standard request/error logs and do not include cookies, tokens, magic-link URLs, or email addresses; sign-in log lines name only the part of the address after the @. The exception is an instance set to print emails to its log instead of sending them, a setting meant for development: there, each email's address, subject and the start of its text are logged, with the private part of its links and any sign-in code removed.

For each view of a public signup page, the server writes a single activity entry containing a user-agent class (browser, bot, or unknown), the host of the referring page (not the full referer URL), the signup's status, and whether the viewer is a returning participant on that signup. We do not record your IP address on this entry. Bot traffic and requests carrying a Do Not Track or Global Privacy Control signal are skipped. The same applies when you follow an “edit your commitment” link, when you load the marketing home page, and when you click the “Start a signup” button on it (where we record only the user-agent class and the referring host).

Email delivery

signups_SA6thward sends four kinds of email: organizer magic-link sign-in emails, a confirmation to a participant when they commit to a slot, a reminder before a dated slot, and an email when the organizer moves a participant's slot to a new date or time. A participant gets these only if they gave an email address. Moving to a different slot gives your spot a new private link, and sends a fresh confirmation with it. The old link then leads to the new one. Each of these participant emails contains a private link that lets you change or cancel that commitment without signing in, so treat them as you would a password and don't forward them. Reminders go out the day before the slot, and a moved-slot email about 10 minutes after the organizer's last change to its date or time; organizers can turn both off for a signup entirely, with the reminders setting. Every reminder and moved-slot email carries a link that stops both for that signup; we record only the time you opted out, and it does not affect any other signup or your slot itself. Delivery uses whichever transport the operator has configured (SMTP, a transactional provider, or local console output in development). signups_SA6thward sends no marketing email.

Connected apps and AI assistants

An organizer can connect a third-party app, typically an AI assistant such as the Claude app, Claude Code, or ChatGPT, to their signups_SA6thward account. Nothing is connected unless the organizer approves it on a consent screen that names the domain the app identified itself from (or, for an app the operator of this instance registered in advance, the name the operator gave it) and lists exactly what it will be able to do. Participants are never asked to sign in and cannot connect anything.

A connected app acts as the organizer who approved it, across every workspace that organizer belongs to, with the same role and never more access than the organizer has themselves. Permissions are approved individually: seeing your signups and their slots, and creating, editing, publishing and deleting signups. Participant names and email addresses sit behind a separate permission an app has to ask for explicitly; the consent screen flags it in amber and says plainly that participants gave those details to you, not to the app. An app that was not granted that permission cannot read participant details at all.

For each connected app we store the approval (which organizer, which app, which permissions, when it was approved, when it was last used, and when it expires), the app's identifier and the name it reports about itself, the refresh tokens that keep the connection alive, and, for the minute it takes to set a connection up, the single-use code that establishes it. Access tokens themselves are not stored. The activity log records that a connection was approved, declined, or disconnected, together with the app's domain (or its configured identifier, for a pre-registered app), and, for every change a connected app makes on your behalf, which app made it. It never records a token or an email address.

You can see and end every connection from Connected apps in your account settings. Disconnecting deletes the approval and every refresh token under it at once, so the app can get no new access; an access token it already holds keeps working until it expires, which is at most 15 minutes. No approval survives longer than 90 days without you approving the app again.

Whatever a connected assistant reads under the permissions you approved is then processed by that assistant's vendor under their own terms and privacy policy, not ours. Apart from AI drafting, described under “Third parties” below, signups_SA6thward sends nothing to an AI vendor itself: only an app you connected, acting on your instructions, can pull data out.

Third parties

OpenSignup is designed to have no required external dependencies beyond a Postgres database. Optional integrations (email provider, error reporting, product analytics, AI draft generation, and third-party sign-in) are off by default and only enabled if the operator has configured them via environment variables. Where this instance has enabled any such integration, the operator will list it on request. Separately from anything the operator configures, an organizer can connect an app or AI assistant to their own account. See “Connected apps and AI assistants” above.

If the operator has turned on AI drafting, what an organizer types into it to describe their signup, along with any answers they give to the questions it asks, is sent to the AI provider the operator configured, which turns it into a draft. It goes as typed, so leave out anything you wouldn't want the provider to see; nothing else about you, your signups or the people on them goes with it. The provider handles it under its own terms. To keep a description away from the provider, skip AI drafting and fill the signup in by hand.

If third-party sign-in (for example, Google) is enabled and you choose it, you authenticate on the provider's own site and they return your email, name, avatar, and a unique account identifier. We store the link between that provider account and your organizer record — along with the standard sign-in tokens the provider issues — so we can recognise you on future sign-ins. If that sign-in created your account, we also keep the web address of the avatar the provider returned. We do not use those tokens to access anything on the provider beyond the basic profile needed to sign you in.

Why we use your data

Data protection law asks us to say what allows us to use your data. For each use:

• To provide what you asked for: an organizer's account, sign-in, signups, and the AI drafting and connected apps an organizer chooses to use; a participant's place on a slot, the confirmation email, and the link to change or cancel it. (In GDPR terms, this is necessary to provide the service you asked for.)
• To send reminders and moved-slot emails, when the organizer has them on, so people turn up at the right time. (Our and the organizer's legitimate interests. Every one of these emails has a link that stops them.)
• To keep the service safe and working: the rate-limit records, the activity log, and server logs. (Our legitimate interest in preventing abuse and fixing problems.)
• To count, in total, how the service is used: the page-view entries and where organizers get stuck, described above. (Our legitimate interest in improving the service.)
• Where the law requires it, for example to answer a valid legal request.

Where we rely on legitimate interests, you can object by emailing us.

How long we keep it

• Organizer accounts, signups, slots, participants' sign-ups and the activity log: nothing deletes these automatically yet. They stay until someone asks us to erase them (see “Your rights”), including after an organizer deletes a signup.
• Sign-in links and codes: until they are used or expire, then an hourly cleanup deletes them.
• Rate-limit records: normally a few hours.
• Connected-app approvals and tokens: until they expire or the organizer disconnects the app, as described under “Connected apps and AI assistants”.
• Server logs: as long as the hosting this instance runs on keeps them.
• What your browser keeps: see the cookies page.

Where your data is stored

Your data is kept in this instance's database, on servers we run or rent. If those servers, or a provider under “Third parties” that this instance has turned on, are in another country, your data goes to that country. Email pierson.jarvis@gmail.com to find out where this instance and its providers are.

Children

signups_SA6thward is not meant for children to use on their own. When a signup is for a child, such as a class rota or a team's snack list, a parent or guardian should sign up for them, with their own email address. If you think a child has given us their details, email pierson.jarvis@gmail.com and we will delete them.

Your rights

You can ask us for a copy of the data we hold about you, or ask us to correct it, delete it, or stop a use you object to, by emailing pierson.jarvis@gmail.com. Today this is a manual process — self-service export and deletion may be added later. If you signed up for a slot, you can also ask the organizer about their own use of your details. Organizers can already delete a signup from its settings. That takes the signup and everyone's commitments to it off the site at once: its page and everyone's edit links stop working, lists and exports stop showing them, and nobody can sign up to it. The records themselves stay in our database until someone asks us to erase them, as above.

If you are not happy with how we handle a request, you can complain to the data protection authority where you live or work.

Self-hosting note

If you are reading this on a self-hosted copy of OpenSignup, the operator of that instance — not the OpenSignup project — is responsible for how your data is handled. The OpenSignup project publishes source code only; it does not operate or have access to data on other people's deployments.

Contact

Questions about this policy or about data we hold: pierson.jarvis@gmail.com.