Saying "anonymous" is easy. Most platforms do. The question a careful student should ask is: what would an attacker with full access to the database actually see? On Poray Kemon, the answer is: nothing that could re-pair a review to its author. This post walks through why.
What we know about you
You sign in with Google, and that is the only identity we ever touch. From that sign-in, we store two things: an opaque internal identifier that Google gives us, and the display name you chose to show. We do not store your email address. We do not store your profile photo. We do not track IP addresses.
What happens when you submit a review
When you press submit, three separate things happen inside a single database transaction:
- A row is inserted into the reviews table. This row contains your ratings, the tags you picked, and your written text. Nothing else. There is no column on this row that names you or points to your account.
- A row is inserted into a completely separate table that tracks which account has reviewed which course. This table exists so you cannot review the same course twice. It holds no review content and no reference back to any specific review.
- The running average scores on that professor-course are updated.
Why the two tables cannot be re-paired
A naive design would leak authorship in three different ways. We spent real time making sure ours does not:
- No foreign key. There is no column that joins the two tables. A single SQL query cannot line them up.
- Different identifier styles. The reviews table uses sequential ids. The submissions table uses random UUIDs. That prevents an attacker from lining them up by sorted id order.
- No submission timestamp. The submissions table does not store when the submission happened. That prevents matching by time. This one detail is easy to miss and matters a lot: without it, two rows written in the same transaction share the exact same server time and could be paired by anyone with access.
What we cannot do (even if we wanted to)
Because there is no bridge between the two tables, there is no query we can run (nor any query someone with a stolen database dump can run) that would answer "who wrote this review?" This is not a policy commitment. It is a structural property of the schema.
The one thing this design does prevent: it prevents us from ever offering an "edit your reviews" feature. That is a tradeoff we made deliberately. Being unable to edit is the same property that makes the anonymity honest.
Verifying this for yourself
The codebase will be open source once the initial launch settles. When that happens, anyone can inspect the schema, the migration history, and the review submission code and confirm the guarantee holds. Trust matters more when you can check it.
The right question is not "do they promise anonymity?" The right question is "could they violate it if they wanted to?" Here, the answer is no.