Datenschutzhinweis – Skriza Shield
Stand: 5. Juli 2026
Skriza Shield ist ein datensparsames Botschutz- und CAPTCHA-System („Anti-Bot“). Betreiber binden Shield auf ihren Websites, in Formularen und Log-ins ein, um automatisierte Zugriffe, Spam, Fake-Registrierungen und Missbrauch abzuwehren – ohne Google, ohne Cookies, ohne seitenübergreifendes Tracking und ohne Geräte-Fingerprinting. Dieser Hinweis beschreibt, welche Daten Shield im Browser der Besucher und auf unseren Servern verarbeitet. Betreiber, die Shield einsetzen, dürfen diesen Hinweis verlinken oder die zutreffenden Abschnitte in ihre eigene Datenschutzerklärung übernehmen.
1. Rollen: Verantwortlicher und Auftragsverarbeiter
Verantwortlicher im Sinne der DSGVO für die auf einer eingebundenen Website erhobenen Daten ist der jeweilige Betreiber dieser Website. Skriza Shield verarbeitet die nachfolgend beschriebenen Daten im Auftrag des Betreibers und handelt insoweit als Auftragsverarbeiter (Art. 28 DSGVO).
Anbieter von Skriza Shield ist:
Yusuf Senel, Von-Hünefeld-Str. 8, 40764 Langenfeld, Deutschland
E-Mail (Datenschutz): [email protected]
Wenn Skriza selbst Shield auf skriza.com einsetzt, ist Skriza zugleich Verantwortlicher; die dortige Verarbeitung ist zusätzlich in der allgemeinen Datenschutzerklärung von Skriza beschrieben.
2. Grundprinzip: Datensparsamkeit by Design
Shield ist so gebaut, dass keine identifizierenden Merkmale dauerhaft gespeichert werden. Wir setzen keine Cookies und keinen localStorage, erstellen keinen wiedererkennbaren Geräte-Fingerabdruck (kein Canvas-, Font- oder WebGL-Hashing), binden keine Dienste von Google oder anderen Werbenetzwerken ein und legen kein seitenübergreifendes Besucherprofil an. Alle Verarbeitung dient ausschließlich der Sicherheitsentscheidung „Mensch oder Bot“.
3. Was auf dem Endgerät gespeichert wird: nichts
Shield speichert keine Informationen in der Endeinrichtung der Besucher und greift auch nicht auf dort gespeicherte Informationen zu: kein Cookie, kein localStorage, kein sessionStorage, keine IndexedDB, keine cache-basierte Kennung. Der Nachweis lässt sich in jedem Browser führen – Anwendungs- bzw. Speicher-Tab der Entwicklerwerkzeuge öffnen und eine Shield-Prüfung durchlaufen.
Deshalb ist der Tatbestand des § 25 Abs. 1 TDDDG (Speichern von oder Zugriff auf Informationen in der Endeinrichtung) nicht erfüllt, und es bedarf für Shield keiner Einwilligung und keines Cookie-Banners. Auf die Ausnahme für unbedingt erforderliche Dienste (§ 25 Abs. 2 Nr. 2 TDDDG) müssen wir uns dafür nicht berufen – sie käme nur zum Tragen, wenn überhaupt etwas gespeichert würde.
Der Unterschied zu verbreiteten CAPTCHA-Diensten ist an dieser Stelle praktisch: Wer Informationen auf dem Gerät ablegt, muss begründen, warum das unbedingt erforderlich ist, und trägt das Risiko, dass eine Aufsichtsbehörde oder ein Gericht das anders sieht. Wo nichts abgelegt wird, entsteht die Frage nicht.
4. Im Browser erhobene technische Signale
Beim Laden des Shield-Widgets wertet ein Skript im Browser eine kompakte Menge technischer Merkmale aus, die typisch für automatisierte/„headless“ Browser (z. B. Selenium, Puppeteer, Playwright) sind. Jedes Merkmal wird bereits im Browser auf einen Wahrheitswert oder eine kleine gerundete Zahl reduziert. Der Rohwert (etwa der genaue Grafik-Renderer-Name) verlässt das Gerät nicht.
- Automatisierungs-Indikatoren (z. B. navigator.webdriver, bekannte Automatisierungs-Objekte)
- Browser-/Umgebungskonsistenz (Plugins-Anzahl, Sprachenanzahl, Prozessorkerne, Gerätespeicher-Klasse, Fenster-/Bildschirmmaße, Touch-Fähigkeit, Zeitzonen-Versatz)
- Grafik-Hinweise (nur: Software-Renderer ja/nein, WebGL verfügbar ja/nein) – kein Renderer-String, kein Canvas-Bild
- Aggregierte Interaktions-Kennwerte während das Widget sichtbar ist (Anzahl Zeiger-Bewegungen, Art der ersten Interaktion, grobe Zeit bis zur ersten Interaktion, ein Kurvigkeits-Maß) – es werden weder Koordinaten noch eine Bewegungsspur übertragen
5. Serverseitig verarbeitete Daten
Die oben genannten Signale werden an unseren Server gesendet, dort zu einer Risikobewertung (0–100) verrechnet und anschließend verworfen; sie werden nicht dauerhaft gespeichert. Zusätzlich verarbeiten wir serverseitig:
- IP-Adresse: ausschließlich in Form eines nicht umkehrbaren HMAC-Hashwerts als Schlüssel für kurzlebige Missbrauchs- und Sperrzähler. Die rohe IP-Adresse wird nicht gespeichert.
- Netz-Reputation: die IP wird an unseren internen WHOIS-Dienst übergeben, um Land und Netzbetreiber (ASN, z. B. Rechenzentrum) abzuleiten; dieser Dienst speichert die IP nicht, das Ergebnis wird nur kurz unter dem IP-Hash zwischengespeichert.
- Missbrauchs- und Geschwindigkeitszähler pro (gehashter) IP: Anzahl Prüfungen, Fehlversuche, erfolgreiche Prüfungen und daraus abgeleitete zeitlich begrenzte Sperren.
- Seitenübergreifende Reputation: ein rein zahlenbasierter Zähler (gehashte IP), der zählt, wie oft ein Aufrufer über Shield-geschützte Seiten hinweg blockiert wurde – ohne zu speichern, welche Seiten das waren, und ohne Inhalte.
- Bei einer interaktiven Prüfung (z. B. „Objekt aufrichten“): anonyme Bewegungsproben (Zeit/Winkel) allein zur Mensch-oder-Bot-Entscheidung; sie werden unmittelbar danach verworfen.
- Ausgestellte Freigabe-Tokens: kurzlebige, signierte Einmal-Tokens (Gültigkeit ca. 5 Minuten), die die Prüfung bestätigen und den Verdict (Risikowert, Aktionsname, Prüfmethode, wenige maschinenlesbare Gründe) an das Backend des Betreibers zurückgeben.
- Aggregierte, nicht personenbezogene Statistikzähler pro eingebundener Website (z. B. verifiziert/blockiert) für das Betreiber-Dashboard.
6. Automatisierte Entscheidungen und Sperren (Art. 22 DSGVO)
Shield bewertet Anfragen automatisiert. Aus dem Risikowert folgt eine von drei Aktionen: durchlassen, eine interaktive Prüfung verlangen oder – bei eindeutig erkannter Automatisierung oder nach wiederholten Fehlversuchen – zeitlich begrenzt sperren. Diesen Vorgang beschreiben wir hier ausdrücklich, weil er automatisierte Entscheidungsfindung im Sinne des Art. 22 DSGVO berühren kann und ein Botschutz, der das verschweigt, seine Betreiber in ein Problem laufen lässt.
Was Shield tatsächlich entscheidet, hängt von der Einbindung ab. Im Regelfall gibt Shield lediglich ein Prüfergebnis (Risikowert, Aktionsempfehlung, maschinenlesbare Gründe) an das Backend des Betreibers zurück; welche Folge daraus gezogen wird – Anmeldung verweigern, Bestellung prüfen, Beitrag zurückstellen – entscheidet der Betreiber. Insoweit trifft Shield keine Entscheidung über eine Person, sondern liefert eine Tatsachengrundlage, und die Verantwortung für die daraus folgende Entscheidung liegt beim Verantwortlichen.
Verweigert Shield den Zugang selbst, ist das eine automatisierte Entscheidung. Sie ist jedoch nach Zweck und Wirkung begrenzt: Eine interaktive Prüfung ist eine Hürde, keine Ablehnung. Eine Sperre wirkt nur für den geschützten Endpunkt, nicht für ein Konto oder einen Vertrag, sie läuft nach Ablauf der Frist von selbst wieder aus (siehe Abschnitt „Speicherdauer und Löschung“), und sie stützt sich nie auf besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO. Erwägungsgrund 71 DSGVO nennt die Überwachung und Verhinderung von Betrug ausdrücklich als Fall, in dem eine automatisierte Entscheidung zulässig sein kann – verlangt dafür aber angemessene Garantien.
Diese Garantien setzen wir wie folgt um: Jede Sperre nennt einen Grund und verweist auf eine Einspruchsseite. Dort kann sich der Betroffene als Mensch verifizieren, und die Anfrage wird von einer Person geprüft, die die Entscheidung aufheben kann – keine bloße Bestätigung durch dasselbe Verfahren, das gesperrt hat. Damit steht der Weg zu menschlichem Eingreifen, zur Darlegung des eigenen Standpunkts und zur Anfechtung der Entscheidung nach Art. 22 Abs. 3 DSGVO offen.
Offen gesagt: Der seitenübergreifende Reputationszähler bedeutet, dass ein Aufrufer, der auf einer Shield-geschützten Seite blockiert wurde, auf einer anderen früher zu einer interaktiven Prüfung aufgefordert werden kann. Gespeichert wird dafür nur eine Zahl zu einem IP-Hash in einem gleitenden 24-Stunden-Fenster – nicht, welche Seiten besucht wurden. Wer das nicht möchte, kann dieser Verarbeitung widersprechen (Art. 21 DSGVO); der Betreiber kann den Zähler für seine Website außerdem abschalten.
7. Einspruch und Entsperrung
Wurde ein Zugang vorübergehend gesperrt, kann sich der Besucher über eine Einspruchsseite als Mensch verifizieren. Dort kann optional eine E-Mail-Adresse angegeben werden. Deren Vertrauenswürdigkeit bewerten wir anhand der Domain (etablierter Anbieter vs. Wegwerf-Adresse); die Anfrage wird zur manuellen Prüfung gespeichert. Die E-Mail-Adresse wird ausschließlich zur Bearbeitung dieser Entsperr-Anfrage verwendet.
Die Angabe einer E-Mail-Adresse ist freiwillig. Ohne sie ist der Einspruch möglich, wir können das Ergebnis dann aber nicht mitteilen.
8. Speicherdauer und Löschung
Alle sicherheitsrelevanten Datensätze löschen sich selbst über kurze Verfallszeiten (TTL):
- Risikosignale des Browsers: nach der Bewertung sofort verworfen (keine Speicherung).
- Bewegungsproben interaktiver Prüfungen: unmittelbar nach der Entscheidung verworfen.
- Missbrauchs-/Sperrzähler (gehashte IP): typischerweise Minuten bis wenige Stunden.
- Zwischengespeicherte Netz-Reputation (gehashte IP): rund eine Stunde.
- Seitenübergreifender Reputationszähler: gleitendes 24-Stunden-Fenster.
- Freigabe-Tokens/Einmal-Nonces: wenige Minuten.
- Aggregierte Statistikzähler pro Website: nicht personenbezogen, spätestens nach rund 90 Tagen.
- Einspruchs-Datensätze mit E-Mail-Adresse: nur so lange, wie es für die Prüfung sowie für Nachweis- und Sicherheitszwecke erforderlich ist.
9. Rechtsgrundlage
Rechtsgrundlage ist das berechtigte Interesse des Betreibers (und von Skriza) an der Sicherheit, Integrität und Verfügbarkeit der Systeme sowie an der Verhinderung von Betrug, Spam und Missbrauch (Art. 6 Abs. 1 lit. f DSGVO). Die Erwägungsgründe 47 und 49 DSGVO stellen ausdrücklich klar, dass die Verhinderung von Missbrauch und die Gewährleistung der Netz- und Informationssicherheit ein berechtigtes Interesse darstellen.
Eine Einwilligung nach § 25 Abs. 1 TDDDG ist nicht erforderlich, weil Shield keine Informationen in der Endeinrichtung speichert oder ausliest (siehe Abschnitt „Was auf dem Endgerät gespeichert wird: nichts“).
10. Hosting und Datenübermittlung
Die Verarbeitung durch Skriza Shield erfolgt auf Servern innerhalb der Europäischen Union. Eine Übermittlung in ein Drittland findet nicht statt; es sind keine Standardvertragsklauseln erforderlich, weil es keinen Drittlandtransfer gibt, der abzusichern wäre. Eine Weitergabe der verarbeiteten Daten an Dritte zu Werbe- oder Tracking-Zwecken findet nicht statt.
11. Auftragsverarbeitung und Pflichten des Betreibers
Betreiber, die Shield einbinden, schließen mit dem Anbieter einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Darüber hinaus liegen folgende Pflichten beim Betreiber als Verantwortlichem:
- Die Verarbeitung in der eigenen Datenschutzerklärung benennen. Dieser Hinweis darf dafür verlinkt oder abschnittsweise übernommen werden.
- Das eigene berechtigte Interesse und die Abwägung dokumentieren (Art. 6 Abs. 1 lit. f, Art. 5 Abs. 2 DSGVO) sowie den Eintrag im Verzeichnis der Verarbeitungstätigkeiten führen (Art. 30 DSGVO).
- Prüfen, ob aus der Einbindung eine Entscheidung mit rechtlicher Wirkung folgt, und in diesem Fall die Garantien nach Art. 22 Abs. 3 DSGVO im eigenen Ablauf sicherstellen.
- Bei Verarbeitungen mit hohem Risiko eine Datenschutz-Folgenabschätzung durchführen (Art. 35 DSGVO); die dafür nötigen Angaben zu Datenarten, Zwecken, Speicherdauern und Sicherheitsmaßnahmen stellen wir bereit.
- Eine barrierefreie Alternative vorhalten, wo die interaktive Prüfung für einzelne Nutzergruppen nicht bedienbar ist.
12. Betroffenenrechte
Betroffene können ihre Rechte auf Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit und Widerspruch (Art. 15–21 DSGVO) grundsätzlich gegenüber dem Betreiber der jeweiligen Website als Verantwortlichem geltend machen; wir unterstützen den Betreiber dabei.
Aufgrund der bewussten Datensparsamkeit – nur gehashte, kurzlebige Kennwerte, keine dauerhafte Zuordnung zu einer Person – können einzelne Datensätze in der Regel keiner bestimmten Person zugeordnet werden. In diesem Fall gilt Art. 11 Abs. 2 DSGVO: Wir müssen mitteilen, dass eine Zuordnung nicht möglich ist, und der Betroffene kann zusätzliche Angaben machen, die eine Identifizierung ermöglichen. Das ist keine Ausrede, sondern die Folge davon, nichts gespeichert zu haben, womit man jemanden wiedererkennen könnte.
13. Änderungen
Es gilt die jeweils aktuelle, hier veröffentlichte Fassung. Mit der Weiterentwicklung von Skriza Shield wird dieser Hinweis angepasst.