7 posts tagged with "near-border"

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 16, 2026 weekly sync.
Ticket. CIV-54: Locance (LocationSmart) — full validation.

What we tested​

Integration validation of Locance (LocationSmart) on Luxury Casino Ontario — cross-border movement between Ontario and Quebec, remote access (TeamViewer, AnyDesk, HopToDesk on desktop and Android), VPN usage across Mac / Android / iOS, and near-border location accuracy on iOS.

What happened​

Area	Result	Notes
Cross-border play (ON ↔ QC)	✗ Non-compliant	Wagering was possible for multiple kilometres across the provincial boundary in both directions with no friction.
Remote access (TeamViewer, AnyDesk, HopToDesk)	✗ Undetected	Gameplay continued with active remote control on desktop and Android solutions with little to no friction.
VPN — Mac	✓ Detected	VPN / proxy usage was identified; platform access denied.
VPN — Android	✗ Undetected	Active VPN tunneling was not blocked; user authenticated and wagered.
VPN — iOS	⚠️ Blocked, no UX	Access was denied with VPN enabled, but no error message or troubleshooting guidance was shown.
Near-border UX (iOS)	✗ Poor accuracy	~100–150 m from the border the app placed the user in Quebec despite a physical Ontario location.

Why it matters​

Locance failed on the two vectors regulators care about most on a border-adjacent Ontario deployment: jurisdictional containment (cross- border play for kilometres) and remote session control (three major RDP tools undetected). VPN handling is inconsistent across platforms — Android is fully open, iOS blocks silently — which is both a compliance gap and an operator-support problem. The near-border mis-location suggests geofence accuracy degrades exactly where enforcement should be strictest.

Cross-reference​

• Locance / Luxury Casino Ontario — remote-access block fails on retry (June 8, CIV-53) — prior retest on the same operator; retry-fragile remote block.
• Locance Ontario — KYC gap + detection rules exposed in API (June 2, CIV-53) — compliance finding on the same provider from the prior cycle.

Locance profile → · June 16 weekly sync →

Source. June 2, 2026 weekly sync.
Ticket. CIV-64: MI advanced spoofing retest.

What we tested​

During advanced spoofing retests near the Michigan–Canada border, the team tested several remote-control applications on Android against the Fanatics MI app (OpenBet), plus iOS screen sharing for comparison.

What happened​

• ✗ HopToDesk — NOT detected at installation or during an active remote session on Android. Bets were placed consistently while a remote user was in control.
• ✓ TeamViewer — detected and blocked.
• ✓ AnyDesk — detected and blocked.
• ✓ iOS FaceTime screen sharing — detected near the border.

Why it matters​

This is a known detection gap for a specific tool, not a blanket failure: the two most common remote-access apps (TeamViewer, AnyDesk) are caught, and FaceTime screen sharing is caught on iOS — but HopToDesk slips through entirely on Android. A sophisticated fraudster who identifies this specific gap can use it to circumvent geolocation checks on Fanatics in Michigan while the obvious tools stay blocked.

Cross-reference​

• XPoint / bet365 MI — RustDesk evades detection when launched after the geolocation client (CIV-64) — the desktop half of the same MI advanced-spoofing retest.
• Bet365 MI (Radar / XPoint) — full validation: iOS FaceTime + Windows RDP undetected (May 26) — direct contrast: FaceTime screen sharing is caught here on Fanatics, but went undetected on Bet365 MI.

OpenBet 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 19, 2026 weekly sync.
Ticket. CIV-59: Fanatics — OpenBet Locator | adv spoofing.

What we tested​

Close-to-border testing of the Fanatics (OpenBet Locator) deployment on iOS. The tester opened a West Virginia casino game session inside WV, then physically crossed into Virginia while keeping the session active.

What happened​

• Session maintained. The active WV casino-game session was held open consistently while the tester stood 10 meters inside the Virginia border — a state where the operator is not licensed.
• iOS only. The issue was not reproduced on Android in the same conditions.

Why it matters​

A 10m post-border allowance is meaningful in real-world geographies where homes, hotels, parking lots, and businesses sit directly on the state line. A player who lives or works on the line can sustain an active gaming session while physically on the wrong side of it. This is the exact compliance scenario near-border buffer zones exist to prevent.

The iOS/Android asymmetry suggests the regression is in the iOS-side boundary handling specifically, not in the underlying geofence geometry.

Cross-reference​

• OpenBet near-border has been a documented gap since May 5 — see Fanatics TN border-jumping + zero buffer (May 5). The May 19 finding gives us a precise, reproducible measurement (10m, iOS) to anchor that.
• Compare with the DraftKings DFS NJ post-border lag of 100–150m on Radar this week — different problem (session-state lag vs no buffer), same UX outcome (active session past the line).

OpenBet profile → · May 19 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 →

Source. April 14, 2026 weekly sync — Border Performance Limitations.

What we tested. Approach to the OK state border from inside the regulated jurisdiction at varying distances, on iOS / Android / desktop (Mac+Windows over public Wi-Fi).

What happened.

• iOS — validation unsuccessful until 100m from the state line.
• Android — validation unsuccessful until 220m from the state line.
• Desktop (static, public Wi-Fi) — verification failed at 1,750m from the border on both Mac and Windows. Success threshold undetermined.

Why it matters. Legitimate users physically inside the licensed state — but close to the border — can't bet. The mobile case (100–220m windows) maps directly to lost revenue: 100m and 220m are city-block distances, not edge cases.

The 1,750m desktop failure is more severe — the user is nowhere near the border, and the system still can't verify. That's not a buffer zone, that's a broken validation flow.

Radar profile → · April 14 weekly sync →