Browser-Fingerprinting

Was diese Prüfung macht

Scannt die geladenen Skripte und das Laufzeitverhalten nach bekannten Fingerprinting-Techniken:

• Kommerzielle SDKs — FingerprintJS Pro (fpjs.io, api.fpjs.io, metrics.<deine-domain> CNAMEs), ThreatMetrix, IPQS, SEON.
• Canvas-API-Missbrauch — Aufrufe von canvas.toDataURL() oder getImageData() auf versteckten, off-screen oder OffscreenCanvas-Elementen direkt nach dem Rendern einer festen Zeichenkette.
• WebGL-Proben — Auslesen von WEBGL_debug_renderer_info (GPU-Hersteller/Renderer-Strings) ohne sichtbaren 3D-Kontext.
• AudioContext-Fingerprinting — Instanziieren eines OfflineAudioContext, einen Oszillator laufen lassen und den Buffer hashen.
• Font-Enumeration — Breiten von Test-Strings über hunderte Font-Familien messen, um zu erkennen, welche installiert sind.

MetricSpot pflegt eine Allow-Liste für gängige Analytics-SDKs (GA4, Plausible, Fathom), die einige dieser APIs harmlos berühren, sodass die Prüfung nur anschlägt, wenn das Muster zu aktivem Fingerprinting passt.

Warum es zählt

Aufsichtsbehörden haben das Schlupfloch “es ist kein Cookie, also gilt keine Einwilligungspflicht” geschlossen. Die EDPB-Leitlinien 2023 zu Art. 5(3) ePrivacy behandeln jede clientseitige Technik, die Informationen vom Gerät der Nutzer:innen liest oder schreibt — Fingerprinting eingeschlossen — als gleichermaßen einwilligungspflichtig wie Cookies. CNIL, ICO und DPC haben das bestätigt.

Das bedeutet: Ein Fingerprinting-Skript, das vor der Zustimmung im Cookie-Consent-Banner feuert, ist derselbe Compliance-Verstoß wie ein _ga-Cookie vor der Einwilligung — und die Durchsetzung läuft aktiv. Die CNIL hat Criteo 2023 unter anderem auf dieser Basis mit 40 Mio. € bestraft.

Über das rechtliche Argument hinaus: Fingerprinting identifiziert Nutzer:innen sitzungs- und netzwerkübergreifend. Leakt ein Third-Party-SDK den Fingerprint, hast du ein Schattenprofil jedes Besuchers mit aufgebaut.

So behebst du es

Das ist eine Erkennungsregel, kein Config-Flag. Die Lösung lautet: prüfen, was läuft, und es hinter Einwilligung schalten.

1. Inventur. Öffne DevTools → Network → filtere nach Initiator und suche die von MetricSpot markierten Skripte. Verfolge jedes zurück zu einer Tag-Manager-Regel oder einem <script> in deinem Template. Wenn du nicht weißt, warum es da ist, gehört es nicht hin.

2. Entscheide, ob du es brauchst. Betrugserkennung auf einer Checkout-Seite kann FingerprintJS Pro rechtfertigen. Eine Marketing-Landingpage fast nie. Die EDPB-Ausnahme für “unbedingt erforderlich” ist eng — Sicherheit und Betrugsprävention können qualifizieren, Analytics-Anreicherung nicht.

3. Schalte es hinter Einwilligung. Wenn du das Skript behältst, lade es erst nach Opt-in. Mit einem CMP (OneTrust, Cookiebot, Iubenda, Klaro):

<!-- Nicht direkt laden -->
<script src="https://fpjs.io/web/v3/<key>/loader.js"></script>

<!-- Über CMP gaten - Beispiel: Klaro -->
<script type="text/plain" data-name="fingerprintjs"
        src="https://fpjs.io/web/v3/<key>/loader.js"></script>

Dann in deiner klaro-config.js:

services: [{
  name: "fingerprintjs",
  purposes: ["security"],
  required: false,
  default: false,
}]

4. Serverseitige Erkennung. Wenn ein Anbieter ein serverseitiges SDK anbietet (FingerprintJS Pros serverApi), bevorzuge das auf authentifizierten Routen — es bleibt innerhalb deiner First-Party-Trust-Boundary und ist leichter zu auditieren.

5. Dokumentiere es. Aktualisiere deine Datenschutzerklärung mit Anbieter, Zweck (“Zahlungsbetrugs-Prävention”), erfassten Daten und Speicherdauer. Generischer Standardtext reicht nicht.

Kombiniere diese Regel mit der Drittanbieter-Tracker-Prüfung — beide untersuchen dieselbe Skript-Inventur aus unterschiedlichen Blickwinkeln.

Häufig gestellte Fragen

Ist “cookieless Tracking” in der EU legal?

Nein, nicht ohne Einwilligung. Der Marketing-Pitch, cookieless = einwilligungsfrei, ist nach aktueller EDPB-Auslegung falsch. Auslöser der Einwilligungspflicht ist das Lesen oder Schreiben auf dem Gerät, unabhängig vom Mechanismus.

Was ist mit serverseitigen Analytics wie Plausible oder Fathom?

Die sind in Ordnung. Sie leiten serverseitig einen täglich rotierenden Hash aus IP + User-Agent ab, speichern ihn nie und greifen nicht auf clientseitige APIs zu. MetricSpots Allow-Liste schließt sie aus.

Mein Fraud-Team braucht FingerprintJS auf dem Checkout. Darf ich es behalten?

Wahrscheinlich ja, eng gefasst: nur auf /checkout und /login laden, den Sicherheitszweck in deiner Datenschutzerklärung dokumentieren und dich auf die EDPB-Ausnahme “unbedingt erforderlich für einen vom Nutzer ausdrücklich gewünschten Dienst” stützen. Hol dir die Freigabe der Rechtsabteilung — die Grenze ist jurisdiktionsspezifisch.