Why Our Sub-Processors List Has More Names On It Now (And What That Says About How We Manage It)

If you look at our sub-processors page today, you'll see two names that weren't explicitly listed a month ago: Google Fonts and jsDelivr. Not because we just started using those services — they've been running since the site launched. We decided: if we claim "complete list, no exceptions", that list actually has to be complete. Even the services that look "harmless" at first glance.

This piece explains what a sub-processor is exactly, why a CDN serving fonts qualifies as one, and why we'd rather be honest now than dodge questions later.

What is a sub-processor, actually?

In GDPR terms (Article 28), a sub-processor is any external party that processes personal data on behalf of the controller — us, Okidoky, in this case. The well-known examples are obvious: the hosting provider, the payment service provider, the mail provider. They see your name, email, payment data or the content of messages. For them the rules are clear: data processing agreement required, purpose limited, logs kept.

It gets less obvious for services that don't directly handle your account. For instance a CDN serving a font file. That CDN doesn't see you as an Okidoky user — but it does see the browser requesting a font, and along with it your IP address automatically. IP address has been a personal data point under GDPR since Breyer v. Bundesrepublik Deutschland (C-582/14, 2016).

So: when your browser fetches a font from fonts.googleapis.com because our site tells it to, we are indirectly processing your IP via Google. That puts Google LLC in the chain as a sub-processor — no matter how brief and stateless the interaction is.

What changed exactly?

The new entries:

Google Fonts — serves the two typefaces (Inter + Poppins) used by the public site. One request per unique font file, heavily cached, no cookies. But with your IP address and User-Agent, plus our site's URL as Referer.

jsDelivr — a non-profit open-source CDN (infrastructure via Cloudflare + Fastly) delivering the Bootstrap Icons font file. One small CSS + .woff2 file per visitor, also cached. No cookies, same kind of request metadata.

Both load on every public page of okidoky.nl — before any cookie choice, because fonts are needed before the page renders. The app behind login loads no external fonts; it uses system fonts there.

Why does it matter? The LG München ruling

In January 2022 the Munich Regional Court ruled that a website operator loading Google Fonts through the Google CDN had unlawfully transferred a visitor's IP address to the US. The fine was symbolic (€100), but the legal core was solid: if you make a visitor unexpectedly call a US service, you should have obtained consent for that — or self-hosted the font.

The ruling rippled through the German and Dutch privacy communities. Not because it generated one fine (there was a later backlash against the "Google Fonts extortion letters" that legal firms mailed around), but because the underlying principle stuck: if you trigger a stateless third-party call in your page, you're responsible for it.

Why not just self-host then?

We're going to, but doing it properly costs one build iteration:

  1. Store the two typefaces locally in /assets/fonts/ with the right font-display: swap and preload hints.
  2. Subset Bootstrap Icons — we don't use all ~1,800 icons, so the font file can shrink significantly.
  3. Check how much the layout shifts during font load (CLS budget).
  4. Repeat for all 5 languages, including Chinese where font fallback behaves differently.

That's not trivial enough to say "we'll do it real quick". And while it's not done yet, we think: being upfront that it's not self-hosted beats creating the impression that we only call EU services.

What this means for a user concretely

Not much, actually — and that's the whole point. Most users have been on the web for years without ever thinking about which CDNs their browser touches. But for anyone who takes privacy seriously, "which parties see me" is a legitimate question. And our answer to that shouldn't be "just these three you can see on the marketing site". It has to be "these nine, and for each service you can read what data they see and why".

That's why the list grew. Not because a regulator forced it. Because we'd rather walk through the open door than hope nobody asks.

Security.txt added too

In the same motion, we published a security.txt per RFC 9116. That's the machine-readable equivalent of our Responsible Disclosure policy: security scanners and bug-bounty hunters can now automatically find how to report a vulnerability to us. Contact, expiry date, preferred languages and a pointer to the longer policy all in one text file.

It's a small step, but one that works as a signal: "this is a company that participates in modern security norms". Scanners like Bug Bounty platforms, Mozilla Observatory and internal corporate audits check for it.

What to expect from us

Every change to the sub-processors list follows the same procedure:

  1. Internal review — why this service is needed and which alternatives we considered.
  2. Publication at /sub-verwerkers — at least 30 days before the change takes effect.
  3. Email to active users — with reason and link.
  4. 30-day objection window — anyone who disagrees on principle can export fully and leave.

This isn't invented to sound grandiose. It's the only way to keep transparency from silting up into a policy page nobody reads because it never changes. When a list grows, you talk about it. This is that talking.

Questions about which service sees what data? Email info@okidoky.nl or use the contact form. We reply ourselves — no support bot.