Concept-fase, ontwerp-uitleg

Stayd

Privacy en vertrouwen

Wat het systeem wel en niet ziet, en hoe gevoelige info beschermd is.

Een crisis-app raakt aan de meest gevoelige kanten van het leven van mensen: wie zijn je dierbaren, wie woont alleen op vier hoog, wie heeft welke medicijnen nodig, op wie kun jij terugvallen. Als dat niet zorgvuldig wordt vormgegeven, levert het systeem juist nieuwe kwetsbaarheden op in plaats van weerbaarheid. Op deze pagina staat hoe Stayd dat probeert te doen, welke keuzes daarvoor nu worden onderzocht, en waar de eerlijke trade-offs zitten.

Veel keuzes op deze pagina zijn voorlopige richtingen. Het concept wordt momenteel gevalideerd. Voor de bredere context, zie stayd.brenco.nl.

Op deze pagina:

Vier ontwerpprincipes

Privacy is in Stayd geen los blok dat erbij is geschoven, maar een ontwerpvereiste die de hele architectuur kleurt. Vier principes vormen samen de basis.

Welk risico heeft het werken zonder accounts?

Zonder e-mail, telefoonnummer of naam-verificatie kan iemand technisch onbeperkt pubkeys genereren. Dat is een Sybil-risico: één persoon die zich voordoet als vele. Wat de schade beperkt:

Wat blijft: iemand kan wel massaal accounts aanmaken en mesh-capaciteit belasten. Rate-limiting per pubkey (bandbreedte per uur per identiteit) beperkt de schade, maar biedt geen fundamentele bescherming tegen vasthoudende misbruikers.

Wat ziet het systeem wel, wat niet

De Stayd-backend (de centrale dienst die in normale tijden helpt met doorgifte van berichten en backup) wordt zo ontworpen dat hij zo min mogelijk weet over zijn gebruikers. Dezelfde principes gelden voor Outpost-nodes, met één belangrijke nuance: een Outpost-node in een crisis ziet wel routing-metadata om berichten te kunnen afleveren.

De Stayd-backend ziet De Stayd-backend ziet niet
Welke cryptografische sleutels (pubkeys) verbinding maken Inhoud van berichten (e2e-versleuteld)
Versleutelde berichten in transit (inhoud onleesbaar) Wie naar wie schrijft (sealed sender)
Globale statistieken (totaal verkeer, geen identiteit) Naam, e-mailadres, telefoonnummer van gebruikers
Wie geverifieerd contact is van wie
Hulpprofiel-inhoud (versleuteld voor specifieke ontvangers)
Status zoals "online" of "laatst actief" (gaat via mesh, niet via backend)
Sealed sender, hoe dat werkt

Een gewone messenger weet aan welke ontvanger een bericht gaat én van welke afzender. Met sealed sender wordt de afzender-informatie versleuteld in een laag die alleen de ontvanger kan openen. De tussenliggende server weet alleen "er moet iets naar deze pubkey", niet wie het stuurde. Pas wanneer de ontvanger het bericht opent, weet die wie het stuurde. Signal heeft dit als eerste op grote schaal gedaan en heeft het mechanisme publiek beschreven. Stayd gebruikt een vergelijkbare aanpak.

Outpost-nodes in een crisis: wat anders

Een Outpost-node moet berichten over de mesh kunnen routeren naar de juiste bestemming. Dat betekent dat hij wel ziet welke pubkey-naar-pubkey een bericht onderweg is, en op welk tijdstip. Inhoud blijft versleuteld, identiteit blijft pseudoniem (pubkeys, geen namen). Dit is onvermijdelijk voor de routering. Wel wordt deze routing-metadata kort onthouden (typisch 6-24 uur) en daarna vergeten, zodat er geen langlopend privacy-archief ontstaat.

Hoe contacten worden geverifieerd

Een sterk netwerk staat of valt met betrouwbare identiteiten. Tegelijk willen we voorkomen dat het verifiëren van iemand een hoge drempel wordt of dat het surveillance-achtig voelt. Drie wegen werken naast elkaar.

In persoon bevestigd (sterkste vorm)

Je staat tegenover de ander en scant zijn QR-code op zijn telefoon. Daarmee zien beide apparaten elkaars cryptografische sleutels. De verificatie gebeurt fysiek, en daarna is verbinding via internet of mesh cryptografisch gegarandeerd: je weet dat de berichten echt van die persoon komen. Vergelijkbaar met hoe Signal QR-verificatie doet.

Dit is de basis voor familie, buren, vrienden, mantelzorgers.

