Häufig gestellte Fragen

Echte Fragen aus echten Integrationen. Wenn Ihre nicht dabei ist, erhalten Sie über die Kontaktseite eine echte Antwort von jemandem, der das Produkt kennt.

Funktioniert das mit Tor?

Ja. Traffic von Tor-Exit-Knoten startet mit einem moderaten Risikolevel – es ist eine bekannte Anonymisierungsroute – aber wir lesen dennoch das vollständige Bild der Sitzung. Wenn Ihre Anwendung Tor-Nutzer ausdrücklich willkommen heißt, etwa für Journalismus, vertrauliche Suchen oder Schutzabläufe für Missbrauchsopfer, können Sie Noxtica anweisen, das Tor-Signal nicht in den Score einfließen zu lassen, während alle anderen Signale aktiv bleiben. Das Signal bleibt in beiden Fällen im Ergebnis sichtbar. Sie entscheiden, ob es zählt.

Die vollständige Begründung, warum Tor-Nutzer nicht automatisch blockiert werden, finden Sie unter Umgang mit Privacy-Browsern im Dokument zu den Bedrohungskategorien.

Was ist mit datenschutzorientierten Browsern – Brave, LibreWolf, Tor?

Alle funktionieren. Jeder Privacy-Browser hat eine unverwechselbare Form, die wir aus unseren Populationsdaten kennen. Tracking-Schutzfunktionen brechen die Verifizierung nicht; sie erzeugen lediglich ein anderes, aber in sich konsistentes Profil. Wir behandeln das Schutzniveau als ehrliches Signal, anstatt den Nutzer still dafür zu bestrafen, dass er sich für einen Privacy-Browser entschieden hat.

Das ist Prinzip 03 (False Positives sind keine akzeptablen Verluste) in der Praxis. Einen Brave-Nutzer zu blockieren kostet Sie einen Kunden, der sich bewusst für einen Privacy-Browser entschieden hat. Das Risiko-Nutzen-Verhältnis lohnt sich nicht, und die Kalibrierung spiegelt das wider.

Wie viel kommt zu meiner Seite dazu?

Sehr wenig. Der erste Ladevorgang ist winzig, weil die aufwendigen Messungen erst dann beginnen, wenn die Seite tatsächlich eine Bewertung anfordert. Alles läuft im Hintergrund und verzögert nie die Nutzbarkeit Ihrer Seite. Wiederkehrende Besucher senden ein noch kleineres Signal. In der Praxis bemerkt der Nutzer nie, dass es vorhanden ist.

Müssen wir ein Backend betreiben?

Ja. Der Collector läuft im Browser und erzeugt ein versiegeltes Ergebnis; die eigentliche Verifizierung findet auf Ihrem Server über unsere API statt. Da das vollständige Bild innerhalb dieses versiegelten Ergebnisses reist, ist die Verifizierung schnell – es gibt keine neue Datenerfassung und keine zusätzlichen Netzwerkanfragen während einer laufenden Anfrage. Das Ergebnis wird in wenigen Millisekunden geprüft.

Der Grund, warum das Backend notwendig ist: Ein Urteil, das rein im Browser getroffen wird, ist trivial zu fälschen. Das versiegelte Ergebnis ist die Garantie, dass nach der Erfassung nichts manipuliert wurde, und diese Garantie in Ihrem eigenen vertrauenswürdigen Backend zu verifizieren, macht das gesamte System vertrauenswürdig.

Sind Sie datenschutzkonform?

Wir agieren als Unterauftragsverarbeiter unter Ihrem Auftragsverarbeitungsvertrag und haben unseren eigenen auf Anfrage verfügbar. Wir behandeln die von uns verarbeiteten Daten als personenbezogene Daten, weil sie einen wiederkehrenden Besucher re-identifizieren könnten, und wenden die vollständigen damit verbundenen Kontrollen an. Die Infrastruktur befindet sich in der EU, ohne Übermittlungen außerhalb davon. Eine vollständige Löschung ist auf Anfrage über das Backoffice möglich, und wir können Verträge innerhalb eines Tages unterzeichnen. Unsere Liste der Unterauftragsverarbeiter finden Sie unter /subprocessors.

