33 posts tagged with "radar"

Source. June 23, 2026 weekly sync.
Ticket. CIV-91: Wind Creek Bethlehem PA — environment compliance updates.

What we tested​

Full integration testing of Wind Creek Casino Online PA (Radar) across iOS, Android, and browser. Results delivered June 19.

What happened​

Test	Result	Detail
RDP — iOS FaceTime & iPhone Mirroring	✗ Non-compliant	Not detected. User outside PA (TN) remotely controls an in-state iPhone and places bets. In-state user must log in first; remote user controls the screen from there.
RDP — Android DroidVNC + Tailscale	✗ Non-compliant	Not detected. Remote user in an excluded state places bets on a PA Android device using DroidVNC and Tailscale together.
VPN — Android (Turbo VPN)	✗ Non-compliant	Not detected on Android. User logged in, placed bets, and played casino with VPN active.
VPN — iOS	✓ Compliant	VPN detected at login and mid-session.
RDP — Android (TeamViewer, AnyDesk, HopToDesk)	✓ Compliant	Detected at login or interval check.
Fake location — Android (FLA)	✓ Compliant	Detected before and during a gaming session.
Cross-border into exclusion state	✓ Compliant	User fails geolocation at or just past the border (~90 m buffer).
Rooted Android + mocked location	⚠️ Compliant*	User fails for mock location / jurisdiction errors. Root itself not detected, but mocked location is caught. With GPS JoyStick the failure took longer — suggesting IP mismatch or low confidence score rather than direct root detection.

UX issues — new user flow & deposit​

Operator-side friction observed during the same test cycle (not Radar detection failures, but worth tracking):

• Android Galaxy S16 deposit loop: debit card deposit failed and sent the user into a loop — account flagged for Wind Creek approval with no timeline and no clear prompt. User attempted 3 times before abandoning.
• ID verification false positive: notification asked user to close any app using the camera (triggered by screen recording). User bypassed by restarting the app — screen recording continued undetected.
• No autofill for address, phone, or email on either platform.
• Deposit methods limited to PayPal, Venmo, and debit card only.

Why it matters​

Three undetected vectors on the same Radar deployment while the "standard toolkit" checks pass — native iOS screen sharing, Android DroidVNC + Tailscale, and Android VPN. The compliant iOS VPN handling directly contrasts with the undetected iOS RDP gap.

Cross-reference​

• BetRivers PA (XPoint) — advanced spoofing review (June 23, CIV-88) — parallel Pennsylvania operator testing.
• Underdog DFS (Radar) — Tailscale undetected (June 2, CIV-81).

Radar profile → · June 23 weekly sync →

Source. June 23, 2026 weekly sync — Competitive Research (Valeria).

What's new​

Radar released a new Web version 5.0.0 and 5.1.0 with a structural change to how fraud signals are delivered:

• Fraud detection moved to a separate, easy-to-use JS module — clients can now opt in and opt out of individual fraud signals rather than taking an all-or-nothing bundle.
• New signal classes called out: emulator detection, screen sharing detection, and an IP check hardcoded to every 30 seconds.

Why it matters​

The modular JS architecture makes it easier for operators to toggle fraud checks — which cuts both ways: faster iteration for Radar, but also a configuration surface where gaming integrations might ship with screen-sharing or emulator checks disabled unless we validate each deployment.

The 30-second IP polling is a concrete cadence we can test against — especially relevant given undetected iOS screen-sharing gaps on Radar deployments this same cycle (Wind Creek PA, CIV-91).

Watch point​

Confirm whether any live gaming integrations have upgraded to Web 5.x and which fraud modules are enabled by default vs opt-in.

Radar profile → · June 23 weekly sync →

Source. June 2, 2026 weekly sync.
Ticket. CIV-81: Underdog DFS — Remote screen control via Tailscale (Radar).

What we tested​

The same remote-screen-control pattern that GeoComply blocked on Bally Bet NJ this week: a tool lets one person take full control of another person's computer screen from a completely different location. The person physically in the permitted state does nothing — the remote user places all the bets. Here the target was Underdog DFS, running on Radar.

Stack: a Tailscale tunnel linking the two machines, driven through built-in screen-sharing.