Via een institutionele check (voor hulpverleners)

Een huisarts of EHBO-vrijwilliger kun je niet altijd in persoon ontmoeten voor verificatie. Daarvoor bestaat een certificate authority (CA): een vertrouwde partij (een gemeentelijke organisatie, of een beroepsvereniging) ondertekent de sleutel van de hulpverlener op basis van een check tegen het BIG-register. De app van een gebruiker vertrouwt de CA-sleutels vooraf, en daarmee elke geverifieerde hulpverlener automatisch.

Bij beëindiging van de bevoegdheid wordt de signatuur ingetrokken (revocatie). De gebruiker hoeft hier niets voor te doen.

Via een gedeeld vertrouwd contact (vouching)

Een derde optie als persoonlijke ontmoeting niet kan: een gedeeld contact dat jullie beiden kennen, vouchet ("ik ken Marieke, dit is haar"). Niet zo sterk als in persoon, maar in een crisis-context kan het voldoende zijn om snel een verbinding op te bouwen, met een eerlijk gemarkeerde verlaagde status. Volledig vertrouwen krijgt het pas na een persoonlijke ontmoeting.

Vier lagen in het hulpprofiel

Het hulpprofiel is voor veel mensen het gevoeligst. Je deelt wat voor iemand in een crisis belangrijk is om over jou te weten: dat je alleen woont, slecht ter been bent, dementeert, welke medicijnen je nodig hebt, waar je sleutel ligt. Te ruim delen is risicovol, te beperkt delen maakt het profiel niet effectief. De oplossing: vier lagen, elk met een eigen bereik.

LaagWatVoor wie zichtbaar
Levensreddend Bloedgroep, ernstige allergie, primaire diagnose Iedereen die de Stayd-visitekaart in je portemonnee vindt
Algemeen profiel "Ik heb hulp nodig", contactenlijst, basisinformatie Geverifieerde contacten in Stayd
Niet-acuut gevoelig Medicijnen, sleutel-locatie, dementie, specifieke context CA-geverifieerde hulpverleners + opt-in mantelzorger
Kwetsbaarheid-vlag Adres + voornaam + type hulp ("slecht ter been", "alleen boven 80") Buurthelpers ter plaatse, alleen tijdens een actieve crisis-modus van de Outpost
Belangrijke kanttekeningen

Officiële berichten van gemeente of hulpdienst

Een gemeente of hulpdienst moet officiële berichten naar een wijk kunnen sturen ("evacueer wijk X", "verzamel hier voor warme maaltijd"). Hoe weet een burger dat zo'n bericht echt van zijn gemeente komt en niet van een kwaadwillende?

Een hiërarchie van cryptografische handtekeningen

Een landelijke CA tekent regionale CA's. Regionale CA's tekenen gemeentelijke. De gemeente tekent berichten met haar eigen sleutel. De app van een burger heeft de landelijke CA vooraf vertrouwd en kan daarmee de hele keten verifiëren. Een vals bericht zonder geldige handtekening wordt niet getoond.

Signatuur-verificatie werkt volledig lokaal, ook zonder internet: de CA-sleutels zijn vooraf in de app opgenomen. Wat wel internet vereist is de revocatie-check: is deze CA-sleutel intussen ingetrokken? Zonder internet weet de app dat niet en accepteert een sleutel die eigenlijk al ingetrokken zou moeten zijn. In een langdurige crisis groeit dit risico met de tijd, maar voor de eerste uren tot dagen is de kans op precies dit misbruik-scenario klein.

Dezelfde keten geldt voor beroepsgroepen (huisartsen, EHBO, brandweer): KNMG en KNMP kunnen via dit model ook hun eigen leden verifiëren.

Drie urgentie-niveaus

Welke urgentie een afzender mag gebruiken hangt af van wie hij is (gemeente, veiligheidsregio, landelijk). Er zit een beperking op om misbruik te voorkomen.

Wat een eventueel datalek wel en niet kan betekenen

Eerlijk: geen enkel systeem is honderd procent veilig. De vraag is niet of er iets mis kan gaan, maar wat in dat geval de impact is.

Stayd-backend volledig gehackt

Wat de aanvaller krijgt: een lijst van cryptografische sleutels, versleutelde transit-berichten die voor maximaal 7-30 dagen worden bewaard, en versleutelde backups van gebruikers.

Wat de aanvaller niet krijgt: namen, e-mailadressen, telefoonnummers (die zijn er niet), berichten in leesbare vorm (e2e-versleuteld), wie naar wie schrijft (sealed sender), wie contact is van wie. Backups openen vereist de master-passphrase van elke individuele gebruiker, die alleen op hun eigen apparaat staat.

