Security · Coetio

Coetio holds student names, attendance records, service hours, and sometimes a parent's phone number. Most of the people using it are under 18. This page says what protects that information and what does not exist yet.

Coetio is one product, built and run by one student. It holds no security certification. No outside firm has audited it or tested it. Everything below describes how the code works today, including where each protection stops.

Two things built into how records are stored

Most of what protects a student on Coetio is a permission check that runs on the server every time someone asks, and the next section lists those. Two protections come from how the records are stored instead.

A date of birth stays with the account

A student's date of birth is stored on their account. The roster screens, the roster export and the organization backup all read the membership record, and the membership record has no date-of-birth column, so there is nothing in them to strip out. Nobody sees a date of birth but the account holder and the site administrator. Not the owner, not an officer, not a roster, not a backup a leader can download.

The database has no public API

Coetio's data is hosted on Supabase. Every app built that way ships a public database key inside the web page itself, and anyone can open View Source and read it. On most such apps, that key can fetch tables directly. On Coetio it fetches nothing. Row-level security is switched on for every table, and the public roles have had every privilege revoked, including the default privileges that a table created next month would otherwise inherit. Data moves through Coetio's own permission checks or it does not move.

Who can see what

Each rule below is checked on the server every time a page or an export is asked for.

Phone numbers. Among an organization's leaders, only the owner sees them. An officer who can otherwise manage the roster cannot, and every screen and export that could show a phone number checks whether the reader is the owner before including it. A guardian's phone number at a volunteer program follows the same rule. As the privacy policy says, accounts with platform administrative access can also reach them.
Guardian names. At a volunteer program, a guardian's name appears on the volunteer's page to any coordinator who can view the roster. It is left out of any export produced by someone other than the owner.
Kiosk PINs. The PIN a member taps in with is left out of every export an organization can download, the owner's included. It is in the site administrator's full database backup, along with everything else.
Poll ballots. A poll reaches a member's screen as the count for each option, the total, and that reader's own vote. Other people's ballots stay on the server, so on a question like “should we replace the treasurer” there is no list of voters in the page source to find.
Viewing as a member. An owner can see what a member sees, to check a screen looks right. They cannot do anything as that member. Two independent parts of the system refuse every write while that view is on: one stops the request before it reaches a page, the other stops it inside the action. The feature can only take permissions away, never add one.
Roles. What a leader may do is checked on the server against their role each time they do it.

Check-in and volunteer programs

Attendance QR codes are signed, so a screenshot of yesterday's code will not check anyone in today and a code for one event will not mark anyone present at another. The rotating kiosk code changes every 30 seconds.

At a school club, the check-in screen is a leader's session

A school club's tap-your-name screen and its rotating code run on the signed-in session of the leader who opened them. Clubs have no paired device, so a tablet left at the door is signed in as that leader, with everything that leader can reach. Sign out before leaving it unattended.

At a volunteer program, the front-desk tablet is a paired device

A volunteer program pairs the tablet itself rather than leaving a coordinator signed in on it. A paired tablet can see who is scheduled today and record their taps, and that is all it can do. It cannot reach the roster, a phone number, another page, or another organization. Only a hash of the tablet's secret is stored, so someone who read the database still could not act as that tablet, and a coordinator can revoke a lost tablet from any device without touching it.

A shift's activity is picked from a list

A volunteer shift records what the volunteer did, picked from the program's own list. The server refuses a shift carrying an activity that is not on that list. A typed box would have turned “Bingo” into “Bingo with Margaret” the first week someone was being helpful. Coetio never asks for anything about the people a program serves. It cannot stop someone typing a name into a free-text box, such as the note on logged hours, and the terms of service make keeping those names out the program's responsibility.

Accounts, passwords and age

Coetio is a 13-and-over service. The signup form asks for a real date of birth and the server works the age out itself, month and day included, before an account exists. There is no authentication record and no database row until that check passes.

Signing in with Google creates an account at Google before Coetio can ask anything. If the answer then comes back under 13, Coetio signs the session out and deletes the authentication records rather than leaving a half-made account behind.

