VeriTrust: Corporate Privacy Shield

• 

  Landing page

• 

Inspiration

Most "anonymous" feedback tools aren't really anonymous — they're just unlabeled. Under the hood, a lot of platforms still store a userId next to every submission "for moderation purposes," which means anonymity is really just a promise, not a property of the system. That gap between what companies say ("your feedback is anonymous") and what their database schema actually does (stores exactly who said what) felt worth fixing.

We wanted to build a feedback portal where anonymity isn't a policy decision made by whoever has database access — it's architecturally impossible to break, because the data to de-anonymize someone simply doesn't exist in the first place.

What it does

VeriTrust is an anonymous employee feedback and rating portal with two roles:

• Employees authenticate, then submit feedback (department, 1–5 star rating, and a message) through a form with a "Midnight Privacy Lock" — an animated verification step that visually reinforces that the submission is being decoupled from their identity.
• Admins (HR) log into an analytics dashboard showing aggregate metrics (total submissions, average rating, department breakdown) and a card-based grid of every feedback entry — each one stamped with a unique cryptographic proof token instead of any name or email.

The key design constraint: the Feedback collection has zero foreign keys, ObjectIds, or references back to the User collection. Once a submission hits the database, there is no join, query, or admin privilege that can trace it back to an employee — because the link was never persisted to begin with.

How we built it

• Backend: Node.js + Express, with MongoDB/Mongoose for storage. Auth uses JWTs and bcrypt-hashed passwords, with role-based middleware (Employee vs Admin) gating every route.
• Anonymity layer: When feedback is submitted, the authenticated user's identity is used only to pass the role check in middleware — the controller that actually writes to the database never reads or stores req.user. Each entry instead gets a midnightProofToken: a SHA-256 digest generated from a random seed and a high-resolution timestamp, giving every submission a unique, verifiable "receipt" with nothing identifying baked in.
• Frontend: React (Vite) with Tailwind CSS, styled as a dark, glassmorphic "corporate security terminal" — deep slates, teal/violet neon accents, and subtle grid backgrounds — to make the privacy guarantees feel as tangible as the UI itself. react-router-dom handles role-protected routing between the employee dashboard and the admin panel.

Challenges we ran into

• Designing a schema that resists its own creator. It's easy to say "no foreign keys" — it's harder to make sure no later feature (analytics, moderation, abuse reports) quietly reintroduces one. We had to treat the absence of a userId field as a hard invariant, not just an initial choice.
• Making "zero-knowledge" honest. We initially described the proof token in more cryptographically loaded language than it deserved. A SHA-256 hash of a random seed is a strong uniqueness guarantee and a good receipt — but it isn't a real zero-knowledge proof system like zk-SNARKs. We had to be precise in our own docs about what the token proves (submission happened, uniquely) versus what it doesn't (a formal, verifiable proof of authorization).
• RBAC without leaking role logic into the wrong layer. Keeping the "who is allowed to do this" check (middleware) cleanly separated from "what gets written to the database" (controller) took a few iterations, so that even a future bug in the middleware couldn't cause identity data to leak into a Feedback document.

What we learned

• Real anonymity is a data-modeling problem before it's a policy problem. If the join is possible, the anonymity is optional — enforced by discipline, not design.
• Being precise about cryptographic claims matters. It's tempting to reach for impressive-sounding security language, but overstating what a hash-based token proves undermines the actual trust you're trying to build.
• A visual design that reflects the security model (dark, terminal-like, deliberate) does real work in helping users believe the privacy guarantees, not just read about them.

Built With

• express.js
• javascript
• mongodb
• node.js
• react
• tailwindcss