Most privacy is a promise: a policy document, a toggle, a company's word that it won't look. For fifteen years I've built the kind that doesn't depend on anyone keeping their word — privacy enforced by the architecture, so it holds whether or not anyone's watching. In practice that's meant access control on every node, data that never leaves the device, accountable access that records why it was used, and encrypted storage a customer can audit with cryptographers of their own choosing.
What I mean by privacy as architecture is concrete: the confidentiality boundary lives in the data layer and the running software, not in a policy document or a promise to behave. Access control rides on every node of the graph, the server refuses anything the rules don't allow, and where it matters most the data is encrypted on the owner's device before it leaves, so the machines that store it never see plaintext and never hold a key.
That holds even when the storage operator itself is the adversary. In SafeCloud — independently written up this month by Help Net Security and published as a research paper — every file is split into chunks and encrypted on the owner's device, the nodes that store data see only ciphertext, and the nodes that route data hold no keys. A customer doesn't have to take the provider's word that their data is private; they can check it.
The same thing works on the device. In the Groups app, used by millions of people in over 100 countries, the vast majority of users' contacts never leave the phone. A browser extension fills any website in with your own contacts locally, so the page becomes personal to you while the site never receives your address book and never learns who you are. The matching runs where the data already is, instead of shipping the data out to where the matching happens. Groups also runs server-supplied code only inside a pristine, inert environment — no script execution, no network access — and applies a code or content update only after checking its signature against pinned keys. That's the same attested-execution idea I've kept building on since, done on the client.
When the architecture can't remove a risk, you measure it. A paper on demographic disclosure works through the differential-privacy side of this — Fréchet-bound cell characterization, the Dinur–Nissim reconstruction threshold, and an (ε,δ) mechanism that spends privacy budget per cell only where a cell actually needs it, and not at all for a large, regular population. You read the privacy cost off the data instead of paying a flat tax on the whole release. Differential privacy also does something no architecture can: it bounds what an adversary learns even when they already know things about a specific person, and the paper is explicit about that.
Some of this is old. I filed a patent application in 2010 on cross-domain personalization that never got granted — I didn't answer the office actions and it lapsed — so it isn't proprietary to anyone, and it's a public record from sixteen years ago of me already working on how to keep someone's identity from leaking across the sites they use. I built the thing years later, in Groups. The next step is consensus between systems — specced out, not built yet — for the layer above storage and compute, where validators see only hashes and never the data underneath.
Independent press coverage of the encrypted-storage work first, then the open-source implementation and its design, the on-device data minimization shipped to millions, the differential-privacy paper that measures disclosure exactly, the privacy-versus-accountability question and the M-of-N answer to it, a design that defeats the intersection attack by construction, the verifiable-elections work where secrecy and a checkable count hold together, and the access-control substrate underneath all of it.
Help Net Security wrote up the SafeCloud research this month. The one design rule: the nodes that store your data see only ciphertext, and the nodes that route it hold no keys. Files are split into chunks and encrypted on the owner's device before anything leaves; the storage node can confirm it holds the right chunk without a key and without ever seeing the contents. A third party's read of the work, not mine.
Read the coverage →Three structures over one addressing scheme: a public Merkle tree for integrity, a key-derivation tree for confidentiality, and an access tree for authorization, so a single path locates a chunk's integrity proof, its decryption key, and its access grant at once. The same key hierarchy doubles as random-access decryptable streaming with per-segment access control — granting a preview or a rented chapter is handing over one range key. The cryptographic core is built and working; the write-up is candid about which payment and proof-of-storage hooks are still being wired in.
Read the architecture →The same idea running in production today. Websites get the social features people want — inviting contacts, tagging people, filling in names — but your address book never leaves your phone. The matching happens locally, and the site receives only an opaque per-site reference for the specific people you chose to share, meaningless to anyone without the mapping that stays on your device. The work moves to where the data already is, instead of the data being shipped out to where the work happens.
Read the architecture →Given the per-group results an election publishes, what can an adversary actually reconstruct about one person? The paper answers it with Fréchet bounds on each cell, works out exactly when a cell collapses to a single value, places the guarantee against k-anonymity, ℓ-diversity, and t-closeness, and adds an (ε,δ) differential-privacy mechanism that spends budget per cell only where a cell needs it — zero for a large, regular electorate. It cites Dwork–Roth, Dwork–McSherry–Nissim–Smith, and Dinur–Nissim. It's also explicit that DP bounds what an adversary learns even when they already know things about a specific person, which the no-noise methods can't.
Read the paper →Total privacy is not always what a community or organization actually needs. Sometimes, when something goes wrong, people need a way to find out what happened — and the hard part is giving them that without wiring surveillance into everything along the way. The approach encrypts data segment by segment and requires several parties to combine their keys (M-of-N) before any part can be read, with a record of why they did it and limits that prevent it from turning into a panopticon. An AI can flag a moment for review without anyone seeing the underlying data until there is a real reason and real due process for everyone involved.
Read the essay →The same idea applied to one of the hardest problems in the field — the intersection attack. Record how someone voted alongside their religion, then their age, then their zip code, and the combination eventually identifies a single person even though no single field does. The usual answer is differential privacy: collect the dangerous dataset and add noise to blur it. This design takes a different route and never creates the dataset at all, running a separate election for each demographic dimension so no record ever holds two attributes together. Voters get a receipt that proves their ballot was counted without revealing how they voted, and the write-up is careful about where this complements differential privacy rather than replacing it.
Read the design →The formal companion to the design above. It holds three properties at once that usually trade against each other: a secret ballot, integrity a person can check without trusting the operator, and a continuously available tally. The treatment is game-based — BPRIV-style ballot privacy, end-to-end verifiability, JCJ-style coercion-resistance — and it says exactly where each guarantee stops, including one residual attack it doesn't claim to defeat. I'd rather state what a system proves and where it breaks than oversell it.
Read the paper →Underneath all of it is a four-tier read, write, and admin model. Every piece of data starts out private and carries its own permissions, and the server checks them on every single request rather than trusting whatever the client claims. As far as I know, it is the only graph database built on ordinary MySQL that still enforces privacy controls at every node, and it has been running in production since 2011.
Read the spec →Gregory Magarshak. Fifteen years building open, sovereign infrastructure where the privacy boundary is the point — the Qbix platform, the Intercoin smart-contract suite, and the SafeCloud encrypted-storage network. M.S. Mathematics, NYU Courant. I teach AI at IE University in New York, and I've published a set of papers on the theory underneath this work. Everything described above is real and running, open-source, or published: the code is on GitHub today, and it is yours to inspect, fork, deploy, or take apart.