GeoComply / Bally Bet NJ: remote screen control via Tailscale blocked at login and mid-session ✓
Source. June 2, 2026 weekly sync.
Ticket. CIV-82: Bally Bet NJ — Remote screen control blocked (GeoComply).
What we tested
The remote-screen-control fraud pattern: one person physically in the permitted state (New Jersey) hands full control of their screen to someone in an entirely different location, who places all the bets. The person in-state does nothing themselves.
Stack used:
- macOS Native Screen Sharing — Apple's built-in remote-desktop feature, driving Mac #1 from Mac #2.
- Tailscale — a networking tool that puts both Macs on the same private network over the internet, so Screen Sharing works as if they were side by side.
Operator: Bally Bet NJ, a GeoComply-integrated deployment.
What happened
- ✓ Blocked at login. The attempt was stopped before any wager,
with the error
Blocked_software. - ✓ Blocked mid-session. Detection also fired during an active session — not only at startup — so a session that began clean could not be handed off to a remote controller later.
Why it matters
This is a clean, real-time win on the exact vector that three competitor integrations missed in the same test cycle. Regulators require operators to prevent geolocation fraud; catching remote screen control in real time — at login and mid-session — reduces operator liability and is a concrete, demonstrable compliance advantage for the GeoComply value proposition. The attack used entirely off-the-shelf, legal tools, which is exactly what makes the competitor gaps below material.
Cross-reference
- Radar / Underdog DFS — same Tailscale remote-control method undetected for 20+ minutes (CIV-81).
- OpenBet / Fanatics — Mac-to-Android remote control undetected, bets placed (CIV-79).
- Bet365 NJ (XPoint) — macOS↔macOS RDP via Tailscale + Screen Sharing undetected (May 26, CIV-73) — the finding that prompted this expanded testing campaign.