Orion
By Alex Morgan, Head of Risk Engineering. Last reviewed: 2026-07-14. This article is for information only and is not legal advice.
A driver crosses a city line at dusk. The app flips from “deliver” to “no-go.” On the map, the blue dot sits inside the zone. Yet the job vanishes. What went wrong? The location stack did. It mixed GPS, Wi‑Fi, cell, and IP in one fast guess. One signal lagged. Another was off by a block. Rules fired, and the run was lost.
I will explain how geolocation APIs work in the real world, where accuracy breaks, how evasion shows up (at a high level), and what the law and app store rules expect. I will not give any steps to bypass checks or geofences.
Quick definition for readers and for search: a geolocation API lets an app ask the device or browser for the user’s place on Earth, with time, method, and error range. It can use GPS, Wi‑Fi, cell, sensors, and IP. See the MDN Geolocation API for the web model and events.
Is IP geolocation accurate? IP data can say a country, and often a city. It is weak at the street level. It is also wrong at times due to VPNs, proxies, mobile carrier NAT, or CDNs. It works best as a coarse hint, not as a gate by itself. For more on limits, see what IP geolocation can and cannot do.
Your app does not “have GPS.” It has a broker that blends many inputs. On Android, this is the Android Fused Location Provider. On iOS, it is Apple Core Location. These frameworks balance speed, battery, and precision. They also adapt to the scene: indoors, outdoors, moving, still.
GPS/GNSS is great in open sky. In city canyons, tall glass can reflect signals (this is “multipath”). The fix can drift by tens of meters. A “cold start” (first fix in a while) takes longer and may be less precise. A “warm start” is faster and better.
Wi‑Fi SSIDs help a lot in towns. Phones see nearby Wi‑Fi names and match them with a big map made from past scans. In many cases, Wi‑Fi can beat GPS for short time-to-fix. Wi‑Fi RTT (round trip time) can do indoor ranging on new phones and routers. See Wi‑Fi RTT on Android for details.
Cell towers and Assisted GPS improve start time. The network gives a hint of place (coarse), then GPS refines it. This is good for drive starts and rural cases, yet cell-only fixes have wide error circles.
IP-based geolocation is the coarsest. It depends on which network path your packets take. Mobile carriers, CDNs, and enterprise networks can shift the view. There is work to map IPs to places with better data. One tool is the RFC 8805 geofeed standard, which lets ISPs share IP-to-location hints. Still, IP should support, not lead, your decision.
Below is a quick map of common signals. Values are typical ranges, not promises. Your results will vary by device, city shape, time of day, and user settings.
| GPS / GNSS | 3–10 m urban (can degrade near tall buildings), 5–20 m rural, worse indoors | Medium to high (hard to fake well, but can be fed mock data on rooted/jailbroken devices) | Cold: seconds to minutes; Warm: seconds | Medium to high during active tracking | Precise location; time stamps | Core Location (iOS), Fused Location (Android), device GPS chip | Needs clear consent for precise data; avoid over-collection and long retention |
| Wi‑Fi SSIDs (databases) | 5–30 m urban; weak in low-density areas | Medium (MAC randomization, stale DBs, or rogue APs can mislead) | Fast once radios are on | Low to medium | Nearby network IDs can be personal data if linked to homes | Core Location, Fused Location; third‑party DBs | Disclose Wi‑Fi scan use; follow platform rules on background scans |
| Wi‑Fi RTT (802.11mc) | 1–2 m indoors with supported routers and phones | Medium (needs hardware support; harder to spoof well) | Fast after calibration | Medium | Very precise indoor data | Android Wi‑Fi RTT API | Use only with clear, opt‑in consent for precise indoor fixes |
| Cell towers | 100–1,000+ m; better in dense areas with many towers | Low to medium | Fast | Low | Coarse location | Core Location, Fused Location | Good for fallbacks and safety; do not use alone for strict fences |
| IP Geolocation | Country: high; City: moderate; Street: poor | Low (VPNs, proxies, carrier NAT) | Instant | Low | Network identifiers can be personal data | CDN or IP data providers | Use as a hint; avoid sole reliance for compliance gates |
| Sensor fusion (OS fused provider) | Best practical balance; varies by scene | Medium (relies on device trust and OS integrity) | Fast after warm‑up | Managed by OS | Mix of precise and coarse data | Core Location, Fused Location | Audit permissions, disclosures, and retention across all inputs |
Border effects hurt most. A 10 m drift near a state or city line can flip a rule. A user can be “in” by GPS and “out” by IP at the same time. If you must meet a law by line (tax, labor, or gaming), add a buffer zone and a soft review path.
Indoors vs outdoors is another pain point. In a mall or high‑rise, GPS fades. Wi‑Fi and sensors carry the load, but AP maps change. On a campus, one big Wi‑Fi mesh can make far spots look close. In rural zones, Wi‑Fi is sparse, so cell guesses grow wide.
App life cycle adds risk. When users stop moving, OS rules can throttle updates. If you ask for background location, both stores need strong user value and clear copy. If you drain battery, users will turn you off. That also kills accuracy.
People and bots try four broad paths: network masking (VPNs, proxies), device tampering (root/jailbreak, mock locations), sensor spoof (feed false data), and social tricks (borrowed accounts, fake photos). The goal is to look “in zone” when they are not. For a safe view of mobile risks, read the OWASP Mobile Security Testing Guide.
How to counter at a high level: blend many signals. Look for odd pairs, like GPS in one city but IP in another. Watch jumps that break speed limits. Track rapid flips between far places. Use risk scores, not hard “yes/no” on one signal. Give users a fair way to prove they are in the right place.
Device and platform checks help. On Android, use the Play Integrity API to see if the app runs on a trusted device and build. On iOS, stick to official APIs and watch for OS signs of tamper. Keep this high level. Do not break platform rules.
Ops matters as much as code. Flag but do not block low risk. Add friction for medium risk (extra prompt, selfie, or doc check if your law allows it). For high risk, block and offer a help path. Log facts, not PII, when you can. Explain your decision in simple words.
In the EU, precise location is personal data. Read GDPR’s definition of personal data. If you rely on consent, it must be free, clear, and easy to withdraw. The EDPB explains this in its note on valid consent for location data. In short: ask before you track, say why, and let people say no without harm if the feature is not core.
In the U.S., the Supreme Court held that long‑term cell site data needs a warrant. See Carpenter v. United States on location privacy. Regulators also act on data flows. See the FTC enforcement around precise geolocation. If you sell, share, or mix precise location in risky ways, you may face action.
Stores set clear lines. On Android, read the Google Play background location rules. On iOS, see Apple’s user privacy requirements. Only ask for what you need, when you need it. Explain it in the prompt and in your product copy. If the value is not clear, your app may be rejected.
In iGaming and sports betting, the law ties offers to state lines. See where online sports betting is legal in the U.S.. In these apps, a 20 m drift at a border can break a rule. Teams use many signals, a safety buffer, and a review flow to avoid false blocks and false allows. If you want neutral context on licensed sites by state, see the independent review hub at https://www.casinoreviewbank.com/. In ad‑tech, auctions also pass location hints. The spec names fields for lat/long, source, and accuracy. See the OpenRTB location signals.
No matter the region, a risk lens helps teams align. The NIST Privacy Framework is a good way to plan and review your controls.
Start with a simple matrix. Columns: accuracy target (m), latency (ms), scale (RPS), privacy stance (data you will collect, store, share), scene mix (indoor, urban, rural), and legal needs (hard fence vs soft guide). If you need strict borders, plan buffers and manual review. If your need is “nearby store list,” you can relax.
When you talk to vendors, ask about: sensor mix, indoor support, drift over time, false allow/deny rates at borders, jailbreak/root detection, consent flows, and audit logs. Ask for a test plan and data export. Validate claims with a city test, a border test, and a mall test. If you work in ads or telecom, make sure they support standard fields and signals you use upstream or downstream, like the OpenRTB location signals you already saw above.
Track: median error by scene (indoor/outdoor), percent of “method = IP only,” rate of border false blocks, rate of user appeals, time to resolve appeals, and battery impact on the top five devices. Watch drift. AP maps and tower maps change. Your model can “rot” if you do not review stats and retrain logic. Set alerts for odd jumps in these metrics.
They may use different chips, OS versions, or data sets. One may prefer GPS, the other Wi‑Fi. One may have a cold start. One may see a different set of APs. Both can be “right” within their error circles.
No. IP is fine as a hint or to block clear out‑of‑country access. It is not safe for city or state lines. Blend it with GPS, Wi‑Fi, and device trust checks. Add a review path for edge cases.
No, VPNs are legal in most places. But using a VPN to break a law or a contract can still bring risk to the user and to your app if you fail to catch it. Focus on risk, not on the tool name.
Use the OS fused provider first. Ask for foreground access at the point of need. When you must run in the background, tie it to a core value (safety, turn‑by‑turn). Sample at a sane rate. At hard borders, keep a small no‑go buffer to the outside. When the fix is near the line, ask users to wait a bit and try again.
Do not rely on raw lat/long alone. Keep the error radius and method. If a user is 15 m from the line with a 30 m error, treat that as “unknown” and add light friction, not a hard block. For fraud checks, look for device tamper and odd network paths. Keep your policy in line with store rules and local law.
A rideshare app saw cancel spikes at an airport. GPS drifted near tall glass. IP showed a POP in another city. Fix: they added Wi‑Fi hints and a 50 m buffer. They split the flow: “wait here” with a timer if near the line. Cancels dropped 38% and driver pay errors fell 22%.
Geolocation accuracy is not a fixed truth. It is a moving mix of signals, scenes, and rules. Teams that respect limits, plan for drift, and build trust do better over time. That trust, paired with solid compliance, compounds.
Alex Morgan leads risk and location engineering at a global app brand. 12+ years shipping mobile systems in regulated fields. Built cross‑border geofencing, fraud scoring, and consent flows at scale.