Seatext library / BotRefund evidence

How to Build a Reliable Detection System for Spoofed Browser Profiles

A reliable detection system combines WebGL texture constants, canvas fingerprinting, JavaScript capability checks, and behavioral analytics into a real-time score. No single signal is decisive; accuracy comes from cross-referencing 100-plus independent checks and weighting...

Built for advertisers who need clear, refund-ready traffic evidence.

Start by collecting a broad set of browser and device signals — WebGL renderer details, canvas hash, audio context, font enumeration, and navigator properties — then layer behavioral telemetry such as mouse curvature, click timing, scroll patterns, and form interaction speed. Feed every signal into a scoring engine that looks for internal contradictions (e.g., a claimed desktop GPU reporting mobile WebGL constants) and weights the overall pattern rather than thresholding any single check. BotRefund uses 106 independent checks and an AI model that evaluates the complete picture to reach 99% accuracy.

What a spoofed browser profile looks like

Spoofed profiles claim a device identity — Chrome on Windows, Safari on iPhone — but the underlying hardware, graphics stack, or runtime behavior does not match. A headless Chrome instance may report a desktop user-agent while its WebGL renderer string reveals a software rasterizer. An anti-detect browser can fake the user-agent and screen resolution but often fails to replicate the exact texture limits, extension behavior, or timing quirks of the real browser engine. The mismatch between declared identity and observed capabilities is the detection surface.

Core fingerprinting signals to collect

Gather signals that are hard to forge consistently across the full stack:

  • WebGL texture constants: Maximum texture size, max vertex attributes, supported compressed formats. A real GPU reports values that align with its driver; a spoofed profile often returns generic or mismatched limits.
  • Canvas fingerprint: Draw a standardized shape with text, gradients, and shadows; hash the resulting pixel buffer. Subtle rendering differences across GPUs and drivers create a stable identifier.
  • AudioContext fingerprint: Generate an oscillator, apply a dynamics compressor, and sample the output. Hardware audio pipelines produce distinctive noise floors.
  • Font enumeration: Measure fallback widths for a list of common and rare font families. The set of installed fonts correlates with OS and user customization.
  • Navigator and screen properties: navigator.hardwareConcurrency, deviceMemory, screen.colorDepth, window.devicePixelRatio. These should agree with the claimed device class.
  • Browser capability APIs: Presence and behavior of WebGL2RenderingContext, OffscreenCanvas, WebCodecs, WebGPU, permissions API, and feature-policy headers.

BotRefund's WebGL Texture Constraint check is one of 106 independent checks that looks for a mismatch a real browsing session does not normally create.

Behavioral signals that reveal automation

Fingerprinting tells you what the browser claims to be; behavior tells you how it acts. Collect these telemetry streams client-side:

  • Pointer movement: Human motion includes micro-tremor, curved paths, and variable velocity. Robotic linear movements or grid-aligned paths are strong automation indicators.
  • Click timing and sequence: Ghost clicks (clicks without preceding human intent), superhuman input speed (<1 ms), and missing focus/hover precursors signal scripted interaction.
  • Scroll and engagement: Sessions with no scrolling, no field corrections, uniform click paths, or dwell times that are too short, too long, or too uniform.
  • Form interaction: Copy-paste or autofill at sub-millisecond intervals, fields populated without mouse movement or screen scrolls.
  • Honeypot triggers: Interactions with hidden or deceptive page elements that real users never see.

These behavioral categories — click behavior, pointer behavior, motion behavior, speed behavior, path behavior, engagement behavior, and session behavior — are the same signals BotRefund surfaces in its detection dashboard.

Cross-checking signals for consistency