What happened​

• ✗ The session lasted over 20 minutes with active remote control in use.
• ✗ Radar did not detect or block it. Bets could be placed freely throughout.

Why it matters​

This is a clear fraud and compliance gap. A user outside a licensed state can bet through a "proxy" device inside the state, with no exotic configuration — the attack uses off-the-shelf, legal tools. Operators running this integration carry regulatory exposure if the method is used by real fraudsters.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale undetected (May 26, CIV-73) — the origin finding that prompted this expanded campaign.
• OpenBet / Fanatics — Mac-to-Android remote control undetected (CIV-79) — same gap, third integration.
• GeoComply / Bally Bet NJ — the same Tailscale remote-control attack blocked at login and mid-session ✓ (CIV-82) — direct contrast on the identical vector.

Radar profile → · June 2 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-63: Bet365 MI — full Radar / XPoint integration research.

What we tested​

A full integration validation of Bet365 Michigan — Radar for the mobile app, XPoint for the web client. Covered: near-border behaviour, cross-state jurisdiction handling, two RDP attack paths (iOS, Windows), and post-failure UX.

What happened​

Area	Result	Notes
Near Canadian border (Belle Isle)	✗ Inconsistent at 200–1,000 m from the border. Betting slip continued to load but functioned unreliably — suggests an insufficient buffer zone.
Detroit ↔ Canada cross-border	✗ An erroneous jurisdiction alert fired on the betting slip, incorrectly telling the user wagering is restricted to New Jersey residents while on Bet365 MI.
iOS FaceTime RDP	✗ Undetected. A tester in Massachusetts placed bets remotely on a device located in Michigan with no issues.
Windows RDP	✗ Undetected. A tester in Massachusetts placed wagers on both the sportsbook and casino via a Windows device located in Michigan.
UX — post-VPN-detection recovery	✗ Persistent application glitches after a VPN-detection event. Tester unable to resume wagering; forced restart of the app required to restore functionality.

Why it matters​

This validation lands five separate issues on a single operator in a single test cycle:

1. Two compliance failures on the same border — buffer-zone unreliability + a flatly wrong jurisdiction message. Either could be cited as a regulator-facing defect.
2. Two undetected RDP paths — iOS (FaceTime) and Windows — both spanning multi-state remote sessions. RDP is the textbook remote-betting fraud vector and both paths went uncaught.
3. The UX recovery loop is broken even when detection does fire. A user who triggers a VPN block cannot recover without restarting the app, and receives no guidance on how to do so.

Cross-reference​

• Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale + Screen Sharing undetected (May 26) — third undetected RDP path on Bet365 in two weeks (NJ and MI, two geo providers).
• Bet365 NJ (Radar) — Tailscale + RealVNC RDP undetected for 25+ minutes (May 19).
• Bet365 MI (Radar) — GPS simulator bypass, restriction not re-applied on re-entry (May 19) — distinct prior gap on the same operator.

Radar profile → · Xpoint profile → · May 26 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-61: iOS spoofing testing with PlayCover tool.

What we tested​

PlayCover lets iPhone / iPad apps be installed and run directly on a Mac, bypassing the intended mobile environment entirely. When a user runs a betting app this way, the "location" can be manipulated without the app realising it is not running on a phone.

The tester ran the FanDuel iOS app under PlayCover on macOS and attempted to wager on FanDuel West Virginia (Radar geolocation).

What happened​

• ✗ Login succeeded. Radar did not flag the non-standard environment.
• ✗ Real-money bet completed. No location or environment check prevented the wager.
• ✗ Advanced variant of the technique produced the same result — the bypass is not dependent on a single configuration of the tool.

Why it matters​

This is a structural compliance gap on FanDuel WV: the operator is trusting an iOS environment that isn't actually iOS, and Radar isn't flagging the host platform. Anyone with a Mac and PlayCover can self-onboard to a wagering session that the integration believes is on a phone.

Cross-reference​

• PlayCover blocked at Bet365 MI (Radar) + Fanatics TN (OpenBet) — confirmed last week. Radar handles PlayCover at Bet365 MI but not at FanDuel WV — the gap is operator-integration shaped, not vendor-wide.
• PlayCover bypass on FanDuel WV — previously seen on May 11, 2026. Two consecutive cycles confirm this is repeatable, not a one-off.

