Privacy by design-principes voor bestandsoverdrachttools

Privacy by design in een bestandsoverdrachtool betekent dat de standaardconfiguratie al persoonsgegevens beschermt zonder dat de gebruiker één instelling hoeft aan te passen. AVG Artikel 25 codificeert twee varianten: gegevensbescherming door ontwerp (Artikel 25(1)) vereist dat je passende technische maatregelen in het product inbouwt vanaf de planningsfase, en gegevensbescherming door standaardinstellingen (Artikel 25(2)) vereist dat de configuratie uit de doos alleen verwerkt wat noodzakelijk is, deelt met alleen wie het nodig heeft, en bewaart alleen zo lang als vereist. Voor een overdrachtstool vertaalt dat zich in standaard ingeschakelde clientsijdige versleuteling, vervaltijden van minder dan 30 dagen, minimale metadataverzameling en éénklikintrekking.

De zeven Cavoukian-principes toegepast op overdrachten

Het kader van Ann Cavoukian uit de jaren negentig — proactief niet reactief, privacy als standaard, ingebouwd in het ontwerp, volledige functionaliteit, end-to-end beveiliging, zichtbaarheid en transparantie, respect voor gebruikersprivacy — is direct toepasbaar op bestandsoverdrachtarchitectuur. Proactief: detecteer zwakke cijfers in de codebase vóór uitrol via geautomatiseerde SAST-scanning. Standaard: AES-256-GCM ingeschakeld zonder opt-out. Ingebouwd: versleuteling vindt plaats in de uploadpijplijn, niet als afzonderlijke stap. Volledige functionaliteit: versleutelde bestanden ondersteunen nog steeds previews via clientsijdige ontsleuteling. End-to-end: het platform raakt nooit aan plaintext. Zichtbaarheid: publiceer de versleutelingsspecificatie. Respect: geef gebruikers controle over bewaring en verval.

Artikel 25(1): verplichtingen in de ontwerpfase

Artikel 25(1) vereist maatregelen "zowel bij de vaststelling van de middelen voor de verwerking als bij de verwerking zelf." Dat betekent privacyverplichtingen bij architectuurontwerp, niet achteraf toegevoegd. Kies een transportprotocol (HTTPS met TLS 1.3), een cijfersuite (AES-256-GCM of XChaCha20-Poly1305), een sleutelafleideingsfunctie (PBKDF2-SHA-256 bij 600.000 iteraties of Argon2id) en een opslagregio (EU) voordat je de eerste regel code schrijft. Documenteer de keuzes in een architectuurbeslissingsrecord zodat toekomstige ontwikkelaars de beperkingen begrijpen.

Artikel 25(2): verplichtingen voor standaardinstellingen

Artikel 25(2) specificeert vier standaardvereisten: beperk de hoeveelheid verzamelde persoonsgegevens, beperk de verwerking, beperk de bewaartermijn en beperk de toegankelijkheid. Voor een overdrachtstool betekent dat: vraag alleen om afzender- en ontvanger-e-mails (niet volledige naam, telefoon, adres); verwerk het bestand eenmalig en verwijder het; bewaar 7 dagen en niet voor altijd; beperk toegang tot de specifieke ontvangers, niet via een openbare URL geïndexeerd door zoekmachines. Vergelijk met WeTransfer Free's openbaar deelbare links — handig maar niet Artikel 25(2)-conform zonder aanvullende waarborgen.

Dataminimalisatie in de uploadstroom

Het uploadformulier van de afzender is waar minimalisatie begint. Slecht ontwerp: vraag om afzendernaam, bedrijf, telefoon, ontvangernaam, ontvangerbedrijf, bericht. Elk veld is een persoonsgegeven dat wordt opgeslagen en geanalyseerd. Goed ontwerp: alleen e-mail, optioneel berichtveld, geen trackingpixels. SwissTransfer en HexaTransfer implementeren beide minimale formulieren; WeTransfer en Dropbox Transfer verzamelen meer. Strip EXIF-metadata uit afbeeldingen aan de serverkant als clientsijdige stripping niet beschikbaar is. Log geen bestandsnamen als ze persoonsgegevens bevatten — hash ze voor het auditlog en bewaar de mapping server-side.

Standaard ingeschakelde versleuteling zonder prestatieexcuses

