privacy policy

who we are

lecturemates is an independent product built for usc students. it is not operated by, endorsed by, or affiliated with the university. "we" below means lecturemates.

what we collect, and why

everything in this table is something the system actually stores today. nothing is listed speculatively.

your account

• your .edu email address. you give it to us to receive a one-time code. two things are then kept: the address itself, held in the sign-in table for as long as your account exists, and a keyed fingerprint of it (an hmac computed under a secret held only on our server). the rest of the product — rate limits, block records, everything outside sign-in — only ever sees the fingerprint, never the address. the parts of the system that serve the app hold no permission to read the address table at all. deleting your account deletes both.
• your surname. collected when you complete your profile. it is not shown to classmates on any screen and appears in no profile view. one moderator-only function can read it, and every such read is logged.
• profile fields you choose: display name, how much of your name to show (full, initial, or none), graduation year, major, a profile photo, and links to other accounts with a per-link visibility setting.
• privacy and notification settings: whether your profile card can be opened at all, whether push notifications may show a preview, which notifications you want, and who can see your class times.
• sign-in sessions: a session token, and — recorded by our authentication library at sign-in — the ip address and browser/device user-agent the sign-in came from. these are kept as security forensics for the life of the session and are deleted with your account.
• one-time codes: a pending code row exists only until you use it or it expires.

what you do in the app

• enrollments — the sections you add, the visibility you pick for each, and an append-only log of adds and removes (which is what the per-term change limit is computed from).
• chat messages in section rooms, event rooms and the campus room, including images you send, whether a message was posted anonymously, reactions, pins, @mentions, and your read position in each room.
• the anonymous board — posts, replies, votes, awards you give, and saves.
• anonymous dms opened from a post. a thread stores a pseudonym drawn fresh for each side of each thread, and a message records which side sent it — there is deliberately no sender id column on a dm message.
• events — events you host or co-host, rsvps, invite links and their redemptions, event photos, and a record of guests a host removed.
• greek rank — your chapter membership if you declare one, and your daily ballots.
• connections, blocks and reports you make.
• streaks and rewards — a single row holding your current and longest sign-in streak (not a per-day log of when you opened the app), plus append-only earn and spend ledgers for invite rewards and post awards.
• push device registrations — the apple push token for each device you sign in on, and a separate token used for live activities.

operational data

• rate-limit events, keyed on your account or your email fingerprint — never on your ip address.
• product analytics. we use no analytics vendor and no third-party sdk. our own event table records a closed list of ten event names (things like "post viewed", "event rsvp", "widget installed") with a closed list of property keys. it has no user id column at all — not an unused one, no column exists — so it cannot be queried for who did what. rows are deleted after 90 days.
• moderation records — reports, decisions, and a log of every moderator read.

how long we keep it

• product analytics: 90 days, deleted by a scheduled job.
• push notification preview permissions: 30 minutes, then swept.
• one-time codes: until used or expired.
• messages and posts: until you delete them, or until you delete your account. we want to be exact here rather than reassuring: an automatic age-based purge of chat messages is designed and intended but is not built yet. we are not going to print a retention window the code does not enforce. this page will state the real figure on the day the sweep ships.
• everything else: for as long as your account exists. see deletion below for what happens after that.

who can see what

• other students see only what the app's own screens show: your roster entry in sections where you opted in, your profile card if it is discoverable, your named messages, and your posts without any author attached. a section roster only appears once enough classmates in it have opted in, so a small seminar may show no roster at all. your .edu address is never shown to a classmate and is not reachable through the app.
• moderators see reported content and, for a reported profile, the display name — nothing else. the moderation queue never shows who filed a report. a moderator can separately look up a reported account's surname through one dedicated function, and that read is logged as its own distinguishable event. reported messages and posts are shown to moderators with no author id at all.
• us, as the operator. honest limit, stated plainly: anonymous posts store an author id in a column that no view, function or app permission exposes, and a build check fails if any student-reachable query joins authorship to identity. that closes the app. it does not close direct database access. a person holding the database's own administrative credential can join an anonymous post to the account that wrote it. anonymity here is a strong guarantee between you and other students; it is not a guarantee against us, and it is not a guarantee against valid legal process.

anonymity, precisely