Einige Details, nach denen Datenschutzbeauftragte fragen:

• Rechtsgrundlage: Für die meisten Integrationen empfehlen wir die Grundlage des berechtigten Interesses für die Betrugsprävention. Einwilligungsabläufe werden ebenfalls unterstützt.
• Datenminimierung: Was wir speichern, ist eine verschleierte, einwegige Zusammenfassung, keine Rohwerte. Wir können die ursprünglichen Signale nicht daraus rekonstruieren.
• Recht auf Löschung: Die Löschung wird auf Speicherebene durchgesetzt, nicht als Soft-Flag. Einmal gelöscht, sind die Daten unwiederbringlich weg.
• Auskunftsersuchen: Wir bieten eine Möglichkeit, alles zurückzugeben, was mit einem bestimmten Besucher verknüpft ist, eingegrenzt auf Ihr Konto.

Wie hoch ist Ihre False-Positive-Rate?

Das hängt davon ab, wo Sie Ihre Schwelle setzen. Mit unseren konservativen Standardeinstellungen misst unser interner Benchmark gegen Millionen von echten, verifizierten Sitzungen deutlich unter einem halben Prozent. Wenn Sie nur bei der extremsten Stufe eingreifen, sinkt die Rate gegen null. Beide Zahlen werden aktuell gehalten und sind im Operator-Dashboard sichtbar, aufgegliedert nach Browserfamilie und Land, damit Sie genau sehen, woher etwaige Fehler kommen.

Wie wir messen: Wir pflegen einen gelabelten Referenzdatensatz aus echten menschlichen und bekannten automatisierten Sitzungen, der vierteljährlich aktualisiert wird. Jede Änderung am Scoring wird vor der Veröffentlichung gegen den vollständigen Datensatz gebenchmarkt.

Wenn Sie den Benchmark auf Ihrem eigenen Traffic ausführen möchten, exportiert das Operator-Dashboard Ihre Sitzungen mit ihren Risikostufen, den Gründen hinter jedem Score und Ihrem eigenen Ergebnis-Label, damit Sie Ihre eigene Rate berechnen können.

Was passiert, wenn Ihr Dienst ausfällt?

Der Collector arbeitet weiterhin. Ergebnisse werden lokal in die Warteschlange gestellt und gesendet, wenn die Verbindung wiederhergestellt ist. Wenn die Verifizierung nach Ablauf Ihres Timeouts nicht erreichbar ist, gibt Noxtica ein sicheres, neutrales Ergebnis mit einem klaren „nicht verfügbar”-Marker zurück, damit Ihr Code auf eine weichere Richtlinie zurückfallen kann – z. B. Challenge statt Block. Wir veröffentlichen ein Verfügbarkeitsziel von 99,95 % und eine öffentliche Statusseite unter status.noxtica.com. Die tatsächliche Verfügbarkeit lag zuletzt darüber.

Der „nicht verfügbar”-Marker ist das Signal für Ihren Fallback. Ein Anmeldeformular könnte eine sanfte Challenge stellen, ein Zahlungsformular könnte blockieren und eine schreibgeschützte API könnte einfach erlauben – der richtige Standard hängt von Ihrer Risikobereitschaft für diese Oberfläche ab.

Kann ich das lokal betreiben?

Ja. Collector und Verifier werden als signierte, eigenständige Images für Enterprise-Kunden ausgeliefert. Gleiches Profilformat, gleiche Signale, gleiche Risikostufen, keine Cloud-Abhängigkeit. Updates werden in Ihrem eigenen Rhythmus gezogen, und Air-Gapped-Installationen werden mit einem Offline-Update-Bundle unterstützt. Sprechen Sie uns darauf an.

