תרגום זה נוצר אוטומטית וממתין לסקירה. עבור לאנגלית
לוח בקרה

Frequently Asked Questions

Real questions from real integrations. If yours isn’t here, the contact page gets a real reply from someone who knows the product.

Does this work with Tor?

Yes. Traffic from Tor exit points starts at a moderate risk level — it’s a known anonymizing route — but we still read the full picture of the session. If your application explicitly welcomes Tor users, such as journalism, sensitive search, or abuse-survivor flows, you can tell Noxtica to stop counting the Tor signal toward the score while keeping every other signal active. The signal stays visible in the result either way. You decide whether it counts.

For the full reasoning on why Tor users aren’t auto-blocked, see Privacy-browser handling in the threat-categories doc.

What about privacy-focused browsers — Brave, LibreWolf, Tor?

All work. Each privacy browser has a distinctive shape we recognize from our population data. Tracking-prevention features don’t break verification; they just produce a different, still-consistent profile. We treat the protection level as an honest signal rather than quietly penalizing the user for choosing it.

This is principle 03 (false positives are not acceptable losses) in practice. Blocking a Brave user costs you a customer who specifically chose a privacy browser. The trade isn’t worth it, and the calibration reflects that.

How much does it add to my page?

Very little. The first load is tiny because the heavy measurements only kick in when the page actually asks for a score. Everything loads in the background and never delays your page from becoming usable. Returning visitors send an even smaller signal. In practice, the user never notices it’s there.

Do we need to run a backend?

Yes. The collector runs in the browser and produces a sealed result; the actual verification happens on your server through our API. Because the full picture travels inside that sealed result, verifying it is fast — there’s no fresh data-gathering and no extra network lookups while a request is in flight. The result is checked in a few milliseconds.

The reason the backend is necessary: a verdict made purely in the browser is trivially faked. The sealed result is the guarantee that nothing was tampered with after collection, and verifying that guarantee in your own trusted backend is what makes the whole system trustworthy.

Are you compliant with privacy regulation?

We act as a sub-processor under your data processing agreement, and we have our own available on request. We treat the data we handle as personal data, because it could re-identify a returning visitor, and apply the full set of controls that implies. Infrastructure stays in the EU with no transfers outside it. Hard-delete is available on request through the backoffice, and we can sign agreements within a day. Our subprocessor list lives at /subprocessors.

A few specifics that data-protection officers ask about:

  • Lawful basis: we recommend a legitimate-interest basis for fraud prevention for most integrations. Consent flows are also supported.
  • Data minimization: what we store is a scrambled, one-way summary, not raw values. We can’t reconstruct the original signals from it.
  • Right to erasure: deletion is enforced at the storage layer, not as a soft flag. Once deleted, the data is gone for good.
  • Subject access requests: we provide a way to return everything associated with a given visitor, scoped to your account.

What’s your false-positive rate?

It depends on where you set your threshold. With our conservative defaults, our internal benchmark against millions of real, verified sessions measures well under half a percent. Reserve action for only the most extreme tier and the rate drops near zero. Both numbers are kept current and visible in the operator dashboard, broken down by browser family and country so you can see exactly where any misses come from.

How we measure it: we maintain a labeled reference set of real human sessions and known automated sessions, refreshed every quarter. Every change to the scoring is benchmarked against the full set before it ships.

If you want to run the benchmark on your own traffic, the operator dashboard exports your sessions with their risk levels, the reasons behind each score, and your own outcome label so you can compute your own rate.

What happens if your service is down?

The collector keeps working. Results are queued locally and sent when the connection returns. If verification is unreachable past your timeout, Noxtica returns a safe, neutral result with a clear “unavailable” marker, so your code can fall back to a softer policy — challenge instead of block, for example. We publish a 99.95% availability target and a public status page at status.noxtica.com. Recent uptime has run higher than that.

The “unavailable” marker is the cue for your fallback. A signup form might soft-challenge, a payment form might block, and a read-only API might simply allow — the right default depends on your risk tolerance for that surface.

Can I run this on-prem?

Yes. The collector and verifier ship as signed, self-contained images for Enterprise customers. Same profile format, same signals, same risk tiers, no cloud dependency. You pull updates on your own schedule, and air-gapped installs are supported with an offline update bundle. Talk to us about it.

On-prem is usually requested by regulated industries — banking, healthcare, government — where data-residency rules rule out a hosted verifier. The trade-off is operational: you maintain the verifier, pull the updates, and run the calibration benchmarks. We provide the software and the runbook; your team operates it.

How do you handle embedded widgets and frames?

The collector detects when it’s running inside an embedded frame and adjusts what it measures — some signals still work, just with less detail. We surface the embedded context as an honest signal, never as automatic risk. What does matter is when the embedded frame and the main page contradict each other, because that’s a well-known automation tell. You decide what embedded frames mean for your app.

Legitimate embedded use is common — checkout widgets, third-party tools, content previews — and treating frames as automatic risk would block real customers. The contradiction is the signal that matters: a genuine embedded frame inherits a consistent state from its parent, while an automation-driven one often doesn’t.

What does the collector send over the network?

When the page is scored: one sealed result, a few kilobytes, sent to your own endpoint. When your server verifies it: just that result. No extra telemetry, no analytics beacons, no fonts pulled from elsewhere, no third-party calls anywhere in the path. The sealed result is the only payload — and you can open it locally to see exactly what’s inside.

You can confirm all of this in your browser’s network panel during integration. The only request the collector makes is to your own same-origin endpoint. Nothing goes to Noxtica from the browser during collection; verification happens later, server-to-server, from your backend.

Can I customize the risk thresholds?

Yes. The defaults are conservative on purpose (see principle 03). You can adjust where each tier triggers, per key, in the operator console. The tuning is at the threshold level rather than the internals of the model — we don’t want individual customers reshaping the model in ways that drift away from the calibration benchmark.

If you need deeper tuning, that’s an Enterprise conversation. We support it for on-prem deployments, where the benchmark can be re-run against your own traffic.

What’s the difference between Noxtica and a CAPTCHA?

A CAPTCHA asks the user to prove they’re human. Noxtica asks the browser to describe what it is, then weighs that description against the wider population. The two are complementary, not substitutes.

Many integrations use Noxtica to decide whether to show a CAPTCHA at all. A suspicious session gets the challenge; a clean one doesn’t. That combination removes the CAPTCHA from the vast majority of real users, who never see it.