From Newsgroup: misc.phone.mobile.iphone

Alan Browne wrote:

Alan Browne wrote:

Where a GPS position in Lat/Long (base 10 real*) is concerned,
anything beyond the 5th dp is noise in almost all cases including SBAS
aided.**

What we have to ask ourselves then is why Apple stores them this way?

a BSSID: 8c:85:80:d1:be:37
a Latitude: 32.45985031
a Longitude: -93.81759643000001
a BSSID: 8e:76:3f:f8:5d:cd
a Latitude: 32.4594841
a Longitude: -93.8175888

This isn't esp. obscene. A little overkill (2 or 3 dp's)

a BSSID: 92:76:3f:f8:5d:cd
a Latitude: 32.4594841
a Longitude: -93.81756591

a BSSID: 92:95:51:b5:b6:ae
a Latitude: 32.45910644
a Longitude: -93.81759643000001

That trailing "1" seems to be a conversion artifact from a
multiplication somewhere - sourced as 64b integer and stored as 64b
float (probably).

Does anyone have any idea why the highly insecure Apple WPS database
contains GPS entries to this illogically numerous set of decimal places?

"illogical"? Not at all. Nobody got fired or crashed a Mars lander for excessive resolution. The reverse case is a different matter.

I appreciate the technical explanation. You and others clearly understand
the GPS math at a deeper level than I do, and I am not disputing the
precision itself.

My concern is about privacy and the fact that my access points exist in the Apple WPS database in the first place, not the number of decimal places
they use.

That is why I updated the script to pull the raw values exactly as they
appear in the Apple WPS database. The numbers themselves are less important
to me than the fact that the system allows this kind of tracking at all.

I'm only responding here because you (and others) brought up the decimal places, which I wanted to faithfully respond to, since they're in the
original database, but my script converted them to human-readable form.

I am focusing mostly on the fact that I'm in Apple's WPS database even
though I opted out as per Apple's published instructions, because privacy
is the part that affects users directly. Not so much millimeter accuracy.

However, I agreed with you on the decimal places, even as I didn't (and
still do not) completely understand why they are what they are in Apple's
WPS database.

Hence, to provide you (and everyone) more completely information about what
is actually stored in Apple's WPS database, I modified the script for you.

What I did was take your input to heart by modifying the python script
(which I posted previously) to get EXACTLY what's in the Apple WPS db.

Enter the BSSID (or q to quit): 00:18:f8:c1:4a:65
-----------------------------------------------
=== Lookup started at Sat 12/20/2025 4:18:02.21 ===
BSSID: 00:18:f8:c1:4a:65

Searching for location of bssid: 00:18:f8:c1:4a:65

BSSID: 00:18:f8:c1:4a:65
Raw latitude integer: 3245990371
Raw longitude integer: -9381384277
Latitude (degrees): 32.459904
Longitude (degrees): -93.813843

BSSID: 02:aa:a0:e3:5f:38
Raw latitude integer: 3245890808
Raw longitude integer: -9381494903
Latitude (degrees): 32.458908
Longitude (degrees): -93.814949

BSSID: 44:1c:12:99:23:58
Raw latitude integer: 3245909881
Raw longitude integer: -9381492614
Latitude (degrees): 32.459099
Longitude (degrees): -93.814926
... and so on ...

As far as I'm aware, that's the number of INTEGER digits Apple uses in
their highly insecure WPS database to report on the location of my APs.

I wonder if it scares anyone on this newsgroup that I, a nobody, can
collect all 2 billion of Apple's WPS datapoints, using a FOSS script?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: misc.phone.mobile.iphone

Alan Browne wrote:

If you understood the code you'd know that the WPS DB returns the lat/lon >>>> as a 64bit integer and the python script converts into a float with a
simple multiplication of 1e-8. Anything beyond the 8th dp is noise.

Where a GPS position in Lat/Long (base 10 real*) is concerned, anything
beyond the 5th dp is noise in almost all cases including SBAS aided.**

Even beyond the the 4th dp, it is likely noise in most cases.