Radar profile → · May 26 weekly sync →

Source. May 26, 2026 weekly sync.
Ticket. CIV-75: Saracen AR — Radar Verify app retest, full competitor validation.

What we tested​

Retest, since May 19, 2026, of how Radar behaves on Bet Saracen Arkansas when the Remote Desktop Connection (RDC) client is merely present on the Windows host — i.e. installed but not actively driving a remote session.

Setup:

• Windows 10, with RDC pre-installed, later upgraded in-place to Windows 11.
• No active remote-desktop session at the time of testing.

What happened​

• ✗ Presence of RDC is no longer enough to block the app. This contradicts the April 19 finding, which had previously recorded pre-installed RDC as sufficient grounds for Radar to refuse access.
• ✗ The system does block access whenever the app is launched, even with no remote session running in the background.
• ✗ Block fires with no explanatory error. Users see no recovery guidance — they cannot wager and they cannot tell why.

Why it matters​

Two distinct issues stacked on one another:

1. Detection regression. The April 19 baseline (presence of RDC blocks the app) no longer holds — a measurable loosening of Radar's posture between cycles. Worth confirming whether this is intentional or a regression.
2. UX-as-compliance failure. Even when the block fires, it does so silently. A legitimate user with RDC installed on their PC (a common configuration in any IT-managed environment) is permanently locked out with no signal as to what is wrong. This is significant UX friction and a customer-support amplifier.

Cross-reference​

• Bet Saracen AR (Radar) — resigned iOS app placed bets from MI (May 19) — distinct prior compliance gap at the same operator.
• Bet Saracen AR (Radar) — Oxylabs + Location Guard combination blocked (May 19).

Radar profile → · May 26 weekly sync →

Source. May 19, 2026 weekly sync.
Tickets. CIV-48 · CIV-61: iOS — spoofing testing with PlayCover tool.

What we tested​

Desktop-based emulation of iOS apps via PlayCover on ARM-based macOS, attempted against two operators in two jurisdictions:

Operator	Geo provider	Result
Bet365 MI	Radar (mobile) / XPoint (web)	✓ Blocked at login stage
Fanatics TN	OpenBet Locator	✓ Blocked at login stage

What happened​

No geolocation bypass possible. Both platforms neutralised the PlayCover environment before any compliance check ran — the apps refused to authenticate at all when running under PlayCover.

Why it matters​

PlayCover is the most credible iOS-on-Mac sideloading tool. Two different geo vendors blocking it on two different operators in the same test cycle is a clean "compliant tier" signal — and consistent with the cross-operator PlayCover block we recorded on May 11.

The standing outlier remains FanDuel WV (Radar), where PlayCover bypassed the platform on May 11. PlayCover is therefore a vendor-handled vector when the operator integration is fully wired up, and an operator-integration gap when it isn't.

Cross-reference​

• Cross-operator PlayCover blocked (May 11) — Bet365 MI + Fanatics TN + Bet Saracen AR.
• FanDuel WV PlayCover bypass (May 11) — outlier on the same vector.

Radar profile → · OpenBet profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-48: Test Fake Location using GPS Simulator Accessory on Competitor Apps.

What we tested​

A hardware GPS simulator accessory was used to spoof the tester's physical location while connecting to Bet365 Michigan (Radar deployment) from Tennessee.

What happened​

• First login attempt — an error was returned (location restriction triggered).
• Second login attempt — succeeded with no further location checks enforced. The tester opened a casino game and placed real-money bets from Tennessee.
• The restriction that appeared on the first login was not re-applied on re-entry — the bypass is repeatable.

Why it matters​

This is a structural detection failure, not a one-off bug: the GPS simulator was identified once, then the operator's session state effectively whitelisted the device. Anyone who has triggered a restriction once can simply log out and back in to bypass it.

Combined with the Bet365 NJ Tailscale RDP gap confirmed in the same week, Bet365's Radar integration is producing two distinct, easily-reproducible spoof methods across two different states.

Cross-reference​

