Waarom onze sub-verwerkers-lijst meer namen heeft gekregen (en wat dat zegt over hoe we het beheren)

Als je onze sub-verwerkers-pagina vandaag bekijkt, staan daar twee namen die er een maand geleden nog niet expliciet bij stonden: Google Fonts en jsDelivr. Niet omdat we die diensten nét zijn gaan gebruiken — ze draaien al sinds de launch van de website. Maar wel omdat we hebben besloten: als we claimen "complete lijst, geen uitzonderingen", dan moet die lijst ook écht compleet zijn. Ook de diensten die op het eerste gezicht "onschuldig" lijken.

Dit stuk legt uit wat een sub-verwerker precies is, waarom een CDN voor lettertypen daar eigenlijk onder valt, en waarom we liever nu eerlijk zijn dan later tegen vragen aanlopen.

Wat is een sub-verwerker eigenlijk?

In AVG-termen (artikel 28) is een sub-verwerker elke externe partij die namens de verantwoordelijke — in dit geval wij, Okidoky — persoonsgegevens verwerkt. De bekende voorbeelden zijn duidelijk: de hosting-provider, de payment service provider, de mailprovider. Die zien je naam, e-mail, betaalgegevens of inhoud van berichten. Bij hen geldt: verwerkersovereenkomst verplicht, doel beperkt, logs bewaard.

Minder duidelijk wordt het bij diensten die niet direct met je account te maken hebben. Bijvoorbeeld een CDN dat een lettertype serveert. Die CDN ziet jou niet als gebruiker van Okidoky — maar wel de browser die een font-bestand opvraagt, en daarbij automatisch je IP-adres meestuurt. IP-adres is volgens de AVG een persoonsgegeven (vast jurisprudentie sinds Breyer v. Bundesrepublik Deutschland, C-582/14, 2016).

Dus: als jouw browser een font ophaalt bij fonts.googleapis.com omdat onze site dat oplegt, verwerken wij indirect jouw IP-adres via Google. En dan valt Google LLC in dat pad onder "sub-verwerker" — hoe kortstondig en stateless de interactie ook is.

Wat is er precies veranderd aan de lijst?

De nieuwe entries:

Google Fonts — serveert de twee lettertypen (Inter + Poppins) die de publieke site gebruikt. Één request per uniek font-bestand, zwaar gecached, zonder cookies. Maar met jouw IP-adres en User-Agent, plus de URL van onze site als Referer.

jsDelivr — een non-profit open-source CDN (infrastructuur via Cloudflare + Fastly) dat de Bootstrap Icons-fontfile levert. Één kleine CSS- en één .woff2-file per bezoeker, ook gecached. Geen cookies, wel hetzelfde type request-metadata.

Beide worden geladen op elke publieke pagina van okidoky.nl — vóór enige cookie-keuze, omdat fonts nodig zijn voordat de pagina rendert. De app achter login laadt géén externe fonts; daar gebruiken we system-fonts.

Waarom doet het ertoe? Het LG München-arrest

In januari 2022 oordeelde het Landgericht München dat een websitebeheerder die Google Fonts via de Google-CDN laadde, onrechtmatig het IP-adres van een bezoeker naar de VS had overgedragen. De boete was symbolisch (€100), maar de juridische kern was hard: als je een bezoeker onverwacht een US-dienst laat aanroepen, had je daar voorafgaand toestemming voor moeten vragen — of de font self-hosten.

Het arrest trok golven door de Duitse en Nederlandse privacywereld. Niet omdat dit één boete opleverde (later kwam er een tegenreactie tegen de "Google Fonts-afpersingsbrieven" die rechtshulpbedrijven rondstuurden), maar omdat het uitgangspunt bleef staan: als je een stateless derde-partij-aanroep aanzet in je pagina, ben je daarvoor verantwoordelijk.

Waarom niet gewoon self-hosten dan?

Dat gaan we ook doen, maar het kost één build-iteratie om het goed te doen:

  1. De twee lettertypen lokaal opslaan in /assets/fonts/ met de juiste font-display: swap en preload-hints.
  2. Bootstrap Icons subsetten — we gebruiken niet alle ~1.800 iconen, dus de fontfile kan flink kleiner.
  3. Check doen op hoeveel pixels het layout verschuift tijdens font-load (CLS-budget).
  4. Herhalen voor alle 5 talen, inclusief Chinees waar de font-fallback anders werkt.

Dat is niet triviaal genoeg om "even doen" te zeggen. En zolang het nog niet af is, vinden we: eerlijk vermelden dat het nog niet self-hosted is, is beter dan de suggestie wekken dat we alleen EU-diensten aanroepen.

Wat een gebruiker hier concreet aan heeft

Nog weinig, eigenlijk — en dat is het hele punt. De meeste gebruikers gebruiken het internet al jaren zonder ooit na te denken over welke CDN's hun browser raakt. Maar voor wie privacy serieus neemt, is de vraag "welke partijen zien me" legitiem. En ons antwoord moet dan niet zijn: "alleen die drie op de marketing-site zichtbaar zijn". Het moet zijn: "deze negen, en hier lees je per dienst welke data ze zien en waarom".

Dat is waarom de lijst is uitgebreid. Niet omdat het moest van een toezichthouder. Omdat we liever de open deur intrappen dan hopen dat niemand vraagt.

Security.txt erbij gedaan

In dezelfde beweging hebben we een security.txt gepubliceerd conform RFC 9116. Dat is het machine-leesbare equivalent van ons Responsible Disclosure-beleid: security-scanners en bug-bounty-hunters kunnen nu automatisch vinden hoe ze een kwetsbaarheid bij ons moeten melden. Contact, vervaldatum, voorkeurstalen en een verwijzing naar het uitgebreidere beleid staan in één tekstbestand.

Het is een kleine stap, maar één die werkt als signaalfunctie: "dit is een bedrijf dat meedoet aan moderne veiligheidsnormen". Scanners zoals Bug Bounty-platforms, Mozilla Observatory en interne corporate-audits checken het.

Wat je bij ons mag verwachten

Elke wijziging in de sub-verwerkers-lijst volgt dezelfde procedure:

  1. Interne beoordeling — waarom deze dienst nodig is en welke alternatieven we hebben overwogen.
  2. Publicatie op /sub-verwerkers — minstens 30 dagen vóór de wijziging ingaat.
  3. E-mail aan actieve gebruikers — met reden en link.
  4. Bezwaar-window van 30 dagen — wie het principieel oneens is, kan volledig exporteren en vertrekken.

Dit is niet uitgevonden om hoogdravend te doen. Het is de enige manier om transparantie niet te laten verzanden in een policy-pagina die niemand leest omdat hij nooit verandert. Als een lijst groeit, moet je erover vertellen. Dat is dit stuk.

Heb je vragen over welke dienst welke data ziet? Mail info@okidoky.nl of gebruik het contactformulier. We antwoorden zelf — geen support-robot.