A browser that has been refused cannot try a different birth year a second later. The refusal is stored for 30 days in a cookie the page's own code cannot read, and the blocked page renders no form. That makes a casual retry fail. Someone who clears their cookies or opens a different browser gets a fresh attempt, and 30 days rather than forever is deliberate, so a shared school computer is not locked out for a term.

The age check is not retroactive, and it does not cover a roster entry a leader types in for someone with no account, or a guest checking in at an event. The privacy policy states exactly who it covers and who it does not.

Coetio's database has no password column. Sign-in is handled by Coetio's authentication provider, which stores passwords only in hashed form. Coetio's own code never sees one.

Signing in, signing up, resetting a password, joining an organization, uploading a file and the public contact form are all rate-limited, and every limit in the app is listed in one place in the code. The numbers are sized for a school: a class of 40 opening the same invite link on one wifi network is normal traffic, not an attack. Whether a limit refuses or allows when the limiter itself is failing is decided limit by limit. Anything that could be used to send email or reach an outside service during an outage refuses. A limit guarding a write to Coetio's own database allows, because that database is down in the same scenario and students should not be locked out of their own organization by it.

An invite or sign-in link carries a “where to go next” instruction. Coetio accepts a destination inside Coetio and nothing else, so a link that looks like a Coetio sign-in cannot land a student on another website.

Files, photos and links

Since late August 2026, permission slips, budget sheets and signed forms attached to a post or to minutes are stored as private files. The only link a page renders goes through Coetio, which checks who is asking at the moment they click and then hands back a link that stops working 60 seconds later and downloads rather than opening in the browser. Photos, banners, avatars and images inside posts uploaded since then are sent by Coetio itself, which re-runs the page's own visibility check on every request before any bytes go out.

Files uploaded before late August 2026 were stored with a permanent public address, and they were left where they were rather than moved. Anyone who copied one of those addresses can still open it. Opening an old attachment through Coetio still checks the reader first, and then hands over that same permanent address.

Uploads are limited by file type and size on the server, the size is checked again against the file as stored, and every upload is written under the uploader's own folder.

A personal calendar link contains no email address. A subscribed calendar re-fetches its link every few hours forever and hosting platforms record the full address of every request, so the old shape was accumulating a roster's worth of student addresses in log files. The address is now encrypted into one meaningless path segment, and decrypting that segment is what authenticates the request. A student can reset their own link from their profile. That stops every earlier link working, including the old form with the email address in it, without affecting anyone else. A reset cannot recall what a calendar app already fetched.

Exported spreadsheets cannot run code on the machine of the teacher who opens them. A cell beginning with an equals sign is a live formula to Excel and Google Sheets, and names arrive through a public join form, so every such cell is neutralized on the way out.

The connection and the browser

Traffic between a phone and Coetio is encrypted with HTTPS, and browsers are told for two years at a time never to attempt an unencrypted connection to it, subdomains included. Coetio also tells the browser not to guess at the type of a file it serves, to send only the origin of a Coetio page when following a link off it, and to deny the microphone and location permissions outright. The camera is allowed only to Coetio's own pages, for scanning a check-in code.

No other website can load Coetio inside its own frame, which is what stops a page elsewhere wrapping Coetio invisibly and tricking a student into clicking something. That is the only content security policy directive Coetio sets. It guards against framing and does nothing against injected scripts.

What is kept, and what deleting removes

Coetio backs up daily. Fourteen daily copies and eight weekly copies are kept, and nothing is kept past 90 days, including the newest file. That 90-day limit is what the privacy policy promises, and it is enforced by code with a test that proves it rather than by anyone remembering. So information deleted from the live service can still sit in a backup for up to three months, and then it is gone. A backup is a private file. It is not separately encrypted, and it contains the whole database, phone numbers and ballots included.

Five kinds of thing go to a trash for 30 days before they are gone: announcements, events, minutes, tasks and committees. Other things are deleted immediately with no undo, including documents, photos, ledger entries, service hours, attendance records and sign-up sheets. Any officer holding the document permission can delete a document, and a deleted signed permission slip cannot be recovered except by asking the family to sign it again.

