3 posts tagged with "ux"

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-52: Ontario — mkodo / GeoLocs — Compliance Failures & Retest (Casumo, High Flyer, OLG).

What we tested​

Two VPN scenarios against the OLG (Ontario Lottery and Gaming) web app, geolocated by GeoLocs / mkodo:

1. Ontario-based VPN — exit-node inside the licensed jurisdiction.
2. Netherlands-based VPN — out-of-jurisdiction exit node.

In both cases device location services were left active so the system had a real GPS signal alongside the VPN IP.

What happened​

• ✗ Ontario-based VPN was authorised when location services remained active. Unrestricted gameplay and wagering were permitted — the VPN itself was not flagged.
• ✗ Netherlands-based VPN did not trigger any immediate session termination. The user was able to keep playing.
• ✗ Detection only fired on re-entry — when the user exited a game and tried to come back in, the system finally prohibited access.
• ✗ No explanatory error notification was shown to the user at the point of block. Silent failure on a compliance event.

Why it matters​

Two distinct failure modes in one test:

1. VPN-tolerance when device GPS agrees. A VPN with an in-state exit-node is fine, even though VPN-detection is a normal column of any modern compliance stack. Anyone wanting to obscure their network identity inside Ontario faces no friction.
2. Late, silent block on out-of-state VPN. The system does eventually detect the Netherlands VPN, but only at a session boundary — and tells the user nothing. From the user's perspective the platform "just stopped working."

This combines into a UX-and-compliance double failure: the wrong thing is allowed, the right thing is detected too late, and the user is never told what happened.

Cross-reference​

• High Flyer Casino TN (GeoLocs / mkodo) — iOS + Android spoofing bypass (May 26) — same vendor, second operator failure in the same week.
• OLG iOS (GeoLocs / mkodo) — location services off → session terminated (May 26) — positive counterpart.

GeoLocs 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 →