Wann externe Schrifteneinbindung einwilligungspflichtig ist, warum „technisch erforderlich" nicht greift, und wie der rechtlich saubere Weg über Self-Hosting aussieht.
Adobe Fonts (ehemals Typekit) liefert Schriften dynamisch über Adobe-Server aus — typischerweise über use.typekit.net. Beim Laden der Schrift stellt der Browser des Nutzers eine Verbindung zu diesen Servern her und überträgt dabei zwangsläufig die IP-Adresse — ein personenbezogenes Datum.
Da Adobe ein US-Unternehmen ist, handelt es sich zudem um einen Drittland-Transfer in die USA. Das ist exakt dieselbe Konstellation wie beim bekannten Google-Fonts-Urteil (LG München I, Az. 3 O 17493/20, 2022), bei dem das dynamische Nachladen ohne Einwilligung als Verstoß gewertet wurde.
Nicht die Schrift selbst ist das Problem, sondern die Verbindung zu einem Drittserver ohne vorherige Einwilligung. Wird die Schrift lokal vom eigenen Server geladen, entfällt der gesamte Problemkomplex.
Kurz: Nein, das ist rechtlich nicht haltbar.
Die Kategorie „technisch notwendig" bzw. „unbedingt erforderlich" (§ 25 Abs. 2 TDDDG, ehemals TTDSG) gilt nur für das, was für den vom Nutzer ausdrücklich gewünschten Dienst zwingend nötig ist. Eine bestimmte Schriftart ist eine gestalterische Präferenz — die Seite funktioniert auch mit einer System- oder Fallback-Schrift vollständig.
Eine externe Wunsch-Schrift in der Consent-Lösung als „essenziell / erforderlich" einzustufen, um die Einwilligung zu umgehen. Aufsichtsbehörden und Gerichte werten Schriften durchweg als nicht technisch notwendig. Du schaffst dir damit dieselbe Angriffsfläche wie bei extern geladenen Google Fonts (Abmahnrisiko, Schadensersatzforderungen).
Nein. Im Gegenteil — das Thema Drittland-Transfer bleibt heikel.
Seit 2023 gibt es zwar wieder eine Rechtsgrundlage für US-Transfers über das EU-US Data Privacy Framework (DPF), und Adobe ist darunter zertifiziert. Aber:
DPF löst die „Transfer-Frage", nicht die „Consent-Frage". Beide müssen erfüllt sein — und Consent vor dem Laden bleibt Pflicht, solange extern geladen wird.
Der technisch und rechtlich saubere Weg ist, die Schrift vom eigenen Server auszuliefern statt vom Adobe-CDN. Dann findet keine Drittserver-Verbindung statt, keine IP wird an Adobe übertragen — und damit ist auch keine Einwilligung nötig.
Schrift lokal hosten (z. B. woff2 im eigenen /fonts-Verzeichnis, eingebunden per @font-face). Das passt zur ohnehin bevorzugten Praxis: Fonts und Icons lokal statt über CDN. Damit ist der Consent-Punkt komplett vom Tisch.
Vorteile über den Datenschutz hinaus: keine Abhängigkeit von Adobe-Verfügbarkeit, schnellere Auslieferung (gleicher Origin, kein zusätzlicher DNS-/TLS-Handshake), volle Kontrolle über Caching.
Wichtig — hier unterscheidet sich Adobe deutlich von Google Fonts:
Adobe-Fonts dürfen nicht einfach heruntergeladen und selbst gehostet werden. Die Adobe-Fonts-Lizenz (im Rahmen des Creative-Cloud-Abos) erlaubt nur die Auslieferung über Adobes eigenes CDN. Ein Download zum Self-Hosting verstößt gegen die Nutzungsbedingungen.
Wenn du die Schrift wirklich selbst hosten willst, brauchst du eine Lizenz, die Webfont-Self-Hosting ausdrücklich erlaubt:
@font-face einbinden. Kein Consent nötig, kein Drittland-Transfer.| Methode | Consent nötig? | Drittland-Transfer | Lizenz-OK |
|---|---|---|---|
| Adobe Fonts via CDN | Ja, vor Laden | USA (DPF) | ja |
| Adobe Font „erforderlich" deklariert | unzulässig | USA (DPF) | Risiko |
| Adobe-Font heruntergeladen & selbst gehostet | nein | keiner | verboten |
| Gekaufte Webfont-Lizenz, selbst gehostet | nein | keiner | ja |
| OFL-Alternative, selbst gehostet | nein | keiner | ja |
Fazit: Als „erforderlich" deklarieren ist nicht haltbar, gelockert wurde nichts. Der Weg, der technisch und rechtlich sauber ist, ist eine selbst-hostbare Lizenz der gewünschten — oder einer äquivalenten — Schrift.