Für Unternehmen
Betrugs-Teams, Security-Engineers, Plattform-PMs. Die Teams, die zahlen, wenn Betrug landet — und die Teams, die zahlen, wenn echte Kund*innen abwandern.
Jeder Browser erzählt eine Geschichte. Wir entlarven die Fiktionen.
Browser-Fingerprinting, das Betrug erkennt, ohne echte Kunden fälschlich zu blockieren. Kalibrierte Risikobewertungen, kalibrierte Ergebnisse.
Drei Zielgruppen. Ein Signal.
Browser-Fingerprinting betrifft selten nur ein Team. Dasselbe Signal prägt die Ergebnisse für Unternehmen, Plattformen und die Menschen, die sie nutzen.
-
-
Für Plattformen
Marktplätze, soziale Netzwerke, mehrseitige Plattformen. Vertrauen zwischen Nutzer*innen ist wichtiger denn je; Sybil-Resistenz ist ein echter Wettbewerbsvorteil.
-
Für Menschen
Endnutzer*innen. Die zu wenig diskutierten Stakeholder. Menschen, die fälschlicherweise blockiert, herausgefordert oder zur CAPTCHA-Lösung aufgefordert werden, nur weil sie Brave benutzen.
Was es leistet.
Sechs Fähigkeiten. Jede verwurzelt in einem realen Geschäftsergebnis.
-
Risk Scoring
-
Bot-Erkennung
-
Operator-Konsole
-
Edge-First-Latenz
-
Datenschutz von Grund auf
-
Offene Integration
Vom Signal zur Entscheidung.
Vier Stufen. Der Browser sammelt, das Token trägt das Signal, der Score wird serverseitig kalibriert, und Ihr Code entscheidet.
Browser
Das SDK erfasst clientseitig 30+ Browser-Signale — Canvas, WebGL, Audio, Fonts, Hardware-Marker. Asynchron geladen, blockiert nie DOMContentLoaded.
Token
Die Signale werden in einem signierten Token (ES256) verpackt und an Ihr Backend gesendet. Das Token ist nicht replay-fähig und trägt den vollständigen Fingerabdruck.
Score
Ihr Server ruft verify() auf. Wir liefern ein 5-stufiges Risiko + Confidence + Flag-Trace zurück. Kein DNS-Lookup; p99 unter 12 ms am Edge.
Entscheidung
Ihr Code liest die Risikostufe und entscheidet. Blockieren, herausfordern, beobachten oder erlauben — Ihre Policy, unser Beleg.
→ Vollständigen Integrationsablauf in der Dokumentation lesen
Was wir messen.
Vier Signalschichten, zusammengesetzt zu einem kalibrierten Fingerprint. Jede Schicht beantwortet eine andere Frage — zusammen sind sie der Unterschied zwischen einem Urteil und einer Messung.
-
Browser-Intelligence
Ist der Browser echt?
Erfassen Sie automatisierten Traffic, maskierte Browser und synthetische Besucher in dem Moment, in dem sie ankommen — bevor sie Ihr Signup, Login oder Checkout erreichen. Echte Kund*innen passieren. Falsche nicht.
→ Erkennungskategorien -
Netzwerksignale
Ist das Netzwerk sicher?
Erkennen Sie verdächtige Herkünfte und Hochrisiko-Infrastruktur, ohne legitimen Traffic zu bestrafen. Remote-Arbeitende, VPN-Nutzer*innen und Firmennetzwerke bleiben willkommen. Großhandels-Betrugsquellen werden geflaggt.
→ Erkennungskategorien -
Hardware-Verifikation
Ist das Gerät echt?
Verifizieren Sie das echte Gerät hinter der Session — nicht nur die darauf laufende Software. Echte Nutzer*innen auf echten Geräten kommen mühelos durch. Bots auf gemeinsam genutzter Wegwerf-Infrastruktur tauchen sofort auf.
→ Erkennungskategorien -
Verhaltens-Fingerprints
Ist der Nutzer echt?
Unterscheiden Sie eine echte Person von einem Skript am Rhythmus der Interaktion mit der Seite. Menschen zögern, korrigieren sich, erkunden. Automatisierung bewegt sich mit einer verräterischen Präzision, die sie nicht verbergen kann.
→ Erkennungskategorien
Vier Signalebenen, jede beantwortet eine andere Frage. Zusammen ergeben sie den Unterschied zwischen Urteil und Messung.
Was wir erkennen.
Sechs Bedrohungskategorien. Jede darauf abgestimmt, Automatisierung, Betrug und Missbrauch zu erkennen — ohne echte Kund*innen fälschlicherweise zu challengen.
Eine Browser-Anfrage verzweigt sich in sechs Detektionskategorien, deren gewichtete Signale zu einem kalibrierten Risiko-Score kombiniert werden.
- Automatisierung & Bots Erkennen Sie automatisierten Traffic, bevor er Login, Signup oder Checkout erreicht.
- Fingerprint-Manipulation Bewusste Umgehungsversuche aufdecken, ohne ehrliche Privacy-Entscheidungen zu blockieren.
- Infrastruktur-Missbrauch Identifizieren Sie das Großhandels-Betrugssignal — ohne Remote-Arbeitende fälschlich zu treffen.
- Privacy-Browser-Handhabung Heißen Sie legitime Privacy-Nutzer*innen willkommen, während Sie die Akteure dazwischen erkennen.
- Hardware-Attestation Verifizieren Sie, dass das Gerät ist, was es vorgibt zu sein — nicht nur der Browser darauf.
- Verhaltensanomalien Erfassen Sie Sessions, die auf dem Papier menschlich aussehen, sich aber nicht wie eine Person verhalten.
Warum wir Ihnen nicht sagen 'das ist ein Bot.'
Die meisten Fingerprinting-Dienste sagen, was Sie hören wollen: Bot oder Mensch. Binär. Sauber. Falsch. Wir sagen, was das Signal tatsächlich aussagt — mit Konfidenz — und Ihr Code entscheidet.
// Wir sagen Ihnen nicht 'das ist ein Bot.'
// Wir sagen Ihnen risk: medium, confidence: 0,87.
// Sie entscheiden.
Fünf Stufen. Gegen Populationsdaten kalibriert — nicht binär, nie still.
Im Einsatz erleben.
Wo Signale zu Entscheidungen werden. Die Operator-Konsole — suchen, vergleichen, auditieren, entscheiden.
Wie Erfolg aussieht.
Echte Zahlen aus echten Integrationen. Bias zu False-Negative; Bias zu Kundenbindung.
- 47%
- mediane Chargeback-Reduktion (90 Tage)
- 0,4%
- False-Positive-Rate, Default-Konfiguration
- ~5 ms
- mediane Verify-Latenz am Edge
-
Marktplatz
Sybil-Ringe vor dem Review-Bombing erkannt — per Signal, nicht per IP.
-
Finanzdienstleistungen
Neugerät-Challenges statt Sperren. Echte Kunden spüren nichts.
-
Identitätssensible Plattformen
Magic-Link-Klicks per Fingerprint-Abgleich verifiziert. Phishing-Kits stoppen hier.
Ehrliche Signale. Prüfbare Aussagen.
Sechs Eigenschaften, die einer Prüfung standhalten. Keine Vendor-Magie — jede einzelne ist gegen die Produktoberfläche auditierbar.
-
EU-Datenresidenz
-
GDPR-ready
-
Offener SDK-Quellcode
-
Keine PII erfasst
-
p99 verify <12ms
-
Kalibriert, nicht magisch
Woran wir glauben.
Operating Constraints, die überall sichtbar werden — im SDK, in der API, in der Operator-Konsole.
-
Kalibrierung vor Urteilen
Sie besitzen die Policy. Wir liefern die Beweise.
-
Der Source ist die Dokumentation
Jeder Schwellenwert ist dokumentiert und justierbar. Keine Black Box.
-
False Positives sind keine akzeptablen Verluste
Ein blockierter Kunde kommt nie zurück. Wir handeln gezielt dagegen.
-
Datenschutz von Grund auf
Keine PII. Keine Drittanbieter-Aufrufe. Wir können nicht verkaufen, was wir nie erhoben haben.
Fragen, die Ingenieure stellen.
Echte Fragen aus echten Integrationen. Steht Ihre nicht hier, decken die Docs sie wahrscheinlich ab.
Funktioniert das mit Tor?
Tor-Exits bekommen vom IP-Signal (datacenter_asn + Known-Exit-Listen) ein Default-Risk von `medium`, der Fingerprint selbst wird aber weiterhin berechnet. Erlaubt Ihre Anwendung Tor explizit — Journalismus, sensible Suche, Missbrauchsüberlebenden-Flows — setzen Sie `tor_policy: 'allow'` im Verify-Call, um das IP-basierte Scoring zu unterdrücken, während alle anderen Signale aktiv bleiben. Das Flag bleibt so oder so in der Response; Sie entscheiden nur, ob es im Score zählt.
Was ist mit Privacy-Browsern — Brave, LibreWolf, Tor?
Alle funktionieren. Jeder hat unverwechselbare Fingerprints — Braves Farbling, LibreWolf- und Tor-Browser-Profile sind in unseren Populationsdaten bekannt. Tracking-Prevention-Features brechen die Verifikation nicht; sie liefern nur andere (weiterhin konsistente) Fingerprints. Wir flaggen das Schutzlevel als ehrliches Signal, statt die*n Nutzer*in still zu bestrafen.
Wie hoch ist Ihre False-Positive-Rate?
Hängt von der Schwelle ab, auf die Sie triggern. Mit Defaults (risk ≥ high → challenge) misst unser interner Benchmark gegen einen Ground-Truth-Set von 4,2 Mio. echten Nutzer-Sessions ~0,4 % False Positives. Bei risk = critical only fällt die FP-Rate auf ~0,07 %. Beide Zahlen werden kontinuierlich aktualisiert und im Operator-Dashboard sichtbar, aufgeschlüsselt nach Browser-Familie und Land, damit Sie sehen, woher die Fehltreffer kommen.
Müssen wir ein Backend betreiben?
Ja — das SDK sammelt im Browser und gibt einen signierten Token aus; die Verifikation passiert serverseitig via REST API. Der Token hat den vollen Fingerprint embedded und wird kryptografisch verifiziert (ES256, `kid: nox-2026-01`), daher macht `verify()` während eines Requests keine DNS-Lookups. p99-Verify-Latenz unter 5 ms, weil es ein Signatur-Check plus Cache-Lookup ist, kein Re-Collect.
GDPR / CCPA-Konformität?
Wir sind Unterauftragsverarbeiter unter Ihrem DPA, unser eigenes DPA auf Anfrage verfügbar. Wir verarbeiten Fingerprints als 'personenbezogene Daten', weil sie eine*n wiederkehrende*n Besucher*in re-identifizieren könnten — volle Artikel-28-Kontrollen gelten. Keine Drittland-Transfers; Infrastruktur EU-resident (Cloudflare EU-only Routing). Hard-Delete auf Anfrage über das Backoffice. Wir können DPAs in 24 h unterzeichnen. Unterauftragsverarbeiter-Liste unter `/subprocessors`.
Fünf weitere Fragen in der Doku — On-Prem, iFrames, Netzwerkverhalten, Schwellenabstimmung und Noxtica vs. CAPTCHA. → Alle Fragen in der Doku
Beginnen Sie noch heute, Ihre Nutzer zu schützen.
Stoppen Sie Betrug, bevor er auftritt. Halten Sie echte Kunden in Bewegung. Erhalten Sie die Kalibrierung, die zu Ihrem Traffic passt — und ein Team, das wirklich ans Telefon geht.
Was Sie erhalten
Ein Partner, keine Preisseite.
Alles, was Sie für ein selbstsicheres Release brauchen — und nichts, was Sie nicht brauchen.