• GPS simulator at FanDuel WV (Radar) — previously bypassed from Vietnam (March 24, 2026). The GPS-simulator gap is not new and not WV-specific.
• PlayCover at Bet365 MI — blocked the same week. Bet365 catches the iOS-on-Mac vector but misses the hardware-GPS vector.
• GPS simulator at Fanatics TN (OpenBet) — detected with a clear, specific error message. OpenBet handles this vector; Radar does not.

Radar profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-69: Bet365 NJ — RDP Testing on Android.

What we tested​

Remote desktop access against the Bet365 New Jersey Radar deployment, using:

• Tailscale (mesh VPN) to bring the controlling Mac and the controlled Android device onto the same overlay network despite being on physically separate networks.
• RealVNC to drive the Android device from the Mac.

The tester then placed real-money bets through the remote session.

What happened​

• 25+ minutes of continuous, real-money betting through the remote session.
• Zero interruptions, timeouts, or restrictions.
• Radar's geolocation checks did not detect the remote session at any point — neither at session start, nor at any of the periodic re-checks during the session.

Why it matters​

Tailscale + RealVNC is a credible, easily-assembled remote-access setup. The fact that it went completely undetected for 25 minutes suggests Radar's RDP signal detection at Bet365 NJ either does not exist for this combination, or does not run frequently enough to matter.

Combined with the Bet365 MI GPS-simulator bypass on the same week, this is the second confirmed spoof method against a Bet365 / Radar deployment in a single test cycle.

Cross-reference — RDP across providers this week​

Operator	Provider	Tool	Result
Bet365 NJ	Radar	Tailscale + RealVNC	✗ Undetected (this finding)
RSI BetRivers NJ	XPoint	Tailscale	✗ Inconsistent
DraftKings DFS NJ	Radar	Zoom / AnyDesk / TeamViewer	✗ Inconsistent
Fanatics TN	OpenBet	TeamViewer	✗ Undetected
Fanatics TN	OpenBet	FaceTime	✓ Blocked
Fanatics NJ	OpenBet	droidVNC-NG	✓ Blocked and named

Radar leads the failure list this week with two distinct RDP bypasses on two distinct operators.

Radar profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-65: DraftKings DFS — validate the competitor's integration.
Migration context. DraftKings DFS NJ migrated from GeoComply to Radar (May 11).

What we tested​

A full integration validation of DraftKings' New Jersey web DFS product following its confirmed migration from GeoComply to Radar. The Sportsbook and the mobile apps (iOS / Android) remain on GeoComply. Compliance and security testing focused on the gaps from running two providers in parallel.

What happened​

1. RDP detection: inconsistent​

Tool	May 8 baseline	May 13 retest	May 14 retest
TeamViewer	✓ Blocked	✗ Undetected	✗ Undetected
Zoom	✗ Undetected	✗ Undetected	✗ Undetected
AnyDesk	✗ Undetected	✗ Undetected	✗ Undetected

TeamViewer's flip from blocked-to-undetected across consecutive retests is the headline — detection is unreliable rather than absent.

2. Cross-border session lag: ~100–150m past the PA→NJ line​

After physically crossing from Pennsylvania into New Jersey with an active session, bet placement remained blocked for approximately 100–150 metres past the state border — significantly wider than GeoComply's 2–5m range.

Users entering NJ without a prior PA session were unaffected, pointing to a session-state issue on the provider side rather than a geofence-geometry issue. The session carries the prior-state restriction across the line instead of cleanly re-evaluating.

3. UX: generic error messaging​

Both RDP-triggered blocks and cross-border blocks surface the same "Account Locked" message with no diagnostic data or guidance on next steps. Players cannot self-correct; operators take the support load.

Why it matters​

DraftKings DFS NJ is Radar's first major US live-traffic win on a Tier-1 operator (confirmed May 11). This validation is the first post-migration look at how the integration is performing in production. Findings:

