Hoe ik een kluis bouw waar ik zelf niet bij kan

Ik bouw een digitale kluis. Eentje waar mensen hun belangrijkste bestanden in bewaren: wachtwoorden, cryptosleutels, documenten voor als ze er niet meer zijn. En de moeilijkste beslissing die ik tot nu toe genomen heb: zorgen dat ik zelf nergens bij kan.

Als je een SaaS-product bouwt, wil je alles zien. Dashboards met gebruikersdata, support-toegang tot accounts, logging van wat er in en uit gaat. Elke tutorial, elk framework, elk voorbeeld gaat ervan uit dat jij als founder ergens een admin-paneel hebt waar je kunt meekijken.

Bij Trustbourne heb ik dat bewust opgegeven. Als ik een kluis verkoop voor je belangrijkste bestanden en ik kan er zelf bij, dan is het geen kluis. Dan is het een map op iemand anders z'n server.

Twee kluizen, één keuze

De architectuur van Trustbourne draait op encryptie in de browser. Bestanden worden versleuteld op jouw apparaat, vóórdat ze mijn servers bereiken. Ik zie encrypted blobs. Inhoud, metadata: ik heb er geen toegang toe.

Maar hier wordt het interessant. Trustbourne heeft twee encryptie-modi, en de reden waarom zegt meer over het product dan de technologie zelf.

Seamless is de standaard. Je bestanden worden in je browser versleuteld met een master key. Die master key wordt twee keer versleuteld: één keer met je wachtwoord (zodat jij erbij kunt), en één keer met een release key die Trustbourne bewaart op aparte infrastructuur. Die release key staat los van je vaultdata — andere systemen, andere toegangscontroles, audit logging ertussen.

Zou ik technisch gezien de stukken kunnen combineren om te ontsleutelen? Ja. Ik voorkom dat met toegangscontroles, scheiding van systemen en operationele policies. Maar "we kiezen ervoor om het niet te doen" is een andere belofte dan "we kunnen het niet."

En toch is Seamless de standaard. Bewust.

Want denk even na over wat er aan de andere kant gebeurt. Je partner moet bij je kluis. Ze heeft net te horen gekregen dat je er niet meer bent. Ze regelt de uitvaart, belt de notaris, zoekt uit welke rekeningen er nog openstaan. En nu moet ze óók nog een wachtwoordzin vinden die je ergens bewaard hebt, uitzoeken waar die voor dient, en die correct invoeren voordat ze iets kan zien.

Dat is wrijving op het slechtste moment.

Met Seamless klikt je contactpersoon op een link, bevestigt haar identiteit via e-mail en SMS, en ziet je bestanden. De decryptie gebeurt volledig in haar browser — onversleutelde bestanden staan nooit op mijn servers. Maar zij hoeft er niks voor te doen behalve zijn wie ze is.

Maximum Privacy gaat verder. Geen release key op de server. Je master key wordt alleen versleuteld met een wachtwoordzin die je zelf kiest, los van je accountwachtwoord. Ik heb die zin niet. Ik bewaar hem niet. Ik kan hem niet herstellen.

Zelfs bestandsnamen zijn versleuteld. Bij Seamless kan ik je mappenstructuur en bestandsnamen zien — handig voor je contactpersonen om te navigeren na een release. Bij Maximum Privacy zie ik niks. Versleutelde namen, versleutelde inhoud, versleutelde sleutels. Het hele ding is ondoorzichtig.

Als je kluis vrijgegeven wordt, krijgen je contactpersonen de versleutelde data maar geen release key. Hij heeft de wachtwoordzin nodig die je via een ander kanaal gedeeld hebt. Een verzegelde brief. Een notaris. Een kluis bij de bank. Dat is wat "zero-knowledge" in de praktijk betekent. Ik kan structureel, wiskundig niet meekijken. De sleutel bestaat niet op mijn servers.

Maximum Privacy zit op het Plus-abonnement. En er zit een harde consequentie aan: als je je wachtwoordzin kwijtraakt, is je data weg. Geen "neem contact op met support." Weg. Ik kan het niet resetten. Ik kan je master key niet herstellen. De wiskunde trekt zich er niks van aan. Dat is het hele punt.

De technische details staan in ons encryptie-artikel.

Waarom twee modi?

Ik had alleen Maximum Privacy kunnen bouwen. Puurder verhaal. Makkelijker uit te leggen.

Maar de persoon die je kluis ontvangt, zit midden in een rouwproces. Ik vond het niet verdedigbaar om die persoon ook nog een puzzel te laten oplossen. Seamless bestaat omdat de ontvanger ertoe doet, ook in de architectuur.

Voor de meeste mensen is dat de juiste afweging. Voor mensen met significante crypto-holdings, gevoelige bedrijfsdocumenten, of situaties waar elk risico op toegang door derden te veel is — daarvoor bestaat Maximum Privacy.

Twee modi, eerlijk over de afwegingen van beide. Dat vind ik een sterkere belofte dan één modus met een marketingverhaal eromheen.

Wat ik dagelijks merk

Trustbourne zit in beta. Echte mensen bewaren er echte bestanden. Cryptosleutels, inloggegevens, instructies voor nabestaanden.

En ik kan er niet bij. Als ik nu in de database zou kijken, zie ik versleutelde data en metadata over wanneer iemand z'n laatste check-in deed. Meer niet.

Dat voelt soms kwetsbaar. Ik kan niet controleren of mensen het systeem goed gebruiken. Geen handige statistieken, geen A/B-tests op gebruikersdata. Al die optimalisatietechnieken waar SaaS-founders op leunen, werken niet als je niks kunt zien. Ik moet het doen met audit logs die me vertellen welke acties genomen zijn, zonder me de data te geven.

Maar het klopt wel.

De afweging

Zero-knowledge kost je features die gebruikers verwachten. Zoeken in je bestanden? Kan niet server-side. Previews genereren? Onmogelijk als je de inhoud niet kunt lezen. Slimme suggesties, automatische categorisering, AI-features — allemaal van tafel als je de data niet kunt zien.

Elke feature die ik wil bouwen moet ik bedenken vanuit de vraag: kan dit volledig op het apparaat van de gebruiker draaien? Soms is het antwoord nee, en dan bouw ik het niet.

Minder features, meer vertrouwen. Geen dashboards vol gebruikersdata voor mij, maar een kluis die doet wat een kluis hoort te doen.

Een tijdje geleden schreef ik over het probleem — wat er gebeurt met je digitale leven als jij er niet meer bent. Dit stuk gaat over de andere kant: hoe je iets bouwt waar mensen dat soort data aan durven toevertrouwen.

Trustbourne zit in beta. Als je het wilt proberen of vragen hebt over de encryptie-architectuur: [email protected].