33 posts tagged with "radar"

What's new. Radar SDK iOS + Android v3.31.0 released April 24, 2026. The notable feature: when Radar's backend is unreachable, the SDK generates geofence entry/exit events directly on the device from cached data, tagged as offline.

It's a backend-toggled feature (Radar's backend enables it per integration), so we don't yet know whether it will be enabled for gaming markets. Tracking intensity also adjusts automatically based on geofence context — even mid-outage.

Why it matters. This is a meaningful step in Radar's strategic direction documented in the Apr 14 weekly: shifting from "where is the user?" to "can we continuously trust this location?" The 3-week-to-2-month release cadence is producing functionality that's interesting in retail / non- gaming contexts but unproven in regulated contexts.

Watch point. We need to validate whether offline-generated geofence events satisfy regulatory requirements (the regulator typically expects a server-side decision and full audit trail per transaction). If Radar enables offline events on a gaming integration, this is a finding worth escalating.

GitHub monitoring. As of Apr 14, we are subscribed to both XPoint and Radar GitHub repos to track new releases, SDK changes, and any publicly visible technical updates going forward.

Radar profile →

Source. April 14, 2026 weekly sync — Installation, Network, and Software Compatibility sections.

The findings​

• Mobile Hotspot Incompatibility — geolocation verification is unstable when connected via mobile hotspots on Mac + Windows; prevents legitimate wagering.
• Installation Workflow — access denial during web installation triggers persistent download prompts, regardless of whether the software is already on the system.
• Auto-Launch — Radar initiates automatically on system startup (Mac + Windows) without consent. Intrusive UX, support load.
• Desktop CPU — location checks trigger 4% CPU spikes every 10s at 600m from the border. Consistent resource drain — and the closer you get to the border, the more frequent the checks.
• Software Compatibility — inconsistent Radar performance across macOS Tahoe 26.0.1 vs 26.3.1 and Chrome 146 vs 147. Point releases break the integration.

Why it matters​

Three of these (auto-launch, install prompts, hotspot incompat) generate support tickets. The CPU pulses are not catastrophic but become noticeable on poker tables. The macOS / Chrome version sensitivity is the most concerning — Radar's desktop integration is fragile across the exact version range that most US users sit on.

For BetSaracen players this stacks on top of the existing generic "account security" error messaging (no diagnostic data, high self-troubleshoot friction).

Radar profile → · April 14 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 →

Source. April 14, 2026 weekly research sync.
Coverage window. April 2025 → April 2026 (full Radar SDK changelog).

Cadence​

Radar ships every 3 weeks to a couple of months. We are now subscribed to both XPoint and Radar GitHub repositories to track new releases, SDK changes, and any publicly visible technical updates going forward.

Strategic direction​

Clear shift from "where is the user?" to "can we continuously trust this location?" — via four axes:

1. IP-triggered re-validation — location re-checked on network / IP change.
2. Multi-signal decisioning — motion, device context, network alongside GPS.
3. Indoor / vertical accuracy — floor-level detection on mobile plus BLE beacons.
4. Modular fraud architecture — plugin-based, allows rapid new detection logic.

Why it matters​

This is the architectural pitch Radar is making to non-gaming customers (retail, mobility) — and the same plumbing is what lets them say "we're adding compliance signals quickly." Worth watching whether the v3.31.0 offline geolocation events (April 24) are enabled on any gaming integration — that would be a notable regulator-attention moment.

Radar profile → · April 14 weekly sync → · v3.31.0 offline events →

What we confirmed. Bet365's geolocation stack is split — XPoint on the web, Radar on mobile.

Why it matters. Bet365 is XPoint's flagship US reference, often quoted in displacement conversations. Confirming that even Bet365 needed a co-provider on the most important surface (mobile = the bulk of session volume) reframes the displacement narrative. The pitch becomes "Bet365 needed two challengers to do the job GeoComply does with one."

Adjacent signal. Bet365 (XPoint web) social signal continued through April: wrong-state detection (MD placed in NJ), endless XPoint Verify install loop, app freeze + bet slip erasure, delete-and-reinstall every session, 1-star reviews. Bet365 (Radar) Android also accumulated 1-star reviews ("location verification is trash", "Stuck on trying to find the location, very bad app, likely a scam").

Spoof posture, same operator. Reddit user publicly asked how to spoof XPoint Verify from Florida. Two users offered help via Magisk. Worth a dedicated Magisk + XPoint Verify investigation.

Xpoint profile → · Radar profile →

Source. April 7, 2026 weekly sync — Field Testing section.

What we tested. Jailbroken iOS device with root hiding enabled. Attempted to wager from a prohibited location on three operators in sequence: Sleeper Sports, PrizePicks, Fliff.

What happened. All three allowed the wager through. Radar did not detect the jailbroken / root-hidden state on any of the three.

Why it matters. This is a structural Radar SDK gap that surfaces at every operator, not an operator-specific bug. The same compliance hole appears in three different deployments (DFS, sweepstakes, social gaming) within a single week of testing.

