Privacy Notice — Skriza Shield

1. Roles: controller and processor

The controller under the GDPR for data collected on a site that embeds Shield is the operator of that site. Skriza Shield processes the data described below on the operator's instructions and acts as a processor (Art. 28 GDPR).

Skriza Shield is provided by:

Yusuf Senel, Von-Hünefeld-Str. 8, 40764 Langenfeld, Deutschland

Email (data protection): [email protected]

Where Skriza itself uses Shield on skriza.com, Skriza is also the controller; that processing is additionally described in Skriza's general privacy policy.

2. Principle: data minimisation by design

Shield is built so that no identifying characteristic is stored permanently. We set no cookies and no localStorage, build no recognisable device fingerprint (no canvas, font or WebGL hashing), embed no Google or ad-network services, and build no cross-site visitor profile. All processing serves the single security decision: human or bot.

3. What is stored on the device: nothing

Shield stores no information on visitors' terminal equipment and reads nothing stored there: no cookie, no localStorage, no sessionStorage, no IndexedDB, no cache-based identifier. You can verify this in any browser — open the application or storage tab of the developer tools and run a Shield check.

§ 25(1) TDDDG (and Art. 5(3) ePrivacy), which governs storing or accessing information on terminal equipment, is therefore not triggered, so Shield needs no consent and no cookie banner. We do not need to rely on the strictly-necessary exemption in § 25(2) no. 2 TDDDG for this — that exemption only matters if something is stored in the first place.

The practical difference from common CAPTCHA services sits here: whoever writes to the device has to argue why that is strictly necessary, and carries the risk that a supervisory authority or a court sees it differently. Where nothing is written, the question does not arise.

4. Technical signals collected in the browser

When the Shield widget loads, a script in the browser evaluates a compact set of characteristics typical of automated or headless browsers (e.g. Selenium, Puppeteer, Playwright). Each characteristic is reduced to a boolean or a small rounded number in the browser itself. The raw value — the exact graphics renderer name, for instance — never leaves the device.

• Automation indicators (e.g. navigator.webdriver, known automation objects)
• Browser/environment consistency (plugin count, language count, CPU cores, device-memory class, window and screen dimensions, touch capability, timezone offset)
• Graphics hints (only: software renderer yes/no, WebGL available yes/no) — no renderer string, no canvas image
• Aggregate interaction metrics while the widget is visible (pointer-move count, kind of first interaction, coarse time to first interaction, a curvature measure) — neither coordinates nor a motion trace are transmitted

5. Data processed server-side

The signals above are sent to our server, combined into a risk score (0–100) and then discarded; they are not stored permanently. In addition we process server-side:

• IP address: only as a non-reversible HMAC hash, used as the key for short-lived abuse and block counters. The raw IP address is not stored.
• Network reputation: the IP is passed to our internal WHOIS service to derive country and network operator (ASN, e.g. data centre); that service does not store the IP, and the result is cached only briefly under the IP hash.
• Abuse and rate counters per hashed IP: number of checks, failures, successful checks, and the time-limited blocks derived from them.
• Cross-site reputation: a purely numeric counter (hashed IP) recording how often a caller was blocked across Shield-protected sites — without storing which sites those were, and without content.
• During an interactive challenge (e.g. “right the object”): anonymous motion samples (time/angle) used solely for the human-or-bot decision; discarded immediately afterwards.
• Issued pass tokens: short-lived, signed single-use tokens (valid about 5 minutes) that confirm the check and return the verdict (risk score, action name, check method, a few machine-readable reasons) to the operator's backend.
• Aggregate, non-personal statistics counters per embedded site (e.g. verified/blocked) for the operator dashboard.

6. Automated decisions and blocks (Art. 22 GDPR)

Shield assesses requests automatically. The risk score leads to one of three actions: allow, require an interactive challenge, or — on clearly detected automation or after repeated failures — block for a limited time. We describe this explicitly because it can engage automated decision-making within the meaning of Art. 22 GDPR, and a bot protection that stays quiet about it walks its operators into a problem.

What Shield actually decides depends on the integration. Normally Shield only returns a result (risk score, recommended action, machine-readable reasons) to the operator's backend; what follows from it — refuse the sign-in, review the order, hold the post back — is the operator's decision. To that extent Shield takes no decision about a person but supplies a factual basis, and responsibility for the resulting decision rests with the controller.