On-Premises wird typischerweise von regulierten Branchen angefragt – Banking, Gesundheitswesen, Behörden –, wo Anforderungen an die Datenresidenz einen gehosteten Verifier ausschließen. Der Kompromiss ist operativer Natur: Sie pflegen den Verifier, ziehen die Updates und führen die Kalibrierungs-Benchmarks durch. Wir liefern die Software und das Runbook; Ihr Team betreibt sie.

Wie gehen Sie mit eingebetteten Widgets und Frames um?

Der Collector erkennt, wenn er in einem eingebetteten Frame läuft, und passt an, was er misst – einige Signale funktionieren weiterhin, aber mit weniger Detail. Wir geben den eingebetteten Kontext als ehrliches Signal aus, nie als automatisches Risiko. Was jedoch relevant ist: wenn der eingebettete Frame und die Hauptseite sich widersprechen, denn das ist ein bekanntes Automatisierungsindiz. Sie entscheiden, was eingebettete Frames für Ihre App bedeuten.

Legitime eingebettete Nutzung ist verbreitet – Checkout-Widgets, Drittanbieter-Tools, Content-Vorschauen – und Frames als automatisches Risiko zu behandeln würde echte Kunden blockieren. Der Widerspruch ist das Signal, das zählt: Ein echter eingebetteter Frame erbt einen konsistenten Zustand von seinem Parent, während ein automatisierungsgesteuerter das oft nicht tut.

Was sendet der Collector über das Netzwerk?

Wenn die Seite bewertet wird: ein versiegeltes Ergebnis, ein paar Kilobyte, gesendet an Ihren eigenen Endpunkt. Wenn Ihr Server es verifiziert: nur dieses Ergebnis. Keine zusätzliche Telemetrie, keine Analytics-Beacons, keine Fonts von anderswo, keine Drittanbieter-Aufrufe irgendwo im Pfad. Das versiegelte Ergebnis ist die einzige Nutzlast – und Sie können es lokal öffnen, um genau zu sehen, was drin ist.

Sie können das alles im Netzwerk-Panel Ihres Browsers während der Integration bestätigen. Die einzige Anfrage, die der Collector stellt, geht an Ihren eigenen Same-Origin-Endpunkt. Während der Erfassung geht nichts vom Browser an Noxtica; die Verifizierung erfolgt später, Server-zu-Server, von Ihrem Backend aus.

Kann ich die Risikoschwellen anpassen?

Ja. Die Standardwerte sind bewusst konservativ (siehe Prinzip 03). Sie können anpassen, ab wann jede Stufe ausgelöst wird, pro Schlüssel, in der Operator-Konsole. Die Anpassung erfolgt auf Schwellenebene, nicht an den Modell-Internals – wir möchten nicht, dass einzelne Kunden das Modell so verändern, dass es vom Kalibrierungs-Benchmark abweicht.

Wenn Sie eine tiefere Anpassung benötigen, ist das ein Enterprise-Gespräch. Wir unterstützen es für On-Premises-Deployments, wo der Benchmark erneut gegen Ihren eigenen Traffic ausgeführt werden kann.

Was ist der Unterschied zwischen Noxtica und einem CAPTCHA?

Ein CAPTCHA bittet den Nutzer zu beweisen, dass er ein Mensch ist. Noxtica bittet den Browser zu beschreiben, was er ist, und wägt diese Beschreibung dann gegen die breitere Population ab. Beides ergänzt sich, keines ersetzt das andere.

Viele Integrationen nutzen Noxtica, um zu entscheiden, ob überhaupt ein CAPTCHA angezeigt werden soll. Eine verdächtige Sitzung bekommt die Challenge; eine saubere nicht. Diese Kombination entfernt das CAPTCHA für die überwiegende Mehrheit echter Nutzer, die es nie zu sehen bekommen.

Weiterführende Lektüre

• Erste Schritte – die Integrationsanleitung.
• Browser-Laufzeit – was der Collector zum Erfassungszeitpunkt tut.
• Backend-Integration – wie die Verifizierung auf Ihrem Server funktioniert.
• Bedrohungskategorien – was wir erkennen und warum.