How Wi-Fi positioning works

Wi-Fi positioning 101

Every Wi-Fi access point continuously broadcasts a globally-unique hardware address — its BSSID. Access points rarely move. That makes the set of BSSIDs a device can hear a remarkably stable fingerprint of where that device physically is.

Mapping services (Apple, Google, Skyhook and others) have spent years observing which BSSIDs appear at which coordinates. fraud.xxx operates a large, US-focused observation graph of that relationship: given a BSSID we know roughly where it lives; given a coordinate we know which BSSIDs to expect nearby.

That unlocks two directions of inference:

• Forward (verify): a device reports the BSSIDs it currently sees → we return where that points, and whether it matches a claimed location.
• Reverse (locate): you give a coordinate or ZIP → we return the access points expected around it.

BSSID & OUI

A BSSID looks like aa:bb:cc:dd:ee:ff — six bytes. The first three (the OUI, Organizationally Unique Identifier) are assigned by the IEEE to a manufacturer, so they reveal the vendor (Cisco, Ubiquiti, eero, a phone hotspot chipset, …). fraud.xxx resolves the OUI to a vendor and a device_class, and flags addresses whose OUI bit marks them locally administered — the hallmark of a randomized or virtual MAC.

hacc, vacc & altitude

Each stored access point carries the positioning system's own error estimates:

• hacc_m — horizontal accuracy in metres. The radius of the circle the AP is believed to sit within. Smaller is better; single-digit values are common in dense areas.
• vacc_m — vertical accuracy in metres, when an altitude solution exists.
• alt_m — estimated altitude. Useful to separate floors in tall buildings; pair it with the altitude filter on /v1/aps/nearby.

Treat hacc_m as the per-point confidence. A verify result aggregates many points, so its spread_m (how far the matched points scatter) is the better signal of overall certainty.

Randomized MACs & twins

Phones and some APs rotate their MAC address for privacy. These randomized MACs are marked is_random: true — they are poor location anchors and should be discounted. fraud.xxx also detects twins: the same BSSID observed at two distinct locations (a device that physically moved, or address reuse). When present, the twin object reports the second location and how far it sits from the primary, so you can decide whether the anchor is trustworthy.

ZIP vs coordinate precision

You can query by exact lat/lon or by zip. They are not the same thing, and fraud.xxx never pretends they are:

Every response includes a precision object. If you make risk decisions, branch on precision.mode — a zip_centroid answer must never be treated as a fix.

Confidence & freshness

Access points move, get replaced, or vanish. A point last seen two years ago is weaker evidence than one seen last week. fraud.xxx exposes this directly:

• first_seen / last_seen — observation window for the point.
• confidence (on verify) — 0…1, combining how many submitted BSSIDs matched and how tightly they cluster.
• spread_m — the geographic scatter of matched points; low spread = high certainty.

Rule of thumb: confidence > 0.7 with spread < 100 m is a strong on-site match. Anything ZIP-derived is contextual, not conclusive.

Recipe: a login anti-spoof check

Collect the BSSIDs the client sees (mobile SDK / browser permission), then gate the session:

verdict = fraud.post("/v1/verify", json={"bssids": observed}).json()

claimed = (user.profile_lat, user.profile_lon)
near = haversine_m(claimed, verdict["centroid"]) if verdict["matched"] else 1e9

if verdict["confidence"] > 0.7 and near < 500:
    risk -= 30          # network environment confirms the claim
elif verdict["matched"] and near > 50_000:
    risk += 40          # device sees networks far from where it claims to be

Use the result as one factor among many. See acceptable use below.