AES-256-GCM in moderne browsers via Web Crypto API draait op grofweg 200-500 MB/s op een laptop uit 2020. Een bestand van 100 MB versleutelt in ruim minder dan een seconde. Libsodium's XChaCha20-Poly1305 presteert vergelijkbaar snel. Het prestatieargument voor optionele versleuteling is verdwenen. Gebruik per-bestandssleutels afgeleid van een door de gebruiker gehouden geheim — een wachtwoord of een willekeurige sleutel ingebed in het URL-fragment (na het #, zodat servers het nooit zien). Verwijs naar Firefox Send's architectuur van 2017-2019 voor een bewezen patroon: het URL-fragment droeg de sleutel, de server zag alleen ciphertext.

Pseudonimisering waar mogelijk

Artikel 4(5) definieert pseudonimisering. Onder Overweging 28 wordt het door de hele verordening aangemoedigd. Voor bestandsoverdrachten betekent pseudonimisering het vervangen van directe identificatoren in systeemmetadata: afzender@bedrijf.nl wordt een SHA-256-hash voor het auditlog, waarbij de koppelingstabel afzonderlijk wordt opgeslagen onder strengere toegangscontroles. Ontvangers eveneens. Als een aanvaller alleen het auditlog compromitteert, ziet hij hashes, geen contactgraph. De koppelingstabel — kleiner en in een aparte kluis — is beschermd met verschillende sleutels en toegangsbeleid.

Transparantie via gepubliceerde architectuur

Artikel 25 verplicht geen open source, maar transparantie is een privacy-by-design-principe. Publiceer: de versleutelingsspecificatie (cijfer, KDF, iteraties, lengte authenticatietag), het gegevensstroomdiagram, de lijst van subverwerkers met rechtsgebieden, het bewaarschema, de tijdlijn voor inbreukmelding en het auditlogschema. Proton, Tresorit en HexaTransfer publiceren allemaal technische whitepapers. Cryptografische claims die niet geverifieerd kunnen worden — vage "militaire encryptie" — zijn rode vlaggen. Als de provider de cipher niet wil noemen, ga dan uit van zwakke beveiliging.

Gebruikerscontrole als standaard, niet als premiumfunctie

Privacy by design ontspoort wanneer controles achter betaalde niveaus worden vergrendeld. Wachtwoordbeveiligde links mogen geen extra kosten met zich meebrengen. Downloadlimieten mogen niet premium zijn. Linkintrekking mag niet vereisen dat je contact opneemt met ondersteuning. De minimale privacypositie — verval, wachtwoord, intrekking, downloadmeldingen — moet gratis zijn, waarbij betaalde niveaus schaal toevoegen (opslag, teambeheer) of gemak (merklinks, langere bewaring). Dit is zowel een AVG-positie als een commerciële: gebruikers vertrouwen producten die hen controle geven zonder betaalmuur.

Loggen dat het principe respecteert

Auditlogboeken zijn zelf persoonsgegevens. Te veel loggen creëert een nieuw lekoppervlak. Te weinig loggen en je kunt niet voldoen aan Artikel 33 of naleving aantonen onder Artikel 5(2). De balans: log gebeurtenistype, tijdstempel, bestandshash, acteurs-ID-hash, resultaat. Log geen volledige IP-adressen — kap af tot /24 (IPv4) of /64 (IPv6). Log geen volledige user-agents — extraheer browserfamilie en hoofdversie. Bewaar voor de minimale periode die nodig is voor beveiliging en compliance (typisch zes maanden), rol dan af. Versleutel de logpijplijn end-to-end; logtoegang zelf wordt een gebeurtenis.

De positie testen vóór lancering

Voer een gegevensstroomaudit uit met een nieuwe ontwikkelaar die niet betrokken was bij de bouw. Vraag: voor elk systeem, welke persoonsgegevens passeren erdoorheen? Waar worden ze opgeslagen? Hoe lang? Wie kan ze benaderen? Hoe wordt toegang gelogd? Hoe worden ze verwijderd? Vergelijk antwoorden met de Artikel 25-toezeggingen gedocumenteerd in de DPIA. Penetratietesten tegen de gestelde architectuur — ziet de server werkelijk alleen ciphertext? Staat de URL-fragmentsleutel echt buiten de logboeken? Diensten met zwakke privacy-by-design-claims falen deze tests snel. Diensten met solide — HexaTransfer's 7-daagse verval met clientsijdige AES-256-GCM — overleven omdat de architectuur doet wat de documentatie beschrijft.

Bouw privacy in; schroef het er niet achteraf aan. Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.