Deleting an account clears the name, email, phone number, any note a leader wrote, and anything an owner collected in a custom roster field. A guardian's name and phone number go with it, which matters because a parent never had an account and cannot ask for that themselves. The organization keeps its own history, such as attendance counts and hours, attached to a row with nobody's name on it. Deleting an organization also deletes its files, the private ones included, rather than leaving them fetchable by anyone holding an old link.

The full retention schedule, record type by record type, is in the privacy policy.

What Coetio does not do

These are the known gaps, as of the date at the top of this page.

No two-factor authentication. Sign-in is a password, a one-time email link, or Google. A password has to be at least 8 characters and is not checked against lists of known-breached passwords.
No certification and no outside audit. There is no SOC 2 report, no ISO certification, no third-party penetration test and no bug bounty. Nobody outside has assessed Coetio's security.
No compliance badge. Coetio is not certified under FERPA or COPPA and does not claim to be. It is not a school and it is not a student-records system. What it enforces is the 13-and-over check described above. Compliance with a school's own rules on student data and parental consent stays with the organization's leaders. A school weighing Coetio should read this page and the privacy policy rather than look for a badge, and what school verification does and does not grant is written out in full on its own page.
Encryption at rest belongs to the providers. Coetio's database and files are hosted by Supabase and the application by Vercel. Both encrypt stored data as a platform default. Coetio adds no layer of its own and does not control that one. The one thing Coetio encrypts itself is the address inside a personal calendar link.
Not every credential is hashed. A member's kiosk PIN is stored as plain digits. It is a 4 to 6 digit code used at the check-in kiosks, both a club's and a volunteer program's. It is left out of every export an organization can download, and it is in the site administrator's full database backup. At a school club's tap screen, the first person to tap a name with no PIN sets one, so a member who wants a PIN should set it from their own profile first.
One person, and no pager. There is no security team, no on-call rotation and no monitoring that wakes anyone up. An outage can run for hours before anyone notices. If an incident ever affects personal information, affected accounts will be told without undue delay, which is what the privacy policy commits to. No number of hours is promised.
A restore has never been performed. The backup runs every day and the files are readable, but Coetio has never actually been rebuilt from one. Uploaded files are not in the backup and neither are sign-in credentials. Only the database is.
One host, one database, no failover. If either provider has an incident, Coetio is down until they fix it.
Unlisted is not private. An unlisted organization is kept out of the directory. Anyone holding the link still sees its page. For a public organization, the leadership names and the member count are visible to anyone, signed in or not. That is deliberate, and it is how a student finds an organization to join.
Not everyone on Coetio has an account. A leader can add a roster entry for someone who never signed up, and an event can take guest check-ins. Neither of those people agreed to the terms and neither passed the age check. Either record can be removed on request to support@coetio.com.
Rate limits are not a wall. They slow automated attempts. Most of them deliberately allow the request through if the limiter itself is failing. The ones guarding sign-in, uploads and outbound alerts refuse instead.

No online service can guarantee absolute security, and Coetio does not.

Reporting a security problem

Email support@coetio.com with “Security” in the subject line. Machine-readable contact details are at /.well-known/security.txt.

What to expect

One person reads that inbox. A report gets a reply once he has seen it. There is no reward, no bug bounty, and no promised response time, because promising one that cannot be met is worse than promising nothing. A report that turns out to be real gets fixed ahead of everything else, and the reporter is told when it is done and credited if they want to be.

What helps

Say what you found, the steps to see it, and what it exposes. Include the smallest amount of data needed to show the problem is real, and nothing more. Coetio is coetio.com and the interfaces behind it.

Rules for testing

Use your own account and an organization you run. Do not read, change or download anyone else's information, and stop as soon as you can see that something is wrong. Do not run scanning that slows the service down for the students using it. Do not attempt anything involving another person, a physical device, or a denial-of-service. Report a problem rather than exploiting it, which is the same rule the community guidelines already state. Testing kept within these rules will not be treated as an attack.