Dark
Request a walkthrough
On this page
Developer overview

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.

Key points

  1. The assessment layerBrowser Intelligence turns characteristics available during a browser session, together with supported edge context, into a site-scoped result.
  2. No single signal decidesNo single characteristic decides the outcome. The product returns a combined assessment.
  3. A context, not a personA fingerprint identifies an assessed browser/device context, not a legal person, account owner, or guaranteed physical device.
  4. Evidence can be reducedBrowser settings, privacy protections, blocked scripts, content-security policy, network failure, or unsupported capabilities can reduce available evidence.
  5. Action is separateBrowser Security describes how a customer can act on the result.
  1. When it applies
  2. How customers use it
  3. How Noxtica does it
  4. Outputs and decisions
  5. Supported limitations
  6. Where it fits
  7. Read deeper
How this page is organisedBar length shows each section’s share of the text. Select a section to jump to it.

  1. Your page

    Browser session

    Collection runs in the browser runtime.

  2. Noxtica

    Combined assessment

    Several public categories of evidence. No single characteristic decides the outcome.

  3. Returned to you

    Site-scoped result

    Identifier, score and risk level, confidence, flags, and cache and error state.

  4. Your policy

    Route-specific action

    Apply policy in your code, or use separately provisioned controls where available.

From a browser session to your decision

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.

Rendering context

What it looks at

Consistency in browser-exposed canvas, WebGL, audio, and related media behavior.

How it is used

Combined with the other categories into one assessment. No single characteristic decides the outcome.

Environment context

What it looks at

Browser-exposed fonts, platform details, and available device characteristics.

How it is used

Combined with the other categories into one assessment. No single characteristic decides the outcome.

Consistency context

What it looks at

Whether the browser's claimed properties agree with its observed behavior.

How it is used

Combined with the other categories into one assessment. No single characteristic decides the outcome.

Network context

What it looks at

Supported attributes such as country, network type, and datacenter classification derived during service processing.

How it is used

Combined with the other categories into one assessment. No single characteristic decides the outcome.

Four evidence categories, one combined assessment

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