• board posts and anonymous room messages carry no author on the wire. the response shape has no author field, which is a structural property rather than a filter someone remembered to apply.
• anonymous dms use a fresh pseudonym per thread, per side. the message row records a side, not a person.
• anonymous posting only turns on once a room is large enough, and is rate-limited to one anonymous message per room per day.
• anonymous messages are not filtered by blocks. blocking someone hides their named messages from you, not their anonymous ones — doing the reverse would let you unmask them by elimination. the control is "hide anonymous messages in this room".
• anonymity is not a defence against these terms. reports are reviewed and content is removed regardless of whether a name was attached.

who we share it with

we do not sell your data and we run no advertising. a small number of service providers process data on our behalf, and each one is listed with what it actually receives on the subprocessors page. two are worth calling out here:

• images you upload are scanned. every avatar, chat image and event photo is sent to openai's moderation endpoint before it is stored. if the scanner cannot be reached, the upload is refused rather than allowed.
• some post text is sent to a language model. three background jobs — the greek board's tag strip, the daily campus digest, and the trending-post summary — send recent anonymous post bodies to openrouter to be summarized. every body passes through a redaction step first that strips emails, phone numbers, @handles and name-shaped word sequences, and there is no code path from the database to that request which skips it. the redaction deliberately over-removes. no account id, no name and no email is included in these requests.

we may also disclose information where we are legally required to, or where it is necessary to address an immediate risk to someone's safety.

your controls

• export. one request per day returns a single json document with twenty-one sections: your profile, settings, links, coursework, consent history, enrollments and enrollment history, connections, the messages you wrote, your board posts, replies, votes and awards given, your reward ledgers, your invites, your greek membership and ballots, the reports you filed, and your registered devices. three things are deliberately left out: your email fingerprint, your block list (a portable block list is also a portable list of who blocked you, once two exports are compared), and reports filed about you.
• delete your account, and choose what happens to what you wrote. the default, sever authorship, removes you from your messages and posts and leaves the bodies in place so threads stay readable. the alternative, purge bodies, blanks the text and images as well. either way your account, profile, settings, enrollments, connections, votes, ballots, ledgers, sessions, devices and email address are deleted outright, and your choice is recorded.
• per-section visibility — you choose what shows on each section's roster, per class.
• discoverability — whether your profile card can be opened at all.
• name visibility — full, initial only, or none.
• class-time visibility — everyone, connections, or nobody. sections you share with someone are always visible to them.
• notification settings, including whether a push notification may show a preview on your lock screen.
• anonymous dms — a post's author decides whether it can be dm'd.
• block anyone, subject to the anonymous-message caveat above.

what survives deletion, and why

deletion is close to total, and the exceptions are deliberate. we would rather name them than let you find them.

• blocks become tombstones. a block between you and someone else survives as a pair of email fingerprints with no account id attached and nothing joinable to a live user. if either of you re-verifies with the same address, the block comes back. without this, deleting and re-registering would be free block evasion.
• removals from events become tombstones on the same fingerprint, for the same reason.
• the moderation audit trail is severed, not erased. decisions and moderator-access records keep their verb, timestamp and outcome, with your id blanked out. an audit trail a deleted account can delete is not an audit trail.
• one anonymized consent row records that a deletion happened and which mode was chosen. it carries no reference to you.
• invite join events survive with both ends nulled, so an inviter's reward count stays honest without keeping a record of who joined.

your rights

depending on where you live, you may have rights to access, correct, delete, or receive a portable copy of your personal information, and to object to or restrict certain processing. the export and deletion controls above are how we serve access, portability and erasure today; for anything else, contact us at the address below. we will not discriminate against you for exercising a privacy right. we do not sell or share personal information as those terms are used in california law, and we run no targeted advertising.

age

lecturemates is for university students and requires an account holder to be 18 or older, checked at signup and recorded with the policy version you agreed to. it is not directed at children, and we do not knowingly collect information from anyone under 18. if you believe a minor has an account, contact us and we will remove it.

where your data is

our database and servers are in the united states. if you use lecturemates from outside the united states, your information is processed there. the subprocessors page lists each provider and its region where we can determine it.

changes

the version of this policy you agreed to is recorded against your account at the time you agreed to it, and material changes will be called out rather than silently reflowed. the date at the foot of this page changes whenever the text does.

contact

TODO — privacy contact address not yet published. a monitored mailbox will be named here before signup opens; until then this page carries the draft notice below.