If Lat is represented as a fraction of a semi-circle, then a signed 32
bit integer is more than adequate for general purposes.
Likewise Longitude as a fraction of a circle.
(LSB=0.0046...m and 0.0093...m respectively - though you could represent >>> Lat as a circle as well at the loss of 1 bit of resolution).

*by real I mean number line real, not computer language "real" type.

**(Excluding survey RTK measurements - which are baseline lengths, not
L/L but might be tied to a precise L/L - there 1cm+1mm/km error is common) >>

All of which goes against Arlen's desperate attempts to prove that one can be
"tracked by a router". When the reality is that all one can track is the
router. Which is meaningless.

There are literally 100's of thousands of router locations (WiFi) that
are available in databases with their locations well known. Any
receiver (including smartphones) can have apps that use the GPS to "tag"
a WiFi label with the position where it was detected. The error in
position being where the detecting radio (smartphone or other) was when
it found that WiFi. (SSID).

This can be on any system - whether Apple did so or contributed to such
- I don't know.

It's a meaningless complaint, regardless of who is doing it. As in all
such things: if there is an outcome that "can" happen - it assuredly
"will" happen.

In yet another desperate attempt to make Apple "look bad".

Par. Ignore it.

To your concern that privacy is a "meaningless complaint", I would say the
same if I found my access point in Google's or Mozilla's public WPS DBs.

Besides, I am not arguing about decimal places, GPS math, or the precision
of the stored coordinates that any of these public WPS databases employ.

I accept explanations in this thread about integer storage & conversion.
None of that is the point I am raising because my point is privacy.

My overwhelming concern is that my own access point has nomap in the SSID
and is also hidden, yet it still appears in the Apple WPS database with coordinates attached. That means the access point was collected and stored despite the opt-out flag and despite not broadcasting the SSID. That is a privacy issue, not a numerical one.

Apple is doing the antithesis of what Apple advertises that it's doing.
Apple even lied to Congress, as far as I know, about what it's doing.

That's a problem.
a. It's a moral problem (where morality is internal to Apple)
b. It's a legal problem (where legality is what Apple must abide by)
c. And it's an ethical problem (where ethicality is basic standards)

Whether the location is accurate to four decimal places or eight does not matter. The issue is that the location exists in the database at all when
the SSID was explicitly marked not to be mapped which is 100% following
Apple's stated legally enforceable public privacy policy (& to Congress!)

That is the part I am trying to understand and discuss here.
Not decimal places, per se, although decimal places point to accuracy.

To respond to your other issues, I am not trying to make any company look
bad as I would do the same if Google or Mozilla did what Apple does.

They don't.
<https://en.wikipedia.org/wiki/Mozilla_Location_Service>
"Mozilla's client applications do not collect information
about WiFi access points whose SSID is hidden or ends with
the string '_nomap' (e.g. 'Simpson-family-wifi_nomap')."

In summary, I am trying to understand why an access point that should not
be included in any mapping system is still present in Apple's WPS database

That is the main point I am raising here, where I disagree with your characterization of that fact being "anti Apple" as it's about privacy.

Clearly Apple doesn't bother to care to respect their own privacy policy.

But knowing that fact does not mean I'm anti Apple as I'd act the same if Mozilla (see above) didn't follow their own stated privacy policy also.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: misc.phone.mobile.iphone

Alan Browne wrote:

On 2025-12-19 10:40, candycanearter07 wrote:

Never trust a float for anything that requires precision.

Silly statement.

If you understand the structure of the float (IEEE 754) as implemented
in your programming language and OS then analyzing the _resolution_ of
the floating value and the resultant _precision_ of the result (2 things that many programmers ignore) then float is fine for many (if not all) things requiring precision.

As I stated in another post, Python (and many C) programmers seem quite
lazy in this respect and so liberally use 64 bit float where 32 would
do. Or even 16. So much excess resolution pretty much guarantees conservation of information in most cases with a reasonably large number
of operations. (akin to having a 500HP engine where 200HP is much more
than adequate).

A key point is understanding the effect of operations on the _precision_
of an operation and the order of operations on variables and the result
that conserve information and _precision_ and not merely _resolution_
which itself is a characteristic of the "instrument" (in this case CPU registers and memory and not a guarantee of _precision_ in the result).