1. The dual-vendor concern was real. DFS-web is on Radar; the rest of DraftKings stays on GeoComply. Cross-product UX is divergent, and the DFS-web side is the weaker integration.
2. The RDP gap is the new sales pivot. Zoom + AnyDesk consistently undetected on a regulated US DFS product is the cleanest possible "Radar is not ready for Tier-1" example.
3. The 100–150m post-border lag is a category miss. GeoComply measures in single-digit metres on the same line.
4. Generic Account-Locked is operator pain. Sales conversations should bring this up alongside compliance: every false-positive block is a support ticket DraftKings owns.

Cross-reference​

• DraftKings DFS NJ migration confirmation (May 11) — the underlying provider transition.
• Bet365 NJ (Radar) Tailscale + RealVNC undetected this week — same provider, same state, comparable RDP gap.
• Bet Saracen AR (Radar) resigned iOS bypass this week — three live Radar deployments (Bet365 NJ, DraftKings DFS NJ, Bet Saracen AR), three independent failure modes, one test cycle.

Radar profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-44.

What we tested​

A combination attack against Bet Saracen Arkansas (Radar):

• Oxylabs residential proxy — egress IP pointing to a residential address in Little Rock, AR.
• Location Guard browser extension — Chrome extension reporting a spoofed Little Rock, AR location to the Geolocation API.

Both layers were aligned to the same in-state Arkansas location, to test whether browser-level spoofing on top of network-level spoofing would defeat Radar's checks.

What happened​

Detected as out-of-state. The platform returned a STATE_NOT_ALLOWED error and refused the wager — despite both the IP and the browser's reported geolocation pointing to a permitted in-state address.

Why it matters​

This is a genuine Radar positive — worth recording for parity. The existence of a residential-proxy signal beyond just the egress IP, or of a corroborating signal (Wi-Fi BSSID, traceroute, accelerometer, something) that survives a Location-Guard override, is meaningful.

However, this finding does not rewrite the Radar weaknesses column:

• The Location Guard extension alone bypassed Underdog DFS on April 28 — so a Chrome extension on its own is still a known gap.
• Proxy betting is otherwise allowed at Radar — the system has historically asked the user to "wait additional time" if another login was seen from a different location (March 31).

The May 19 positive at Bet Saracen is therefore best read as "Radar can stack a state-line check on top of network spoofing in this particular operator integration" rather than "Radar handles proxies + browser extensions in general."

Cross-reference​

• Radar / Bet Saracen AR: resigned iOS bypassed this week — same operator, application-level vector slipped past.
• Radar / Underdog DFS: Chrome extension bypass (April 28) — same Location Guard tool, different result.

Radar profile → · May 19 weekly sync →

Source. May 19, 2026 weekly sync.
Ticket. CIV-44: Saracen Arkansas — Radar: verify the wagering experience for static connection closer to the border.

What we tested​

A resigned Bet Saracen iOS app — re-signed with a developer certificate to remove Apple's app integrity / attestation protections — installed on a device in Michigan and used to attempt real-money betting against the Bet Saracen AR (Radar) deployment.

The same player account was also tested on the unmodified App Store build, as a control.

What happened​

• Resigned app: bets placed from Michigan with no issues. No geolocation challenge, no error message, no session interruption.
• Unmodified app: correctly blocked on the same account, from the same location. The control behaved as expected.

This isolates the gap to the tampered build — Radar's checks at Bet Saracen do not detect that the iOS app has been resigned.

Why it matters​

This is a direct fraud + compliance risk. With a freely-available resigning workflow, a bad actor can:

1. Re-sign the Saracen iOS app once.
2. Distribute or use the modified build from any state.
3. Place real-money bets that bypass Radar's location enforcement.

This finding contradicts the May 11 result where resigned iOS at Bet Saracen + Fanatics was reportedly blocked — the gap may have evolved, the prior detection may have been build-specific, or the integrity check may be running inconsistently. Either way, the May 19 result is the current, verified state.

Cross-reference​

• Radar / FanDuel WV: resigned iOS bypassed from Tennessee — same vector, second operator.
• Radar / Bet Saracen AR: Oxylabs proxy + Location Guard combo blocked this week — Radar handles network-level spoofing at this operator while missing application-level integrity tampering.

Radar profile → · May 19 weekly sync →

Source. May 11, 2026 weekly sync — "Unsuccessful Spoofing Methods" section.

What we tested​