Eén Outpost-node fysiek meegenomen of gehackt

Wat de aanvaller krijgt: de recente routing-tabel (welke pubkey is recent gezien via deze node, maximaal 24 uur terug). Eventueel transit-berichten die nog niet zijn afgeleverd, allemaal versleuteld.

Wat hij niet krijgt: historische sociale grafiek (oude routing wordt vergeten), bericht-inhoud, identiteiten in leesbare vorm. De rest van de mesh blijft werken: één Outpost is geen single point of failure.

Eén gebruiker zijn apparaat verliest

Wat de vinder krijgt: toegang tot Stayd alleen na de pincode of biometrie te omzeilen. De cryptografische sleutels zelf liggen in de beveiligde opslag van het besturingssysteem (Secure Enclave bij iOS, Keystore bij Android).

Wat de gebruiker kan doen: via een ander apparaat z'n sleutels revoceren, zodat de gestolen kopie geen verbinding meer maakt. De andere contacten zien automatisch dat de oude sleutel niet meer geldig is.

AVG, dataverwerking en juridische positie

Stayd is ontworpen om binnen de AVG te passen. Een paar concrete punten.

Wie is verwerker, wie is verwerkings­verantwoordelijke?

In de huidige opzet: de gebruiker is zelf verantwoordelijk voor zijn eigen data (lokaal-first). De Stayd-backend treedt op als verwerker voor de korte transit en de versleutelde backup, niet als verwerkings­verantwoordelijke voor inhoud. Bij gemeente-gehoste varianten kan de gemeente verwerkings­verantwoordelijke zijn. Voor elk hosting-model is een verwerkers­overeenkomst denkbaar.

Dataminimalisatie als ontwerpregel

Het AVG-principe dataminimalisatie (artikel 5.1.c) zegt: verzamel alleen wat strikt nodig is. Stayd vertaalt dit naar: geen account-gegevens, geen contactenlijst-uploads, geen telefoonnummer-koppeling, geen analytics, geen tracking. Wat niet wordt verzameld, kan ook niet worden gevorderd, gehackt, of misbruikt.

Recht op inzage en verwijdering

Een gebruiker heeft volgens AVG recht op inzage in alle data over hem, en op verwijdering. Bij Stayd is dat technisch eenvoudig: alle data staat op het eigen apparaat (inzage is "open de app"), en verwijdering is "wis app + master-key revocatie". De Stayd-backend heeft alleen versleutelde blobs en routing-pointers; die kunnen op verzoek worden gewist.

Eerlijke trade-offs

Privacy en functionaliteit staan vaak op gespannen voet. Stayd kiest soms voor functionaliteit met een eerlijke uitleg, in plaats van puristisch puur op privacy te ontwerpen. Hier de belangrijkste afwegingen.

Routing-metadata bij een Outpost in crisis

In normale tijden werkt sealed sender goed: de backend ziet niet wie naar wie schrijft. In een crisis op de mesh wel: een Outpost moet weten waar een bericht heen moet om het te kunnen routeren. Pseudoniem (pubkeys, geen namen), tijdelijk (24 uur), maar het is een verschil met de vredestijd-situatie. We kiezen voor de mogelijkheid om berichten te ontvangen boven volledige metadata-bescherming.

Kwetsbaarheid-vlag bij crisis-modus

De kwetsbaarheid-vlag laat buurthelpers ter plaatse zien welke adressen mogelijk hulp nodig hebben. Dat is een privacy-blootstelling, beperkt tot crisis-modus en alleen voor wie fysiek bij de Outpost is. Voor sommigen voelt dat ongewenst, voor anderen levensreddend. Daarom: standaard uit, expliciete opt-in, mogelijk samen met huisarts of mantelzorger geactiveerd.

Geen permanent bericht-archief

De Stayd-backend bewaart berichten alleen kort (typisch 7-30 dagen), de Outpost 48-72 uur. Wie een lang archief wil, beheert dat zelf op zijn apparaat. Privacy-voordeel: geen lange-termijn lekrisico bij de centrale dienst. Trade-off: bij verlies van het apparaat is de eigen historie weg, tenzij de versleutelde backup beschikbaar is.

Open vraagstukken

Bronnen

Cryptografische technieken

Privacy-inspiratie en verwante systemen

AVG en juridisch kader

Belangenorganisaties en privacy-debat

Nederlandse zorg- en informatiecontext