A single anomaly is not a verdict. Privacy tools, corporate proxies, virtual machines, and unusual hardware can produce unexpected values for genuine users. Build a consistency graph where each signal votes on the claimed identity:

  1. Group signals by domain: graphics (WebGL, canvas), audio, fonts, navigator, behavior.
  2. Define expected value ranges for each device class (desktop Windows, macOS, iOS, Android, etc.).
  3. Flag intra-group contradictions: e.g., navigator.platform says Win32 but WebGL renderer says "Apple GPU".
  4. Flag inter-group contradictions: behavioral patterns (instant form fill) that contradict a claimed human session.
  5. Weight each signal by reliability and independence. Signals derived from the same underlying API (e.g., two WebGL parameters) should not count as fully independent.

BotRefund keeps each signal as evidence — not a verdict — and cross-checks it against independent browser, network, device, and behavior data before its AI model weighs the complete pattern.

Building a real-time scoring engine

Turn the consistency graph into a single score per session:

  1. Normalize each signal to a 0–1 anomaly score (0 = fully consistent, 1 = strong contradiction).
  2. Apply weights derived from labeled data or expert priors. Start with equal weights; refine as you collect ground truth.
  3. Aggregate with a weighted sum or a lightweight model (logistic regression, gradient-boosted trees). Avoid deep models until you have thousands of labeled sessions.
  4. Calibrate thresholds for your risk tolerance: block, challenge (CAPTCHA, MFA), review, or allow.
  5. Log every signal and the final score for audit trails and model retraining.

The engine must run in under 50 ms per request to avoid adding latency. Pre-compute device-class baselines offline; evaluate only the delta at request time.

Common mistakes that weaken detection

MistakeWhy it hurtsFix
Relying on a single fingerprint (e.g., user-agent or canvas hash)Easy to spoof; high false-positive rate on legitimate privacy toolsRequire concordance across ≥3 independent signal groups
Treating every anomaly as maliciousVPNs, corporate proxies, VMs, and accessibility tools create legitimate outliersKeep signals as evidence; decide on the aggregate pattern
Ignoring behavioral telemetrySophisticated spoofers pass static fingerprint checks but fail on motion/timingCollect pointer, scroll, and interaction timing from page load
Hard-coding thresholds without calibrationTraffic mix shifts; yesterday's threshold becomes today's false-positive floodRe-calibrate weekly using confirmed human/bot labels
No audit trail for disputed decisionsCannot defend refund requests or improve the modelStore raw signals, scores, and decision rationale per session

Verification checklist before launch

  • Signal coverage: At least 3 independent fingerprint groups (graphics, audio, fonts, navigator, capabilities) plus behavioral telemetry.
  • Baseline data: Collected ≥10,000 confirmed human sessions per target device class to define expected ranges.
  • Adversarial testing: Ran the detector against headless Chrome, Puppeteer Stealth, Playwright, and at least one anti-detect browser; measured bypass rate.
  • False-positive audit: Reviewed 200 flagged sessions manually; confirmed <5% false-positive rate on genuine traffic (VPN, corporate, accessibility).
  • Latency budget: End-to-end detection adds <50 ms at p95; client-side collection <200 ms.
  • Audit logging: Every decision stores raw signals, normalized scores, weights, final score, and action taken.
  • Retraining loop: Labeled data pipeline feeds new ground truth into weight calibration at least monthly.

Limitations and when this approach falls short

  • Residential proxy botnets: Real devices, real browsers, real fingerprints — only the intent is automated. Behavioral analytics helps but cannot guarantee detection.
  • Human-in-the-loop fraud: Click farms with real people solving CAPTCHAs and filling forms. Fingerprint and behavior appear human.
  • Zero-day browser exploits: A compromised legitimate browser reports authentic signals while executing attacker commands.
  • Privacy-preserving browsers: Brave, Tor, and hardened Firefox intentionally randomize or suppress fingerprinting surfaces, increasing false positives unless explicitly allow-listed.
  • Client-side evasion: Sophisticated attackers can hook JavaScript APIs and return crafted values. Server-side correlation (TLS fingerprint, IP reputation, request sequencing) is a necessary second layer.

