Seatext library / BotRefund evidence
Can a Single CPU Concurrency Anomaly Be a False Positive?
Yes, a single CPU concurrency anomaly is often a false positive. Legitimate factors like privacy tools, corporate networks, virtual machines, or unusual hardware can create mismatches that look suspicious but come from real users....
✓ Built for advertisers who need clear, refund-ready traffic evidence.
Yes, a single anomaly in CPU concurrency can be a false positive. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people. BotRefund keeps this signal as evidence—not a verdict—and cross-checks it against independent browser, network, device, and behavior data.
What Is CPU Concurrency Anomaly Detection?
CPU concurrency refers to the number of threads or processes the browser can run simultaneously, often reported via JavaScript APIs. The CPU Concurrency Lie check looks for a mismatch that a real browsing session does not normally create. Virtual machines and spoofed profiles can claim one device while their graphics, fonts, audio, or processor behavior tells another story.
In a normal browser, hardware, graphics, fonts, and operating-system details naturally fit together for that device. When those details conflict, the check flags it. This is one of 106 independent checks BotRefund uses to build a reliable picture of whether a visit is human or automated.
Why a Single Anomaly Can Be a False Positive
Real users often trigger this check without any automation. A developer testing in a virtual machine, a remote worker on a corporate VDI, someone using a privacy-focused browser that spoofs hardware fingerprints, or a traveler on an unfamiliar device can all produce a CPU concurrency mismatch. These are legitimate sessions that happen to look inconsistent to a single heuristic.
Additionally, measurement errors can occur. JavaScript execution timing, CPU throttling on mobile devices, or browser extensions that alter APIs can cause false anomalies. Maintenance activities like system updates or antivirus scans can also affect concurrency reports. A single anomaly, therefore, is not a bot verdict.
How BotRefund Validates Anomalies
BotRefund uses a three-step process to avoid false positives:
- Independent evidence — This signal adds one objective fact about the visit.
- Cross-checked context — BotRefund tests whether other signals support the same story.
- AI prediction — The model weighs the complete pattern instead of trusting a raw rule.
Accuracy comes from corroboration, not one browser tell. The prediction AI evaluates the complete picture across browser, network, device, and behavior evidence. By seeing how all signals fit together, it identifies a visit as bot or human with 99% accuracy.
Common Legitimate Causes of CPU Concurrency Mismatches
- Virtual machines or containerized browsers used for development or testing
- Corporate virtual desktop infrastructure (VDI) environments
- Privacy browsers or extensions that randomize hardware fingerprints
- Unusual hardware configurations (e.g., external GPUs, ARM-based laptops)
- Remote desktop or screen-sharing sessions
- Browser automation tools used for legitimate QA or accessibility
Each of these scenarios can produce a concurrency value that does not match the claimed device profile. For example, a VM might report a different processor core count than the host, causing a mismatch. Such mismatches are common in enterprise environments.
How to Verify If a Single Anomaly Is a False Positive
When you see a CPU concurrency flag, you should not block immediately. Instead, follow a verification process:
- Check the complete signal list — Look at all 106 checks for the session. If most pass, the anomaly is likely innocent.
- Review the behavioral data — Did the user interact naturally? Were there mouse movements, scrolling, and pauses?
- Look for corroborating signals — Headless browser fingerprints, superhuman input speeds, or suspicious network patterns strengthen the bot hypothesis.
- Consider user context — Is this a known corporate IP range? Is the user on a VPN or privacy tool?
- Use analytics to examine the session — Check session duration, page flow, and conversion patterns.
If other signals are clean, treat the anomaly as evidence, not a decision.
Decision Framework: When to Trust vs Investigate
| Scenario | Likely Cause | Action |
|---|---|---|
| Single anomaly, all other signals clean | Legitimate environment quirk | Monitor; do not block |
| CPU anomaly + headless browser signals | Automation likely | Challenge or block |
| CPU anomaly + residential proxy + superhuman speed | Sophisticated bot | Block and report |
| CPU anomaly + known VPN exit node | Privacy user | Allow; log for review |
Real-World Scenarios That Cause False Positives
Consider a developer using a VM to test a new feature. The VM reports a concurrency mismatch, but the session includes natural mouse movements and typed forms. Blocking this user would disrupt legitimate work.
Another example: a remote employee connects via a corporate VDI. The VDI environment may have a different CPU profile than a standard laptop. The anomaly appears, but other signals—such as regular working hours and normal click patterns—suggest humanity.
A privacy advocate uses a browser extension that spoofs hardware fingerprints. The extension alters concurrency values to avoid tracking. The user still scrolls, clicks, and reads articles normally. A single signal cannot tell this from a bot.
Common Mistakes When Interpreting Anomalies
Many teams make the mistake of treating any single anomaly as proof of bot traffic. That leads to false blocks and lost revenue. Another mistake is ignoring anomalies entirely because they are often false positives. The correct approach is to look at the whole pattern.
For example, a developer testing a site on a VM may show a CPU concurrency mismatch. If you block that IP, the developer cannot verify changes. On the other hand, a botnet using headless Chrome may also show the mismatch, but it will also show many other automated signatures.
Best Practices for Handling Edge Cases
To minimize false positives, consider these practices:
- Maintain an allowlist for known internal IPs, such as corporate offices and staging environments.
- Use BotRefund's dashboard to exclude specific subnets or user-agent patterns that frequently trigger harmless anomalies.
- Monitor anomaly rates over time to spot systematic issues, like a new browser extension used by your audience.
- Set up alerting for combinations of signals, not for single flags.
Limitations of Single-Signal Detection
Relying on one check creates two problems. First, you block real users who happen to use uncommon setups. Second, sophisticated bots learn to spoof the specific signal you watch. BotRefund avoids both by treating each of its 106 checks as independent evidence that feeds a model, not a rule. The model learns which combinations matter in your traffic, not in a lab.
Key Facts
| Fact | Detail |
|---|---|
| Check name | CPU Concurrency Lie |
| Total independent checks | 106 |
| Single-anomaly policy | Evidence, not verdict |
| Cross-check domains | Browser, network, device, behavior |
| Decision method | AI prediction model |
| Reported accuracy | 99% |
| Common false-positive triggers | VMs, VDI, privacy tools, unusual hardware |
FAQ
What exactly does the CPU Concurrency Lie check measure?
It compares the CPU concurrency value reported by the browser against the expected value for the claimed device, OS, and graphics stack. A mismatch suggests the environment is not what it claims to be.
Can a VPN cause a CPU concurrency anomaly?
A VPN alone usually does not. But a VPN combined with a privacy browser that spoofs hardware fingerprints, or a corporate VPN that routes through a virtual desktop, can trigger it.
How many signals does BotRefund need before blocking?
There is no fixed number. The AI model weighs the full pattern. A single strong signal (like superhuman input speed) may be enough; a weak signal like CPU concurrency alone is not.
Does BotRefund share the raw anomaly data with me?
Yes. The audit logs show each of the 106 checks and whether it passed, failed, or was inconclusive for every session.
Can I tune the sensitivity for this specific check?
Not directly. The model learns from your traffic. If you see repeated false positives from a known environment (like your staging VMs), you can exclude that subnet or user-agent pattern in the dashboard.
What happens if I block based on this check alone?
You will block real users. Developers, QA teams, privacy advocates, and remote workers on VDI will look like bots to this single heuristic.
How does this differ from traditional WAF rules?
WAFs typically use static rules ("if X then block"). BotRefund uses a model that learns which signal combinations predict automation in your specific traffic. The same CPU anomaly means different things on a gaming site vs a B2B SaaS dashboard.
Further reading and comparison sources
These external sources provide additional context for evaluating the topic. Their inclusion is not an endorsement.
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.