If a PI makes you log in, the screen shows nothing

Advisor reviews are not like restaurant reviews. A student can be told to open the site while someone watches. PhdEnvision is built so that moment gives away nothing.

Logging in reveals no history

There is no “my reviews” page. No review is marked as yours. There is no edit button, no timestamp, and no list of PIs you have rated. A signed-in account looks the same whether it has written ten reviews or none.

Nothing can be deleted

Not by you, and not on request. Anything that can be withdrawn can be withdrawn under pressure, and a score that can be pulled can be gamed. Write it once, as if it will stay.

Your address is not stored with your review

Your review is saved with a one-way token instead of your email. There is no list of who wrote what, and the token cannot be turned back into an address. The site keeps no record of which account logged in or when.

Stars are not attached to a paragraph

You can write as many reviews as you want, and they all stay. Scores are separate from the text: no review shows a number, so a paragraph cannot be matched to a score. If you later change a score, only the new one counts.

Nothing public updates immediately

A new review waits 24 hours before it appears. Averages show only after at least five different .edu accounts have rated a PI, and they refresh on a delay. The numbers you see are deliberately inexact, and the inexactness itself shifts over time, so watching the page will not tell you what one person did.

This does not make retaliation impossible. It makes the common “open the laptop and we’ll see” test fail.

Technical details

For readers who want to check the claims above against how the system is actually built.

Identity

  • Login is a one-time 6-digit code sent to a .edu address. There are no passwords. Codes are stored only as keyed hashes and deleted on use or expiry.
  • The session holds an account id. The navigation bar never prints the address. No page filters, marks, or counts reviews by the signed-in account.

Storage

  • The reviews table has no email column. Each review carries an author token: HMAC-SHA256(secret, PI id ‖ normalized address).
  • The secret lives only in the server environment, not in the database. A copy of the database alone yields tokens that cannot be reversed, listed by person, or linked across PIs (the PI id is inside the hash, so one account produces unrelated tokens for different PIs).
  • The token exists for one purpose: when the same account rates the same PI again, the new scores replace the old ones. Review text is never replaced or removed.
  • Review timestamps are rounded up to the hour before storage. Public lists are ordered by a keyed hash of the row id, not by time.

Aggregation and display

  • Per PI, the current score is the latest submission per token. Nothing is shown until at least five distinct tokens exist and 24 hours have passed since the fifth.
  • Displayed averages are a delayed snapshot, not a live query. They do not change when a review is written.
  • Displayed numbers are perturbed, and the perturbation is not a simple zero-mean noise that averages out under repeated observation. Its form and magnitude are deliberately not published, because here the uncertainty is the protection.

Logging

  • The application writes no access log and never logs a recipient address, code, or client IP. Rate limiting uses in-memory counters only.
  • The hosting provider keeps its own HTTP request logs that the application cannot disable. Because the database holds no addresses, no sub-hour timestamps, and no submission order, there is little for those logs to be joined against.

What this does not do

  • It does not hide you from what you write. A story only two people know identifies its author regardless of cryptography.
  • It does not protect against a compromised server. Whoever controls the running code can capture submissions as they arrive. The design protects against after-the-fact inspection of the database, the screen, and the logs, not against a live takeover.
  • The operator holds the secret. With both the secret and the database, a specific suspected address could be tested against a token. The database cannot be turned into a list of authors, but an operator who wanted to confirm a guess could. You are trusting the operator not to.