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.
- Vier ontwerpprincipes
- Wat ziet het systeem wel, wat niet
- Hoe contacten worden geverifieerd
- Vier lagen in het hulpprofiel
- Officiële berichten van gemeente of hulpdienst
- Wat een eventueel datalek wel en niet kan betekenen
- AVG, dataverwerking en juridische positie
- Eerlijke trade-offs
- Open vraagstukken
- Bronnen
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.
- Lokaal-first. De primaire opslag van persoonlijke gegevens (contacten, berichten, hulpprofiel) staat op het apparaat van de gebruiker zelf. Een centrale dienst is alleen doorgeefluik en backup, geen primair archief.
- End-to-end versleuteld. Berichten en hulpprofielen zijn alleen leesbaar voor zender en geadresseerde ontvanger. Tussenliggende partijen zien versleutelde inhoud die ze technisch niet kunnen openen.
- Minimale data, geen accountkoppeling. Geen e-mail, geen telefoonnummer, geen naam in centrale opslag. Identiteit is een cryptografische sleutel die niet direct herleidbaar is naar een persoon. Wat niet wordt opgeslagen, kan niet uitlekken.
- Eerlijk over de trade-offs. Geen mooie marketing. Bij elke ontwerpkeuze staat wat er wel en niet beschermd is, en welke compromissen worden gemaakt voor functionaliteit.
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:
- Fake accounts komen niet in jouw geverifieerde noodcontacten zonder een fysieke QR-scan.
- Alleen door een overheidsinstantie ondertekende sleutels tellen als officiële authority (CA-verificatie).
- De app toont standaard alleen berichten van geverifieerde contacten. Berichten van onbekende afzenders komen in een aparte "onbekend"-lijst die je actief moet openen om te bekijken.
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.
| Laag | Wat | Voor 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
- De kwetsbaarheid-vlag staat standaard uit. Activering gebeurt bewust, eventueel samen met de huisarts of mantelzorger.
- De lijfreddende laag werkt analoog, op een fysiek kaartje. Geen accu nodig, geen netwerk, altijd beschikbaar.
- Niemand ziet alle vier de lagen tegelijk. Niveau hoort bij rol en moment.
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
- Info: gewoon zichtbaar in de app, geen geluid of lamp.
- Waarschuwing: signaallamp op de Outpost gaat aan, gebruikers in de buurt kunnen het zien.
- Acuut: lamp én geluidsmelder op de Outpost, plus een melding op de app als die open is.
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 verwerkingsverantwoordelijke?
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 verwerkingsverantwoordelijke voor inhoud. Bij gemeente-gehoste varianten kan de gemeente verwerkingsverantwoordelijke zijn. Voor elk hosting-model is een verwerkersovereenkomst 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
- Hoe leg je dit uit aan een gewone gebruiker? De gemiddelde burger weet niet wat sealed sender is, en heeft daar ook geen geduld voor. Hoe ontwerp je een UI die de gebruiker beschermt zonder dat hij de techniek hoeft te snappen?
- Hoe ga je om met een gecompromitteerde CA? Als een gemeentelijke CA-sleutel uitlekt of misbruikt wordt, hoe revoceer je dat snel zonder dat het hele netwerk vastloopt?
- Welke privacy-audit doe je vóór een pilot? Een externe partij (een hogeschool, Bits of Freedom, een academisch onderzoeker) zou de claims op deze pagina moeten controleren voordat het systeem breed wordt uitgerold.
- Hoe ga je om met justitiële vorderingen? Wat als een opsporingsdienst data opvraagt? Dataminimalisatie maakt dat we weinig hebben om te geven, maar het beleid en de juridische analyse moeten klaar liggen.
- AVG-impact-assessment formeel uitvoeren, samen met een gemeente die als verwerkingsverantwoordelijke optreedt voor een pilot.
- Pseudonimiteit versus anonimiteit: pubkeys zijn pseudoniem, niet anoniem. In een wijk-context kan met genoeg observatie een pubkey alsnog aan een persoon worden gekoppeld. Hoe ver kun je daarin gaan voor je het ontwerp aantast?
- Hoe voorkom je sociale druk om je hulpprofiel breed te delen? Het mag een persoonlijke keuze blijven, niet iets waar je zou moeten "meedoen" om mee te tellen.
- Hoe schaalt vertrouwen van 10 naar enkele honderden bewoners? In persoon verifiëren werkt voor je naaste kring. Voor de rest is een vouching-mechanisme denkbaar: iemand die jij persoonlijk in persoon hebt geverifieerd (bijvoorbeeld je oom) kan zelf anderen in persoon verifiëren (neefjes, nichtjes, buren), en jouw app kan die vouching-lijn optioneel accepteren. Een "vertrouwde tussenpersoon" is dus iemand die jij persoonlijk vertrouwt en die zelf strikt heeft geverifieerd. Maar dat betekent ook: één kwaadwillende schakel in die keten kan tientallen nep-identiteiten binnenhalen. Welke ontwerpregel maakt dit aanvalsbestendig zonder dat het bureaucratisch wordt?
- Wat te doen bij verlies van een vertrouwde tussenpersoon? Als een huisarts vertrekt, een wijkcoach overlijdt of een actieve buurtgenoot verhuist: hoe overleeft het netwerk zonder dat hele takken vertrouwen wegvallen?
Bronnen
Cryptografische technieken
- End-to-end versleuteling (Wikipedia): en.wikipedia.org/wiki/End-to-end_encryption
- Forward secrecy (Wikipedia): en.wikipedia.org/wiki/Forward_secrecy
- Public-key cryptography (Wikipedia): en.wikipedia.org/wiki/Public-key_cryptography
- Ed25519, RFC 8032: datatracker.ietf.org/doc/html/rfc8032
- Curve25519, RFC 7748: datatracker.ietf.org/doc/html/rfc7748
Privacy-inspiratie en verwante systemen
- Signal sealed sender: signal.org/blog/sealed-sender
- Signal private contact discovery: signal.org/blog/private-contact-discovery
- Signal blog (algemene privacy-inzichten): signal.org/blog
- Briar project (peer-to-peer, geen centrale opslag): briarproject.org/manual
- Matrix Foundation (federated messaging): matrix.org/foundation
AVG en juridisch kader
- AVG-verordening (officiële tekst EU): eur-lex.europa.eu
- Algemene verordening gegevensbescherming (Nederlandse Wikipedia): nl.wikipedia.org/wiki/Algemene_verordening_gegevensbescherming
- Autoriteit Persoonsgegevens, basis-AVG: autoriteitpersoonsgegevens.nl/themas/basis-avg/avg-algemeen
- Autoriteit Persoonsgegevens (algemeen): autoriteitpersoonsgegevens.nl
Belangenorganisaties en privacy-debat
- Bits of Freedom (NL digitale burgerrechten): bitsoffreedom.nl
- Electronic Frontier Foundation, privacy-thema: eff.org/issues/privacy
- EFF over encryptie en het web: eff.org/encrypt-the-web
Nederlandse zorg- en informatiecontext
- Nictiz (kennisorganisatie e-health en informatievoorziening in de zorg): nictiz.nl