Den här översättningen är maskingenererad och väntar på granskning.Byt till engelska
Mörkt
InstrumentpanelKontakta oss
På den här sidan

Browser Intelligence

Definition. Browser Intelligence is the collection and assessment layer. It turns characteristics available during a browser session, together with supported edge context, into a site-scoped result. It is the intelligence half of the browser workflow; Browser Security describes how a customer can act on that result.

The problem it solves is ambiguity at high-volume digital entry points. A user-agent string or IP address alone cannot explain whether a session is consistent, automated, unusual, or simply privacy-conscious. Browser Intelligence combines multiple categories of evidence and returns a result your team can review.

When it applies

Use Browser Intelligence where a browser session affects fraud or abuse exposure, including signup, login, account recovery, promotion use, checkout, content access, and other customer-defined routes. Start in observe-only application logic where the cost of customer friction is high.

This concept covers browser traffic. Native mobile attestation has separate integration and eligibility requirements and is not implied by installing the browser collector.

How customers use it

  1. Request access and obtain the Site Key for the intended environment.
  2. Add the collector using Automatic Collection, or call checkOnce() when your application needs explicit timing.
  3. Listen for the collection result or read the returned object.
  4. Store the fingerprintId with the relevant session or account only when your design requires continuity.
  5. Use the Server API or operator console to review current device and risk context.
  6. Apply route-specific policy in your code, or use separately provisioned controls where available.

The SDK also reports cache state and errors so the application can distinguish a fresh assessment, a reused result, and an unavailable assessment.

How Noxtica does it

Collection runs in the browser runtime and considers several public categories of evidence:

  • Rendering context — consistency in browser-exposed canvas, WebGL, audio, and related media behavior.
  • Environment context — browser-exposed fonts, platform details, and available device characteristics.
  • Consistency context — whether the browser’s claimed properties agree with its observed behavior.
  • Network context — supported attributes such as country, network type, and datacenter classification derived during service processing.

No single characteristic decides the outcome. The product returns a combined assessment. The protected runtime is intended to make manipulation and replay harder, but it is not a guarantee that client-side code cannot be inspected or attacked.

The browser assessment does not ask for a person’s name or email as an input. A device identifier is still operational data that customers should handle under their own retention, access, consent, and legal-basis requirements.

Outputs and decisions

OutputWhat it tells youUseful decision
fingerprintIdA site-scoped handle for the assessed browser/device contextLink permitted observations across your own workflow
score and risk_levelThe assessed level of riskChoose allow, observe, review, or step-up policy for the route
confidenceHow much weight to place on the assessmentDefer a strong action when evidence is limited
flags and summary detailsWhich categories contributed to the resultExplain or investigate why the score changed
cache and error stateWhether the result was reused or could not be refreshedUse a documented fallback instead of treating absence as safety

Supported limitations

  • Browser settings, privacy protections, blocked scripts, content-security policy, network failure, or unsupported capabilities can reduce available evidence.
  • A fingerprint identifies an assessed browser/device context, not a legal person, account owner, or guaranteed physical device.
  • Cached results trade reassessment frequency for lower client work; choose the collection interval for your risk window.
  • Collection modes and available fields follow the current SDK and tenant configuration.
  • Client-side output should not replace server-side authentication, authorization, or transaction controls.

Where it fits

Browser Intelligence feeds Know Your Device, which explains identifier and risk outputs. It pairs with Browser Security, which covers customer-owned actions. Together they let teams observe first, choose thresholds, and introduce friction only where policy requires it.

Read deeper