02 · codename · the real product is confidential
▮ VEIL
Privacy enforced by the database, not the application.
2,869
lines of SQL enforcement
19
persona-matrix test files
3
disclosure tiers
0
rows served without a second factor
/ interactive · change the grants, watch the fields obey
try it, everything responds
what Nadia lets you see
You are viewing as another member. Nadia decides how precise her entry is for you, from nothing at all to full detail.
may you know who it is · separate consent
Seeing the plan and knowing whose plan it is are two separate permissions. Either can be taken back at any time, independently.
The dinner plan is a stand-in; the real system protects information where getting this wrong endangers people. What makes it different: these rules live inside the database itself, not in the app. The app cannot read the underlying tables at all. It can only call vetted functions that return already-masked rows, write the access log as they do it, and refuse to identify the caller unless their login proved a second factor. Nearly 1,900 lines of tests assert exactly which rows and fields every kind of user can and cannot see.
A note on this demo. Every figure, name and data point here is invented for illustration. No client data, real economics or production configuration appears anywhere on this site. What is real is the machinery: the calculations, the rules and the logic running in your browser are the same ones the production system uses, so the demo behaves exactly as the real thing behaves.
What it is
/ in plain terms
A private coordination platform for a small closed group of people whose personal safety depends on who can see their plans. Instead of trusting the app to hide things, the database itself refuses to hand over anything a member has not explicitly allowed, and it keeps a permanent record of every look. If you have no permission, the information does not exist for you at all.
A coordination platform for a small closed group of high-profile people. The thesis is that the application is untrusted, so every privacy promise is enforced inside the Postgres database itself. Each member controls two independently revocable consents: may you see my activity, and may you know it is me. Three disclosure tiers control how precise the visible information is, and every read path returns rows that are already masked. Without a grant the row is absent from the result, never redacted-but-present.
Lead engineer, 28 of 32 commits, alongside one peer developer. Codename used because the product is confidential.
The load-bearing details
- 012,869 lines of SQL migrations, roughly 30 row-level security policies and 23 privileged database functions. The application cannot read the underlying tables at all; it can only call vetted functions that hand back pre-masked rows.
- 02Multi-factor authentication (MFA) enforced inside the database: the identity resolver returns nobody unless the login token proves a second factor was used this session. Below that threshold every policy fails closed.
- 03Anti-oracle hardening: every helper function is bound to the caller, so nothing in the system can be tricked into answering whether a relationship exists between two people.
- 04An append-only access log is written inside the read functions themselves and surfaced back to each member as a record of who viewed them.
- 05A self-audit found a critical authorization bypass and three high-severity field leaks. Every fix shipped with a regression test, in a 1,897-line test suite that checks ten personas against every table and function.
- 06Real names are encrypted with keys held outside the database, so even a stolen copy of the data yields opaque handles rather than people.