PlayCover-based sideloading of iOS apps onto ARM-based macOS, attempted against three operators in three jurisdictions:

Operator	Geo provider	Result
Bet365 MI	Xpoint (web)	✓ Neutralized at authentication
Fanatics TN	OpenBet Locator	✓ Neutralized at authentication
Bet Saracen AR	Radar	✓ Identified at the betting stage

What happened​

No successful exploitations across the three tested jurisdictions. All three platforms have robust defense against this hardware- abstraction method.

Why it matters​

PlayCover is the most credible iOS-on-Mac sideload tool. Three different geo vendors blocking it on three different operators is a clean "compliant tier" signal — worth recording as parity context against the FD WV PlayCover bypass on the same day, which is the outlier.

FD WV PlayCover bypass (failure) → · May 11 weekly sync →

What happened. DraftKings has moved its web DFS product in New Jersey from GeoComply to Radar.

What stayed. The DraftKings Sportsbook and the DraftKings mobile apps remain on GeoComply. This is a partial-displacement, not a wholesale loss.

Open question being tested. Whether running two different geolocation providers side by side introduces compliance or security gaps — internal ticket CIV-65: DraftKings DFS - validate the competitor's integration.

Why it matters. This is Radar's first major US live-traffic win on a Tier-1 operator. The sales narrative is two-sided:

• Concerning: DK's procurement team has now signed off on Radar for a regulated US product. Other operators may treat this as permission.
• Constructive: The pattern "challenger gets the DFS web slice, GeoComply keeps everything else" is the new template for second-source attempts. Lead with "we keep the high-stakes stuff" in displacement conversations.

Counter-evidence. Radar's compliance gaps across other operators (rooted-hidden Android, resigned iOS, GPS simulator, jailbroken iOS at Sleeper/PrizePicks/Fliff, Chrome extension at Underdog) are independent of this migration and should be in every DK-adjacent conversation.

Radar profile →

Source. May 11, 2026 weekly sync.
Test evidence (internal Drive): PlayCover videos · FD WV: Spoofing Tests

What we tested​

Three distinct exploitation methods against the FanDuel WV (Radar) deployment, from Tennessee:

1. iOS app resigning — re-signed FanDuel iOS app with security controls bypassed.
2. Virtualised environment emulation via VMOS — Android device-farm environment running a cloned profile.
3. Sideloading via PlayCover on ARM-based macOS — iOS app loaded on Apple Silicon Mac via PlayCover.

What happened​

All three succeeded. Each technique facilitated out-of-state betting on the WV app. Critical and persistent failure to prevent unauthorized access or potential multi-accounting activities.

Cross-reference — same vectors, different results elsewhere​

• iOS app resigning was detected at Bet Saracen AR on April 7 — see Radar / Saracen AR: resigned iOS app detected. The gap is FD-WV-specific or build-specific.
• PlayCover was detected at Bet365 MI, Fanatics TN, and Bet Saracen AR on the same day — see cross-operator PlayCover blocked. FD WV is the outlier.
• VMOS is also undetected at Bet Saracen AR — see Bet Saracen AR: VMOS not detected. The Android device-farm gap is wider than just FD WV.

Radar profile → · May 11 weekly sync →

Source. May 11, 2026 weekly sync. Test video: BetSaracen VMOS Test.mov (internal Drive).

What we tested​

Three spoof vectors against Bet Saracen AR (Radar): VMOS Android device-farm, PlayCover sideloading on ARM-based macOS, resigned iOS app.

What happened​

• VMOS (Android) — NOT detected. Out-of-state bet placed from Tennessee.
• PlayCover (ARM macOS) — detected and restricted ✓
• Resigned iOS app — detected and blocked ✓

Why it matters​

The mixed result confirms Radar's posture is per-vector-uneven: catches the ARM-macOS hardware-abstraction vector and resigned iOS app integrity, but the Android VMOS device-farm slips through. This is also the second operator (after FanDuel WV) where the same VMOS gap shows up — a structural Android detector issue.

Radar profile → · FD WV three-method bypass → · May 11 weekly sync →

Source. May 5, 2026 weekly sync (monthly brief) — Radar Browser-Based Solution / Saracen AR section. Full recording: BetSaracenFullTestingSession.mov (21 min, internal Drive).