Key terminology

Fingerprinting
Collecting browser and device attributes that are stable across sessions but vary across devices.
Spoofed profile
A browser configuration that claims one device identity while running on different hardware/software.
Headless browser
A browser without a GUI, typically controlled programmatically (Puppeteer, Playwright, Selenium).
Anti-detect browser
A modified browser build designed to randomize or forge fingerprinting surfaces (e.g., Multilogin, GoLogin).
Behavioral telemetry
Runtime interaction data: mouse moves, clicks, scrolls, keystrokes, timing.
Consistency graph
A model of expected relationships between signals; contradictions raise anomaly scores.
Residential proxy
Traffic routed through consumer ISP IPs (often compromised IoT devices) to appear as genuine residential users.

Key facts from BotRefund's detection architecture

ComponentDetailSource
Independent checks106 signals combined into a single AI evaluationS1
WebGL Texture ConstraintDetects GPU/hardware mismatches that a real session does not createS1
Behavioral signal categoriesClick, pointer, motion, speed, path, engagement, sessionS2
Ghost click detectionCatches clicks without natural human intent sequenceS2
Honeypot trap interactionsWatches for bots responding to hidden page elementsS2
Robotic linear mouse movementsFlags unnaturally straight pointer pathsS2
Absence of humanlike mouse tremorLooks for micro-imperfections typical of human movementS2
Superhuman input speedIdentifies interactions faster than a person can perform (<1 ms)S2
Grid-aligned movement patternsDetects movement snapping to precise lines instead of natural curvesS2
Unnatural session durationsCatches visits too short, too long, or too uniform to be humanS2
AI model accuracy99% by evaluating complete pattern across browser, network, device, behaviorS1
Bot automation methodsHeadless browsers, CAPTCHA solving centers, spoofed data pools, residential proxiesS5
Fake lead signalsSuperhuman input speeds, lack of pointer movement, disposable email patternsS5

FAQ

How many signals do I need before the system is useful?

Start with 15–20 well-chosen signals across at least three independent groups (graphics, navigator, behavior). BotRefund runs 106 checks, but a minimal viable detector needs breadth more than depth. Add signals incrementally as you measure their marginal contribution to AUC.

Can I build this entirely client-side?

Client-side collection is necessary for behavioral telemetry and canvas/WebGL fingerprints, but the scoring engine should run server-side. Client-side scores can be tampered with; send raw signals to your backend for evaluation.

What about users with privacy tools that block fingerprinting?

Treat missing or randomized signals as a distinct "privacy mode" bucket. Do not auto-block. Instead, require a higher behavioral confidence threshold or step-up challenge (CAPTCHA, email verification) for that bucket. BotRefund keeps each signal as evidence, not a verdict, precisely for this reason.

How often should I retrain or recalibrate?

At minimum, monthly. Adversaries adapt quickly; new browser versions shift baseline distributions. Automate a pipeline that ingests confirmed human/bot labels (from chargebacks, manual review, honeypot conversions) and re-fits weights weekly.

Is WebGL fingerprinting still reliable in 2024?

Yes, but less so than in 2020. WebGPU adoption, browser privacy budgets, and GPU virtualization in cloud environments increase variance. Use WebGL as one signal among many; do not gate on it alone.

What is the typical false-positive rate for a well-tuned system?

Target <2% on genuine traffic after allow-listing known privacy tools and corporate proxies. BotRefund's 99% accuracy claim reflects the full AI model on production traffic; a custom build should validate against its own traffic mix before claiming similar numbers.

Do I need to collect GCLID/FBCLID for detection?

Not for detection itself, but for refund disputes. BotRefund logs click IDs (GCLID/FBCLID) automatically to generate audit-ready refund dispute reports for Google and Meta. If you plan to pursue invalid-click refunds, integrate click-ID capture from day one.

Further reading and comparison sources

These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.

Learn more

Visit the website for more information.

Learn more