TL;DR
Worklist maakt gebruik van ChaCha20-Poly1305-versleuteling met zero-knowledge-architectuur. Uw gegevens worden op uw apparaat versleuteld voordat ze onze servers bereiken met behulp van gedocumenteerde cryptografische primitieven. We kunnen uw taken fysiek niet lezen, zelfs niet met volledige toegang tot de database. Het ondersteunt AVG-dataminimalisatie en kan helpen met HIPAA/SOC 2 technische beveiligingen in combinatie met vereiste overeenkomsten en operationele controles.
Ons kernprincipe.
Uw gegevens worden op uw apparaat versleuteld voordat deze onze servers bereiken. We hebben Worklist zo ontworpen dat wij – het bedrijf – uw werklijsten, taken of opmerkingen niet kunnen ontsleutelen, lezen of openen. Dit wordt genoemd zero-knowledge architectuur.
Wat maakt Worklist anders.
Traditionele taakmanagers.
Wat concurrenten doen
- • Slaan uw gegevens in leesbare tekst op hun servers op
- • Kan elke taak, opmerking en bestand lezen dat u maakt
- • Kan uw inhoud scannen op advertenties, AI-training of ‘functies’
- • Kwetsbaar voor datalekken waardoor alles bloot komt te liggen
Worklist (zero-knowledge).
Wat wij doen
- • Versleutelt op uw apparaat voordat het naar onze servers wordt verzonden
- • We kunnen uw taken niet ontsleutelen, zelfs als we dat zouden willen
- • Geen scannen, geen AI-training op uw privéwerk
- • Datalekken onthullen niets betekenisvols: alleen versleutelde blobs
Hoe zero-knowledge-versleuteling werkt.
U maakt uw account aan.
Wanneer u zich registreert, verlaat uw wachtwoord uw browser nooit in platte tekst. In plaats daarvan:
- Uw browser gebruikt Argon2id om een verpakkingssleutel van uw wachtwoord af te leiden
- Er wordt een willekeurige ‘datasleutel’ van 32 bytes op uw apparaat gegenereerd
- Deze gegevenssleutel is versleuteld met uw van een wachtwoord afgeleide verpakkingssleutel
- De versleutelde gegevenssleutel wordt opgeslagen op onze servers, maar we kunnen het niet ontsleutelen zonder uw wachtwoord
- Wij gebruiken OPAQUE PAKE protocol zodat onze servers uw wachtwoord in platte tekst nooit zien
Belangrijk punt: de verpakkingssleutel verlaat uw apparaat nooit. Zonder uw wachtwoord is de versleutelde gegevenssleutel voor ons nutteloos.
Waarom de versleutelde gegevenssleutel opslaan?
U kunt dus vanaf elk apparaat inloggen. Wanneer u van computer wisselt of uw telefoon gebruikt, sturen we u de versleutelde blob, voert u uw wachtwoord opnieuw in om het lokaal te ontsleutelen, en bent u weer binnen. Zonder het op te slaan, zou u handmatig een sleutel van 32 bytes tussen apparaten moeten kopiëren - een slechte gebruikerservaring voor dezelfde beveiliging.
U maakt een werklijst of taak.
Elk stukje gevoelige gegevens wordt versleuteld op uw apparaat:
- Titels, beschrijvingen en instellingen van werklijsten
- Taaktitels, hoofdteksten, checklists en opmerkingen
- Herhalende taaksjablonen en schema's
- Alles is versleuteld met behulp van ChaCha20-Poly1305 AEAD (een modern, gecontroleerd cijfer)
- Elke werklijst heeft zijn eigen unieke versleutelingssleutel, afgeleid van uw gegevenssleutel
Onze servers slaan alleen de versleutelde cijfertekst — ze kunnen de leesbare tekst niet lezen.
U nodigt teamleden uit.
Bij het delen van werklijsten met teamgenoten:
- Elk lid krijgt zijn eigen versleutelde kopie van de werklijstsleutel
- Sleutels worden uitgewisseld via HPKE (Hybride openbare sleutelversleuteling)
- Publieke sleutels worden gepubliceerd naar een transparantielogboek (Merkle-boom) om man-in-the-middle-aanvallen te voorkomen
- Als u een lid verwijdert, wordt de werklijstsleutel gerouleerd en krijgen alle overige leden nieuwe versleutelde kopieën
Onze servers verifiëren zonder te ontsleutelen.
U vraagt zich misschien af: “Als de server niet kan ontsleutelen, hoe kan hij dan de rechten afdwingen?”
We gebruiken HMAC-bewijzen: cryptografische handtekeningen die bewijzen dat u recht heeft op toegang tot gegevens zonder de platte tekst te onthullen.
- Uw browser berekent een HMAC (keyed hash) van de versleutelde gegevens met behulp van een lidmaatschapsspecifieke sleutel
- De server valideert de HMAC om te bevestigen dat u een actief lid bent
- Het knoeien of afspelen van de gegevens van iemand anders mislukt de HMAC-controle
- We ontsleutelen de payload nooit; we verifiëren alleen de integriteit en autorisatie
Wat onze servers wel en niet kunnen zien.
Wij KUNNEN NIET zien
- × Titels of beschrijvingen van werklijsten
- × Taaktitels, hoofdteksten of checklists
- × Opmerkingen of discussies
- × Sjablonen voor herhalende taken
- × Alle inhoud binnen versleutelde payloads
- × Uw wachtwoord (zelfs gehasht)
Wij KUNNEN zien
- ✓ E-mailadres van gebruikersaccount (voor inloggen)
- ✓ Lidmaatschapsrelaties (wie staat in welke werklijst)
- ✓ Taakstatus (open/gesloten) en prioriteit
- ✓ Vervaldata en tijdstempels
- ✓ Delegatietoewijzingen (alleen gebruikers-ID's)
- ✓ Metagegevens die nodig zijn voor zoekopdrachten (ID's, aanmaakdatums)
Waarom sommige metadata zichtbaar zijn: Bepaalde velden (zoals taakstatus en vervaldatums) moeten in leesbare tekst worden opgeslagen, zodat onze servers zoekopdrachten efficiënt kunnen filteren, herinneringen aan vervaldatums kunnen afdwingen en database-indexen kunnen onderhouden. Deze velden bevatten geen gevoelige inhoud, maar alleen operationele metagegevens waarmee de app kan functioneren.
Beveiliging garanties.
Ontgrendeling op basis van wachtwoord (alleen voor klanten).
Uw wachtwoord verlaat uw apparaat nooit in leesbare tekst. Het wordt uitgerekt met behulp van Argon2id om een verpakkingssleutel te maken die uw hoofdgegevenssleutel ontsleutelt. Die gegevenssleutel wordt vervolgens uitgebreid met behulp van HKDF om voor elke werklijst afzonderlijke sleutels af te leiden.
De server kan de payloads niet ontsleutelen.
Onze backend-code roept nooit ontsleutelingsbewerkingen op gebruikersgegevens op. Het valideert alleen HMAC-bewijzen om de autorisatie te bevestigen.
Sleutelroulatie bij ledenwijzigingen.
Wanneer een lid wordt verwijderd of vertrekt, wordt de werklijstsleutel gerouleerd. Alle overige leden ontvangen nieuwe versleutelde kopieën, zodat het vertrekkende lid toekomstige inhoud niet kan ontsleutelen.
Transparantie van uitnodigingssleutels.
Openbare sleutels voor uitnodigingen worden vastgelegd in een Merkle-boom die alleen kan worden toegevoegd. Clients verifiëren insluitings- en consistentiebewijzen, waardoor wordt voorkomen dat de server stilletjes sleutels vervangt om werklijstgegevens te onderscheppen.
Open source-cryptografie.
We gebruiken beproefde bibliotheken: strong-box (ChaCha20-Poly1305), Argon2id (sleutelafleiding), OPAQUE (wachtwoordauthenticatie) en HPKE (sleuteluitwisseling). Al onze cryptocode is open source en controleerbaar.
Hoe we verifiëren onze veiligheid.
Onze beveiligingsclaims zijn verifieerbaar, niet alleen marketing. Zo zorgen we ervoor dat onze zero-knowledge-architectuur werkt zoals beloofd:
- Open-source cryptografische code beschikbaar op GitHub voor openbare audits door beveiligingsonderzoekers
- In de praktijk geteste bibliotheken, waaronder ChaCha20-Poly1305 (RFC 8439), Argon2id, OPAQUE PAKE (RFC 9497) en HPKE
- Cryptografische bewijzen (HMAC) die ontsleuteling op de server wiskundig voorkomen
- Transparantielogboeken (Merkle-bomen) om sleutelvervangingsaanvallen te detecteren
- Sleutelafleiding aan de clientzijde met behulp van Argon2id zorgt ervoor dat we uw wachtwoord of versleutelingssleutels nooit zien
Afwegingen van zero-knowledge.
Geen wachtwoordherstel.
Als u uw wachtwoord vergeet, kunnen wij uw gegevens niet herstellen. Er is geen optie “wachtwoord opnieuw instellen en uw gegevens bewaren” omdat we niet over de sleutels beschikken om het te ontsleutelen.
Geen zoekopdracht op de server.
Omdat uw taakinhoud versleuteld is, kunnen we niet voor al uw taken op de server full-text zoeken. Zoeken gebeurt in uw browser na ontsleuteling.
Beperking: we optimaliseren zoeken aan de clientzijde met geïndexeerde zoekopdrachten en snelle ontsleuteling om de prestaties te behouden.
Technisch specificaties.
| Symmetrische versleuteling | ChaCha20-Poly1305 AEAD (via de strong-box-bibliotheek) |
| Wachtwoord uitrekken | Argon2id (64 MiB geheugen, 3 iteraties, 1 parallelisme) — zet het wachtwoord om in een verpakkingssleutel |
| Sleutelhiërarchie | HKDF-SHA256 — leidt werklijst- en lidmaatschapssleutels af van de gegevenssleutel |
| Wachtwoordverificatie | OPAQUE PAKE (Ristretto255 curve) |
| Sleuteluitwisseling (uitnodigingen) | HPKE (Hybrid Public Key Encryption) met X25519 |
| Integriteitsbewijzen | HMAC-SHA256 |
| Serialisatie | CBOR (Concise Binary Object Representation) |
| Sleutelgrootte | 256-bit (32 bytes) voor alle symmetrische sleutels |
Alle cryptografische bewerkingen gebeuren in uw browser met behulp van WebCrypto API's en gecontroleerde WASM-modules samengesteld uit Rust.
Audits & transparantie.
Open source crypto-stack.
Onze gehele cryptografische implementatie is open source en beschikbaar op GitHub. We verwelkomen beveiligingsonderzoekers om onze code te controleren.
Bekijk op GitHubNaleving.
Onze zero-knowledge-architectuur ondersteunt AVG-dataminimalisatie en kan helpen met HIPAA- of SOC 2-technische beveiligingen. Voor gereguleerde PHI is nog steeds een schriftelijke overeenkomst of BAA vereist, plus de operationele controles en leveranciersbevestiging die uw nalevingsprogramma vereist.
Algemeen vragen.
Wat gebeurt er als u wordt gehackt?
Als een aanvaller toegang krijgt tot onze database, ziet hij alleen versleutelde blobs, in wezen willekeurige bytes. Zonder uw wachtwoord (dat we nooit opslaan) zijn de gegevens wiskundig gezien onmogelijk te ontsleutelen met de huidige technologie.
Kunnen overheidsinstanties u dwingen mijn gegevens te ontsleutelen?
Nee, want dat kunnen we echt niet. We hebben de sleutels niet. Zelfs met een bevelschrift of gerechtelijk bevel kunnen we alleen de versleutelde cijferteksten verstrekken, die zonder uw wachtwoord nutteloos zijn.
Hoe verschilt dit van “versleuteling voor opgeslagen gegevens”?
‘Versleuteld voor opgeslagen gegevens’ betekent dat gegevens op de harde schijven van de server worden versleuteld, maar dat de server nog steeds over sleutels kan beschikken om ze te ontsleutelen. End-to-end-versleuteling betekent dat alleen u (de eindpunten) de sleutels heeft; de server heeft nooit toegang tot platte tekst.
Kunnen medewerkers van Worklist mijn gegevens inzien?
Nee. Onze backend-code is ontworpen om nooit de payloads van gebruikers te ontsleutelen. Zelfs databasebeheerders met volledige toegang tot onze servers kunnen uw werklijsten of taken niet lezen.
Wat moet ik doen als ik mijn gegevens wil exporteren?
U kunt uw ontsleutelde gegevens op elk gewenst moment vanuit de app exporteren. Omdat de ontsleuteling in uw browser plaatsvindt, krijgt u leesbare JSON/CSV-bestanden en geen versleutelde blobs.
Referenties & normen.
Onze cryptografische keuzes volgen industriestandaarden en peer-reviewed specificaties.
- 01 RFC 8439: ChaCha20 en Poly1305 voor IETF-protocollen — Onze symmetrische encryptiestandaard
- 02 RFC 9497: OPAQUE Asymmetrisch PAKE-protocol — Zero-knowledge-wachtwoordverificatie
- 03 RFC 9180: Hybride publieke sleutelversleuteling (HPKE) — Sleuteluitwisseling voor teamuitnodigingen
- 04 RFC 9106: Argon2 Memory-Hard-functie — Op wachtwoord gebaseerde sleutelafleiding
- 05 NIST SP 800-175B: Richtlijn voor het gebruik van cryptografische standaarden — Federale cryptografische begeleiding
- 06 AVG Artikel 32: Beveiliging van de verwerking — EU-vereisten voor gegevensbescherming
Klaar voor echte privacy?
Sluit u aan bij teams die erop vertrouwen dat Worklist hun werk echt privé houdt. Start uw gratis proefperiode – geen creditcard vereist.
Gratis proefperiode startenHeeft u beveiligingsvragen? E-mail ons op security@worklist.app