Implementing precision operations as integer values with some assigned resolution to LSB (say: LSB = 0.001 metres) is NO different if the order
of operations is not carefully designed to conserve actual _information_
in a sequence of operations.

To keep this thread on the concept of answering WHY Apple's precision is
what it is when they store my BSSID (or anyone's BSSID) in their highly insecure yet very public easily accessed WPS database, I'm not disputing
Alan Browne's explanation of floating-point behavior or the distinction
between resolution and precision.

My main point about Apple's highly insecure yet very public WPS database is much narrower and has nothing to do with whether Python uses 32-bit or
64-bit floats, or whether IEEE 754 is appropriate for numerical work.

What I am showing is simply the raw form in which Apple stores these coordinates in the WPS database. The database uses ten-digit integers that convert into latitude and longitude values with several decimal places.
That is the precision of the stored data, regardless of whether the
underlying measurements are accurate to that level.

Enter the BSSID (or q to quit): 00:18:f8:c1:4a:65
-----------------------------------------------
=== Lookup started at Sat 12/20/2025 4:18:02.21 ===
BSSID: 00:18:f8:c1:4a:65

Searching for location of bssid: 00:18:f8:c1:4a:65

BSSID: 00:18:f8:c1:4a:65
Raw latitude integer: 3245990371
Raw longitude integer: -9381384277
Latitude (degrees): 32.459904
Longitude (degrees): -93.813843

BSSID: 02:aa:a0:e3:5f:38
Raw latitude integer: 3245890808
Raw longitude integer: -9381494903
Latitude (degrees): 32.458908
Longitude (degrees): -93.814949

BSSID: 44:1c:12:99:23:58
Raw latitude integer: 3245909881
Raw longitude integer: -9381492614
Latitude (degrees): 32.459099
Longitude (degrees): -93.814926
... and so on ...

The technical question I am raising is why an access point that is both
hidden and marked nomap appears in the database at all. To any precision!

The number of decimal places is not the main issue, although it could be indicative of how the system works by knowing WHY it's what it is.

The main privacy issue is that the access point was collected and stored despite explicit opting out signals not to include it. That is a privacy concern, not a floating-point concern.

I am focusing on the behavior of the database and the implications for
users who expect nomap and hidden SSIDs to prevent this kind of collection.

The integer format and the float conversion are just the mechanism that
reveals the underlying data; they are not the core of the problem I am
pointing out. address it directly.

Despite Alan Baker ridiculing the precision, it is what Apple made it to
be. So what we need to understand is WHY Apple made it to what it is.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: misc.phone.mobile.iphone

Alan Browne wrote:

It is either negative (bit set) or not (bit not set).

Which is exactly how Apple stores GPS coordinates in its WPS database.

Enter the BSSID (or q to quit): 00:18:f8:c1:4a:65
-----------------------------------------------
=== Lookup started at Sat 12/20/2025 4:18:02.21 ===
BSSID: 00:18:f8:c1:4a:65

Searching for location of bssid: 00:18:f8:c1:4a:65

BSSID: 00:18:f8:c1:4a:65
Raw latitude integer: 3245990371
Raw longitude integer: -9381384277
Latitude (degrees): 32.459904
Longitude (degrees): -93.813843

BSSID: 02:aa:a0:e3:5f:38
Raw latitude integer: 3245890808
Raw longitude integer: -9381494903
Latitude (degrees): 32.458908
Longitude (degrees): -93.814949

BSSID: 44:1c:12:99:23:58
Raw latitude integer: 3245909881
Raw longitude integer: -9381492614
Latitude (degrees): 32.459099
Longitude (degrees): -93.814926
... and so on ...

The main question regarding Apple's highly public (open to everyone!) WPS database, is to ask why they store data to that high of integer precision.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: misc.phone.mobile.iphone

Jeff Liebermann wrote:

The question mainly is WHY Apple stores them to the number of integers that >>they do, where all I can do is convert the integer values to human-readable >>decimal coordinates.

If you look at the original data you posted a few articles back, you
might notice that the number of significant digits in the Lat/Long
numbers vary widely for each BSSID.
That implies that the number is
coming from the GPS receiver and is probably not "processed" prior to
be being logged. The entries with fairly few significant figures is
probably an old GPS who's designers were only confident in a few
digits precision. The longer entries could easily be the output of an
RTK differential GPS system capable of millimeter accuracy. A way to
verify this is to write a program that grabs the first half of the
BSSID and searches various OUI databases for the name of the
manufacturer. Something like this:
"Wi-Fi Vendor - Detect vendor of a Wi-Fi access point with just your
iPhone or iPad"
<https://github.com/jiribrejcha/wifi-vendor-lookup>

I'll try it.
BSSID: 84:eb:3e:f8:36:d3
Latitude: 32.45880508
Longitude: -93.81717681
Plugging the BSSID into:
<https://oui.is/>
<https://oui.is/84eb3ef836d3>
I get:
Vivint Smart Home 84:eb:3e:00:00:00/24

Here's a longer Lat:
BSSID: bc:9b:68:7e:15:c3
Latitude: 32.459438320000004
Longitude: -93.817276
<https://oui.is/bc9b687e15c3>
I get:
Vantiva USA LLC bc:9b:68:00:00:00/24

I can't determine if either company has a reason to have a longer
Lat/Long. However, notice the number of digits in the Lat, which are
mostly zeros, except for the last digit:
Latitude: 32.459438320000004
I don't know what they're doing, but it looks like they're using the
Latitude to store some kind of data or ID. There are several other
entries in the data that show a similar pattern of 8 places to the
right of the decimal point for useful data followed by 6 zeros and 1
numeric digit.

This should be useful:
"Accuracy of Decimal Places in Latitude and Longitude Degrees" <https://support.garmin.com/en-US/?faq=hRMBoCTy5a7HqVkxukhHd8>

8 decimal places is 1.11mm resolution which is probably the limit of
GPS resolution (not sure).

Anyway, good luck with whatever you're doing.

Thanks Jeff. We're neighbors in the Santa Cruz Mountains, by the way.

You've taught me a lot over the years, one item of which is that most
consumer routers (e.g., those with Broadcom chipsets) can't change the
outward facing BSSID (although some professional routers certainly can).

I have plenty of old Surfnet, Etheric, Hilltop & Ridge equipment, that I repurpose them as access points even though they're designed for CPE use.
<https://i.postimg.cc/5t4Nhkwx/transceiver01.jpg>
<https://i.postimg.cc/RZXNZBCQ/transceiver02.jpg>
<https://i.postimg.cc/qMhQRkJN/linksys-wrt-54g.jpg>

Loren and Mike, in particular, and sometimes Andrea Lovelady at Surnet,
give me all their old transceivers which I repurpose as access points
(although much of the old Surfnet stuff is licensed Mikrotik stuff).

I'm well aware you're an old hand at UNDERSTANDING what WISPs can do!
So I appreciate that you looked up the brand of each of the strange ones.

My main goal here is simply to UNDERSTAND how Apple's WPS database is completely different than everyone else's, where I'm in discussions
with Brian Krebs and the Mozilla research team (Dan Veditz) so
I'm aware how the morally responsible companies handle hidden SSIDs.

Fundamentally, the results from Apple's RADAR bug report is that following Apple's public legally binding privacy policy will NOT work.

You have to know the super-secret trick to stay out of Apple's WPS
database, and even then, that trick puts you into every other one.

Yes. You of all people understand the catch 22 that Apple puts us in.

My main goal is simply to get Apple to do the morally right, ethically
correct, and legally defensible thing - which I have so far failed at.

But I rarely fail for long as you can note by the PG&E lines NOT failing anymore as PG&E has to call a conference3 with me for an hour EVERY SINGLE
TIME the power goes out (as per my CPUC complaint resolution).

So I rarely fail.
But so far, I'm failing to get Apple to do the right thing.
Even though I'm communicating at the highest (VP) level at Apple.

However, time (and effort) will tell.
Then I will be successful.

And that will preserve the privacy of hundreds of millions of homes.
Which is what drives me after all.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: misc.phone.mobile.iphone

While I will ignore that Chris called me a Trumpist simply because
I proved him wrong and he had no other defense than to resort to
insults, one perfectly reasonable disagreement is that Chris repeatedly disputed
my personal ad hoc characterization that it is "trivial" to get the location
of up to 400 APs near any given AP in Apple's highly insecure but very public WPS database.

That's fine as adults can disagree on effort given differing skill sets.
a. Chris repeatedly claimed it was not trivial
b. I easily proved that it was excessively trivial

Too trivial, in fact.
Anyone can do it.

To prove that this is trivial, even as Chris clearly opined that he felt it wasn't trivial (where trivial is in the eyes of the beholder, I guess),
here is what I've modified just today to convert the raw integer values
Apple stores in its highly insecure but very public WPS database to the typical decimal values we plug into our GPS location devices.

None of us knew how Apple saved the location of our APs until recently.
02:aa:a0:e3:5f:38 3245891571 -9381494140 32.45891571 -93.81494140
00:18:f8:c1:4a:65 3245990371 -9381384277 32.45990371 -93.81384277
44:1c:12:99:23:58 3245911026 -9381490325 32.45911026 -93.81490325
44:1c:12:99:23:5b 3245911026 -9381489562 32.45911026 -93.81489562
44:1c:12:99:23:5d 3245911407 -9381490325 32.45911407 -93.81490325
44:1c:12:99:23:5e 3245912170 -9381490325 32.45912170 -93.81490325
06:aa:a0:e3:5f:38 3245893096 -9381491088 32.45893096 -93.81491088
72:13:01:01:99:9a 3245925521 -9381433868 32.45925521 -93.81433868
72:13:01:01:99:9d 3245924758 -9381433868 32.45924758 -93.81433868
etc.

After digging deeper (see other posts), I've confirmed Apple is simply
storing our personal data to 8 decimal places, but without the decimal
point. So all the conversion of Apple's raw values to GPS are off a bit.

That is, Apple's wide-open yet highly insecure WPS database stores
latitude and longitude as integers representing the real coordinate
multiplied by 100,000,000 (i.e., multiply by one hundred million).

I think mainly, since we're using Windows tools to get Apple privacy data, that we simply needed to UNDERSTAND better what it is that Apple is allowing everyone on the planet, no matter who they are, to access.

I agree with everyone who says the precision for the decimal location
in Apple's highly insecure but all-too-public easily accessed WPS database
is likely far higher than it needs to be for simply locating an access point.
9a:0f:6f:18:7c:00 3246034622 -9381387329 32.460346 -93.813873
a2:0f:6f:18:7c:00 3246035003 -9381387329 32.460350 -93.813873
a6:0f:6f:18:7c:00 3246034622 -9381386566 32.460346 -93.813866
2a:ad:18:fc:8b:1f 3246102142 -9381381988 32.461021 -93.813820
where all four of those in Shreveport, LA map to the same 100-meter area.
0.0008deg latitude ~ 89 meters
0.0010deg longitude at that latitude ~ 92 meters

Apple's WPS (Wi-Fi Positioning System) database appears to be
storing our personal BSSID locations using fixed-point integer
encoding where
Latitude is apparently stored as an integer ~ lat * 1e8
Longitude is stored as an integer ~ lon * 1e8

Hence Apple's WPS database stores coordinates with 8 decimal places:
1e-8 degrees of latitude ~ 1.1 millimeters
But the real-world accuracy of Wi-Fi geolocation is nowhere near that.
So the location of each individual BSSID is probably within ~10 meters.

When you look up your own AP in Apple's database, if you get the
raw numbers, all you need to do to convert Apple's stored value back
into a normal GPS coordinate, you just divide by 100,000,000.

Here's the modified python script that just divides by 100 million
the raw data that Apple stores about us in its highly insecure public
WPS database.

#!/usr/bin/env -S uv run --script
# -*- coding: utf-8 -*-

# C:\app\os\python\apple_bssid_locator\apple_bssid_locator.py
# Queries Apple WPS database for GPS:BSSID location pairs
# Implementation based on https://github.com/hubert3/iSniff-GPS
#
# Usage: apple_bssid_locator.py 11:22:33:AA:BB:CC
# Usage: apple_bssid_locator.py 11:22:33:AA:BB:CC --all
# Usage: apple_bssid_locator.py 11:22:33:AA:BB:CC --map
#
# Changelog:
# v1p0 20251205 - Initial version
# v1p1 20251214 - Added logging to results.txt
# v1p2 20251215 - Timestamped results.txt to avoid overwrites
# v1p3 20251219 - Limited output to 6 decimal places
# v1p4 20251219 - Added raw integer output alongside converted decimals
# v1p5 20251222 - Fixed raw to decimal conversion (divide by 100 Million)

import argparse
import requests
import webbrowser
import AppleWLoc_pb2

def parse_arguments():
parser = argparse.ArgumentParser()
parser.add_argument("bssid", type=str, help="display the location of the bssid")
parser.add_argument("-m", "--map", help="shows the location on google maps", action='store_true')
parser.add_argument("-a", "--all", help="shows all results returned, not just the requested one", action='store_true')
args = parser.parse_args()
return args

def format_bssid(bssid):
return ':'.join(e.rjust(2, '0') for e in bssid.split(':'))

def query_bssid(bssid, output_file="results.txt"):
apple_wloc = AppleWLoc_pb2.AppleWLoc()
wifi_device = apple_wloc.wifi_devices.add()
wifi_device.bssid = bssid
apple_wloc.unknown_value1 = 0
apple_wloc.return_single_result = 0 # request ALL results
serialized_apple_wloc = apple_wloc.SerializeToString()
length_serialized_apple_wloc = len(serialized_apple_wloc)

headers = {'User-Agent':'locationd/1753.17 CFNetwork/889.9 Darwin/17.2.0'}
data = b"\x00\x01\x00\x05"+b"en_US"+b"\x00\x13"+b"com.apple.locationd"+b"\x00\x0a"+b"8.1.12B411"+b"\x00\x00\x00\x01\x00\x00\x00" + bytes((length_serialized_apple_wloc,)) + serialized_apple_wloc
r = requests.post('https://gs-loc.apple.com/clls/wloc', headers=headers, data=data)

apple_wloc = AppleWLoc_pb2.AppleWLoc()
apple_wloc.ParseFromString(r.content[10:])

# Build dictionary of results
results = {}
with open(output_file, "w") as f:
for wifi_device in apple_wloc.wifi_devices:
if wifi_device.HasField('location'):
raw_lat = wifi_device.location.latitude
raw_lon = wifi_device.location.longitude
lat = raw_lat * 1e-8
lon = raw_lon * 1e-8
mac = format_bssid(wifi_device.bssid)
results[mac] = (lat, lon, raw_lat, raw_lon)
# Write both raw integers and converted decimals (8 decimal places)
f.write(f"{mac}\t{raw_lat}\t{raw_lon}\t{lat:.8f}\t{lon:.8f}\n")

print(f"Saved {len(results)} entries to {output_file}")
return results

def main():
args = parse_arguments()
print("Searching for location of bssid: %s" % args.bssid)
results = query_bssid(args.bssid)

# Determine which BSSIDs to process
bssids_to_process = results.keys() if args.all else [args.bssid.lower()]

found = False
for bssid in bssids_to_process:
if bssid in results:
lat, lon, raw_lat, raw_lon = results[bssid]
if lat == -180.0 and lon == -180.0:
continue # Skip entries that were not found
if found:
print()
print(f"BSSID: {bssid}")
print(f"Raw latitude integer: {raw_lat}")
print(f"Raw longitude integer: {raw_lon}")
print(f"Latitude (degrees): {lat:.8f}")
print(f"Longitude (degrees): {lon:.8f}")
if args.map:
url = f"http://www.google.com/maps/place/{lat:.8f},{lon:.8f}"
webbrowser.open(url)
found = True
if not found:
print("The bssid was not found.")

if __name__ == '__main__':
main()

# end of C:\app\os\python\apple_bssid_locator\apple_bssid_locator.py
--
We need to work together to help Apple understand that it is morally,
ethically & legally reprehensible to not allow us to opt out of WPS.
--- Synchronet 3.21a-Linux NewsLink 1.2