Radar profile → · April 7 weekly sync →

Source. April 7, 2026 weekly sync.

What we tested. Re-signed iOS app on Bet Saracen Arkansas.

What happened. Radar successfully detected the resigned app and displayed appropriate error messaging — betting activity was prevented, and the account was not auto-blocked. Clean result.

Cross-reference. Contradicts the FD WV result from March 31, where the same attack class went undetected and bets were placed from TN. Two operators, two different outcomes for the same exploitation method — points to inconsistent / operator-specific detector behaviour in Radar's SDK. Follow-up validation scheduled pending the next iOS app release.

Radar profile → · March 31 FD WV failure → · April 7 weekly sync →

Source. April 7, 2026 weekly sync.

What we tested. Repeat of the March 31 VMOS Android device-farm test on FanDuel WV.

What happened. VMOS usage was not detected this time. The tester placed bets from Tennessee on the West Virginia app.

Why it matters. Two consecutive weeks, opposite results on the same vector + operator combination. Either:

• Radar's device-farm detector has regressed between the two Android build releases the tests targeted, or
• The detector is flaky / instrumentation-sensitive — which is worse, because operators can't rely on what'll happen on any given session.

Cross-reference: VMOS also went undetected at Bet Saracen AR on May 11. The pattern is "VMOS Android catches some sessions, misses others" — not a stable detection posture.

Radar profile → · March 31 positive result → · April 7 weekly sync →

Source. March 31, 2026 weekly sync.

What we observed. Radar is allowing proxy betting and just asks the user to wait some additional time if someone else used the account in another location.

Why it matters. Two problems here:

1. Reactive, not preventive. A proxy-routed session gets through; the only consequence is a delay before the next session.
2. Misleading error messaging. Subsequent enforcement provides "account sharing" messaging instead of clear regulatory restrictions — which risks encouraging illegal workarounds like proxy usage (the user thinks they got flagged for sharing, not for masking location).

Combined with the FanDuel WV state-selector vulnerability (TN user initially verified on the WV platform — reactive rather than proactive validation), this is the same architectural problem expressed two ways: Radar's compliance posture is reactive.

Radar profile → · March 31 weekly sync →

What we tested. Re-signed iOS FanDuel app, modified to bypass security controls. Tester located in Tennessee, targeting the FanDuel WV platform.

What happened. The modified build successfully placed bets from out-of-state. Radar failed to detect the modification.

Cross-reference. Contradicts the Apr 7 result at Bet Saracen AR, where Radar DID detect a re-signed iOS app with appropriate error messaging. Re-signed iOS detection is inconsistent across operators — fix one, the other still fails.

Why it matters. App-resigning is a well-known attack class. A regulator audit that includes a tampered-app test will not accept an inconsistent result.

Radar profile →

Source. March 31, 2026 weekly sync — Field Testing section.

What we tested. VMOS (virtual Android OS) device-farm scenario on the FanDuel WV Android app (Radar-instrumented). Spun up a virtualised device profile and attempted to wager.

What happened. Radar successfully identified the virtual OS environment used to manipulate device integrity. Detection fired.

Why it matters. This is a genuine positive Radar result — worth recording for parity. The sales narrative is honest: Radar catches some device-farm attacks but not all of them. Cross-reference the April 7 weekly: on the second attempt, VMOS was not detected, allowing bets from TN on the WV app — pointing to either a regression or a flaky/instrumentation-sensitive detector. Follow-up validation is scheduled pending the next Android app release.

Radar profile → · March 31 weekly sync → · April 7 weekly sync (regression) →

What we tested. FanDuel West Virginia, Radar-instrumented mobile app, real device with a hardware GPS-simulator attached. Tester's actual location was Vietnam.

What happened. Radar accepted the spoofed coordinates and allowed geolocation verification to succeed. A hardware GPS simulator should be the most obvious off-the-shelf attack and is exactly what the regulator expects a compliance product to catch.

Why it matters. This is the entry-level attack class. If a hardware GPS simulator clears Radar in a regulated US sportsbook deployment, every sophistication-tier attack we've subsequently tested has an obvious predecessor.

Radar profile → · Test matrix →

Source. March 24, 2026 weekly sync — Field Testing section.
Internal reference. CIV-20: Saracen Arkansas – Radar: conduct full competitor validation

What we tested.

1. Installed Radar Verify on a Windows laptop and on a Mac, attempted to start a betting session via Chrome on both.
2. Attempted bet placement from within ~1 km of the Arkansas state line, on a Windows laptop tethered to a mobile hotspot.

What happened.

• Radar Verify does not work in Chrome — confirmed on both Windows and Mac.
• No successful bet could be placed within 1 km of the AR border. Radar bounced between "State not Allowed" and "Buffer Zone" errors as the tester moved.

Why it matters. Chrome is the most common desktop browser in the US. Combined with the near-border accuracy gap (no bet within 1 km), this is a double UX + compliance failure on Radar's flagship regulated-sportsbook reference (BetSaracen).

Radar profile → · March 24 weekly sync →