What we tested​

Distance-graded validation runs against Bet Saracen AR (Radar browser-based deployment) from inside the regulated jurisdiction, on Mac + Windows desktops.

What happened​

• 350m+ from the state line — success rates remained high. ✓
• 100m mark — Mac devices cleared only 44% of verifications.
• Windows users — hit a persistent lockout after a single failure, further complicated by an atypical fraud_jumped_single_device flag during betting attempts.

Why it matters​

100m is a city-block distance — well inside the state. A 44% pass rate at that range is direct booked-bet revenue loss for the operator. The Windows persistent-lockout behaviour is worse: a single retry triggers an account-level block with no clear self-service recovery path. Support ticket volume scales linearly.

The fraud_jumped_single_device flag is interesting — it suggests Radar's device-fingerprint logic is misidentifying repeat verification attempts as suspicious device-jumping behaviour. Pair with the Underdog DFS device-counting bug (every login = new device) — same architectural class of problem.

Radar profile → · Underdog device-counting bug → · May 5 weekly sync →

What we tested. Bet Saracen Arkansas, Radar browser-based deployment. Driven sessions via AnyDesk and TeamViewer.

What happened. Radar effectively restricted both active sessions — wagering outside permitted borders was prevented during tool operation.

Why it matters. This is one of the few positive Radar results we have. Sales conversations should be honest: AnyDesk + TeamViewer are detected at Saracen AR. The narrative is "Radar catches the obvious ones but misses the adjacent ones."

Cross-reference (same test cycle, less positive).

• Pre-loaded Windows "Remote Screen Sharing" triggered account restriction silently — false-positive RDP flag, high support-ticket risk.
• Cross-Boundary Validation passed: attempts to wager from Oklahoma uniformly blocked across all test cases.
• 350m+ from border: high success rates. 100m: Mac 44% pass rate; Windows users hit persistent lockout after a single failure with atypical fraud_jumped_single_device flag.

Action. Add HopToDesk, iPhone screen mirroring, RustDesk, VNC, MS Teams remote-control to the Radar test scope per the May 11 Betting Hero plan — these are the adjacent tools that distinguish "catches the obvious" from "is a compliance product."

Radar profile →

Source. May 5, 2026 weekly sync.

The finding​

The pre-loaded Windows Remote Desktop Connection app (labelled "Remote Screen Sharing" in the OS) triggers Radar account restrictions without notifying the user.

Why it matters​

This is a false-positive RDP flag: the app is present on virtually every Windows install, and is not running an active remote session. Triggering account restrictions silently from its mere presence is the worst case for support teams — the user has no idea what failed, no suggested resolution path, and no diagnostic message.

Cross-reference (same test cycle)​

On the same operator + same week, AnyDesk and TeamViewer were correctly restricted during active sessions (positive result). So the detector posture is: detects two real RDP tools, false-positives on one pre-installed Windows app it shouldn't flag. The RDP class is where Radar is most inconsistent.

Radar profile → · May 5 weekly sync →

What we tested. Underdog DFS, browser-based Radar geolocation deployment. Installed the free Location Guard Chrome extension and reported a spoofed location.

What happened. Undetected. Radar did not flag the browser-extension spoofing.

Adjacent gaps from the same test (April 28 weekly).

• Device-counting logic flaw — every login at Underdog is recorded as a new device, regardless of whether the device has been seen before. Inflates device counts and prevents multi-account detection — significantly weakening fraud detection.
• Border crossing — testing confirmed users can continue placing wagers for approximately 1 minute after entering a restricted zone before Radar intervenes. Regulatory compliance risk.
• Increased geolocation frequency + buffer-zone false positives — no single-license support; more frequent checks; unnecessary failures.
• Loss of meaningful error messaging — generic error messages for all geolocation failures post-GeoComply switch; ability to self-troubleshoot eliminated; support contact volume likely up.

Why it matters. A free Chrome extension that anyone can install defeating Radar's regulated-DFS deployment is the entry-level sophistication. The device-counting flaw makes multi-accounting effectively free. Bundle these into the Underdog talking points.

Radar profile →