Every login attempt is a synthetic event with a real (lat, lon), device id, and outcome (success/fail) for one simulated account, scored with the same weighted formula the 3D globe uses:
v = haversine(prevLoc, loc) / Δt_hours [km/h]
velocityScore = (v − 120) / 8 (fixed: no longer capped at 100 — see below)
deviceScore = 30 if device is new for this account else 0
failScore = min(60, 15 × consecutiveFailedAttempts)
timeScore = 10 if local hour ∈ [2,5) else 0
risk = clamp(0, 100, 0.5·velocityScore + 0.25·deviceScore
+ 0.2·failScore + 0.05·timeScore)
Bug found and fixed here (not in the 3D source): the 3D sim additionally clamps velocityScore itself to 100 before weighting it. Because it is weighted at 0.5, that inner clamp caps velocity's own contribution to the composite risk at exactly 50 out of 100 — no matter how impossible the implied speed is. That silently contradicts the sim's own claim that "impossible travel alone can push risk above threshold": at the default 70 threshold (and anywhere above 50), a login from New York to Tokyo in nine minutes (implied velocity ≈ 72,000 km/h) can never trigger an auto-lock by itself in the 3D version, even though it is the textbook impossible-travel signal. Verified numerically with a standalone script: haversine(New York, Tokyo) ≈ 10,851 km, at Δt = 0.15 h that is a velocity of ≈72,342 km/h, giving velocityScore = (72342−120)/8 ≈ 9,028 uncapped vs. exactly 100 under the 3D sim's inner clamp — a 50-point ceiling either way once weighted at 0.5, unless the cap is removed. This 2D sibling removes only that redundant inner clamp (the outer clamp(0,100, …) on the final composite score is untouched and still the only clamp needed), so a sufficiently extreme impossible-travel event can legitimately dominate the score and cross the threshold on its own, matching the documented intent.
- Impossible travel — two logins geographically far apart in too little time imply a physically impossible speed (faster than a commercial flight, ~900 km/h); with the fix above, an extreme case can now cross the auto-lock threshold by itself.
- Credential stuffing — a burst of failed attempts before a success (often from many IPs testing leaked password lists) drives up
failScore even when the final login's location looks unremarkable.
- Auto-lock — when composite risk crosses the threshold slider, the account is flagged and the event marker turns red; this mirrors how platforms silently step up to MFA or freeze the session rather than blocking outright.
This is a simplified version of the velocity-check / impossible-travel heuristics used by real identity-protection systems (e.g. risk-based authentication in enterprise IAM and social-platform trust & safety pipelines) — never an attack tool, only the defensive scoring side.