Where Shield refuses access itself, that is an automated decision. It is limited in purpose and effect, though: an interactive challenge is a hurdle, not a rejection. A block applies only to the protected endpoint, not to an account or a contract, it expires by itself when its window elapses (see “Retention and deletion”), and it never rests on special categories of personal data under Art. 9 GDPR. Recital 71 GDPR names fraud monitoring and prevention explicitly as a case where an automated decision can be permissible — but requires suitable safeguards for it.

We implement those safeguards as follows. Every block states a reason and points to an appeal page. There the person concerned can verify as a human, and the request is reviewed by a person who can reverse the decision — not a rubber stamp by the same mechanism that blocked. This keeps open the route to human intervention, to expressing one's point of view and to contesting the decision under Art. 22(3) GDPR.

Stated plainly: the cross-site reputation counter means a caller blocked on one Shield-protected site may be asked for an interactive challenge sooner on another. All that is stored for this is a number against an IP hash in a rolling 24-hour window — not which sites were visited. Anyone who objects to this processing may do so (Art. 21 GDPR), and an operator can switch the counter off for their own site.

7. Appeal and unblocking

If access has been blocked temporarily, the visitor can verify as a human on an appeal page. An email address may optionally be given there. We assess its trustworthiness by domain (established provider vs. disposable address); the request is stored for manual review. The email address is used solely to handle that unblock request.

Giving an email address is voluntary. The appeal works without one, but then we cannot tell you the outcome.

8. Retention and deletion

Every security-relevant record deletes itself through a short TTL:

• Browser risk signals: discarded immediately after scoring (not stored).
• Motion samples from interactive challenges: discarded immediately after the decision.
• Abuse/block counters (hashed IP): typically minutes to a few hours.
• Cached network reputation (hashed IP): about an hour.
• Cross-site reputation counter: rolling 24-hour window.
• Pass tokens / single-use nonces: a few minutes.
• Aggregate per-site statistics counters: non-personal, at most around 90 days.
• Appeal records containing an email address: only as long as needed for the review and for evidence and security purposes.

9. Legal basis

The legal basis is the legitimate interest of the operator (and of Skriza) in the security, integrity and availability of the systems and in preventing fraud, spam and abuse (Art. 6(1)(f) GDPR). Recitals 47 and 49 GDPR state expressly that preventing abuse and ensuring network and information security constitute a legitimate interest.

No consent under § 25(1) TDDDG is required, because Shield stores and reads no information on terminal equipment (see “What is stored on the device: nothing”).

10. Hosting and data transfers

Processing by Skriza Shield takes place on servers within the European Union. There is no transfer to a third country; no Standard Contractual Clauses are needed, because there is no third-country transfer to safeguard. The processed data is not passed to third parties for advertising or tracking purposes.

11. Processing agreement and operator duties

Operators embedding Shield enter into a data-processing agreement with the provider under Art. 28 GDPR. Beyond that, the following duties sit with the operator as controller:

• Name the processing in your own privacy policy. You may link this notice or copy sections of it.
• Document your own legitimate interest and the balancing test (Art. 6(1)(f), Art. 5(2) GDPR) and keep the entry in your record of processing activities (Art. 30 GDPR).
• Assess whether your integration produces a decision with legal effect, and if so ensure the Art. 22(3) safeguards inside your own process.
• Carry out a data-protection impact assessment for high-risk processing (Art. 35 GDPR); we provide the necessary detail on data categories, purposes, retention and security measures.
• Keep an accessible alternative available wherever the interactive challenge cannot be operated by some groups of users.

12. Data subject rights

Data subjects can exercise their rights of access, rectification, erasure, restriction, portability and objection (Arts 15–21 GDPR) against the operator of the relevant website as controller; we support the operator in doing so.

Because of the deliberate data minimisation — only hashed, short-lived values, no lasting link to a person — individual records generally cannot be attributed to a specific person. Art. 11(2) GDPR then applies: we must say that attribution is not possible, and the data subject may provide additional information enabling identification. That is not an excuse but the consequence of having stored nothing you could recognise someone by.

13. Changes

The version published here applies. This notice will be adjusted as Skriza Shield develops.