From Newsgroup: alt.internet.wireless

All my tutorials use freeware so that EVERYONE can use them, but I
wrote this tutorial before I found out about this Apple WPS query:
<https://wavedigger.networksurvey.app/?tab=bssid>

Hence, this tutorial is only useful if you want to control the query
of Apple's highly insecure WPS database, which has no privacy controls.

For example, you can query thousands of BSSID's in a single command.
I'm not promoting that action, but I'm making the point it can be done.

See also:
From: Marian <marianjones@helpfulpeople.com>
Newsgroups: alt.comp.os.windows-10,comp.mobile.android,misc.phone.mobile.iphone,alt.internet.wireless
Subject: How to test if your access point BSSID is in the highly insecure Apple WPS database
Date: Fri, 5 Dec 2025 05:08:08 -0700
Message-ID: <10guhv8$ig7$1@nnrp.usenet.blueworldhosting.com>

Tutorial: *Query the Apple database for your access point BSSID*
<https://github.com/darkosancanin/apple_bssid_locator>

0. Download & install 7zip if you don't already have it on Windows.
<https://www.7-zip.org/>

1. Download & install Python 3.14.1 on Windows & create site-packages
<https://www.python.org/downloads/windows/>
<https://www.python.org/ftp/python/3.14.1/python-3.14.1-amd64.exe>
Name: python-3.14.1-amd64.exe
Size: 29883656 bytes (28 MiB)
SHA256: 74E1516408744190FCC12307C150DE30902898444F77F85F4C2AC18F36788A80
I installed into C:\app\os\python\python.exe
REM Create site-packages if missing
mkdir C:\app\os\python\Lib\site-packages

2. Download the requests package & copy into your Python environment
<https://pypi.org/project/requests/#files>
<https://files.pythonhosted.org/packages/source/r/requests/requests-2.32.5.tar.gz>
Name: requests-2.32.5.tar.gz
Size: 134517 bytes (131 KiB)
SHA256: DBBA0BAC56E100853DB0EA71B82B4DFD5FE2BF6D3754A8893C3AF500CEC7D7CF
When 7-Zip asks Would you like to replace the existing file
@PaxHeader, Press A (Always) to overwrite all such header files.

C:\app\archiver\7zip\7z.exe x requests-2.32.5.tar.gz
C:\app\archiver\7zip\7z.exe x requests-2.32.5.tar
xcopy /E /I requests-2.32.5\src\requests C:\app\os\python\Lib\site-packages\requests

3. Do the same for urllib3 -> handles HTTP connections
<https://files.pythonhosted.org/packages/source/u/urllib3/urllib3-2.5.0.tar.gz>
Name: urllib3-2.5.0.tar.gz
Size: 393185 bytes (383 KiB)
SHA256: 3FC47733C7E419D4BC3F6B3DC2B4F890BB743906A30D56BA4A5BFA4BBFF92760
C:\app\archiver\7zip\7z.exe x urllib3-2.5.0.tar.gz
C:\app\archiver\7zip\7z.exe x urllib3-2.5.0.tar
xcopy /E /I urllib3-2.5.0\src\urllib3 C:\app\os\python\Lib\site-packages\urllib3

4. Do the same for certifi -> provides SSL certificates
<https://files.pythonhosted.org/packages/source/c/certifi/certifi-2025.11.12.tar.gz>
Name: certifi-2025.11.12.tar.gz
Size: 160538 bytes (156 KiB)
SHA256: D8AB5478F2ECD78AF242878415AFFCE761CA6BC54A22A27E026D7C25357C3316
C:\app\archiver\7zip\7z.exe x certifi-2025.11.12.tar.gz
C:\app\archiver\7zip\7z.exe x certifi-2025.11.12.tar
xcopy /E /I certifi-2025.11.12\certifi C:\app\os\python\Lib\site-packages\certifi

5. Do the same for idna -> supports international domain names
<https://files.pythonhosted.org/packages/source/i/idna/idna-3.11.tar.gz

Name: idna-3.11.tar.gz
Size: 194582 bytes (190 KiB)
SHA256: 795DAFCC9C04ED0C1FB032C2AA73654D8E8C5023A7DF64A53F39190ADA629902
xcopy /E /I idna-3.11\idna C:\app\os\python\Lib\site-packages\idna
C:\app\archiver\7zip\7z.exe x idna-3.11.tar.gz
C:\app\archiver\7zip\7z.exe x idna-3.11.tar
xcopy /E /I idna-3.11\idna C:\app\os\python\Lib\site-packages\idna

6. Do the same for charset'normalizer -> handles text encoding
<https://files.pythonhosted.org/packages/source/c/charset-normalizer/charset_normalizer-3.4.4.tar.gz>
Name: charset_normalizer-3.4.4.tar.gz
Size: 129418 bytes (126 KiB)
SHA256: 94537985111C35F28720E43603B8E7B43A6ECFB2CE1D3058BBE955B73404E21A
C:\app\archiver\7zip\7z.exe x charset_normalizer-3.4.4.tar.gz
C:\app\archiver\7zip\7z.exe x charset_normalizer-3.4.4.tar
xcopy /E /I charset_normalizer-3.4.4\src\charset_normalizer C:\app\os\python\Lib\site-packages\charset_normalizer

7. Test for the expected outcome of "2.32.5"
C:\app\os\python\python.exe -c "import requests; print(requests.__version__)"

8. Now we have to add the protobuf 5.29.4 archive
https://files.pythonhosted.org/packages/source/p/protobuf/protobuf-5.29.4.tar.gz
Name: protobuf-5.29.4.tar.gz
Size: 424902 bytes (414 KiB)
SHA256: 4F1DFCD7997B31EF8F53EC82781FF434A28BF71D9102DDDE14D076ADCFC78C99
C:\app\archiver\7zip\7z.exe x protobuf-5.29.4.tar.gz
C:\app\archiver\7zip\7z.exe x protobuf-5.29.4.tar
xcopy /E /I protobuf-5.29.4\google C:\app\os\python\Lib\site-packages\google

Note that protobuf has a version compatibility rule which only
shows up once you actually try to load a generated .proto file.
When you run the apple_bssid_locator.py, it will complain if the
version of protoc you installed is different than what had been
used to generate AppleWLoc_pb2.py.

9. Test for expected outcome of "5.29.4"
C:\app\os\python\python.exe -c "from google import protobuf; print(protobuf.__version__)"

10. Download & extract the Apple_bssid_locator project
<https://github.com/darkosancanin/apple_bssid_locator/archive/refs/heads/master.zip>
Name: apple_bssid_locator-master.zip
Size: 509563 bytes (497 KiB)
SHA256: 59A89D3AF89E70012493668BD71DD640C8EF39F15A88955E25B7AE242FCFC7BF
I extracted to C:\tmp\apple_bssid_locator-master\apple_bssid_locator.py

11. Obtain your own BSSID of your hidden SSID access point
<http://192.168.0.1/start.htm>
AA:BB:CC:11:22:33

Or scan your local network for BSSIDs:
netsh wlan show networks mode=bssid

12. Run the script
cd C:\tmp\apple_bssid_locator-master
C:\app\os\python\python.exe apple_bssid_locator.py AA:BB:CC:11:22:33

If the BSSID is in the Apple database, you'll get something like this:
{
"bssid": "AA:BB:CC:11:22:33",
"latitude": 40.12345678,
"longitude": -120.12345678
"ssid": null
}

Convert that to a location using the Google Maps URI:
<https://maps.google.com/?q=40.12345678,-120.12345678

If the BSSID is NOT in the Apple database, you'll get this:
C:\app\os\python\python.exe apple_bssid_locator.py AA:BB:CC:11:22:33
Searching for location of bssid: AA:BB:CC:11:22:33
The bssid was not found.

See also:
<https://github.com/acheong08/apple-corelocation-experiments>
--
<https://www.cs.umd.edu/~dml/papers/wifi-surveillance-sp24.pdf>
"In this work, we show that Apples WPS implementation
can easily be abused to create a serious privacy threat
on a global scale."

<https://arxiv.org/abs/2405.14975>
"In this work, we show that Apple's flawed WPS can too easily be abused"

<https://www.govinfosecurity.com/surveillance-risk-apples-wifi-based-positioning-system-a-25330>
"The attack risk stems from Apple's WiFi-based Positioning System, or WPS"

<https://securityboulevard.com/2024/05/apple-wi-fi-location-privacy-richixbw/>
"An unrestricted Apple API endpoint allows for easy tracking."

<https://cybernews.com/privacy/apple-beams-wifi-location-data-privacy-risk/>
"Anyone can exploit Apple's flawed WiFi-based positioning system (WPS)*

<https://www.macworld.com/article/2343297/apple-wi-fi-network-wps-vulnerability-location-services-leak.html>
"Researchers have discovered a crucial vulnerability
in the way only Apple's location services work"

<https://www.theregister.com/2024/05/23/apple_wifi_positioning_system/>
"The threat applies even to users that do not own devices
for which the WPSes are designed - individuals who own no Apple
products, for instance, can have their AP in Apple's WPS merely
by having Apple devices come within Wi-Fi transmission range."

<https://9to5mac.com/2024/05/24/apple-location-services-vulnerability/>
"There is one crucial difference between the way in which
Apple and Google devices carry out this task
and that's exactly where the privacy issue arises."
"We need to understand Apple devices figure out locations differently"

<https://www.bizcommunity.com/article/apple-may-have-turned-wi-fi-routers-into-a-privacy-threat-239637a>
"Researchers from the University of Maryland have uncovered a
significant privacy vulnerability in Apple's Wi-Fi-based
Positioning System (WPS). This vulnerability enables attackers
to track devices globally by exploiting the way Apple's WPS
operates, raising serious privacy concerns."

<https://cyberinsider.com/apples-wi-fi-based-positioning-system-is-a-privacy-nightmare/>
*Apple's Wi-Fi-Based Positioning System is a Privacy Nightmare*
"Researchers from the University of Maryland have uncovered a
significant privacy vulnerability in Apple's Wi-Fi-based Positioning
System (WPS). This vulnerability enables attackers to track devices
globally by exploiting the way Apple's WPS operates, raising
serious privacy concerns."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Mario Tomasella wrote:

On 06/12/2025 17:55, Marian wrote:

All my tutorials use freeware so that EVERYONE can use them, but I
wrote this tutorial before I found out about this Apple WPS query:

What is the Apple WPS query?

It's a query of a massive public database which has absolutely no control
over who queries that database, which has been decried by security pros.
<https://wavedigger.networksurvey.app/?tab=bssid>

If you find your BSSID in that database, even if you have _nomap appended
to your SSID, you might have a legal/moral/ethical case against Apple.

Why is your tutorial not more comprehensive?

I'm working on a separate tutorial for querying the equally massive Google
WPS database, but it has registration controls so not everyone can do it.

How can I use the WPS query on Windows 10 or 11?

Every single step necessary was posted where those steps only work on
Windows, but we could test the same steps as you mainly need python.

When talking about Apple devices, could you also specify which one you
are referring to? Apple makes lots of different devices, so your WPS
query might not be relevant to all of them without significant
modifications and bug testing.

Apple mobile devices upload the unique BSSID & SSID & GPS location &
signal strength & timestamp, etc., of every device within radio range.

In fact, I found my own SSID, which is set to be both hidden broadcast (so
the broadcast packets only contain my BSSID) and opted out (with _nomap)
in Apple's highly insecure public database available to anyone world wide.

That's a legal, moral & ethical privacy flaw in the Apple WPS database.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

In fact, I found my own SSID, which is set to be both hidden broadcast (so the broadcast packets only contain my BSSID) and opted out (with _nomap)
in Apple's highly insecure public database available to anyone world wide.

That's a legal, moral & ethical privacy flaw in the Apple WPS database.

I spoke to a VP at Apple who happens to be a neighbor who knows I am
credible, and I sent him the information so that he can pass it on to the
right people at Apple who can explain to my satisfaction what happened.

Some of the commands I provided to them, run on Windows, are the following (which those of you on Windows can run right now to check your situation).
C:\> netsh wlan show all
C:\> netsh wlan show networks
C:\> setsh wlan show networks mode=ssid
C:\> netsh wlan show networks mode=bssid
C:\> python.exe apple_bssid_locator.py AA:BB:CC:11:22:33

For wavedigger, you can put your BSSID into the URI:
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=11-22-33-AA-BB-CC>

The only way I can even think of how I got into Apple's WPS database is
that there's a bug in the Apple software when hidden SSIDs are involved.

Note: Apple does not document their policy toward hidden SSIDs, but
Mozilla security personnel (whom I've been in contact with) have
documented that they do not "collect" any SSID that is hidden, in
addition to any non-hidden SSID that has _nomap" appended.
Mozilla Location Service
<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')."

But I've sent my query to the Apple VP so I expect a response from Apple.

My query shows that my exact location is clearly identified by Apple's WPS database, so I believe this is a class-action-suit valid privacy flaw.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

My query shows that my exact location is clearly identified by Apple's WPS database, so I believe this is a class-action-suit valid privacy flaw.

UPDATE:

While I was documenting the problem set, I noticed that the number of
decimal places is only 6 in the web page but 8 in the python query.

a. https://wavedigger.networksurvey.app/?tab=bssid&bssid=11-22-33-AA-BB-CC
b. python.exe apple_bssid_locator.py 11:22:33:AA:BB:CC

*<https://i.postimg.cc/C5Pcb6RQ/decimal.jpg>*

But it doesn't really matter, at least not with theoretical calculations:
6 decimal places: ~11 cm resolution.
8 decimal places: ~1 mm resolution.
The specific difference between them is only about 4cm.

What's really different is if you live in the boonies, the BSSID is you.
If you're in the city, the BSSID might be you or people close to you.

Note: It also matters how "close to your BSSID" the Apple devices are.
In my case, they're right here, next to me, so they're close to the router.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Here's how to query Apple's insecure WPS database for hundreds of
BSSID:GPS location pairs, simply by feeding the database one BSSID.

0. python apple_bssid_locator.py 11:22:33:AA:BB:CC
only gives you a single BSSID:GPS pair accurate to 8 decimal places.
1. Edit apple_bssid_locator.py in the previous GitHub download package.
<https://github.com/darkosancanin/apple_bssid_locator>
2. Note that query_bssid() has the following limitation built in:
apple_wloc.return_single_result = 1 (i.e., "yes")
3. Then in process_result(), the code loops through apple_wloc.wifi_devices
and extracts only those with a location field. It builds a dictionary of
{BSSID: (lat, lon)}.
4. In main(), unless you pass --all, it only prints the coordinates for
the one BSSID you asked about.
5. However, Apple's API actually returns a cluster of nearby APs
(hundreds of BSSIDs) when you don't restrict it from doing so.
6. To get *hundreds* of nearby BSSID:GPS pairs, simply change the
def query_bssid(bssid, output_file="results.txt") as shown below.
9. Now run the python script again:
python apple_bssid_locator.py 11:22:33:AA:BB:CC --all
10. You'll get *hundreds* of access point location pairs now!

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'):
lat = wifi_device.location.latitude * 1e-8
lon = wifi_device.location.longitude * 1e-8
mac = format_bssid(wifi_device.bssid)
results[mac] = (lat, lon)
f.write(f"{mac}\t{lat}\t{lon}\n")

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

Note that we can plot those ~400 entries on a map with Python's folium
library so you can visually explore the cluster instead of scrolling.
--
Apple "says" they care about your privacy; but their actions
show that they don't follow their own privacy policies.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Note that we can plot those ~400 entries on a map with Python's folium library so you can visually explore the cluster instead of scrolling.

Here's how to display those hundreds of BSSID:GPS pairs on a local map.

Download the folium source archive <https://pypi.org/project/folium/#files> <https://files.pythonhosted.org/packages/c7/76/84a1b1b00ce71f9c0c44af7d80f310c02e2e583591fe7d4cb03baecd0d3f/folium-0.20.0.tar.gz>
Name: folium-0.20.0.tar.gz
Size: 109932 bytes (107 KiB)
SHA256: A0D78B9D5A36BA7589CA9AEDBD433E84E9FCAB79CD6AC213ADBCFF922E454CB9 C:\app\archiver\7zip\7z.exe xfolium-0.20.0.tar.gz
C:\app\archiver\7zip\7z.exe x folium-0.20.0.tar
xcopy /E /I folium-0.20.0\folium C:\app\os\python\Lib\site-packages\folium
53 files copied
C:\app\os\python\python.exe -c "import folium; print(folium.__version__)"

Download the latest branca release from PyPI: <https://pypi.org/project/branca/#files> https://files.pythonhosted.org/packages/32/14/9d409124bda3f4ab7af3802aba07181d1fd56aa96cc4b999faea6a27a0d2/branca-0.8.2.tar.gz
Name: branca-0.8.2.tar.gz
Size: 27890 bytes (27 KiB)
SHA256: E5040F4C286E973658C27DE9225C1A5A7356DD0702A7C8D84C0F0DFBDE388FE7 C:\app\archiver\7zip\7z.exe x branca-0.8.2.tar.gz
C:\app\archiver\7zip\7z.exe x branca-0.8.2.tar

xcopy /E /I branca-0.8.2\branca C:\app\os\python\Lib\site-packages\branca

10 files copied
C:\app\os\python\python.exe -c "import branca; print(branca.__version__)"

Download Jinja2 source archive
<https://pypi.org/project/Jinja2/#files> https://files.pythonhosted.org/packages/df/bf/f7da0350254c0ed7c72f3e33cef02e048281fec7ecec5f032d4aac52226b/jinja2-3.1.6.tar.gz
Name: jinja2-3.1.6.tar.gz
Size: 245115 bytes (239 KiB)
SHA256: 0137FB05990D35F1275A587E9AEE6D56DA821FC83491A0FB838183BE43F66D6D C:\app\archiver\7zip\7z.exe x Jinja2-3.1.6.tar.gz
C:\app\archiver\7zip\7z.exe x Jinja2-3.1.6.tar
xcopy /E /I Jinja2-3.1.6\src\jinja2 C:\app\os\python\Lib\site-packages\jinja2 26 files copied
C:\app\os\python\python.exe -c "import jinja2; print(jinja2.__version__)"

Since this is getting tedious, I'll install pip:
C:\app\os\python\python.exe -m ensurepip

And then I'll install the rest of the dependencies.
C:\app\os\python\python.exe -m pip install markupsafe C:\app\os\python\python.exe -m pip install numpy
C:\app\os\python\python.exe -m pip install xyzservices

Test:
C:\app\os\python\python.exe -c "import folium; print(folium.__version__)" C:\app\os\python\python.exe -c "import folium; m = folium.Map(location=[0,0], zoom_start=2); m.save('test_map.html'); print('OK')"

python plot_bssid.py
Map saved to bssid_map.html

start msedge "C:\app\os\python\apple_bssid_locator\bssid_map.html"
Voila! Up to 400 nearest access points on the map in a single query.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Here's how to display those hundreds of BSSID:GPS pairs on a local map.

Here is a display of just 400 for an arbitrary Netgear BSSID.
<https://i.postimg.cc/43ysV3Mr/fermium.jpg>

If we want a radial expansion crawler for Apple's WPS database, do this:
1. Choose any arbitrary Netgear (00:22:3f) BSSID (e.g., 00:22:3f:a5:7b:33)
2. Get the whole cluster of 400 BSSID pairs from Apple
python.exe apple_bssid_locator.py 00:22:3f:a5:7b:33 --all
3. This outputs up to 400 BSSID:GPS pairs near it in the Apple WPS DB
(see results.txt below)

Then any BSSID in that cluster (e.g., 34:08:04:cb:b2:a4, D-Link)
And do it again.

Choose another BSSID (e.g., 00:23:aa:d9:6b:ca from HFR, Inc.)
Get another 400.

Keep repeating (e.g., 28:4E:E9:3F:5F:9F from Mercury Corp.)
Easily anyone can garner billions of BSSID:AP pairs from Apple's WPS.

Then all you need to do is track them, en masse.
If I can do this so easily, anyone can.

I plotted them using AppleLocator & Fermium open source software.
python.exe bssidplot.py

Here is a screenshot of the location of those 400 BSSID:GPS pairs:
<https://i.postimg.cc/43ysV3Mr/fermium.jpg>

Here's just the first 400 found, so you can see the BSSID:GPS pairs.
1 00:22:3f:a5:7b:33 35.29422378 126.77641296
2 10:62:e5:b1:8f:12 35.29444885 126.77671051
3 12:09:a5:53:df:13 35.29491043 126.77599334
4 28:6d:97:4f:be:d0 35.29439163 126.77655029
5 28:6d:97:b9:89:96 35.29463195 126.77554321000001
6 42:09:a5:53:df:13 35.294940940000004 126.7760086
7 04:09:a5:53:df:13 35.29491043 126.77601623
8 50:46:ae:f2:9b:15 35.29492568 126.77648162
9 58:86:94:51:6b:0e 35.2944374 126.77667999
10 88:36:6c:06:65:38 35.29442214 126.77668762
11 88:57:1d:4b:a6:79 35.29385757 126.77546691
12 08:5d:dd:9c:c4:93 35.294841760000004 126.77540588000001
13 b0:38:6c:75:10:7e 35.29403686 126.77572631
14 28:6d:97:c8:5a:30 35.2948265 126.77577972
15 70:2c:1f:66:28:49 35.29447174 126.77656555
16 70:2c:1f:66:08:0d 35.2939682 126.77562713
17 70:5d:cc:1e:34:6c 35.29422378 126.77565765
18 70:2c:1f:85:d7:cd 35.29440307 126.7756195
19 88:36:6c:b7:02:b0 35.29481506 126.7758255
20 0c:96:cd:7d:33:96 35.293926230000004 126.77541351
21 bc:10:2f:62:e7:38 35.29484558 126.77593231
22 70:2c:1f:86:e6:51 35.29470825 126.77540588000001
23 70:2c:1f:5d:06:a8 35.294750210000004 126.77560424
24 66:cb:e9:62:81:c6 35.294433590000004 126.77537536
25 6c:72:20:5f:c5:7f 35.293998710000004 126.7753601
26 88:57:1d:3b:3e:e7 35.29479598 126.77539825000001
27 88:36:6c:1a:6e:7e 35.29494857 126.77605438
28 bc:10:2f:51:f7:01 35.29452514 126.77631378000001
29 84:72:07:c6:c7:46 35.29398727 126.77539062
30 62:ab:14:39:fc:a7 35.29427337 126.77566528
31 18:c5:01:df:c0:52 35.29442977 126.77673339
32 32:34:db:e6:91:9c 35.29437637 126.77770233
33 80:ca:4b:96:73:ce 35.29488372 126.77695465000001
34 e0:4f:43:a8:56:13 35.29393768 126.77700042000001
35 2c:2b:f9:f5:ac:72 35.29459381 126.77682495
36 00:23:aa:91:74:ae 35.293952940000004 126.7747879
37 00:23:aa:d5:31:e6 35.294025420000004 126.77478027000001
38 00:07:89:64:05:2b 35.29449844 126.77486419
39 12:23:aa:91:74:ae 35.29396057 126.7747879
40 12:23:aa:d5:31:e6 35.2940216 126.77477264000001
41 12:23:aa:d9:6b:ca 35.29397201 126.77490997
42 12:96:cd:6b:19:c7 35.294216150000004 126.77531433
43 12:96:cd:76:a8:be 35.29397583 126.77486419
44 12:96:cd:82:58:bb 35.2938919 126.77524566
45 12:96:cd:97:53:cb 35.29416656 126.77466583
46 12:09:a5:26:14:df 35.29400253 126.77489471
47 12:09:a5:28:93:bf 35.2939949 126.7747879
48 12:09:a5:47:38:27 35.2939186 126.77476501
49 12:f4:5e:24:59:0b 35.29406738 126.77428436
50 18:34:af:ec:5a:4b 35.29441833 126.77522277
51 18:c5:01:8b:f0:ce 35.29394531 126.77485656
52 18:c5:01:9c:33:b2 35.29389572 126.77508544
53 1c:a5:32:f8:79:46 35.29492568 126.7751007
54 1e:96:cd:6b:19:c7 35.29414749 126.77529907
55 26:e8:53:a0:7d:87 35.29396438 126.77490997
56 28:4e:e9:1e:da:cd 35.29407501 126.77472686
57 28:6d:97:8e:ed:f9 35.29458999 126.77532958
58 28:6d:97:a8:10:98 35.29386901 126.77482604000001
59 28:6d:97:b8:24:44 35.29405212 126.77482604000001
60 28:6d:97:ca:55:74 35.293853750000004 126.77509307
61 28:6d:97:fb:b4:7f 35.29400634 126.77506256000001
62 28:6d:97:fd:be:af 35.293952940000004 126.77492523000001
63 2e:2b:f9:47:2e:0b 35.29449081 126.77493286
64 2e:4e:e9:1e:da:cd 35.294071190000004 126.77472686
65 32:34:db:87:4e:74 35.29406738 126.77487182
66 34:08:04:cb:b2:a4 35.29445648 126.77491760000001
67 38:f4:5e:24:59:0b 35.2940483 126.7743225
68 40:ca:63:38:79:57 35.294651030000004 126.7744522
69 40:ca:63:a6:95:21 35.29398727 126.77502441
70 40:ca:63:c9:8d:90 35.29455947 126.77455902
71 40:ca:63:fb:52:c7 35.29405212 126.77509307
72 42:23:aa:91:74:ae 35.29395675 126.7747879
73 42:23:aa:d5:31:e6 35.29402923 126.77478027000001
74 42:23:aa:d9:6b:ca 35.29397964 126.77489471
75 42:09:a5:26:14:df 35.29401016 126.77489471
76 04:09:a5:26:14:df 35.29401016 126.77487945
77 04:09:a5:28:93:bf 35.2939949 126.77479553
78 04:09:a5:47:38:27 35.29393386 126.77478027000001
79 4c:bc:e9:e0:4d:62 35.2941246 126.77487182
80 50:46:ae:9c:ed:1d 35.29426193 126.77402496
81 50:46:ae:0e:33:c8 35.29411315 126.77483367
82 50:fd:d5:9b:2f:a4 35.29397583 126.77503967
83 56:46:ae:9c:ed:1d 35.29429626 126.77403259
84 58:86:94:3b:9b:e8 35.29405975 126.77502441
85 58:86:94:c8:86:c6 35.294414520000004 126.77493286
86 60:29:d5:01:ab:2a 35.29401779 126.77490234
87 60:29:d5:01:ab:ac 35.29401397 126.77486419
88 64:e5:99:92:21:c4 35.294097900000004 126.7747116
89 70:2c:1f:7c:04:a1 35.29401397 126.77471923
90 70:2c:1f:7e:1b:80 35.29478454 126.77527618
91 70:5d:cc:17:36:d0 35.29401779 126.7751007
92 70:5d:cc:31:12:da 35.294624320000004 126.77457427
93 70:5d:cc:44:b0:70 35.29401779 126.77478027000001
94 70:5d:cc:58:94:0c 35.29427719 126.77507019000001
95 70:5d:cc:ae:2c:40 35.294025420000004 126.77418518
96 70:5d:cc:d6:65:3c 35.29397583 126.77494049
97 72:5d:cc:4d:12:38 35.29391479 126.77490997
98 80:ca:4b:de:ab:22 35.29398345 126.77497863
99 82:5b:65:d0:02:de 35.29393005 126.77513122
100 84:72:07:28:1f:bb 35.29398345 126.77481842
101 88:36:6c:b7:5c:c0 35.29442596 126.77468872
102 88:3c:1c:2f:3b:31 35.29406738 126.77477264000001
103 88:3c:1c:3e:e8:d9 35.2940216 126.77485656
104 88:3c:1c:9e:a3:53 35.29408645 126.7741394
105 88:57:1d:25:89:12 35.2939949 126.77497863
106 08:5d:dd:ba:5e:32 35.29398345 126.77481842
107 08:5d:dd:f7:51:14 35.29397583 126.77490234
108 08:5d:dd:f7:51:15 35.29397201 126.77489471
109 90:9f:33:8c:00:4a 35.2940216 126.77497100000001
110 98:77:e7:a7:76:4b 35.29403305 126.77467346
111 b0:38:6c:08:bd:c2 35.29397583 126.77470397
112 b0:95:75:86:b9:74 35.29386901 126.77503204
113 b4:a9:4f:34:ca:47 35.29388809 126.77496337000001
114 b4:a9:4f:35:52:19 35.29395675 126.77474975
115 b4:a9:4f:35:52:8c 35.29396057 126.77487945
116 b4:a9:4f:3b:2b:6b 35.29397964 126.77478027000001
117 b4:a9:4f:5f:b5:e6 35.29403686 126.77477264000001
118 b4:a9:4f:c8:51:d7 35.29393768 126.77516937
119 ba:16:5f:7d:c0:48 35.2938919 126.77491760000001
120 ba:16:5f:f2:fe:83 35.29394149 126.7751007
121 ba:a9:4f:3b:2b:6b 35.2939682 126.77477264000001
122 ba:a9:4f:5f:b5:e6 35.29404067 126.77477264000001
123 c6:a9:4f:3b:2b:6b 35.29397964 126.77479553
124 c6:a9:4f:3b:2b:73 35.29400253 126.77507019000001
125 c6:a9:4f:5f:b5:e6 35.29404449 126.77477264000001
126 0c:96:cd:6b:19:c7 35.29427337 126.77532958
127 0c:96:cd:76:a8:be 35.29397201 126.77487182
128 0c:96:cd:82:58:bb 35.29390335 126.77524566
129 0c:96:cd:97:53:cb 35.29416656 126.77467346
130 0c:96:cd:d7:05:73 35.29412078 126.77482604000001
131 ca:dd:6a:5c:51:c4 35.2938385 126.77484893
132 d6:8d:26:b9:0e:a0 35.29396438 126.7747879
133 dc:03:98:10:52:eb 35.29436492 126.77451324
134 dc:03:98:f0:84:b5 35.293926230000004 126.77478027000001
135 e2:85:4d:c1:cc:3c 35.29401779 126.7745819
136 e2:85:4d:e6:ce:00 35.293998710000004 126.77483367
137 f0:a7:31:56:45:4f 35.294025420000004 126.77482604000001
138 00:23:aa:84:14:56 35.29405975 126.77496337000001
139 00:23:aa:d9:6b:ca 35.29398727 126.77490234
140 00:07:89:71:65:06 35.293998710000004 126.77493286
141 00:07:89:be:b3:9e 35.29387664 126.77532196
142 12:23:aa:84:14:56 35.29405593 126.77495574
143 12:f4:5e:09:0c:2b 35.29396057 126.77478027000001
144 00:07:89:3e:ce:8e 35.29343032 126.77546691
145 1c:39:29:15:1a:97 35.29319 126.77552032
146 1c:ec:72:45:77:ff 35.29330444 126.77597045
147 1c:ec:72:0e:9e:66 35.29335784 126.77597808
148 24:e4:ce:e9:b8:1a 35.29360961 126.77551269
149 28:4e:e9:72:bd:63 35.29364395 126.77557373
150 28:6d:97:fc:b1:96 35.29290771 126.77545928
151 2e:4e:e9:72:bd:63 35.29365158 126.7755661
152 50:46:ae:03:9c:7d 35.29377365 126.77552795
153 50:46:ae:6d:18:8e 35.29364395 126.77555847
154 50:fd:d5:45:20:a0 35.2933464 126.77579498
155 50:fd:d5:4a:45:03 35.29329299 126.7758255
156 58:86:94:5e:39:36 35.29370117 126.77565002
157 58:86:94:a1:ad:e0 35.29339218 126.77581024
158 58:86:94:b1:55:5a 35.29357528 126.77536773
159 82:5b:65:19:66:b8 35.29380416 126.77572631
160 88:36:6c:42:e2:ec 35.29283523 126.77633666
161 08:5d:dd:8d:b0:37 35.29360961 126.77565765
162 a6:fe:ce:15:de:26 35.29319763 126.77601623
163 0c:96:cd:c8:2a:19 35.293056480000004 126.77550506
164 fa:b9:5a:6a:e3:00 35.29277801 126.77539062
165 fc:5c:45:46:9d:48 35.29340744 126.7758255
166 fc:5c:45:06:9d:48 35.29340744 126.7758255
167 fc:5c:45:86:9d:48 35.29340744 126.7758255
168 fc:5c:45:c6:9d:48 35.29340744 126.77581787
169 50:fd:d5:07:11:9b 35.29300689 126.77578735
170 64:64:4a:33:0c:3e 35.29356384 126.7754364
171 6a:64:4a:33:0c:3e 35.29358673 126.7754364
172 70:2c:1f:78:fe:44 35.29364013 126.77554321000001
173 88:36:6c:6c:31:8e 35.29355239 126.77546691
174 88:3c:1c:38:c6:8e 35.29273986 126.77539825000001
175 88:57:1d:4e:cd:1d 35.29319763 126.77539825000001
176 90:9f:33:5d:08:9d 35.29358291 126.77548217
177 c2:18:03:e3:70:b6 35.2934494 126.77558135
178 70:4f:57:59:1d:57 35.29375457 126.77557373
179 42:2f:86:c4:12:bb 35.29371261 126.7754898
180 42:2f:86:5b:ec:e3 35.29367828 126.77536773
181 00:23:aa:b8:61:ea 35.29595565 126.77580261
182 00:23:aa:d2:67:62 35.2959671 126.77572631
183 12:23:aa:b8:61:ea 35.29595184 126.77581787
184 12:23:aa:d2:67:62 35.2959671 126.77571868
185 12:09:a5:52:24:33 35.29557418 126.77597808
186 28:4e:e9:1f:4f:bd 35.29550933 126.77599334
187 28:4e:e9:4f:84:3c 35.29525375 126.7754364
188 2e:4e:e9:1f:4f:bd 35.29548263 126.77599334
189 32:34:db:b7:bf:52 35.29513931 126.77604675
190 40:ca:63:4d:fb:07 35.29502105 126.77587890000001
191 42:23:aa:b8:61:ea 35.29593276 126.7758255
192 42:23:aa:d2:67:62 35.2959671 126.77572631
193 04:09:a5:52:24:33 35.29559707 126.77596282
194 50:46:ae:14:9f:ac 35.29539108 126.77660369
195 50:46:ae:b2:d5:1b 35.29593276 126.77581024
196 56:46:ae:1c:6e:83 35.29578781 126.77605438
197 5a:86:94:48:21:38 35.295520780000004 126.7757492
198 60:29:d5:39:58:2a 35.29598236 126.77574157000001
199 60:29:d5:6b:19:8f 35.29590988 126.77638244
200 70:5d:cc:b9:a1:f6 35.29498291 126.77603912000001
201 80:ca:4b:5d:e5:46 35.29542541 126.776268
202 80:ca:4b:71:79:12 35.29504394 126.77605438
203 88:36:6c:57:9c:a2 35.2950325 126.77564239
204 88:3c:1c:4e:12:45 35.29601287 126.77585601
205 88:3c:1c:89:49:a9 35.29549789 126.77614593
206 88:3c:1c:d6:ae:d6 35.29568099 126.77609252
207 08:5d:dd:4c:e2:50 35.29590606 126.77584075
208 98:25:4a:46:98:50 35.29500961 126.77645874000001
209 b0:38:6c:0f:6c:ea 35.29594421 126.77574157000001
210 b4:a9:4f:1c:62:95 35.29594802 126.77580261
211 b4:a9:4f:5d:88:dd 35.29548263 126.77631378000001
212 0c:96:cd:c5:52:57 35.29553604 126.77602386000001
213 00:23:aa:d3:c3:ca 35.2959671 126.77546691
214 12:23:aa:d3:c3:ca 35.29594802 126.77545928
215 42:23:aa:d3:c3:ca 35.29596328 126.77547454
216 50:46:ae:1c:6e:83 35.2957611 126.77603912000001
217 50:46:ae:4f:a9:1d 35.29562759 126.77622985
218 50:46:ae:5d:d3:f7 35.29534912 126.77606201
219 50:46:ae:e7:8d:c4 35.29591369 126.77559661000001
220 56:46:ae:4f:a9:1d 35.2956047 126.77623748
221 58:86:94:14:f9:ba 35.29558181 126.77615356
222 60:29:d5:7d:5d:fd 35.2958641 126.77609252
223 62:46:ae:4f:a9:1d 35.295593260000004 126.77624511
224 80:ca:4b:34:ec:1e 35.29566955 126.776268
225 80:ca:4b:41:d1:52 35.29566955 126.77622985
226 80:ca:4b:0e:c5:3e 35.29570388 126.77613067
227 88:3c:1c:90:63:f5 35.29584121 126.77608489
228 08:5d:dd:12:9f:54 35.29575729 126.77597808
229 08:5d:dd:a9:cb:af 35.29591751 126.77636718000001
230 08:5d:dd:be:69:63 35.29563522 126.77593994
231 8a:36:6c:cd:e0:5c 35.29602432 126.77600097
232 8a:3c:1c:90:63:f5 35.29586029 126.77609252
233 90:9f:33:78:60:78 35.29604721 126.77536773
234 0a:5d:dd:12:9f:54 35.29576873 126.77599334
235 0a:5d:dd:be:69:63 35.29561614 126.77594757
236 ba:3c:1c:90:63:f5 35.29584121 126.77608489
237 bc:62:ce:50:29:f0 35.29520034 126.77637481000001
238 c4:e5:32:e5:78:29 35.29533767 126.77600097
239 0c:96:cd:12:e0:47 35.29539108 126.77577972
240 0c:b6:d2:85:1c:3a 35.29597091 126.77560424
241 00:23:aa:c1:1d:02 35.29595947 126.7756195
242 12:23:aa:c1:1d:02 35.29595184 126.7756195
243 1c:ec:72:50:6f:70 35.29543304 126.77540588000001
244 42:23:aa:c1:1d:02 35.29595565 126.7756195
245 9c:a2:f4:d0:8d:c6 35.29564285 126.77597045
246 28:6b:b4:c0:5b:fd 35.29556274 126.77666473000001
247 e4:be:ed:51:e7:f0 35.29564285 126.77607727
248 54:7e:1a:6e:b9:00 35.295448300000004 126.77601623
249 5a:7e:1a:6e:b9:00 35.29544067 126.77601623
250 2e:4e:e9:3f:5f:9f 35.295783990000004 126.77563476
251 28:4e:e9:3f:5f:9f 35.29577636 126.77563476
252 3a:4e:e9:3f:5f:9f 35.29579544 126.77563476
253 1c:e8:9e:36:ea:e4 35.29504776 126.77577972
254 50:46:ae:b1:7e:ff 35.29569244 126.77593994
255 2e:4e:e9:72:8c:d3 35.29540634 126.77609252
256 60:29:d5:ae:2f:78 35.29601669 126.77584838
257 1c:39:29:0d:c0:f9 35.29532623 126.77611541
258 28:4e:e9:72:8c:d3 35.29532623 126.77609252
259 28:6d:97:45:5d:fe 35.29581451 126.77599334
260 80:ca:4b:fe:bd:16 35.29531478 126.77584838
261 50:46:ae:97:56:d0 35.29354858 126.77711486
262 70:5d:cc:96:d5:de 35.293807980000004 126.77748107000001
263 90:9f:33:64:90:d8 35.293109890000004 126.77729034000001
264 00:23:aa:41:0b:f1 35.29380416 126.77499389
265 00:23:aa:47:4a:8e 35.29299545 126.77468872
266 00:23:aa:8e:a2:6a 35.29364395 126.77468872
267 00:23:aa:d9:1b:fa 35.29375076 126.77507781
268 00:27:1c:c7:a1:d4 35.293399810000004 126.77511596000001
269 00:07:89:28:8d:bc 35.292892450000004 126.77526092000001
270 00:07:89:9e:cc:91 35.293472290000004 126.77475738
271 00:07:89:ca:9f:fb 35.29371643 126.77400207000001
272 00:07:89:ca:b9:41 35.29336929 126.77438354
273 00:07:89:d7:82:e8 35.292964930000004 126.7747116
274 00:08:52:3c:9c:a1 35.292892450000004 126.77485656
275 00:08:52:3c:9c:a3 35.29287338 126.77482604000001
276 12:23:aa:47:4a:8e 35.29300308 126.77464294
277 12:23:aa:8e:a2:6a 35.29363632 126.77469635
278 12:23:aa:d9:1b:fa 35.29372024 126.77511596000001
279 12:96:cd:3a:35:df 35.29302978 126.7745819
280 12:96:cd:72:cd:ac 35.29304504 126.77478027000001
281 12:96:cd:c5:52:5c 35.29300308 126.77407836
282 12:96:cd:ce:f8:59 35.292865750000004 126.77511596000001
283 12:09:a5:33:3c:1f 35.29299163 126.7745285
284 12:09:a5:3b:34:67 35.293590540000004 126.77492523000001
285 12:09:a5:51:bf:f7 35.29328155 126.7743988
286 12:f4:5e:0e:72:4b 35.29298782 126.77419281
287 16:7f:67:7f:34:e6 35.29353332 126.77502441
288 18:c5:01:a9:50:2a 35.29311752 126.77510833000001
289 18:c5:01:bc:ea:2a 35.29365539 126.7750473
290 1c:39:29:1c:b9:5f 35.29294204 126.77481842
291 1c:a5:32:f7:8c:62 35.2930603 126.77507019000001
292 1c:e8:9e:0c:10:c0 35.29355621 126.77524566
293 1c:ec:72:50:6d:3b 35.29362869 126.77480316
294 1c:ec:72:58:f1:18 35.2936058 126.77477264000001
295 1c:ec:72:58:f4:92 35.2936058 126.77458953
296 1e:39:29:6a:46:b3 35.29361343 126.7751007
297 22:23:aa:41:0b:f1 35.29380416 126.77499389
298 22:28:bc:62:51:86 35.29367828 126.77466583
299 22:ec:72:58:f1:18 35.29359817 126.77478027000001
300 22:ec:72:58:f4:92 35.29360198 126.77459716
301 24:e4:ce:e9:08:5e 35.29356384 126.77487945
302 24:e8:53:44:16:ac 35.29319763 126.77447509
303 24:e8:53:83:bb:c8 35.29280471 126.77515411
304 28:4e:e9:0f:76:93 35.293109890000004 126.77518463
305 28:6d:97:45:4a:f1 35.29365539 126.7747879
306 28:6d:97:54:1f:95 35.29356384 126.77507781
307 28:6d:97:8c:3a:cc 35.29358673 126.77488708
308 28:6d:97:94:dd:11 35.29353332 126.77497100000001
309 28:6d:97:d3:39:b0 35.29335784 126.77461242
310 28:6d:97:ea:1c:91 35.29302978 126.77452087
311 28:6d:97:fa:4e:21 35.29309463 126.77483367
312 02:27:1c:c7:a1:d4 35.29340362 126.77513885
313 2c:e3:8e:8c:e2:40 35.293537130000004 126.77416229
314 2c:e3:8e:8d:d6:00 35.29319763 126.77423095
315 2c:e3:8e:97:ea:e0 35.29323196 126.77420806
316 2e:4e:e9:0f:76:93 35.29309844 126.77519226
317 38:f4:5e:1e:ae:54 35.29291534 126.77449798
318 38:f4:5e:1e:ca:ba 35.29366683 126.77496337000001
319 38:f4:5e:0e:72:4b 35.2929573 126.77411651
320 3a:f4:5e:1e:ae:54 35.29293823 126.77452087
321 40:31:3c:9e:30:2a 35.29349136 126.77481842
322 40:ca:63:31:16:62 35.29356384 126.77497100000001
323 42:23:aa:47:4a:8e 35.29300308 126.77468872
324 42:23:aa:8e:a2:6a 35.29364395 126.77470397
325 42:23:aa:d9:1b:fa 35.29373168 126.7751007
326 42:2f:86:6c:f7:a6 35.29342651 126.77515411
327 46:cb:8b:bf:c6:22 35.293254850000004 126.77453613
328 46:cb:8b:e1:7a:68 35.29336929 126.77529907
329 04:09:a5:33:3c:1f 35.29300689 126.77457427
330 04:09:a5:3b:34:67 35.29359817 126.77489471
331 04:09:a5:51:bf:f7 35.29329299 126.77440643
332 50:46:ae:74:a1:bd 35.293056480000004 126.77466583
333 50:46:ae:8c:71:91 35.29356765 126.77516174
334 50:46:ae:9d:34:99 35.29345321 126.77519226
335 50:46:ae:d7:ba:f4 35.29364013 126.77487182
336 50:46:ae:0e:0e:a7 35.293445580000004 126.77497100000001
337 50:91:e3:95:60:a6 35.292819970000004 126.77423858
338 50:fd:d5:6e:61:5c 35.29358673 126.77481842
339 50:fd:d5:82:fc:ab 35.29352188 126.77413177
340 50:fd:d5:90:27:6f 35.29364395 126.77474212
341 54:7e:1a:0a:d1:97 35.29342651 126.77449798
342 5a:7e:1a:0a:d1:97 35.29345703 126.7745285
343 60:29:d5:00:dd:8f 35.29349517 126.7750473
344 60:29:d5:01:2f:c4 35.29323959 126.77463531000001
345 60:29:d5:a7:54:18 35.2928276 126.77506256000001
346 60:29:d5:ae:12:9f 35.29360198 126.7751007
347 62:91:e3:95:60:a6 35.29280853 126.77423858
348 68:3a:48:1f:65:7e 35.29356002 126.77505493
349 70:2c:1f:55:eb:a2 35.29368591 126.77475738
350 70:2c:1f:56:e0:55 35.293518060000004 126.77509307
351 70:5d:cc:6e:44:56 35.29328918 126.7748413
352 70:5d:cc:6f:ef:16 35.29357147 126.77500152
353 70:5d:cc:ad:a6:80 35.29349517 126.77519226
354 70:5d:cc:c6:50:fe 35.2931137 126.77483367
355 76:40:be:65:42:a8 35.29277038 126.77419281
356 80:ca:4b:1b:06:72 35.29290771 126.77441406
357 80:ca:4b:55:89:7a 35.2935791 126.77481842
358 1c:ec:72:43:68:57 35.29525756 126.77693939000001
359 70:5d:cc:52:21:c6 35.29499435 126.77783203
360 b4:a9:4f:62:c5:e6 35.295158380000004 126.77710723
361 ba:a9:4f:62:c5:e6 35.2951622 126.77732086
362 c6:a9:4f:62:c5:e6 35.29518127 126.77729797
363 00:07:89:3d:bb:7f 35.29569244 126.7743988
364 12:f4:5e:0b:66:df 35.2950592 126.77472686
365 1c:e8:9e:ca:d9:47 35.29525375 126.77410888
366 28:4e:e9:01:ba:b3 35.29596328 126.77406311
367 28:4e:e9:0d:0d:af 35.29594802 126.77472686
368 28:6b:b4:03:cd:17 35.29567337 126.77416229
369 2e:4e:e9:01:ba:b3 35.2959671 126.77399444
370 2e:4e:e9:0d:0d:af 35.29602813 126.77479553
371 38:f4:5e:0b:66:df 35.29501724 126.77464294
372 40:ca:63:bf:f5:ae 35.2952156 126.77403259
373 50:46:ae:5d:0e:9f 35.29600906 126.77487182
374 50:46:ae:75:63:80 35.29568481 126.77436065
375 50:fd:d5:17:93:c6 35.29563522 126.77405548
376 60:29:d5:b1:81:d5 35.29579544 126.77490997
377 64:cb:e9:13:8a:9a 35.29558944 126.77423095
378 70:5d:cc:c9:14:7a 35.29550933 126.77415466000001
379 88:3c:1c:ab:fc:0b 35.29561614 126.77500152
380 88:57:1d:0b:82:39 35.29566192 126.77424621
381 b4:a9:4f:1c:65:fb 35.29603576 126.77462005
382 b4:a9:4f:02:67:5a 35.29568099 126.77456665
383 28:6d:97:ae:c2:c8 35.29577255 126.77462005
384 28:6d:97:f6:fa:f2 35.29536056 126.7746582
385 28:6d:97:f7:df:11 35.294967650000004 126.77506256000001
386 3a:5d:dd:df:15:57 35.29603576 126.77470397
387 50:46:ae:4f:80:d5 35.29581832 126.7747116
388 50:fd:d5:a5:59:18 35.29528427 126.77491760000001
389 56:46:ae:4f:80:d5 35.29584503 126.77473449
390 60:29:d5:63:d3:16 35.29602813 126.77519989
391 70:2c:1f:86:e5:2e 35.295040130000004 126.77532196
392 86:25:19:ca:f1:c7 35.29604339 126.77488708
393 88:36:6c:5d:7f:bc 35.29579544 126.77529144
394 08:5d:dd:df:15:57 35.29601669 126.7745285
395 0a:5d:dd:df:15:57 35.29604721 126.77451324
396 bc:10:2f:7f:ba:0b 35.29519653 126.77412414
397 da:e3:5e:5c:38:66 35.2957611 126.77399444
398 f0:09:0d:25:82:e2 35.2951889 126.77474975
399 70:2c:1f:6f:85:60 35.29552459 126.77452087

It's trivial for anyone to imagine we can do this forever
until we have every AP listed that is in Apple's WPS database.
--
I am not here for my ego; nor for my amusement; but to teach & learn.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Here is a display of just 400 for an arbitrary Netgear BSSID.
<https://i.postimg.cc/43ysV3Mr/fermium.jpg>

Here is code I hacked out this morning which tracks those 400 BSSID:GPS
pairs, where I set the distance to 100KM but it could be any distance.

If I can write this code, certainly anyone can (since I'm not a coder).

That's the scary part about how easy Apple makes the entire WPS DB
available to anyone in the world without any restrictions whatsoever.


@echo off
:: This is C:\app\os\python\apple_bssid_locator\bssidcompare.bat
:: v1p0 20251215
:: Outputs if there is movecment for any given BSSID in results.txt

setlocal enabledelayedexpansion

:: Threshold for movement (where 0.001 degrees is roughly 100 kilometers)
set THRESH=0.001

:: Input file collected using apple_bssid_locator open source code
:: These are actual BSSID:GPS pairs which you can test yourself!
:: 28:6d:97:c8:5a:30 35.2948265 126.77577972
:: 00:22:3f:a5:7b:33 35.29422378 126.77641296
:: 10:62:e5:b1:8f:12 35.29444885 126.77671051
:: 12:09:a5:53:df:13 35.29491043 126.77599334
:: 28:6d:97:4f:be:d0 35.29439163 126.77655029
:: 28:6d:97:b9:89:96 35.29463195 126.77554321000001
:: 42:09:a5:53:df:13 35.294940940000004 126.7760086

set INFILE=results.txt

echo Checking for GPS movement greater than %THRESH% degrees...
echo.

:: Loop through each line of results.txt
for /f "tokens=1,2,3 delims= " %%A in (%INFILE%) do (
set BSSID=%%A
set LAT=%%B
set LON=%%C

:: If we've seen this BSSID before, compare
if defined lastLAT[!BSSID!] (
set /a diffLAT=1000000*( !LAT! - !lastLAT[!BSSID!]! )
set /a diffLON=1000000*( !LON! - !lastLON[!BSSID!]! )

:: Convert to absolute values
if !diffLAT! lss 0 set /a diffLAT=-!diffLAT!
if !diffLON! lss 0 set /a diffLON=-!diffLON!

:: Compare against threshold (scaled by 1,000,000)
set /a threshScaled=%THRESH%*1000000
if !diffLAT! gtr !threshScaled! (
echo BSSID !BSSID! moved in LAT by more than %THRESH% degrees
)
if !diffLON! gtr !threshScaled! (
echo BSSID !BSSID! moved in LON by more than %THRESH% degrees
)
)

:: Store current coordinates
set lastLAT[!BSSID!]=!LAT!
set lastLON[!BSSID!]=!LON!
)

echo.
echo Comparison complete.
endlocal

:: end of C:\app\os\python\apple_bssid_locator\bssidcompare.bat
--
If I can do this, anyone can.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Here is code I hacked out this morning which tracks those 400 BSSID:GPS pairs, where I set the distance to 100KM but it could be any distance.

Here is code that generates random (or sequential) BSSIDs to place into a
file which can later be checked against Apple's highly insecure WPS DB.

bssidgenerate.bat

Select an OUI from the menu or press Enter to type your own:
1) TP-Link F4:F2:6D
2) Netgear 44:94:FC
3) Arris 60:31:97
4) Ubiquiti 24:A4:3C
5) Technicolor 10:13:31
6) Cisco/Linksys 00:25:9C
7) ASUS AC:9E:17
8) Google/Nest F4:F5:D8
9) Amazon/Eero 74:83:C2
10) Hitron C8:3A:35

Enter menu number (1iV10) or press Enter to type your own: 3
How many BSSIDs do you want to generate?: 100
Random or Sequential? (R/S): r
Generating BSSIDs...
60:31:97:CF:01:AB
60:31:97:21:8A:8B
60:31:97:A2:3D:B5
60:31:97:E3:F7:5F
60:31:97:62:E4:8A
60:31:97:7F:45:6D
60:31:97:77:C3:76
60:31:97:63:9E:DB
60:31:97:5C:33:91
60:31:97:76:B9:71
60:31:97:1D:0B:F0
60:31:97:9C:17:21
60:31:97:25:F7:F5
60:31:97:4D:67:FA
60:31:97:94:88:D0
60:31:97:E7:73:04
etc.
Output file saved to: bssidinput.txt

@echo off
:: C:\app\os\python\apple_bssid_locator\bssidgenerate.bat
:: Runs bssidgenerate.ps1 to generate random/sequential realistic BSSIDs
set "SCRIPT=%~dp0bssidgenerate.ps1"

echo Running PowerShell script:
echo %SCRIPT%
echo.

powershell -NoLogo -NoProfile -ExecutionPolicy Bypass -File "%SCRIPT%"

# C:\app\os\python\apple_bssid_locator\bssidgenerate.ps1
# Usemodel: bssidgenerate.bat (runs this powershell script)
# v1p0 20251217
# Generates BSSIDs based on user input.
# Prompts for:
# 1. OUI (first half), e.g., F4:F2:6D (TP-Link)
# 2. Number of BSSIDs to generate (e.g., 100)
# 3. Mode: R = random, S = sequential
# v1p1 20251217
# Saves results to bssidinput.txt
# Forces an OUI in case enter is hit prematurely
# v1p2 20251217
# Added menu of the ten most common USA OUI's
# v1p3 20251217
# Added sequential-mode starting block
# v1p4 20251217
# Added wraparound protection (at FF:FF:FF)

# --- BEGIN OUI MENU BLOCK ---
Write-Host ""
Write-Host "Select an OUI from the menu or press Enter to type your own:"
Write-Host " 1) TP-Link F4:F2:6D"
Write-Host " 2) Netgear 44:94:FC"
Write-Host " 3) Arris 60:31:97"
Write-Host " 4) Ubiquiti 24:A4:3C"
Write-Host " 5) Technicolor 10:13:31"
Write-Host " 6) Cisco/Linksys 00:25:9C"
Write-Host " 7) ASUS AC:9E:17"
Write-Host " 8) Google/Nest F4:F5:D8"
Write-Host " 9) Amazon/Eero 74:83:C2"
Write-Host " 10) Hitron C8:3A:35"
Write-Host ""

$choice = Read-Host "Enter menu number (1iV10) or press Enter to type your own"

switch ($choice) {
"1" { $oui = "F4:F2:6D" }
"2" { $oui = "44:94:FC" }
"3" { $oui = "60:31:97" }
"4" { $oui = "24:A4:3C" }
"5" { $oui = "10:13:31" }
"6" { $oui = "00:25:9C" }
"7" { $oui = "AC:9E:17" }
"8" { $oui = "F4:F5:D8" }
"9" { $oui = "74:83:C2" }
"10" { $oui = "C8:3A:35" }
default { $oui = $null }
}
# --- END OUI MENU BLOCK ---

# Ask for the first half (OUI)
if (-not $oui) {
$oui = Read-Host "Enter the first half (e.g., F4:F2:6D)"
}
$oui = $oui.ToUpper().Replace("-",":").Trim()

# Prevent empty OUI
if (-not $oui) {
Write-Host "You must enter an OUI such as F4:F2:6D."
exit
}

# Ask how many BSSIDs to generate
$count = Read-Host "How many BSSIDs do you want to generate?"
$count = [int]$count

# Ask for mode: random or sequential
$mode = Read-Host "Random or Sequential? (R/S)"
$mode = $mode.ToUpper()

Write-Host ""
Write-Host "Generating BSSIDs..."
Write-Host ""

# Output file
$outfile = "bssidinput.txt"
Clear-Content -Path $outfile -ErrorAction SilentlyContinue

# Function to format a number 0iV255 as two hex digits
function To-Hex([int]$n) {
return "{0:X2}" -f $n
}

# Sequential mode
if ($mode -eq "S") {

# Ask for starting second-half (e.g., AB:CD:EF)
$startHex = Read-Host "Enter starting second-half (e.g., AB:CD:EF) or press Enter for 00:00:00"
if (-not $startHex) { $startHex = "00:00:00" }

# Normalize
$startHex = $startHex.ToUpper().Replace("-",":").Trim()

# Convert to integer
$parts = $startHex.Split(":")
if ($parts.Count -ne 3) {
Write-Host "Invalid starting value. Must be three bytes like AB:CD:EF."
exit
}

$startVal = ([Convert]::ToInt32($parts[0],16) -shl 16) `
+ ([Convert]::ToInt32($parts[1],16) -shl 8) `
+ [Convert]::ToInt32($parts[2],16)

$maxVal = 0xFFFFFF

for ($i = 0; $i -lt $count; $i++) {

$val = $startVal + $i

if ($val -gt $maxVal) {
Write-Host "Reached maximum value FF:FF:FF. Stopping."
break
}

$b1 = ($val -shr 16) -band 0xFF
$b2 = ($val -shr 8) -band 0xFF
$b3 = $val -band 0xFF

$bssid = "${oui}:{0}:{1}:{2}" -f (To-Hex $b1), (To-Hex $b2), (To-Hex $b3)
Write-Host $bssid
Add-Content -Path $outfile -Value $bssid
}
}

# Random mode
elseif ($mode -eq "R") {
$rand = New-Object System.Random
for ($i = 0; $i -lt $count; $i++) {
$b1 = $rand.Next(0,256)
$b2 = $rand.Next(0,256)
$b3 = $rand.Next(0,256)

$bssid = "${oui}:{0}:{1}:{2}" -f (To-Hex $b1), (To-Hex $b2), (To-Hex $b3)
Write-Host $bssid
Add-Content -Path $outfile -Value $bssid
}
}

else {
Write-Host "Invalid choice. Please enter R or S."
}

Write-Host ""
Write-Host "Output file saved to: $(Resolve-Path $outfile)"

# end of C:\app\os\python\apple_bssid_locator\bssidgenerate.ps1
--
Helping others & learning from them is what this Usenet ng is all about.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Here is code I hacked out this morning which tracks those 400 BSSID:GPS
pairs, where I set the distance to 100KM but it could be any distance.

Here is code that generates random (or sequential) BSSIDs to place into a file which can later be checked against Apple's highly insecure WPS DB.

My claim is that it's trivial to gather valid access points to check
against Apple's highly insecure WPS database, where below is that check.

Once we have tens of thousands of random (or sequential) BSSIDs (which we
can start at any start point but I stop at the FF:FF:FF wrap around), we
can then check each of them against Apple's highly insecure WPS database.

@echo off
:: This is C:\app\os\python\apple_bssid_locator\bssidcheck.bat
:: v1p0 20251217
:: checks a list of BSSIDs from bssidcheck.txt in Apple's WPS db
:: outputs to the console and into a timestamped log file
:: v1p1 20251217
:: added fullpath to output files in the console output
:: v1p2 20251217
:: only log when a lookup is successful
:: v1p3 20251217
:: added summary section of bssid's that were found

:: Begin Log setup
set LOGDIR=%~dp0log
if not exist "%LOGDIR%" mkdir "%LOGDIR%"

for /f %%A in ('wmic os get localdatetime ^| find "."') do set dt0=%%A
set "session_ts=%dt0:~0,8%_%dt0:~8,6%"
set "session_log=%LOGDIR%\session_%session_ts%.log"
:: End Log setup

:: --- begin Success list setup ---
set "FOUND_LIST="
:: --- end Success list setup ---

echo === New BSSID lookup session started at %date% %time% === >> "%session_log%"
echo Session log: %session_log%

:: Begin FILE MODE
if exist "%~dp0bssidcheck.txt" (
echo Processing BSSIDs from bssidcheck.txt...
for /f "usebackq tokens=*" %%X in ("%~dp0bssidcheck.txt") do (
set "BSSID=%%X"
call :process_bssid
)
goto end
)
:: End FILE MODE

:: Begin INTERACTIVE MODE
:loop
echo.
set /p BSSID=Enter the BSSID (or q to quit):
if /I "%BSSID%"=="q" goto end

call :process_bssid
goto loop

:: End INTERACTIVE MODE

:: Begin PROCESS ONE BSSID
:process_bssid
:: --- Clean up input ---
set "BSSID=%BSSID:"=%"
set "BSSID=%BSSID: =%"

:: --- begin Make filename-safe version ---
set "safeBSSID=%BSSID::=-%"
:: --- end Make filename-safe version ---

:: --- begin Generate timestamp for THIS lookup ---
for /f %%A in ('wmic os get localdatetime ^| find "."') do set dt=%%A
set "ts=%dt:~0,8%_%dt:~8,6%"
:: --- end Generate timestamp for THIS lookup ---

:: --- begin Timestamped output file ---
set "outfile=%LOGDIR%\bssidlookup_%ts%_%safeBSSID%.log"
:: --- end Timestamped output file ---

:: --- begin Clear previous coordinates ---
set LAT=
set LON=
:: --- end Clear previous coordinates ---

:: --- begin Run Python lookup ---
echo === Lookup started at %date% %time% === > "%outfile%"
echo BSSID: %BSSID% >> "%outfile%"
echo. >> "%outfile%"

python.exe apple_bssid_locator.py %BSSID% --all >> "%outfile%"
:: --- end Run Python lookup ---

:: --- begin Display results ---
echo -----------------------------------------------
type "%outfile%"
echo -----------------------------------------------
if defined LAT if defined LON echo Log written to: %outfile%
:: --- end Display results ---

:: --- begin Extract coordinates ---
for /f "tokens=2 delims=: " %%A in ('findstr /i "Latitude" "%outfile%"') do set LAT=%%A
for /f "tokens=2 delims=: " %%B in ('findstr /i "Longitude" "%outfile%"') do set LON=%%B

echo === Lookup finished at %date% %time% === >> "%outfile%"
echo. >> "%outfile%"
:: --- end Extract coordinates ---

:: --- begin Append to session log ---
if defined LAT if defined LON (
echo [%date% %time%] BSSID: %BSSID% >> "%session_log%"
echo Latitude: %LAT% >> "%session_log%"
echo Longitude: %LON% >> "%session_log%"
echo. >> "%session_log%"

:: Add to success list
set "FOUND_LIST=%FOUND_LIST% %BSSID%"
)
:: --- end Append to session log ---

:: --- begin Append to master log ---
if defined LAT if defined LON (
echo [%date% %time%] BSSID: %BSSID% >> "%LOGDIR%\bssidcheck_%session_ts%.log"
echo Latitude: %LAT% >> "%LOGDIR%\bssidcheck_%session_ts%.log"
echo Longitude: %LON% >> "%LOGDIR%\bssidcheck_%session_ts%.log"
echo. >> "%LOGDIR%\bssidcheck_%session_ts%.log"
)
:: --- end Append to master log ---

:: --- begin Open in Google Maps ---
if defined LAT if defined LON start msedge "https://www.google.com/maps/search/?api=1&query=%LAT%,%LON%"
:: --- end Open in Google Maps ---

goto :eof
:: End PROCESS ONE BSSID


:end

:: --- begin Summary of successful lookups ---
echo.
echo ===== Summary of Successful BSSID Lookups =====
if defined FOUND_LIST (
echo %FOUND_LIST%
) else (
echo No BSSIDs were successfully located.
)
echo ===============================================
echo.
:: --- end Summary of successful lookups ---

echo Exiting. Goodbye!
:: end of C:\app\os\python\apple_bssid_locator\bssidcheck.bat
--
Never make the mistake of thinking I'm anything like the trolls are.
I am not here for my ego; nor for my amusement; but to teach & learn.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

My claim is that it's trivial to gather valid access points to check
against Apple's highly insecure WPS database, where below is that check.

Anyone interested in running these TP-Link BSSIDs through Apple's
highly insecure WPS lookup database & reporting results to the team?
<https://wavedigger.networksurvey.app/?tab=bssid>

===== Summary of Successful BSSID Lookups =====
F4:F2:6D:B6:A6:97
F4:F2:6D:38:43:72
F4:F2:6D:8E:DE:DC
F4:F2:6D:87:0A:CE
etc.
===============================================

Click on these links and let the team know what you find out from them:
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-B6-A6-97>
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-38-43-72>
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-8E-DE-DC>
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-87-0A-CE>
etc.

Here's a report of the nearest 400 APs to the Shreveport Louisiana BSSID:
<https://www.google.com/maps/place/32#27'32.07"N+93#48'53.84"W/>
(4302 Josey Cir, Shreveport, LA 71109)

Enter the BSSID (or q to quit): F4:F2:6D:B6:A6:97
-----------------------------------------------
=== Lookup started at Wed 12/17/2025 3:15:21.02 ===
BSSID: F4:F2:6D:B6:A6:97

Searching for location of bssid: F4:F2:6D:B6:A6:97
Saved 309 entries to results.txt
BSSID: f4:f2:6d:b6:a6:97
Latitude: 32.45974349
Longitude: -93.81695556

BSSID: 18:de:50:5b:14:6c
Latitude: 32.45925521
Longitude: -93.81757354

BSSID: 1a:1e:19:0d:c9:a9
Latitude: 32.45926666
Longitude: -93.8175888

BSSID: 1e:9e:cc:d6:cb:71
Latitude: 32.45985031
Longitude: -93.81725311

BSSID: 1e:9e:cc:d6:cb:76
Latitude: 32.45985031
Longitude: -93.81725311

BSSID: 02:aa:a0:ba:26:e0
Latitude: 32.45988464
Longitude: -93.81759643000001

BSSID: 50:95:51:b5:b6:ae
Latitude: 32.4591217
Longitude: -93.81761169

BSSID: 54:b2:03:2f:1b:60
Latitude: 32.45988082
Longitude: -93.81723022

BSSID: 62:b2:03:2f:1b:60
Latitude: 32.45986175
Longitude: -93.81723785

BSSID: 06:aa:a0:ba:26:e0
Latitude: 32.45986938
Longitude: -93.81759643000001

BSSID: 6a:b2:03:2f:1b:60
Latitude: 32.45987701
Longitude: -93.81723022

BSSID: 6e:b2:03:2f:1b:60
Latitude: 32.459846490000004
Longitude: -93.81730651000001

BSSID: 84:eb:3e:f8:36:d3
Latitude: 32.45880508
Longitude: -93.81717681

BSSID: 84:eb:3e:fa:b2:63
Latitude: 32.4595375
Longitude: -93.81742858

BSSID: 84:eb:3f:08:e0:72
Latitude: 32.45973968
Longitude: -93.81745147000001

BSSID: 8c:76:3f:f8:5d:cd
Latitude: 32.45948791
Longitude: -93.81759643000001

BSSID: 8c:85:80:d1:be:37
Latitude: 32.45985031
Longitude: -93.81759643000001

BSSID: 8e:76:3f:f8:5d:cd
Latitude: 32.4594841
Longitude: -93.8175888

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

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

BSSID: 96:76:3f:f8:5d:cd
Latitude: 32.45948791
Longitude: -93.8175888

BSSID: 96:ad:43:e3:f8:a8
Latitude: 32.45892715
Longitude: -93.81752014

BSSID: 9c:34:26:9e:ff:4a
Latitude: 32.45941162
Longitude: -93.8166275

BSSID: 9e:34:26:9e:ff:4a
Latitude: 32.45940017
Longitude: -93.81663513000001

BSSID: ae:4c:a5:65:93:62
Latitude: 32.45982742
Longitude: -93.81752014

BSSID: ae:4c:a5:65:93:67
Latitude: 32.45983505
Longitude: -93.81752014

BSSID: ba:5e:71:08:7c:6c
Latitude: 32.45958709
Longitude: -93.81726837000001

BSSID: ba:5e:71:08:7c:6f
Latitude: 32.45959091
Longitude: -93.81725311

BSSID: bc:9b:68:7e:15:c0
Latitude: 32.45943069
Longitude: -93.817276

BSSID: bc:9b:68:7e:15:c1
Latitude: 32.4594078
Longitude: -93.817276

BSSID: bc:9b:68:7e:15:c3
Latitude: 32.459438320000004
Longitude: -93.817276

BSSID: bc:9b:68:7e:15:c5
Latitude: 32.45941543
Longitude: -93.81728363

BSSID: bc:9b:68:7e:15:c6
Latitude: 32.45944976
Longitude: -93.81729125

BSSID: be:34:26:9e:ff:4a
Latitude: 32.45941925
Longitude: -93.81661987

BSSID: c6:4f:d5:41:a5:59
Latitude: 32.45885467
Longitude: -93.81680297

BSSID: de:34:26:9e:ff:4a
Latitude: 32.4594078
Longitude: -93.81664276000001

BSSID: ec:aa:a0:ba:26:e0
Latitude: 32.45988845
Longitude: -93.8175888

BSSID: fa:aa:a0:ba:26:e0
Latitude: 32.45989227
Longitude: -93.81759643000001

BSSID: 12:3d:0a:47:68:48
Latitude: 32.45932769
Longitude: -93.81684875

BSSID: 3a:1e:19:0d:c9:a9
Latitude: 32.45920944
Longitude: -93.8175888

BSSID: 72:95:51:b5:b6:ae
Latitude: 32.45911026
Longitude: -93.81761932

BSSID: 74:ea:e8:a0:a7:d7
Latitude: 32.45973205
Longitude: -93.81691741

BSSID: 78:d2:94:c9:68:48
Latitude: 32.45880889
Longitude: -93.81738281

BSSID: 82:da:c2:f4:9c:fd
Latitude: 32.45885086
Longitude: -93.81640625

BSSID: 88:ad:43:e3:f8:a8
Latitude: 32.45894241
Longitude: -93.8175354

BSSID: 9e:ad:43:e3:f8:a8
Latitude: 32.45894622
Longitude: -93.8175354

BSSID: a2:ad:43:e3:f8:a8
Latitude: 32.45894622
Longitude: -93.81755065

BSSID: 0a:1e:19:0d:c9:a9
Latitude: 32.45919799
Longitude: -93.81758117

BSSID: c6:4f:d5:41:a5:5e
Latitude: 32.45884704
Longitude: -93.81679534

BSSID: de:72:23:a3:8a:04
Latitude: 32.45986557
Longitude: -93.81764984

BSSID: e6:bf:fa:bb:35:f8
Latitude: 32.45929718
Longitude: -93.81698608

BSSID: e6:bf:fa:bb:35:fb
Latitude: 32.45929718
Longitude: -93.81697845000001

BSSID: 10:93:97:0a:e7:80
Latitude: 32.45983123
Longitude: -93.81554412

BSSID: 12:36:aa:62:9c:39
Latitude: 32.45924758
Longitude: -93.81565093

BSSID: 12:36:aa:62:9c:3a
Latitude: 32.45924377
Longitude: -93.81565856

BSSID: 12:36:aa:62:9c:3d
Latitude: 32.4592247
Longitude: -93.81564331

BSSID: 12:36:aa:62:9c:3e
Latitude: 32.45925521
Longitude: -93.81563568

BSSID: 12:36:aa:85:84:c9
Latitude: 32.45958709
Longitude: -93.81570434

BSSID: 18:9c:27:b6:4b:8a
Latitude: 32.45975494
Longitude: -93.81597137

BSSID: 02:cb:7a:c2:d1:42
Latitude: 32.45950698
Longitude: -93.81557464000001

BSSID: 02:cb:7a:c2:d1:43
Latitude: 32.45950698
Longitude: -93.81555938

BSSID: 02:cb:7a:c2:d1:45
Latitude: 32.45949935
Longitude: -93.81555938

BSSID: 36:e6:e6:86:cd:1c
Latitude: 32.45980453
Longitude: -93.81570434

BSSID: 3a:9c:27:b6:4b:8a
Latitude: 32.45976257
Longitude: -93.81599426

BSSID: 5a:9c:27:b6:4b:8a
Latitude: 32.45975112
Longitude: -93.81600189

BSSID: 8c:76:3f:d4:13:8d
Latitude: 32.4597969
Longitude: -93.81586456000001

BSSID: 8c:85:80:e4:35:dd
Latitude: 32.45980834
Longitude: -93.81555938

BSSID: 8c:0f:6f:21:c8:80
Latitude: 32.45982742
Longitude: -93.81553649

BSSID: 8c:0f:6f:d3:3b:68
Latitude: 32.459030150000004
Longitude: -93.81517791

BSSID: 8e:76:3f:d4:13:8d
Latitude: 32.4597969
Longitude: -93.81587982

BSSID: 94:a6:7e:31:02:35
Latitude: 32.45889282
Longitude: -93.81509399000001

BSSID: 96:76:3f:d4:13:8d
Latitude: 32.45978546
Longitude: -93.81589508

BSSID: 9a:0f:6f:21:c8:80
Latitude: 32.45982742
Longitude: -93.81553649

BSSID: 9a:0f:6f:d3:3b:68
Latitude: 32.45904922
Longitude: -93.81517791

BSSID: a2:0f:6f:21:c8:80
Latitude: 32.4598236
Longitude: -93.81553649

BSSID: a2:0f:6f:d3:3b:68
Latitude: 32.45904159
Longitude: -93.81518554

BSSID: a6:0f:6f:21:c8:80
Latitude: 32.45983123
Longitude: -93.81555175

BSSID: a6:0f:6f:d3:3b:68
Latitude: 32.45905303
Longitude: -93.8152008

BSSID: be:61:e9:cd:aa:a8
Latitude: 32.458812710000004
Longitude: -93.81623077

BSSID: ca:3a:6b:db:9b:ba
Latitude: 32.45902252
Longitude: -93.81513977

BSSID: ce:6c:6d:53:02:e5
Latitude: 32.45965194
Longitude: -93.81586456000001

BSSID: d4:6c:6d:53:02:e5
Latitude: 32.45964431
Longitude: -93.81583404

BSSID: d6:6c:6d:53:02:e5
Latitude: 32.45964431
Longitude: -93.81583404

BSSID: da:e3:5e:f7:08:87
Latitude: 32.45980453
Longitude: -93.81556701

BSSID: f8:aa:3f:fe:b2:1e
Latitude: 32.4590187
Longitude: -93.81517791

BSSID: 4e:6b:b8:aa:8c:80
Latitude: 32.45885467
Longitude: -93.81540679

BSSID: 78:b2:13:e7:91:39
Latitude: 32.45882797
Longitude: -93.81607055

BSSID: 1e:30:08:a4:b8:64
Latitude: 32.45988082
Longitude: -93.81547546

BSSID: 9e:b3:f7:21:91:e7
Latitude: 32.459102630000004
Longitude: -93.81617736

BSSID: ce:8b:66:31:a1:df
Latitude: 32.45933151
Longitude: -93.81556701

BSSID: 80:30:dc:c2:05:26
Latitude: 32.45886993
Longitude: -93.81635284000001

BSSID: 6e:29:90:f7:23:74
Latitude: 32.45904159
Longitude: -93.81517028

BSSID: 0c:73:29:ff:29:93
Latitude: 32.45893096
Longitude: -93.81542968000001

BSSID: 7e:27:bc:95:f5:35
Latitude: 32.45974349
Longitude: -93.81566619

BSSID: 54:21:60:82:f9:80
Latitude: 32.45933914
Longitude: -93.81817626

BSSID: 66:c6:d2:a2:ca:41
Latitude: 32.45928955
Longitude: -93.81825256

BSSID: 72:13:01:e1:d9:24
Latitude: 32.45993041
Longitude: -93.81851959000001

BSSID: 82:da:c2:8e:e8:de
Latitude: 32.45935821
Longitude: -93.81826019

BSSID: 86:ea:ed:9d:93:56
Latitude: 32.45885467
Longitude: -93.81848144

BSSID: 88:57:1d:5f:b0:29
Latitude: 32.45927047
Longitude: -93.8179779

BSSID: 8c:0f:6f:3c:c5:a8
Latitude: 32.45972442
Longitude: -93.81800079

BSSID: 8e:49:62:3e:0e:4a
Latitude: 32.45919418
Longitude: -93.81777191

BSSID: 9a:0f:6f:3c:c5:a8
Latitude: 32.45974731
Longitude: -93.81801605

BSSID: a2:0f:6f:3c:c5:a8
Latitude: 32.45973968
Longitude: -93.81801605

BSSID: a6:0f:6f:3c:c5:a8
Latitude: 32.45972442
Longitude: -93.81801605

BSSID: c6:4f:d5:7e:64:69
Latitude: 32.45947647
Longitude: -93.81790924

BSSID: c6:4f:d5:7e:64:6f
Latitude: 32.45946502
Longitude: -93.81789398000001

BSSID: 2e:3f:75:b6:2f:07
Latitude: 32.45936203
Longitude: -93.81813812

BSSID: 82:da:c2:8e:e8:d9
Latitude: 32.459365840000004
Longitude: -93.81826019

BSSID: ae:ae:19:b3:82:47
Latitude: 32.45906448
Longitude: -93.81778717

BSSID: 32:9b:d6:b8:39:e9
Latitude: 32.45936965
Longitude: -93.81829833

BSSID: 70:13:01:ef:d9:23
Latitude: 32.459583280000004
Longitude: -93.81856536000001

BSSID: 70:13:01:ef:d9:26
Latitude: 32.45959091
Longitude: -93.81858062

BSSID: 70:13:01:ef:d9:27
Latitude: 32.45959091
Longitude: -93.81858062

BSSID: 70:13:01:ef:d9:25
Latitude: 32.45958709
Longitude: -93.81858062

BSSID: 50:fd:d5:04:5f:42
Latitude: 32.45814132
Longitude: -93.81715393

BSSID: 62:9c:8e:29:da:30
Latitude: 32.45869445
Longitude: -93.81692504

BSSID: 62:9c:8e:29:da:32
Latitude: 32.45867538
Longitude: -93.81691741

BSSID: 62:9c:8e:29:da:35
Latitude: 32.45868301
Longitude: -93.81696319

BSSID: 72:13:01:28:3a:49
Latitude: 32.4581108
Longitude: -93.81741333000001

BSSID: 72:13:01:28:3a:4a
Latitude: 32.45811462
Longitude: -93.81740570000001

BSSID: 88:ad:43:13:50:e8
Latitude: 32.4581871
Longitude: -93.81671905

BSSID: 96:ad:43:13:50:e8
Latitude: 32.45817947
Longitude: -93.81671905

BSSID: 9c:34:26:19:5d:7c
Latitude: 32.4576683
Longitude: -93.817276

BSSID: 9e:34:26:19:5d:7c
Latitude: 32.45766448
Longitude: -93.81726837000001

BSSID: 9e:ad:43:13:50:e8
Latitude: 32.45819091
Longitude: -93.81671905

BSSID: bc:2e:48:ee:7e:a5
Latitude: 32.45818328
Longitude: -93.81676483

BSSID: be:34:26:19:5d:7c
Latitude: 32.45766448
Longitude: -93.81728363

BSSID: de:2e:48:ee:7e:a5
Latitude: 32.45818328
Longitude: -93.81674957

BSSID: de:34:26:19:5d:7c
Latitude: 32.45765686
Longitude: -93.81728363

BSSID: ee:79:0a:fc:38:85
Latitude: 32.45792388
Longitude: -93.81736755

BSSID: fa:79:0a:fc:38:85
Latitude: 32.45790863
Longitude: -93.81735229

BSSID: fe:2e:48:ee:7e:a5
Latitude: 32.4582138
Longitude: -93.81678771

BSSID: 12:3d:0a:60:d0:1c
Latitude: 32.45816421
Longitude: -93.81655883

BSSID: 18:9c:27:2c:f7:40
Latitude: 32.45811462
Longitude: -93.81652069

BSSID: 1c:e8:9e:86:6f:43
Latitude: 32.45815658
Longitude: -93.81722259

BSSID: 4a:bd:ce:cf:8f:71
Latitude: 32.458641050000004
Longitude: -93.81672668

BSSID: 4a:bd:ce:cf:8f:76
Latitude: 32.45863723
Longitude: -93.81671142

BSSID: 68:3a:48:cd:9b:2a
Latitude: 32.45803451
Longitude: -93.81713867

BSSID: a2:ad:43:13:50:e8
Latitude: 32.45833969
Longitude: -93.8167572

BSSID: a4:11:62:b8:a5:5a
Latitude: 32.45875167
Longitude: -93.81645965

BSSID: a6:53:d2:96:a3:a6
Latitude: 32.45819091
Longitude: -93.81773376

BSSID: d6:53:d2:96:a3:a6
Latitude: 32.45819854
Longitude: -93.81772613

BSSID: 72:c9:4e:2b:23:6b
Latitude: 32.4580574
Longitude: -93.81681823

BSSID: 5c:47:5e:a6:ed:ef
Latitude: 32.4579811
Longitude: -93.81711578000001

BSSID: 10:56:11:6a:80:86
Latitude: 32.46089553
Longitude: -93.81726074000001

BSSID: 10:da:43:3f:a1:0d
Latitude: 32.46057891
Longitude: -93.81767272

BSSID: 1e:9d:72:d4:4c:51
Latitude: 32.46066284
Longitude: -93.81764984

BSSID: 1e:9d:72:d4:4c:54
Latitude: 32.4606781
Longitude: -93.81765747

BSSID: 2c:7e:81:c7:f2:44
Latitude: 32.460353850000004
Longitude: -93.81745910000001

BSSID: 32:56:11:6a:80:86
Latitude: 32.46089172
Longitude: -93.81726837000001

BSSID: 38:17:b1:6e:e1:f6
Latitude: 32.46012115
Longitude: -93.81768035

BSSID: 42:17:b1:6e:e1:f6
Latitude: 32.46009063
Longitude: -93.81764984

BSSID: 4e:7e:81:c7:f2:44
Latitude: 32.46035003
Longitude: -93.81746673

BSSID: 52:56:11:6a:80:86
Latitude: 32.46089935
Longitude: -93.81726074000001

BSSID: 6e:7e:81:c7:f2:44
Latitude: 32.46036911
Longitude: -93.81747436

BSSID: 88:ad:43:58:8b:28
Latitude: 32.460617060000004
Longitude: -93.81711578000001

BSSID: 8c:85:80:ba:9f:da
Latitude: 32.460742950000004
Longitude: -93.81735992

BSSID: 96:ad:43:58:8b:28
Latitude: 32.46060943
Longitude: -93.81713104

BSSID: 9e:ad:43:58:8b:28
Latitude: 32.4606018
Longitude: -93.81712341000001

BSSID: a2:ad:43:58:8b:28
Latitude: 32.46061325
Longitude: -93.81712341000001

BSSID: ca:e5:da:d7:c2:44
Latitude: 32.45995712
Longitude: -93.81754302

BSSID: 00:1e:e5:7c:74:93
Latitude: 32.46081161
Longitude: -93.81645965

BSSID: 5c:b0:66:0b:d3:46
Latitude: 32.4608879
Longitude: -93.81703948

BSSID: 7e:b0:66:0b:d3:46
Latitude: 32.46088409
Longitude: -93.81703948

BSSID: 9e:b0:66:0b:d3:46
Latitude: 32.46088409
Longitude: -93.81703948

BSSID: 36:5e:08:70:77:09
Latitude: 32.46072006
Longitude: -93.81699371

BSSID: ce:8b:66:29:32:d4
Latitude: 32.4603157
Longitude: -93.81760406000001

BSSID: c6:50:9c:f9:9c:29
Latitude: 32.46025848
Longitude: -93.81729888

BSSID: c6:50:9c:f9:9c:2a
Latitude: 32.46026992
Longitude: -93.81729125

BSSID: c6:50:9c:f9:9c:2e
Latitude: 32.460254660000004
Longitude: -93.81729888

BSSID: c6:50:9c:f9:9c:2f
Latitude: 32.46035766
Longitude: -93.81731414000001

BSSID: 58:96:71:75:47:18
Latitude: 32.45874404
Longitude: -93.8155899

BSSID: b8:3a:9d:ff:8f:ba
Latitude: 32.45768737
Longitude: -93.81520843

BSSID: ce:6c:6d:bd:5a:e9
Latitude: 32.458641050000004
Longitude: -93.81510925

BSSID: d4:5d:df:38:18:a0
Latitude: 32.45795822
Longitude: -93.81510162000001

BSSID: d4:6c:6d:bd:5a:e9
Latitude: 32.45866012
Longitude: -93.81512451

BSSID: d6:6c:6d:bd:5a:e9
Latitude: 32.458667750000004
Longitude: -93.81512451

BSSID: e2:5d:df:38:18:a0
Latitude: 32.45796966
Longitude: -93.81510925

BSSID: ea:5d:df:38:18:a0
Latitude: 32.45796203
Longitude: -93.81511688

BSSID: ee:5d:df:38:18:a0
Latitude: 32.45796585
Longitude: -93.81511688

BSSID: 12:59:32:bf:8f:69
Latitude: 32.45852661
Longitude: -93.81599426

BSSID: 34:ea:e7:69:1a:03
Latitude: 32.45866012
Longitude: -93.81589508

BSSID: b0:7f:b9:01:3b:e3
Latitude: 32.45864868
Longitude: -93.81630706

BSSID: c8:63:fc:21:48:e6
Latitude: 32.458667750000004
Longitude: -93.81589508

BSSID: ce:63:fc:21:48:e6
Latitude: 32.45867156
Longitude: -93.81587982

BSSID: d6:63:fc:21:48:e6
Latitude: 32.45867156
Longitude: -93.81588745

BSSID: da:63:fc:21:48:e6
Latitude: 32.45867156
Longitude: -93.81587219000001

BSSID: 54:e0:19:43:85:8d
Latitude: 32.458667750000004
Longitude: -93.81587219000001

BSSID: 2e:3f:75:35:25:b9
Latitude: 32.45836257
Longitude: -93.8187561

BSSID: 3c:b7:4b:a2:12:74
Latitude: 32.45783233
Longitude: -93.81846618

BSSID: 3c:b7:4b:a2:12:75
Latitude: 32.45782852
Longitude: -93.81846618

BSSID: 04:17:b6:01:74:91
Latitude: 32.45777511
Longitude: -93.81830596

BSSID: 4c:bc:e9:ae:85:e6
Latitude: 32.458477020000004
Longitude: -93.8188095

BSSID: 54:a6:5c:b0:58:af
Latitude: 32.45839691
Longitude: -93.81859588

BSSID: 54:a6:5c:b0:58:b4
Latitude: 32.45838546
Longitude: -93.81859588

BSSID: 72:13:01:fd:d6:19
Latitude: 32.458404540000004
Longitude: -93.81896972

BSSID: 86:ef:16:b0:c3:44
Latitude: 32.4580307
Longitude: -93.81842803

BSSID: 88:ef:16:b0:c3:44
Latitude: 32.45802688
Longitude: -93.81842041

BSSID: 08:65:f0:85:af:46
Latitude: 32.458133690000004
Longitude: -93.81807708000001

BSSID: 9c:34:26:24:02:fe
Latitude: 32.45853042
Longitude: -93.81868743

BSSID: 9e:ad:43:e2:72:58
Latitude: 32.45835494
Longitude: -93.81844329

BSSID: a6:36:c7:93:a6:e3
Latitude: 32.45809555
Longitude: -93.81831359

BSSID: ac:91:9b:d4:bd:30
Latitude: 32.45775222
Longitude: -93.81910705

BSSID: ae:61:a3:82:38:31
Latitude: 32.45793151
Longitude: -93.81826782

BSSID: ae:97:cd:1d:65:1d
Latitude: 32.45816421
Longitude: -93.81831359

BSSID: ae:ae:19:be:75:b9
Latitude: 32.45865631
Longitude: -93.81803894000001

BSSID: be:34:26:24:02:fe
Latitude: 32.45854187
Longitude: -93.81868743

BSSID: be:d7:d4:c9:42:98
Latitude: 32.4582901
Longitude: -93.81867218000001

BSSID: c6:50:9c:9d:03:92
Latitude: 32.45809555
Longitude: -93.81854248

BSSID: dc:eb:69:59:75:17
Latitude: 32.45872497
Longitude: -93.81905364

BSSID: dc:eb:69:59:75:1a
Latitude: 32.45876693
Longitude: -93.81905364

BSSID: dc:eb:69:59:75:1c
Latitude: 32.458740230000004
Longitude: -93.81904602

BSSID: dc:eb:69:59:75:1d
Latitude: 32.45874404
Longitude: -93.81906127

BSSID: de:34:26:24:02:fe
Latitude: 32.45853424
Longitude: -93.8186798

BSSID: e2:db:d1:ca:98:99
Latitude: 32.45833587
Longitude: -93.8184967

BSSID: f6:79:0a:5a:0e:aa
Latitude: 32.45858383
Longitude: -93.81819915

BSSID: f8:79:0a:5a:0e:aa
Latitude: 32.45858001
Longitude: -93.81817626

BSSID: 3c:b7:4b:a2:12:6f
Latitude: 32.45782089
Longitude: -93.81845855

BSSID: 3c:b7:4b:a2:12:72
Latitude: 32.45783233
Longitude: -93.81846618

BSSID: 4a:ea:62:bb:12:84
Latitude: 32.45869445
Longitude: -93.81802368

BSSID: 08:65:f0:84:e3:7e
Latitude: 32.45810699
Longitude: -93.81805419

BSSID: 08:65:f0:85:ab:f6
Latitude: 32.45824813
Longitude: -93.81806182

BSSID: 9e:b3:f7:e9:12:d2
Latitude: 32.45869445
Longitude: -93.81893157

BSSID: a6:6a:44:d3:d3:fb
Latitude: 32.45800399
Longitude: -93.81819915

BSSID: b6:53:d2:96:a3:a6
Latitude: 32.45809936
Longitude: -93.81781768

BSSID: be:d7:d4:d1:6d:a5
Latitude: 32.4582138
Longitude: -93.81854248

BSSID: de:cd:2f:94:a1:f3
Latitude: 32.45821762
Longitude: -93.81860351

BSSID: bc:64:4b:13:e5:b4
Latitude: 32.45775985
Longitude: -93.81871795

BSSID: 0e:64:4b:13:e5:b4
Latitude: 32.4577713
Longitude: -93.81870269

BSSID: 6e:29:90:48:48:f8
Latitude: 32.45824813
Longitude: -93.81910705

BSSID: 6e:29:90:44:df:e4
Latitude: 32.45845794
Longitude: -93.81904602

BSSID: 6e:29:90:48:5c:92
Latitude: 32.45841598
Longitude: -93.81911468

BSSID: 10:9a:dd:89:81:75
Latitude: 32.46053314
Longitude: -93.81541442

BSSID: 16:93:7c:21:d8:cd
Latitude: 32.460472100000004
Longitude: -93.81539154000001

BSSID: 1c:93:7c:21:d8:cd
Latitude: 32.46047592
Longitude: -93.81538391000001

BSSID: 1e:51:a4:d5:ad:2e
Latitude: 32.46110534
Longitude: -93.81504821

BSSID: 22:76:13:0c:4a:e6
Latitude: 32.46063232
Longitude: -93.81548309

BSSID: 02:71:47:b8:8e:45
Latitude: 32.46051788
Longitude: -93.81537628

BSSID: 02:a0:0d:cf:38:92
Latitude: 32.46069717
Longitude: -93.81577301

BSSID: 2a:c5:c8:13:e4:09
Latitude: 32.46052169
Longitude: -93.81542205

BSSID: 3a:a0:97:ae:25:b0
Latitude: 32.46107101
Longitude: -93.81588745

BSSID: 42:75:c3:38:ad:5d
Latitude: 32.45996475
Longitude: -93.81601715000001

BSSID: 48:ea:62:19:c1:37
Latitude: 32.46043395
Longitude: -93.81559753

BSSID: 58:07:f8:2c:e9:f4
Latitude: 32.46059417
Longitude: -93.81523895000001

BSSID: 84:eb:3f:39:d3:36
Latitude: 32.460472100000004
Longitude: -93.81536102

BSSID: c0:a0:0d:cf:38:92
Latitude: 32.46071243
Longitude: -93.81578826

BSSID: c2:38:96:68:ab:18
Latitude: 32.46050643
Longitude: -93.81540679

BSSID: e2:a0:0d:cf:38:92
Latitude: 32.46071243
Longitude: -93.81578063

BSSID: e8:97:b8:8e:f4:99
Latitude: 32.4604988
Longitude: -93.81613159

BSSID: 0e:93:7c:21:d8:cd
Latitude: 32.46048355
Longitude: -93.81538391000001

BSSID: f8:a0:97:ae:25:b0
Latitude: 32.46107482
Longitude: -93.8159027

BSSID: 28:6b:b4:e6:5a:6a
Latitude: 32.46052169
Longitude: -93.81571197

BSSID: 42:75:c3:38:ad:59
Latitude: 32.46013259
Longitude: -93.81605529000001

BSSID: 42:75:c3:38:ad:5a
Latitude: 32.46012878
Longitude: -93.81604766

BSSID: 42:75:c3:38:ad:5e
Latitude: 32.46014404
Longitude: -93.81604766

BSSID: 42:75:c3:38:ad:5f
Latitude: 32.46013259
Longitude: -93.81605529000001

BSSID: 54:21:60:82:37:08
Latitude: 32.46048736
Longitude: -93.81610107

BSSID: 8c:61:a3:83:5c:19
Latitude: 32.4610939
Longitude: -93.81595611

BSSID: 8c:85:80:e4:91:ab
Latitude: 32.46012115
Longitude: -93.81610107

BSSID: 90:d0:92:56:be:64
Latitude: 32.46058654
Longitude: -93.81621551

BSSID: a2:ff:70:fe:7b:e8
Latitude: 32.46064376
Longitude: -93.81583404

BSSID: a2:ff:70:fe:7b:ed
Latitude: 32.46063995
Longitude: -93.81584167

BSSID: 0a:05:81:2b:bb:4d
Latitude: 32.4604988
Longitude: -93.81541442

BSSID: ae:61:a3:83:5c:19
Latitude: 32.4610939
Longitude: -93.81596374

BSSID: c2:e5:da:6e:1b:48
Latitude: 32.46081161
Longitude: -93.81608581

BSSID: ce:61:a3:83:5c:19
Latitude: 32.46108627
Longitude: -93.81595611

BSSID: 86:ea:ed:40:1b:57
Latitude: 32.4599533
Longitude: -93.81594848

BSSID: da:a0:11:b9:d5:51
Latitude: 32.46051788
Longitude: -93.81621551

BSSID: 72:13:01:e1:d9:21
Latitude: 32.4601593
Longitude: -93.81848907

BSSID: 72:13:01:e1:d9:22
Latitude: 32.46015167
Longitude: -93.81848907

BSSID: 72:13:01:e1:d9:26
Latitude: 32.46016311
Longitude: -93.81850433

BSSID: 84:eb:3f:39:cb:07
Latitude: 32.46070098
Longitude: -93.81808471000001

BSSID: 84:eb:3f:07:10:ef
Latitude: 32.46009826
Longitude: -93.81835174

BSSID: 8c:61:a3:a1:11:01
Latitude: 32.46061325
Longitude: -93.8179779

BSSID: 8c:76:3f:51:c7:f7
Latitude: 32.46059036
Longitude: -93.81776428

BSSID: 8c:0f:6f:1b:1a:60
Latitude: 32.46043014
Longitude: -93.81858062

BSSID: 8e:49:62:6e:f4:8a
Latitude: 32.46063995
Longitude: -93.81803131

BSSID: 8e:76:3f:51:c7:f7
Latitude: 32.46057891
Longitude: -93.81777954

BSSID: 96:76:3f:51:c7:f7
Latitude: 32.46059417
Longitude: -93.81775665

BSSID: 9a:0f:6f:1b:1a:60
Latitude: 32.46042251
Longitude: -93.81858825

BSSID: a0:68:7e:90:9d:50
Latitude: 32.46071243
Longitude: -93.81809997

BSSID: a2:0f:6f:1b:1a:60
Latitude: 32.460426330000004
Longitude: -93.81858825

BSSID: a6:0f:6f:1b:1a:60
Latitude: 32.46038436
Longitude: -93.81861877

BSSID: cc:58:30:61:e8:27
Latitude: 32.46091461
Longitude: -93.81833648

BSSID: d4:5d:df:e4:38:10
Latitude: 32.46094512
Longitude: -93.81808471000001

BSSID: 18:60:24:d6:92:0f
Latitude: 32.46081161
Longitude: -93.81790161

BSSID: 2a:c5:c8:04:a7:dd
Latitude: 32.46001434
Longitude: -93.81880187

BSSID: 4a:4b:d4:6a:36:fd
Latitude: 32.46064376
Longitude: -93.81900787000001

BSSID: 8e:49:62:f2:22:22
Latitude: 32.460762020000004
Longitude: -93.81889343

BSSID: ae:61:a3:a1:11:01
Latitude: 32.46060943
Longitude: -93.8179779

BSSID: ce:61:a3:a1:11:01
Latitude: 32.46060943
Longitude: -93.8179779

BSSID: d4:5d:df:e8:5b:90
Latitude: 32.46016311
Longitude: -93.81820678

BSSID: e2:5d:df:e8:5b:90
Latitude: 32.46017837
Longitude: -93.81820678

BSSID: ea:01:c7:48:27:3c
Latitude: 32.46076965
Longitude: -93.81806945

BSSID: ea:5d:df:e4:38:10
Latitude: 32.46091842
Longitude: -93.81809234

BSSID: ea:5d:df:e8:5b:90
Latitude: 32.46017074
Longitude: -93.81820678

BSSID: ee:5d:df:e8:5b:90
Latitude: 32.46022033
Longitude: -93.81821441

BSSID: fa:d2:ac:08:fd:ed
Latitude: 32.46027374
Longitude: -93.81826782

BSSID: fc:51:a4:ae:a5:50
Latitude: 32.46082305
Longitude: -93.81792449

BSSID: fe:51:a4:ae:a5:50
Latitude: 32.46081542
Longitude: -93.81790924

BSSID: e2:3e:cb:98:c8:2c
Latitude: 32.46010589
Longitude: -93.81864929

BSSID: 00:18:f8:c1:4a:65
Latitude: 32.45991134
Longitude: -93.81384277000001

BSSID: 02:aa:a0:e3:5f:38
Latitude: 32.458904260000004
Longitude: -93.81495666

BSSID: 06:aa:a0:e3:5f:38
Latitude: 32.45891189
Longitude: -93.81496429

BSSID: 72:13:01:01:99:9a
Latitude: 32.45918273
Longitude: -93.81450653

BSSID: 72:13:01:01:99:9d
Latitude: 32.45917892
Longitude: -93.81450653

BSSID: ec:aa:a0:e3:5f:38
Latitude: 32.45891189
Longitude: -93.81495666

BSSID: fa:aa:a0:e3:5f:38
Latitude: 32.45890808
Longitude: -93.81495666
-----------------------------------------------
--
The point being made is not that I wish to track movement (I don't!);
but that it's trivial to do using the insecure Apple WPS database.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

BSSID: 8c:85:80:d1:be:37
Latitude: 32.45985031
Longitude: -93.81759643000001

BSSID: 8e:76:3f:f8:5d:cd
Latitude: 32.4594841
Longitude: -93.8175888

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

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

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

BSSID: 8c:85:80:d1:be:37
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=8c-85-80-d1-be-37>

BSSID: 8e:76:3f:f8:5d:cd
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=8e-76-3f-f8-5d-cd>

BSSID: 92:76:3f:f8:5d:cd
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=92-76-3f-f8-5d-cd>

BSSID: 92:95:51:b5:b6:ae
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=92-95-51-b5-b6-ae>
--
Intelligent people ask questions to get help from those who know answers.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian <marianjones@helpfulpeople.com> posted both:

Longitude: -93.81759643000001

...

Longitude: -93.81759643000001

and:

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

Probably just the result of a 64-bit (double) floating point calculation
that they didn't bother to round off.
-WBE
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

On Thu, 12/18/2025 4:43 PM, Winston wrote:

Marian <marianjones@helpfulpeople.com> posted both:

Longitude: -93.81759643000001

...

Longitude: -93.81759643000001

and:

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

Probably just the result of a 64-bit (double) floating point calculation
that they didn't bother to round off.
-WBE

It could be a closest-representable-number problem.

You should really code a thing like this up. Use the GMP library
to do the multiply of mantissa and exponent part. I've only
used this once, and not for floats. You can code for C or C++
and doing it in C++ is slower (for the temporary copies of
numbers the code makes, and when there are a lot of digits in play).
The C++ code is easier to read (unlike the C you write in that case).

https://en.wikipedia.org/wiki/GNU_Multiple_Precision_Arithmetic_Library

You're right, that the double looks like a reasonable candidate
to contributing to the problem. Just need a better calculator to
see how close it is to an exact representation.

https://gregstoll.com/~gregstoll/floattohex/

-93.81759643

Single Mantissa ExponentContribution
0xc2bba29b 1.465899825 0961304 64 ?
0xc2bba29c 1.465899944 30542 64 ?
0xc2bba29d 1.465900063 5147095 64 ?

Double Mantissa ExpC
0xc05774537ffa0b48 1.465899944 2187497 64 -93.81759642999998 0xc05774537ffa0b49 1.465899944 21875 64 -93.81759643000000 <==== need more careful conversion
0xc05774537ffa0b4a 1.465899944 2187501 64 -93.81759643000001

1.4658998250961304 * 64 = \
1.46589994430542 * 64 = \___ Need a calc that takes that many digits 1.4659000635147095 * 64 = / to verify the single precision representation "?"
My Microsoft "calc" gives "Invalid Input".

*******

It's sloppy workmanship :-)
We knew that much before investigating.
If your input numbers coming from somewhere are eight digits
after the decimal, then the tool output should also be
eight digits or so. Printing that many extra digits is silly,
as the database collecting these numbers, isn't "doing math" on
them. It is just storing a GPS coord as reported (from NMEA
message) and puking it back out on demand.

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

On Thu, 12/18/2025 4:29 PM, Marian wrote:

Marian wrote:

-a BSSID: 8c:85:80:d1:be:37
-a Latitude: 32.45985031
-a Longitude: -93.81759643000001
-a -a BSSID: 8e:76:3f:f8:5d:cd
-a Latitude: 32.4594841
-a Longitude: -93.8175888
-a -a BSSID: 92:76:3f:f8:5d:cd
-a Latitude: 32.4594841
-a Longitude: -93.81756591
-a -a BSSID: 92:95:51:b5:b6:ae
-a Latitude: 32.45910644
-a Longitude: -93.81759643000001

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

BSSID: 8c:85:80:d1:be:37 <https://wavedigger.networksurvey.app/?tab=bssid&bssid=8c-85-80-d1-be-37>

BSSID: 8e:76:3f:f8:5d:cd <https://wavedigger.networksurvey.app/?tab=bssid&bssid=8e-76-3f-f8-5d-cd>

BSSID: 92:76:3f:f8:5d:cd <https://wavedigger.networksurvey.app/?tab=bssid&bssid=92-76-3f-f8-5d-cd>

BSSID: 92:95:51:b5:b6:ae <https://wavedigger.networksurvey.app/?tab=bssid&bssid=92-95-51-b5-b6-ae>

Well, check the NMEA messages and see what they contain.

First, you have to be aware of the conversion steps.

https://stackoverflow.com/questions/66978496/parsing-and-converting-output-from-a-gps-dongle

import pynmea2

line = "$GPGLL,3745.81303,N,12214.62049,W,175033.00,A,D*7C" # degrees minutes fractions-of-a-minute
nmeaobj = pynmea2.parse(line)

coord = f'{nmeaobj.latitude} {nmeaobj.longitude}'
print(coord)
# 37.763551 -122.243675 # Degrees fractions-of-a-degree

https://en.wikipedia.org/wiki/Decimal_degrees#Precision

I just shifted the stuff over here, to see how many digits they give.
The GLL seems to give me eight digits. The GGA less so.

GLL

https://gocut.tiwri.com/gll_geographic_position___latitude_longitude.htm

$GPGLL,5943.432134,N,01020.998301,E,080920.91,A,A*6C # degrees minutes fractions-of-a-minute

Latitude in dd mm,mmmm format (0-7 decimal places). 59.43432134 as 59. 43.432134
Latitude N or S.
Longitude in ddd mm,mmmm format (0-7 decimal places). 010.20998301 as 010. 20.998301
Longitude E or W.

GGA

https://w3.cs.jmu.edu/bernstdh/web/common/help/nmea-sentences.php

$GPGGA,210230,3855.4487,N,09446.0071,W,1,07,1.1,370.5,M,-29.5,M,,*7A # degrees minutes fractions-of-a-minute

Latitude (in DDMM.MMM format) 38.554487 as 38. 55.4487
Latitude compass direction
Longitude (in DDDMM.MMM format) 094.460071 as 094. 46.0071
Longitude compass direction

We don't want to go into the minutiae to dismiss the crap on the end of -93.81759643000001

Paul
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

this tutorial is only useful if you want to control the query
of Apple's highly insecure WPS database, which has no privacy controls.

I've not followed this thread in detail, I could understand the outrage
*if* apple were storing SSID/GPS pairs, such as ssid:Arlens_house_nomap=latitude:40.12345678,longitude:-120.12345678

But how is it compromising to store BSSID/GPS pairs such as bssid:AA:BB:CC:11:22:33=latitude:40.12345678,longitude:-120.12345678

How could anyone discover that AA:BB:CC:11:22:33 belongs to Arlen?




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Andy,

How could anyone discover that AA:BB:CC:11:22:33 belongs to Arlen?

Easy : Someone drives up to his house and than checks their phone which
SSIDs it detects. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Paul wrote:

It's sloppy workmanship :-)
We knew that much before investigating.

Thanks Paul and Winston for taking a look at the precision of the GPS data stored in the Apple WPS database.

I thought I had responded to this where I will always openly admit when I
don't understand anything, so I will say I have no idea WHY Apple stores
the integer GPS values to the number of integer precision that they do.

I can only add the value that I modified the FOSS scripts so that they
report both the original machine-readable GPS coordinates and my
human-readable conversion since decimal GPS coordinates are what we use.

These are actual values output when I input the first BSSID below:
column 1 = the BSSID
column 2 = the integer latitude stored in the Apple WPS database
column 3 = the integer longitude stored in the Apple WPS database
columns 4 & 5 = a conversion of integer to decimal for GPS display tools

00:18:f8:c1:4a:65 3245990371 -9381384277 32.459904 -93.813843
02:aa:a0:e3:5f:38 3245890808 -9381494903 32.458908 -93.814949
44:1c:12:99:23:58 3245909881 -9381492614 32.459099 -93.814926
44:1c:12:99:23:5b 3245910644 -9381491088 32.459106 -93.814911
44:1c:12:99:23:5d 3245910644 -9381491851 32.459106 -93.814919
44:1c:12:99:23:5e 3245911026 -9381491088 32.459110 -93.814911
06:aa:a0:e3:5f:38 3245891952 -9381494903 32.458920 -93.814949
72:13:01:01:99:9a 3245920944 -9381445312 32.459209 -93.814453
72:13:01:01:99:9d 3245919036 -9381446838 32.459190 -93.814468
ec:aa:a0:e3:5f:38 3245891571 -9381494140 32.458916 -93.814941
fa:aa:a0:e3:5f:38 3245891571 -9381493377 32.458916 -93.814934
12:36:aa:7d:3d:b1 3245915603 -9381276702 32.459156 -93.812767
12:36:aa:7d:3d:b2 3245915222 -9381278228 32.459152 -93.812782
12:36:aa:7d:3d:b6 3245914840 -9381275177 32.459148 -93.812752
12:36:aa:c2:2c:01 3245956802 -9381256103 32.459568 -93.812561
12:59:32:64:b2:bc 3245960617 -9381244659 32.459606 -93.812447
14:c0:3e:38:ef:36 3245923614 -9381269073 32.459236 -93.812691
16:c0:3e:38:ef:36 3245925140 -9381269836 32.459251 -93.812698
1a:c0:3e:38:ef:36 3245925140 -9381269073 32.459251 -93.812691
02:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
38:17:b1:28:28:46 3245931625 -9381245422 32.459316 -93.812454
40:48:6e:f1:9f:34 3245958328 -9381306457 32.459583 -93.813065
42:17:b1:28:28:46 3245932388 -9381243133 32.459324 -93.812431
46:d8:78:a3:03:a3 3245965576 -9381226348 32.459656 -93.812263
5c:b0:66:13:26:c1 3245907974 -9381227874 32.459080 -93.812279
5e:b0:66:13:26:c1 3245907592 -9381227111 32.459076 -93.812271
06:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
72:13:01:46:3c:c1 3245978546 -9381228637 32.459785 -93.812286
72:13:01:46:3c:c6 3245979690 -9381228637 32.459797 -93.812286
7e:b0:66:13:26:c1 3245907211 -9381227874 32.459072 -93.812279
88:ad:43:48:4a:a8 3245934295 -9381259918 32.459343 -93.812599
8c:76:3f:b7:b7:97 3245985412 -9381255340 32.459854 -93.812553
8e:76:3f:b7:b7:97 3245984649 -9381256103 32.459846 -93.812561
96:76:3f:b7:b7:97 3245984649 -9381255340 32.459846 -93.812553
98:52:4a:86:fa:4c 3245908737 -9381267547 32.459087 -93.812675
98:52:4a:86:fa:4f 3245908355 -9381267547 32.459084 -93.812675
98:52:4a:86:fa:51 3245908355 -9381267547 32.459084 -93.812675
98:52:4a:86:fa:52 3245908737 -9381268310 32.459087 -93.812683
9e:ad:43:48:4a:a8 3245934677 -9381259918 32.459347 -93.812599
9e:b0:66:13:26:c1 3245907211 -9381227874 32.459072 -93.812279
ac:91:9b:c6:7d:d2 3245978927 -9381267547 32.459789 -93.812675
b2:4f:b8:7f:cb:83 3245938873 -9381260681 32.459389 -93.812607
ce:6c:6d:83:12:4d 3245933151 -9381253051 32.459332 -93.812531
d4:6c:6d:83:12:4d 3245931243 -9381252288 32.459312 -93.812523
d6:6c:6d:83:12:4d 3245933914 -9381251525 32.459339 -93.812515
da:13:99:28:92:b0 3245917510 -9381269836 32.459175 -93.812698
e8:97:b8:8e:5d:0a 3245927047 -9381250000 32.459270 -93.812500
0e:c0:3e:38:ef:36 3245924758 -9381269073 32.459248 -93.812691
ec:aa:a0:79:a6:b8 3245919418 -9381246185 32.459194 -93.812462
f4:0e:83:d7:fb:68 3245946121 -9381263732 32.459461 -93.812637
fa:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
fc:ae:34:94:57:f0 3245948028 -9381231689 32.459480 -93.812317
fe:ae:34:94:57:f1 3245947265 -9381232452 32.459473 -93.812325
00:71:c2:b2:32:68 3245960998 -9381239318 32.459610 -93.812393
16:71:c2:b2:32:68 3245961761 -9381238555 32.459618 -93.812386
1a:71:c2:b2:32:68 3245961761 -9381238555 32.459618 -93.812386
10:93:97:0a:e7:80 3245982742 -9381553649 32.459827 -93.815536
12:36:aa:62:9c:39 3245925140 -9381566619 32.459251 -93.815666
12:36:aa:62:9c:3a 3245926284 -9381568908 32.459263 -93.815689
12:36:aa:62:9c:3d 3245923614 -9381565856 32.459236 -93.815659
12:36:aa:62:9c:3e 3245925521 -9381567382 32.459255 -93.815674
12:36:aa:85:84:c9 3245957183 -9381577301 32.459572 -93.815773
18:9c:27:b6:4b:8a 3245976257 -9381594085 32.459763 -93.815941
02:cb:7a:c2:d1:42 3245947265 -9381558227 32.459473 -93.815582
02:cb:7a:c2:d1:43 3245948028 -9381558227 32.459480 -93.815582
02:cb:7a:c2:d1:45 3245947265 -9381559753 32.459473 -93.815598
36:e6:e6:86:cd:1c 3245981216 -9381570434 32.459812 -93.815704
3a:9c:27:b6:4b:8a 3245977020 -9381596374 32.459770 -93.815964
5a:9c:27:b6:4b:8a 3245976257 -9381596374 32.459763 -93.815964
8c:85:80:e4:35:dd 3245977783 -9381558990 32.459778 -93.815590
8c:0f:6f:21:c8:80 3245982742 -9381554412 32.459827 -93.815544
8c:0f:6f:d3:3b:68 3245903778 -9381518554 32.459038 -93.815186
8e:76:3f:d4:13:8d 3245978164 -9381594085 32.459782 -93.815941
94:a6:7e:31:02:35 3245890045 -9381510162 32.458900 -93.815102
9a:0f:6f:21:c8:80 3245982742 -9381554412 32.459827 -93.815544
9a:0f:6f:d3:3b:68 3245905303 -9381518554 32.459053 -93.815186
a2:0f:6f:21:c8:80 3245982360 -9381554412 32.459824 -93.815544
a2:0f:6f:d3:3b:68 3245904541 -9381518554 32.459045 -93.815186
a6:0f:6f:21:c8:80 3245983123 -9381557464 32.459831 -93.815575
a6:0f:6f:d3:3b:68 3245905685 -9381520080 32.459057 -93.815201
be:61:e9:cd:aa:a8 3245882415 -9381622314 32.458824 -93.816223
ca:3a:6b:db:9b:ba 3245902252 -9381513977 32.459023 -93.815140
ce:6c:6d:53:02:e5 3245964050 -9381594848 32.459640 -93.815948
d4:6c:6d:53:02:e5 3245963287 -9381592559 32.459633 -93.815926
d6:6c:6d:53:02:e5 3245962142 -9381593322 32.459621 -93.815933
da:e3:5e:f7:08:87 3245980834 -9381555938 32.459808 -93.815559
f8:aa:3f:fe:b2:1e 3245905303 -9381512451 32.459053 -93.815125
4e:6b:b8:aa:8c:80 3245885086 -9381540679 32.458851 -93.815407
78:b2:13:e7:91:39 3245882797 -9381607055 32.458828 -93.816071
9e:b3:f7:21:91:e7 3245910263 -9381617736 32.459103 -93.816177
ce:8b:66:31:a1:df 3245933151 -9381556701 32.459332 -93.815567
80:30:dc:c2:05:26 3245886993 -9381635284 32.458870 -93.816353
6e:29:90:f7:23:74 3245903396 -9381517791 32.459034 -93.815178
0c:73:29:ff:29:93 3245893096 -9381542968 32.458931 -93.815430
7e:27:bc:95:f5:35 3245974349 -9381566619 32.459743 -93.815666
00:cb:7a:d0:d1:42 3245967102 -9381575775 32.459671 -93.815758
00:cb:7a:d0:d1:47 3245966720 -9381576538 32.459667 -93.815765
2c:7e:81:ab:cd:1b 3245813751 -9381472778 32.458138 -93.814728
2c:fb:0f:0f:66:06 3245831298 -9381491851 32.458313 -93.814919
36:fb:0f:0f:66:06 3245833969 -9381491088 32.458340 -93.814911
4e:7e:81:ab:cd:1b 3245811080 -9381472778 32.458111 -93.814728
6e:7e:81:ab:cd:1b 3245812988 -9381472778 32.458130 -93.814728
84:00:2d:41:9a:38 3245840454 -9381491088 32.458405 -93.814911
88:6a:e3:e0:51:c4 3245843887 -9381491088 32.458439 -93.814911
92:00:2d:41:9a:38 3245839691 -9381491088 32.458397 -93.814911
9a:00:2d:41:9a:38 3245840454 -9381491088 32.458405 -93.814911
9a:9d:5d:df:f0:6a 3245788955 -9381491851 32.457890 -93.814919
9e:00:2d:41:9a:38 3245840072 -9381491088 32.458401 -93.814911
be:8c:cd:2f:95:16 3245823669 -9381494903 32.458237 -93.814949
c2:18:03:fb:7c:5e 3245796585 -9381478118 32.457966 -93.814781
0c:83:cc:c6:58:4f 3245823669 -9381491851 32.458237 -93.814919
ce:3f:cb:da:f6:1b 3245833587 -9381475830 32.458336 -93.814758
ce:ab:82:cf:55:98 3245824432 -9381491088 32.458244 -93.814911
d4:3f:cb:da:f6:1b 3245833206 -9381475067 32.458332 -93.814751
d4:ab:82:cf:55:98 3245824432 -9381491088 32.458244 -93.814911
d6:3f:cb:da:f6:1b 3245833969 -9381475067 32.458340 -93.814751
d6:ab:82:cf:55:98 3245823669 -9381490325 32.458237 -93.814903
da:3f:cb:da:f6:1b 3245833587 -9381475067 32.458336 -93.814751
da:ab:82:cf:55:98 3245823669 -9381491088 32.458237 -93.814911
0e:fe:7b:7e:0e:29 3245786666 -9381475830 32.457867 -93.814758
f8:aa:3f:fe:b2:3b 3245837783 -9381485748 32.458378 -93.814857
42:9e:9d:73:67:ef 3245817947 -9381486511 32.458179 -93.814865
6e:57:25:f3:7c:e5 3245834732 -9381487274 32.458347 -93.814873
9e:73:b1:ef:ad:77 3245817184 -9381499481 32.458172 -93.814995
1c:56:8e:0b:3b:34 3246085739 -9381424713 32.460857 -93.814247
24:de:8a:10:6e:a4 3246070098 -9381474304 32.460701 -93.814743
24:de:8a:60:04:14 3246067428 -9381462860 32.460674 -93.814629
48:e2:ad:ad:39:f4 3246047592 -9381441497 32.460476 -93.814415
54:2b:57:35:d6:c5 3246046829 -9381445312 32.460468 -93.814453
54:b2:03:53:16:68 3246035766 -9381394195 32.460358 -93.813942
56:2b:57:2f:ff:cf 3246062088 -9381448364 32.460621 -93.814484
62:b2:03:53:16:68 3246036911 -9381393432 32.460369 -93.813934
6a:b2:03:53:16:68 3246036911 -9381393432 32.460369 -93.813934
6e:b2:03:53:16:68 3246028518 -9381393432 32.460285 -93.813934
82:da:c2:2d:1f:12 3246070861 -9381422424 32.460709 -93.814224
82:da:c2:2d:1f:15 3246070480 -9381422424 32.460705 -93.814224
c0:94:35:dc:33:1a 3246071624 -9381478881 32.460716 -93.814789
ce:94:35:dc:33:1a 3246070861 -9381479644 32.460709 -93.814796
d6:94:35:dc:33:1a 3246070861 -9381478881 32.460709 -93.814789
28:c2:dd:dc:c9:b8 3246021270 -9381389617 32.460213 -93.813896
30:13:8b:2b:28:10 3246051025 -9381438446 32.460510 -93.814384
8c:0f:6f:18:7c:00 3246034240 -9381385803 32.460342 -93.813858
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
3a:e7:c0:83:c1:a7 3246105575 -9381404876 32.461056 -93.814049
c6:98:5c:db:c2:43 3246094512 -9381495666 32.460945 -93.814957
etc.

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.
--
Everything is possible if you're intelligent, but it's not always worth it. What makes it worth it, sometimes, is helping others do what you can do.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Andy Burns wrote:

Marian wrote:

this tutorial is only useful if you want to control the query
of Apple's highly insecure WPS database, which has no privacy controls.

I've not followed this thread in detail, I could understand the outrage
*if* apple were storing SSID/GPS pairs, such as ssid:Arlens_house_nomap=latitude:40.12345678,longitude:-120.12345678

But how is it compromising to store BSSID/GPS pairs such as bssid:AA:BB:CC:11:22:33=latitude:40.12345678,longitude:-120.12345678

How could anyone discover that AA:BB:CC:11:22:33 belongs to Arlen?

Since I reproduced almost exactly what the researchers said could be done,
did you read the research papers which were cited about this subject?

How would you summarize what they said about the privacy danger involved?

See references in the sig...
--
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://par.nsf.gov/servlets/purl/10540853>


Cybernews: *Anyone can tap into your WiFi location data to track you*
explains how Apple's WPS can be exploited for mass surveillance. <https://cybernews.com/privacy/apple-beams-wifi-location-data-privacy-risk/>

Cybersecurity News: *Hackers Can Abuse Appleos Wi-Fi Positioning System* details the University of Maryland study showing global tracking risks.
<https://cybersecuritynews.com/apples-wi-fi-positioning-system/>

Dark Reading: *Apple Geolocation API Exposes Wi-Fi Access Points Worldwide* notes that researchers could query hundreds of millions of APs in days. <https://www.darkreading.com/endpoint-security/apple-geolocation-api-exposes-wi-fi-access-points-worldwide>

Krebs on Security: *Why Your Wi-Fi Router Doubles as an Apple AirTag*
describes how Appleos data was used to track billions of devices globally <https://krebsonsecurity.com/2024/05/why-your-wi-fi-router-doubles-as-an-apple-airtag/>

Register: *Apple Wi-Fi Positioning System open to global tracking abuse*
covers the academic paper "Surveilling the Masses with Wi-Fi-Based
Positioning Systems" by Erik Rye and Dave Levin
<https://www.theregister.com/2024/05/23/apple_wifi_positioning_system/>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

On Sun, 21 Dec 2025 17:55:35 -0700, Marian
<marianjones@helpfulpeople.com> wrote:

Paul wrote:

It's sloppy workmanship :-)
We knew that much before investigating.

Thanks Paul and Winston for taking a look at the precision of the GPS data >stored in the Apple WPS database.

I thought I had responded to this where I will always openly admit when I >don't understand anything, so I will say I have no idea WHY Apple stores
the integer GPS values to the number of integer precision that they do.

I can only add the value that I modified the FOSS scripts so that they
report both the original machine-readable GPS coordinates and my >human-readable conversion since decimal GPS coordinates are what we use.

These are actual values output when I input the first BSSID below:
column 1 = the BSSID
column 2 = the integer latitude stored in the Apple WPS database
column 3 = the integer longitude stored in the Apple WPS database
columns 4 & 5 = a conversion of integer to decimal for GPS display tools

00:18:f8:c1:4a:65 3245990371 -9381384277 32.459904 -93.813843
02:aa:a0:e3:5f:38 3245890808 -9381494903 32.458908 -93.814949
44:1c:12:99:23:58 3245909881 -9381492614 32.459099 -93.814926
44:1c:12:99:23:5b 3245910644 -9381491088 32.459106 -93.814911
44:1c:12:99:23:5d 3245910644 -9381491851 32.459106 -93.814919
44:1c:12:99:23:5e 3245911026 -9381491088 32.459110 -93.814911
06:aa:a0:e3:5f:38 3245891952 -9381494903 32.458920 -93.814949
72:13:01:01:99:9a 3245920944 -9381445312 32.459209 -93.814453
72:13:01:01:99:9d 3245919036 -9381446838 32.459190 -93.814468
ec:aa:a0:e3:5f:38 3245891571 -9381494140 32.458916 -93.814941
fa:aa:a0:e3:5f:38 3245891571 -9381493377 32.458916 -93.814934
12:36:aa:7d:3d:b1 3245915603 -9381276702 32.459156 -93.812767
12:36:aa:7d:3d:b2 3245915222 -9381278228 32.459152 -93.812782
12:36:aa:7d:3d:b6 3245914840 -9381275177 32.459148 -93.812752
12:36:aa:c2:2c:01 3245956802 -9381256103 32.459568 -93.812561
12:59:32:64:b2:bc 3245960617 -9381244659 32.459606 -93.812447
14:c0:3e:38:ef:36 3245923614 -9381269073 32.459236 -93.812691
16:c0:3e:38:ef:36 3245925140 -9381269836 32.459251 -93.812698
1a:c0:3e:38:ef:36 3245925140 -9381269073 32.459251 -93.812691
02:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
38:17:b1:28:28:46 3245931625 -9381245422 32.459316 -93.812454
40:48:6e:f1:9f:34 3245958328 -9381306457 32.459583 -93.813065
42:17:b1:28:28:46 3245932388 -9381243133 32.459324 -93.812431
46:d8:78:a3:03:a3 3245965576 -9381226348 32.459656 -93.812263
5c:b0:66:13:26:c1 3245907974 -9381227874 32.459080 -93.812279
5e:b0:66:13:26:c1 3245907592 -9381227111 32.459076 -93.812271
06:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
72:13:01:46:3c:c1 3245978546 -9381228637 32.459785 -93.812286
72:13:01:46:3c:c6 3245979690 -9381228637 32.459797 -93.812286
7e:b0:66:13:26:c1 3245907211 -9381227874 32.459072 -93.812279
88:ad:43:48:4a:a8 3245934295 -9381259918 32.459343 -93.812599
8c:76:3f:b7:b7:97 3245985412 -9381255340 32.459854 -93.812553
8e:76:3f:b7:b7:97 3245984649 -9381256103 32.459846 -93.812561
96:76:3f:b7:b7:97 3245984649 -9381255340 32.459846 -93.812553
98:52:4a:86:fa:4c 3245908737 -9381267547 32.459087 -93.812675
98:52:4a:86:fa:4f 3245908355 -9381267547 32.459084 -93.812675
98:52:4a:86:fa:51 3245908355 -9381267547 32.459084 -93.812675
98:52:4a:86:fa:52 3245908737 -9381268310 32.459087 -93.812683
9e:ad:43:48:4a:a8 3245934677 -9381259918 32.459347 -93.812599
9e:b0:66:13:26:c1 3245907211 -9381227874 32.459072 -93.812279
ac:91:9b:c6:7d:d2 3245978927 -9381267547 32.459789 -93.812675
b2:4f:b8:7f:cb:83 3245938873 -9381260681 32.459389 -93.812607
ce:6c:6d:83:12:4d 3245933151 -9381253051 32.459332 -93.812531
d4:6c:6d:83:12:4d 3245931243 -9381252288 32.459312 -93.812523
d6:6c:6d:83:12:4d 3245933914 -9381251525 32.459339 -93.812515
da:13:99:28:92:b0 3245917510 -9381269836 32.459175 -93.812698
e8:97:b8:8e:5d:0a 3245927047 -9381250000 32.459270 -93.812500
0e:c0:3e:38:ef:36 3245924758 -9381269073 32.459248 -93.812691
ec:aa:a0:79:a6:b8 3245919418 -9381246185 32.459194 -93.812462
f4:0e:83:d7:fb:68 3245946121 -9381263732 32.459461 -93.812637
fa:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
fc:ae:34:94:57:f0 3245948028 -9381231689 32.459480 -93.812317
fe:ae:34:94:57:f1 3245947265 -9381232452 32.459473 -93.812325
00:71:c2:b2:32:68 3245960998 -9381239318 32.459610 -93.812393
16:71:c2:b2:32:68 3245961761 -9381238555 32.459618 -93.812386
1a:71:c2:b2:32:68 3245961761 -9381238555 32.459618 -93.812386
10:93:97:0a:e7:80 3245982742 -9381553649 32.459827 -93.815536
12:36:aa:62:9c:39 3245925140 -9381566619 32.459251 -93.815666
12:36:aa:62:9c:3a 3245926284 -9381568908 32.459263 -93.815689
12:36:aa:62:9c:3d 3245923614 -9381565856 32.459236 -93.815659
12:36:aa:62:9c:3e 3245925521 -9381567382 32.459255 -93.815674
12:36:aa:85:84:c9 3245957183 -9381577301 32.459572 -93.815773
18:9c:27:b6:4b:8a 3245976257 -9381594085 32.459763 -93.815941
02:cb:7a:c2:d1:42 3245947265 -9381558227 32.459473 -93.815582
02:cb:7a:c2:d1:43 3245948028 -9381558227 32.459480 -93.815582
02:cb:7a:c2:d1:45 3245947265 -9381559753 32.459473 -93.815598
36:e6:e6:86:cd:1c 3245981216 -9381570434 32.459812 -93.815704
3a:9c:27:b6:4b:8a 3245977020 -9381596374 32.459770 -93.815964
5a:9c:27:b6:4b:8a 3245976257 -9381596374 32.459763 -93.815964
8c:85:80:e4:35:dd 3245977783 -9381558990 32.459778 -93.815590
8c:0f:6f:21:c8:80 3245982742 -9381554412 32.459827 -93.815544
8c:0f:6f:d3:3b:68 3245903778 -9381518554 32.459038 -93.815186
8e:76:3f:d4:13:8d 3245978164 -9381594085 32.459782 -93.815941
94:a6:7e:31:02:35 3245890045 -9381510162 32.458900 -93.815102
9a:0f:6f:21:c8:80 3245982742 -9381554412 32.459827 -93.815544
9a:0f:6f:d3:3b:68 3245905303 -9381518554 32.459053 -93.815186
a2:0f:6f:21:c8:80 3245982360 -9381554412 32.459824 -93.815544
a2:0f:6f:d3:3b:68 3245904541 -9381518554 32.459045 -93.815186
a6:0f:6f:21:c8:80 3245983123 -9381557464 32.459831 -93.815575
a6:0f:6f:d3:3b:68 3245905685 -9381520080 32.459057 -93.815201
be:61:e9:cd:aa:a8 3245882415 -9381622314 32.458824 -93.816223
ca:3a:6b:db:9b:ba 3245902252 -9381513977 32.459023 -93.815140
ce:6c:6d:53:02:e5 3245964050 -9381594848 32.459640 -93.815948
d4:6c:6d:53:02:e5 3245963287 -9381592559 32.459633 -93.815926
d6:6c:6d:53:02:e5 3245962142 -9381593322 32.459621 -93.815933
da:e3:5e:f7:08:87 3245980834 -9381555938 32.459808 -93.815559
f8:aa:3f:fe:b2:1e 3245905303 -9381512451 32.459053 -93.815125
4e:6b:b8:aa:8c:80 3245885086 -9381540679 32.458851 -93.815407
78:b2:13:e7:91:39 3245882797 -9381607055 32.458828 -93.816071
9e:b3:f7:21:91:e7 3245910263 -9381617736 32.459103 -93.816177
ce:8b:66:31:a1:df 3245933151 -9381556701 32.459332 -93.815567
80:30:dc:c2:05:26 3245886993 -9381635284 32.458870 -93.816353
6e:29:90:f7:23:74 3245903396 -9381517791 32.459034 -93.815178
0c:73:29:ff:29:93 3245893096 -9381542968 32.458931 -93.815430
7e:27:bc:95:f5:35 3245974349 -9381566619 32.459743 -93.815666
00:cb:7a:d0:d1:42 3245967102 -9381575775 32.459671 -93.815758
00:cb:7a:d0:d1:47 3245966720 -9381576538 32.459667 -93.815765
2c:7e:81:ab:cd:1b 3245813751 -9381472778 32.458138 -93.814728
2c:fb:0f:0f:66:06 3245831298 -9381491851 32.458313 -93.814919
36:fb:0f:0f:66:06 3245833969 -9381491088 32.458340 -93.814911
4e:7e:81:ab:cd:1b 3245811080 -9381472778 32.458111 -93.814728
6e:7e:81:ab:cd:1b 3245812988 -9381472778 32.458130 -93.814728
84:00:2d:41:9a:38 3245840454 -9381491088 32.458405 -93.814911
88:6a:e3:e0:51:c4 3245843887 -9381491088 32.458439 -93.814911
92:00:2d:41:9a:38 3245839691 -9381491088 32.458397 -93.814911
9a:00:2d:41:9a:38 3245840454 -9381491088 32.458405 -93.814911
9a:9d:5d:df:f0:6a 3245788955 -9381491851 32.457890 -93.814919
9e:00:2d:41:9a:38 3245840072 -9381491088 32.458401 -93.814911
be:8c:cd:2f:95:16 3245823669 -9381494903 32.458237 -93.814949
c2:18:03:fb:7c:5e 3245796585 -9381478118 32.457966 -93.814781
0c:83:cc:c6:58:4f 3245823669 -9381491851 32.458237 -93.814919
ce:3f:cb:da:f6:1b 3245833587 -9381475830 32.458336 -93.814758
ce:ab:82:cf:55:98 3245824432 -9381491088 32.458244 -93.814911
d4:3f:cb:da:f6:1b 3245833206 -9381475067 32.458332 -93.814751
d4:ab:82:cf:55:98 3245824432 -9381491088 32.458244 -93.814911
d6:3f:cb:da:f6:1b 3245833969 -9381475067 32.458340 -93.814751
d6:ab:82:cf:55:98 3245823669 -9381490325 32.458237 -93.814903
da:3f:cb:da:f6:1b 3245833587 -9381475067 32.458336 -93.814751
da:ab:82:cf:55:98 3245823669 -9381491088 32.458237 -93.814911
0e:fe:7b:7e:0e:29 3245786666 -9381475830 32.457867 -93.814758
f8:aa:3f:fe:b2:3b 3245837783 -9381485748 32.458378 -93.814857
42:9e:9d:73:67:ef 3245817947 -9381486511 32.458179 -93.814865
6e:57:25:f3:7c:e5 3245834732 -9381487274 32.458347 -93.814873
9e:73:b1:ef:ad:77 3245817184 -9381499481 32.458172 -93.814995
1c:56:8e:0b:3b:34 3246085739 -9381424713 32.460857 -93.814247
24:de:8a:10:6e:a4 3246070098 -9381474304 32.460701 -93.814743
24:de:8a:60:04:14 3246067428 -9381462860 32.460674 -93.814629
48:e2:ad:ad:39:f4 3246047592 -9381441497 32.460476 -93.814415
54:2b:57:35:d6:c5 3246046829 -9381445312 32.460468 -93.814453
54:b2:03:53:16:68 3246035766 -9381394195 32.460358 -93.813942
56:2b:57:2f:ff:cf 3246062088 -9381448364 32.460621 -93.814484
62:b2:03:53:16:68 3246036911 -9381393432 32.460369 -93.813934
6a:b2:03:53:16:68 3246036911 -9381393432 32.460369 -93.813934
6e:b2:03:53:16:68 3246028518 -9381393432 32.460285 -93.813934
82:da:c2:2d:1f:12 3246070861 -9381422424 32.460709 -93.814224
82:da:c2:2d:1f:15 3246070480 -9381422424 32.460705 -93.814224
c0:94:35:dc:33:1a 3246071624 -9381478881 32.460716 -93.814789
ce:94:35:dc:33:1a 3246070861 -9381479644 32.460709 -93.814796
d6:94:35:dc:33:1a 3246070861 -9381478881 32.460709 -93.814789
28:c2:dd:dc:c9:b8 3246021270 -9381389617 32.460213 -93.813896
30:13:8b:2b:28:10 3246051025 -9381438446 32.460510 -93.814384
8c:0f:6f:18:7c:00 3246034240 -9381385803 32.460342 -93.813858
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
3a:e7:c0:83:c1:a7 3246105575 -9381404876 32.461056 -93.814049
c6:98:5c:db:c2:43 3246094512 -9381495666 32.460945 -93.814957
etc.

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.
--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272 AE6KS 831-336-2558

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

How could anyone discover that AA:BB:CC:11:22:33 belongs to Arlen?

Easy : Someone drives up to his house and than checks their phone which SSIDs it detects. :-)

Here's the key thing we need to do to gain an appreciation for privacy.

I suggest anyone else who thinks a BSSID is "just a number" begin to
separate the object being tracked from the person being inferred.

This is a very common but very incorrect assumption:
"If the thing being tracked isn't me, then I'm not being tracked."

That is factually wrong, and the academic research we have been citing
makes that abundantly clear.

We need to take the time to understand how modern tracking systems work. Because there are layers of complexity involved that interplay together.

The privacy risk in Apple's WiFi Positioning System is not what most think
it is. The core issue is not whether the scanning device is tracked.

The core problem is that the WiFi access point itself becomes a traceable object because Apple publishes its GPS coordinates in a global database.

I've proved it's trivial to obtain the entire WPS database for the mere
cost of modifying the public FOSS scripts and a few GB of disk space.

Apple's WPS stores billions of BSSIDs along with their latitude and
longitude. Anyone can query those coordinates. If a BSSID moves, its
movement can be tracked. If that BSSID is inside a car, an RV, a backpack,
a travel router, a MiFi hotspot, or even a home router that gets relocated, then the person carrying it is tracked indirectly.

This is exactly what the University of Maryland paper "Surveilling the
Masses with Wi-Fi-Based Positioning Systems" demonstrated. The researchers tracked cars, delivery vehicles, people, and sensitive facilities simply by watching BSSIDs move in Apple's database. No user device needed to be compromised. The BSSID itself is the tracking beacon.

It was trivial for me to reproduce their results.
a. I created sequential (or random) valid BSSIDs
b. I looked them up and found where they were located
c. That gave me the next nearest 400 BSSIDs also

From that list, I could expand outward (if I felt like it, and I do not).
Which is exactly what the researchers said could be done (read the paper).

Once I have a BSSID of interest, I could track its movements.
Which I proved was trivial (where I set movement at 100km distance).

Again, that's exactly what the researchers said could be done.
And I did it.,

Apple's system is so different from everyone else's system that it was
trivial for me, a nobody, to do it - using open source code out there.

This is the primary, documented, peer-reviewed risk. It does not depend on speculation about Apple's internal behavior. It is observable, measurable,
and repeatable. Anyone with a script can look up the GPS coordinates of any BSSID in the database and monitor its movement over time.

Separately, it is also true that Apple receives the location of the device
that reports nearby BSSIDs, because that is how the database is built. That
is a different issue, and Apple does not publish that data publicly. But it shows that both the reporting device and the BSSID itself become part of Apple's location infrastructure.

The important point is that the BSSID does not need to be "associated with
you" for this to reveal your movements. If the BSSID moves with you, then tracking the BSSID is tracking you. That is the core finding of the
academic research, and it is the part that cannot be dismissed.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

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 Mikrotick 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: alt.internet.wireless

Marian wrote:

Since I reproduced almost exactly what the researchers said could be done, did you read the research papers which were cited about this subject?

No, I didn't ...


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

See references in the sig...

I hide .sigs to avoid the politics/religion that some people use.

If someone could come up with a single sentence that describes how
someone could find one or more BSSIDs for a person or family, without
already knowing their location, that would spark my curiosity ...

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

How could anyone discover that AA:BB:CC:11:22:33 belongs to Arlen?

Easy : Someone drives up to his house and than checks their phone which
SSIDs it detects. :-)

Here's the key thing we need to do to gain an appreciation for privacy.

I suggest anyone else who thinks a BSSID is "just a number" begin to
separate the object being tracked from the person being inferred.

It is. You can get rid of it - or replace it - at the drop of a hat. Just like you do with your nym.


There is quite a list of "just a number" stuff that you have on you which
are *not* you, but do associate themselves with you. Including the name
you are referring to yourself within your neighbourhood.

You likely have a smartphone. That means that your phone company has got
data about where your phone is, every minute of the day.

Your phone has bluetooth enabled ? Than anyone with less than $50
equipment will be able to register that you walked by. A store will be able to register that you entered and even where you paused (which products
you're looking at).

You have a credit and/or loyalty cards ? Every time you use it data is stored about where you did so it and what you payed for - meaning location
and behavioural data.

Anyone with a bit of equipment can walk near you and scan the cards that you have in your wallet within your trousers or coat.

You drive a car ? Its plates will likely be scanned when you drive around, and that data is also stored. Besides that, you already gave your
"private" data to the DMV and, I might hope, to some insurance company.

And than I have not even talked about the upcoming industry of biometrics, where a random street camera can identify you on your face alone.


Your whole problem with your BSSID is that you had access to a database it appears in, and as such *have become aware* about how many "just a number" thingies are available to other people.

All those other databases you know nothing about / have no access to ? Law enforcement can demand that data, and anyone willing to spend a buck
(private investigators, head-hunters, your neighbour) can also get it.

You think you can be anonymous / untrackable ? Think again.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Andy Burns <usenet@andyburns.uk> wrote:

Marian wrote:

See references in the sig...

I hide .sigs to avoid the politics/religion that some people use.

If someone could come up with a single sentence that describes how
someone could find one or more BSSIDs for a person or family, without already knowing their location, that would spark my curiosity ...

The key question.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Jeff Liebermann <jeffl@cruzio.com> wrote:

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.

These are from loss of precision in the storing of floating-point numbers
in python. They aren't real. The source data will not include all the
zeros.




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Chris wrote:

Jeff Liebermann <jeffl@cruzio.com> wrote:

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.

These are from loss of precision in the storing of floating-point numbers
in python. They aren't real. The source data will not include all the
zeros.

The precision is a red herring, in my opinion, since the fact that you
can't get out of the Apple WPS database even though you followed all of
Apple's legally binding published policies is the main privacy issue.

Apple's decision is legally, morally & ethically reprehensible, so I will
start working on getting Apple to change their decision any way that I can.

However, to the point of the raw precision in the Apple WPS database, I've modified the open source Apple bssid locator tools to report raw integer
values in addition to conversion to the human-readable GPS coordinates.

Here are raw/converted values for the bssid lookup on the access point
located near 4302 Josey Cir, Shreveport, LA 71109 (as a random AP lookup).

00:18:f8:c1:4a:65 3245990371 -9381384277 32.459904 -93.813843
02:aa:a0:e3:5f:38 3245890808 -9381494903 32.458908 -93.814949
44:1c:12:99:23:58 3245909881 -9381492614 32.459099 -93.814926
44:1c:12:99:23:5b 3245910644 -9381491088 32.459106 -93.814911
44:1c:12:99:23:5d 3245910644 -9381491851 32.459106 -93.814919
44:1c:12:99:23:5e 3245911026 -9381491088 32.459110 -93.814911
06:aa:a0:e3:5f:38 3245891952 -9381494903 32.458920 -93.814949
72:13:01:01:99:9a 3245920944 -9381445312 32.459209 -93.814453
72:13:01:01:99:9d 3245919036 -9381446838 32.459190 -93.814468
ec:aa:a0:e3:5f:38 3245891571 -9381494140 32.458916 -93.814941
fa:aa:a0:e3:5f:38 3245891571 -9381493377 32.458916 -93.814934
12:36:aa:7d:3d:b1 3245915603 -9381276702 32.459156 -93.812767
12:36:aa:7d:3d:b2 3245915222 -9381278228 32.459152 -93.812782
12:36:aa:7d:3d:b6 3245914840 -9381275177 32.459148 -93.812752
12:36:aa:c2:2c:01 3245956802 -9381256103 32.459568 -93.812561
12:59:32:64:b2:bc 3245960617 -9381244659 32.459606 -93.812447
14:c0:3e:38:ef:36 3245923614 -9381269073 32.459236 -93.812691
16:c0:3e:38:ef:36 3245925140 -9381269836 32.459251 -93.812698
1a:c0:3e:38:ef:36 3245925140 -9381269073 32.459251 -93.812691
02:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
38:17:b1:28:28:46 3245931625 -9381245422 32.459316 -93.812454
40:48:6e:f1:9f:34 3245958328 -9381306457 32.459583 -93.813065
42:17:b1:28:28:46 3245932388 -9381243133 32.459324 -93.812431
46:d8:78:a3:03:a3 3245965576 -9381226348 32.459656 -93.812263
5c:b0:66:13:26:c1 3245907974 -9381227874 32.459080 -93.812279
5e:b0:66:13:26:c1 3245907592 -9381227111 32.459076 -93.812271
06:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
72:13:01:46:3c:c1 3245978546 -9381228637 32.459785 -93.812286
72:13:01:46:3c:c6 3245979690 -9381228637 32.459797 -93.812286
7e:b0:66:13:26:c1 3245907211 -9381227874 32.459072 -93.812279
88:ad:43:48:4a:a8 3245934295 -9381259918 32.459343 -93.812599
8c:76:3f:b7:b7:97 3245985412 -9381255340 32.459854 -93.812553
8e:76:3f:b7:b7:97 3245984649 -9381256103 32.459846 -93.812561
96:76:3f:b7:b7:97 3245984649 -9381255340 32.459846 -93.812553
98:52:4a:86:fa:4c 3245908737 -9381267547 32.459087 -93.812675
98:52:4a:86:fa:4f 3245908355 -9381267547 32.459084 -93.812675
98:52:4a:86:fa:51 3245908355 -9381267547 32.459084 -93.812675
98:52:4a:86:fa:52 3245908737 -9381268310 32.459087 -93.812683
9e:ad:43:48:4a:a8 3245934677 -9381259918 32.459347 -93.812599
9e:b0:66:13:26:c1 3245907211 -9381227874 32.459072 -93.812279
ac:91:9b:c6:7d:d2 3245978927 -9381267547 32.459789 -93.812675
b2:4f:b8:7f:cb:83 3245938873 -9381260681 32.459389 -93.812607
ce:6c:6d:83:12:4d 3245933151 -9381253051 32.459332 -93.812531
d4:6c:6d:83:12:4d 3245931243 -9381252288 32.459312 -93.812523
d6:6c:6d:83:12:4d 3245933914 -9381251525 32.459339 -93.812515
da:13:99:28:92:b0 3245917510 -9381269836 32.459175 -93.812698
e8:97:b8:8e:5d:0a 3245927047 -9381250000 32.459270 -93.812500
0e:c0:3e:38:ef:36 3245924758 -9381269073 32.459248 -93.812691
ec:aa:a0:79:a6:b8 3245919418 -9381246185 32.459194 -93.812462
f4:0e:83:d7:fb:68 3245946121 -9381263732 32.459461 -93.812637
fa:aa:a0:79:a6:b8 3245920181 -9381246185 32.459202 -93.812462
fc:ae:34:94:57:f0 3245948028 -9381231689 32.459480 -93.812317
fe:ae:34:94:57:f1 3245947265 -9381232452 32.459473 -93.812325
00:71:c2:b2:32:68 3245960998 -9381239318 32.459610 -93.812393
16:71:c2:b2:32:68 3245961761 -9381238555 32.459618 -93.812386
1a:71:c2:b2:32:68 3245961761 -9381238555 32.459618 -93.812386
10:93:97:0a:e7:80 3245982742 -9381553649 32.459827 -93.815536
12:36:aa:62:9c:39 3245925140 -9381566619 32.459251 -93.815666
12:36:aa:62:9c:3a 3245926284 -9381568908 32.459263 -93.815689
12:36:aa:62:9c:3d 3245923614 -9381565856 32.459236 -93.815659
12:36:aa:62:9c:3e 3245925521 -9381567382 32.459255 -93.815674
12:36:aa:85:84:c9 3245957183 -9381577301 32.459572 -93.815773
18:9c:27:b6:4b:8a 3245976257 -9381594085 32.459763 -93.815941
02:cb:7a:c2:d1:42 3245947265 -9381558227 32.459473 -93.815582
02:cb:7a:c2:d1:43 3245948028 -9381558227 32.459480 -93.815582
02:cb:7a:c2:d1:45 3245947265 -9381559753 32.459473 -93.815598
36:e6:e6:86:cd:1c 3245981216 -9381570434 32.459812 -93.815704
3a:9c:27:b6:4b:8a 3245977020 -9381596374 32.459770 -93.815964
5a:9c:27:b6:4b:8a 3245976257 -9381596374 32.459763 -93.815964
8c:85:80:e4:35:dd 3245977783 -9381558990 32.459778 -93.815590
8c:0f:6f:21:c8:80 3245982742 -9381554412 32.459827 -93.815544
8c:0f:6f:d3:3b:68 3245903778 -9381518554 32.459038 -93.815186
8e:76:3f:d4:13:8d 3245978164 -9381594085 32.459782 -93.815941
94:a6:7e:31:02:35 3245890045 -9381510162 32.458900 -93.815102
9a:0f:6f:21:c8:80 3245982742 -9381554412 32.459827 -93.815544
9a:0f:6f:d3:3b:68 3245905303 -9381518554 32.459053 -93.815186
a2:0f:6f:21:c8:80 3245982360 -9381554412 32.459824 -93.815544
a2:0f:6f:d3:3b:68 3245904541 -9381518554 32.459045 -93.815186
a6:0f:6f:21:c8:80 3245983123 -9381557464 32.459831 -93.815575
a6:0f:6f:d3:3b:68 3245905685 -9381520080 32.459057 -93.815201
be:61:e9:cd:aa:a8 3245882415 -9381622314 32.458824 -93.816223
ca:3a:6b:db:9b:ba 3245902252 -9381513977 32.459023 -93.815140
ce:6c:6d:53:02:e5 3245964050 -9381594848 32.459640 -93.815948
d4:6c:6d:53:02:e5 3245963287 -9381592559 32.459633 -93.815926
d6:6c:6d:53:02:e5 3245962142 -9381593322 32.459621 -93.815933
da:e3:5e:f7:08:87 3245980834 -9381555938 32.459808 -93.815559
f8:aa:3f:fe:b2:1e 3245905303 -9381512451 32.459053 -93.815125
4e:6b:b8:aa:8c:80 3245885086 -9381540679 32.458851 -93.815407
78:b2:13:e7:91:39 3245882797 -9381607055 32.458828 -93.816071
9e:b3:f7:21:91:e7 3245910263 -9381617736 32.459103 -93.816177
ce:8b:66:31:a1:df 3245933151 -9381556701 32.459332 -93.815567
80:30:dc:c2:05:26 3245886993 -9381635284 32.458870 -93.816353
6e:29:90:f7:23:74 3245903396 -9381517791 32.459034 -93.815178
0c:73:29:ff:29:93 3245893096 -9381542968 32.458931 -93.815430
7e:27:bc:95:f5:35 3245974349 -9381566619 32.459743 -93.815666
00:cb:7a:d0:d1:42 3245967102 -9381575775 32.459671 -93.815758
00:cb:7a:d0:d1:47 3245966720 -9381576538 32.459667 -93.815765
2c:7e:81:ab:cd:1b 3245813751 -9381472778 32.458138 -93.814728
2c:fb:0f:0f:66:06 3245831298 -9381491851 32.458313 -93.814919
36:fb:0f:0f:66:06 3245833969 -9381491088 32.458340 -93.814911
4e:7e:81:ab:cd:1b 3245811080 -9381472778 32.458111 -93.814728
6e:7e:81:ab:cd:1b 3245812988 -9381472778 32.458130 -93.814728
84:00:2d:41:9a:38 3245840454 -9381491088 32.458405 -93.814911
88:6a:e3:e0:51:c4 3245843887 -9381491088 32.458439 -93.814911
92:00:2d:41:9a:38 3245839691 -9381491088 32.458397 -93.814911
9a:00:2d:41:9a:38 3245840454 -9381491088 32.458405 -93.814911
9a:9d:5d:df:f0:6a 3245788955 -9381491851 32.457890 -93.814919
9e:00:2d:41:9a:38 3245840072 -9381491088 32.458401 -93.814911
be:8c:cd:2f:95:16 3245823669 -9381494903 32.458237 -93.814949
c2:18:03:fb:7c:5e 3245796585 -9381478118 32.457966 -93.814781
0c:83:cc:c6:58:4f 3245823669 -9381491851 32.458237 -93.814919
ce:3f:cb:da:f6:1b 3245833587 -9381475830 32.458336 -93.814758
ce:ab:82:cf:55:98 3245824432 -9381491088 32.458244 -93.814911
d4:3f:cb:da:f6:1b 3245833206 -9381475067 32.458332 -93.814751
d4:ab:82:cf:55:98 3245824432 -9381491088 32.458244 -93.814911
d6:3f:cb:da:f6:1b 3245833969 -9381475067 32.458340 -93.814751
d6:ab:82:cf:55:98 3245823669 -9381490325 32.458237 -93.814903
da:3f:cb:da:f6:1b 3245833587 -9381475067 32.458336 -93.814751
da:ab:82:cf:55:98 3245823669 -9381491088 32.458237 -93.814911
0e:fe:7b:7e:0e:29 3245786666 -9381475830 32.457867 -93.814758
f8:aa:3f:fe:b2:3b 3245837783 -9381485748 32.458378 -93.814857
42:9e:9d:73:67:ef 3245817947 -9381486511 32.458179 -93.814865
6e:57:25:f3:7c:e5 3245834732 -9381487274 32.458347 -93.814873
9e:73:b1:ef:ad:77 3245817184 -9381499481 32.458172 -93.814995
1c:56:8e:0b:3b:34 3246085739 -9381424713 32.460857 -93.814247
24:de:8a:10:6e:a4 3246070098 -9381474304 32.460701 -93.814743
24:de:8a:60:04:14 3246067428 -9381462860 32.460674 -93.814629
48:e2:ad:ad:39:f4 3246047592 -9381441497 32.460476 -93.814415
54:2b:57:35:d6:c5 3246046829 -9381445312 32.460468 -93.814453
54:b2:03:53:16:68 3246035766 -9381394195 32.460358 -93.813942
56:2b:57:2f:ff:cf 3246062088 -9381448364 32.460621 -93.814484
62:b2:03:53:16:68 3246036911 -9381393432 32.460369 -93.813934
6a:b2:03:53:16:68 3246036911 -9381393432 32.460369 -93.813934
6e:b2:03:53:16:68 3246028518 -9381393432 32.460285 -93.813934
82:da:c2:2d:1f:12 3246070861 -9381422424 32.460709 -93.814224
82:da:c2:2d:1f:15 3246070480 -9381422424 32.460705 -93.814224
c0:94:35:dc:33:1a 3246071624 -9381478881 32.460716 -93.814789
ce:94:35:dc:33:1a 3246070861 -9381479644 32.460709 -93.814796
d6:94:35:dc:33:1a 3246070861 -9381478881 32.460709 -93.814789
28:c2:dd:dc:c9:b8 3246021270 -9381389617 32.460213 -93.813896
30:13:8b:2b:28:10 3246051025 -9381438446 32.460510 -93.814384
8c:0f:6f:18:7c:00 3246034240 -9381385803 32.460342 -93.813858
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
3a:e7:c0:83:c1:a7 3246105575 -9381404876 32.461056 -93.814049
c6:98:5c:db:c2:43 3246094512 -9381495666 32.460945 -93.814957
--
My goal is to help people & to learn more from those people I help.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Paul wrote:

$GPGGA,210230,3855.4487,N,09446.0071,W,1,07,1.1,370.5,M,-29.5,M,,*7A # degrees minutes fractions-of-a-minute

Latitude (in DDMM.MMM format) 38.554487 as 38. 55.4487
Latitude compass direction
Longitude (in DDDMM.MMM format) 094.460071 as 094. 46.0071
Longitude compass direction

We don't want to go into the minutiae to dismiss the crap on the end of -93.81759643000001

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

From Newsgroup: alt.internet.wireless

Marian wrote:

Chris wrote:

Jeff Liebermann <jeffl@cruzio.com> wrote:

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.

These are from loss of precision in the storing of floating-point numbers
in python. They aren't real. The source data will not include all the
zeros.

The precision is a red herring, in my opinion, since the fact that you
can't get out of the Apple WPS database even though you followed all of Apple's legally binding published policies is the main privacy issue.

Apple's decision is legally, morally & ethically reprehensible, so I will start working on getting Apple to change their decision any way that I can.

However, to the point of the raw precision in the Apple WPS database, I've modified the open source Apple bssid locator tools to report raw integer values in addition to conversion to the human-readable GPS coordinates.

Here are raw/converted values for the bssid lookup on the access point located near 4302 Josey Cir, Shreveport, LA 71109 (as a random AP lookup).

00:18:f8:c1:4a:65 3245990371 -9381384277 32.459904 -93.813843
02:aa:a0:e3:5f:38 3245890808 -9381494903 32.458908 -93.814949
44:1c:12:99:23:58 3245909881 -9381492614 32.459099 -93.814926
44:1c:12:99:23:5b 3245910644 -9381491088 32.459106 -93.814911

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

From Newsgroup: alt.internet.wireless

Andy Burns wrote:

Marian wrote:

Since I reproduced almost exactly what the researchers said could be done, >> did you read the research papers which were cited about this subject?

No, I didn't ...

Rest assured I'm in direct email contact with Brian at Krebs on Security
who wrote this article, where I've given him all my work and he agrees.

Krebs on Security: *Why Your Wi-Fi Router Doubles as an Apple AirTag*
describes how Appleos data was used to track billions of devices globally <https://krebsonsecurity.com/2024/05/why-your-wi-fi-router-doubles-as-an-apple-airtag/>

His article is what got me started since I wanted to ensure I wasn't in
Apple's highly insecure but very public WPS database since I've opted out
for years on all my access points, so I'm not in anyone else's public WPS.

I almost had a heart attack when I found out that Apple has no intention of honoring their very public privacy policy - which - to me - is so egregious
an act that I am working with Apple at this very moment to change that
policy (since my next-door neighbor is very high in the Apple hierarchy).

So far Apple has NOT agreed to do the ethical, legal & moral thing,
but I'm trying to impress upon Apple execs that this is the wrong approach.

Time (and effort) will tell as I'm trying to protect the privacy of not
only myself, but hundreds of millions of households and firms in the USA.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Chris wrote:

Andy Burns <usenet@andyburns.uk> wrote:

Marian wrote:

See references in the sig...

I hide .sigs to avoid the politics/religion that some people use.

If someone could come up with a single sentence that describes how
someone could find one or more BSSIDs for a person or family, without
already knowing their location, that would spark my curiosity ...

The key question.

While I respect the question, just the fact someone would ask means they haven't read what the security researchers have said about the situation.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://par.nsf.gov/servlets/purl/10540853>

To summarize in a single sentence, I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it).

It's trivial to do.
And I already proved that statement.

If I can do it, the bad guys already have.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

You think you can be anonymous / untrackable ? Think again.

The fundamental issue is Apple is not respecting their legally binding
policy to allow people like me (who care about privacy) to opt out of WPS.

I am working with Apple directly on this (through my next-door neighbor who
is very high in the Apple hierarchy) but so far Apple refuses to honor
their public privacy policy.

I have let Apple know that is an unacceptable response, so my focus moving forward will be to get Apple to make the legal, moral & ethical decision.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it).

But which of those 2 billion belong to me?


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

You think you can be anonymous / untrackable ? Think again.

The fundamental issue is Apple is not respecting their legally binding
policy to allow people like me (who care about privacy) to opt out of WPS.

As long as that BSSID is not openly linked to you, the person, than there is no privacy issue present.

Also, I take it you have disabled the "A" part of your device(s) A-GPS* ?

* If not, your smartphone asking Apple for the coordinates of nearby BSSIDs gives your own location away.

As for your "legally binding policy" claim ?: You have claimed facts *way* to often to believe you without having hard evidence for it.

And you misssed the whole point (but whats new) : you are throwing so much data around that you can't control and even *need* to throw around (smartphone) that removing that BSSID and its coordinates from a database doesn't really help.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

On Mon, 22 Dec 2025 18:00:14 +0000, Andy Burns <usenet@andyburns.uk>
wrote:

Marian wrote:

I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it).

But which of those 2 billion belong to me?

Well, *you* know which it is, and ve haf vays of making you talk, so...

https://en.wiktionary.org/wiki/ve_haf_vays_of_making_you_talk

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Char Jackson wrote on 12/22/2025 3:42 PM:

On Mon, 22 Dec 2025 18:00:14 +0000, Andy Burns <usenet@andyburns.uk>
wrote:

Marian wrote:

I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it). >>

But which of those 2 billion belong to me?

Well, *you* know which it is, and ve haf vays of making you talk, so...

https://en.wiktionary.org/wiki/ve_haf_vays_of_making_you_talk

Hush! You are scaring marian.

He happens to be a super intelligent paranoid schizophrenic and you
could push him over the edge with this sort of talk.

Leave him be. He's performing a valuable service by examining minute
details and writing thousands of tutorials for everyone.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Char Jackson <none@none.invalid> wrote:

On Mon, 22 Dec 2025 18:00:14 +0000, Andy Burns <usenet@andyburns.uk>
wrote:

Marian wrote:

I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it). >>

But which of those 2 billion belong to me?

Well, *you* know which it is, and ve haf vays of making you talk, so...

Do *you* know your MAC address if presented with a list? I certainly don't.


It would be easier just to ask me for my physical address.

https://en.wiktionary.org/wiki/ve_haf_vays_of_making_you_talk

Am surprised there isn't a reference to the 80's comedy show 'Allo 'Allo!

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

On Tue, 23 Dec 2025 10:00:36 -0000 (UTC), Chris <ithinkiam@gmail.com>
wrote:

Char Jackson <none@none.invalid> wrote:

On Mon, 22 Dec 2025 18:00:14 +0000, Andy Burns <usenet@andyburns.uk>
wrote:

Marian wrote:

I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it). >>>

But which of those 2 billion belong to me?

Well, *you* know which it is, and ve haf vays of making you talk, so...

Do *you* know your MAC address if presented with a list? I certainly don't.

I actually don't know my WAN MAC, but I know where to find it and could
do so in a few seconds if I needed it. I was just joking with Andy,
though.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Char Jackson wrote:

On Tue, 23 Dec 2025 10:00:36 -0000 (UTC), Chris <ithinkiam@gmail.com>
wrote:

Char Jackson <none@none.invalid> wrote:

On Mon, 22 Dec 2025 18:00:14 +0000, Andy Burns <usenet@andyburns.uk>
wrote:

Marian wrote:

I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it). >>>>

But which of those 2 billion belong to me?

Well, *you* know which it is, and ve haf vays of making you talk, so...

Do *you* know your MAC address if presented with a list? I certainly don't.

I actually don't know my WAN MAC, but I know where to find it and could
do so in a few seconds if I needed it. I was just joking with Andy,
though.

I wonder if everyone realizes the script I posted will give them your MAC & location of your own access points, including your nearest 400 neighbors'.
<https://i.postimg.cc/43ysV3Mr/fermium.jpg>

You get a map (using Fermium) that shows all 400 of them, down to the very corner of the home where the access point is located (as mine show up
exactly at the barn, in the stables, at the pool, in my office, etc.).

So every one of these is in Apple's WPS database with their GPS location
<https://i.postimg.cc/qMhQRkJN/linksys-wrt-54g.jpg>

I will move one to the location of the Christmas Eve party later today.
I'll then watch it move on Apple's WPS database, hopefully by tomorrow.

It's that easy to track its movement to the exact corner of your home!

The problem here I'm trying to resolve will protect the privacy of hundreds
of millions of owners who opted out correctly from Apple's WPS database,
and yet, Apple has decided not to respect any of their privacy wishes.

What Apple is doing is lying about privacy in a way that is reprehensible.

What Apple is doing is claiming they care about privacy, but clearly Apple
is doing what is clearly the antithesis of privacy (read the research).

Apple "says" they care about privacy.
Apple is lying.

What Apple is doing (by not honoring their own privacy policy) is the antithesis of privacy. It's legally, morally & ethically reprehensible.

Which is easy to prove.
a. Only Apple does this
b. Not Google
c. Not Mozilla

Only Apple.
Nobody else.

Just Apple.
Think about that fact.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

The fundamental issue is Apple is not respecting their legally binding
policy to allow people like me (who care about privacy) to opt out of WPS.

As long as that BSSID is not openly linked to you, the person, than there is no privacy issue present.

Since I have already posted a half dozen security research papers and
articles that expressly claim otherwise, you're entitled to your own
opinion which isn't backed up by a single security researcher on earth.

The research shows that BSSID + geolocation enables inference attacks,
movement tracking, and household identification even without explicit
personal identifiers. That's why every major security researcher treats
Wi-Fi geolocation databases as sensitive.

This isn't a matter of your opinion; it's documented in the literature.

Also, I take it you have disabled the "A" part of your device(s) A-GPS* ?

It's disconcerting that you've said that since it means you don't
understand the problem set to even the most basic level.

For those lurking and learning, this isn't what people like Rudy think it
is, since A-GPS has absolutely nothing directly to do with any of this.

A-GPS is simply a method for a phone to speed up its own location fix using network assistance. It has nothing to do with whether Apple collects and republishes the geolocation of privately owned Wi-Fi access points.

The vulnerability documented in the research applies to every access point, regardless of whether the owner uses A-GPS, GPS, or no smartphone at all.

So the A-GPS question is a separate topic and doesn't address the issue
under discussion.

* If not, your smartphone asking Apple for the coordinates of nearby BSSIDs gives your own location away.

You perhaps didn't read the security research which explained the
vulnerability has nothing directly to do with using Apple products.

*EVERYONE with any access point is affected.*

There are over two billion APs alone in Apple's WPS database (according to
the security research which you must have read by now, haven't you?).

As for your "legally binding policy" claim ?: You have claimed facts *way* to often to believe you without having hard evidence for it.

Apple has a published privacy rule.
Apple admits that they violated it.

Those are facts. They're not opinions.
You not knowing the facts doesn't mean there isn't proof.

It just means you have a very strongly held opinion which nobody on the
planet who understand how the system works would agree with you.

Certainly no security researcher on the planet would agree with you.

And you misssed the whole point (but whats new).

The existence of other privacy risks doesn't justify ignoring this one.

Opt-out mechanisms exist precisely so individuals can control how their infrastructure is used. Apple published a policy promising that AP owners
could opt out, and the research shows they did not honor that policy.

That's the issue being discussed.
It's not a matter of opinion. It's a matter of fact.

you are throwing so much
data around that you can't control and even *need* to throw around (smartphone) that removing that BSSID and its coordinates from a database doesn't really help.

Personal remarks don't change the technical facts, and worse, if you think
my behavior changes anything in Apple's WPS system, you're dead wrong.

The issue is not my behavior, my phone settings, or my credibility.

The issue is Apple's documented collection and redistribution of Wi-Fi
access point locations, including those belonging to people who explicitly opted out.

The security research is publicly available, peer-reviewed, and independent
of me personally. If you disagree with the findings, the appropriate
response is to address the research itself, not the messenger of research.

Read it before repeating you don't believe in the security research, Rudy.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

As long as that BSSID is not openly linked to you, the person, than there
is no privacy issue present.

Since I have already posted a half dozen security research papers and articles that expressly claim otherwise

As you have thrown claims around that you refuse to substanciate in any way since forever I'm not going to believe the above either.

you're entitled to your own opinion which isn't backed up by a single security
researcher on earth

And neither is, as always, yours. Your point ?

The research shows that BSSID + geolocation enables inference attacks, movement tracking,

Yep. Which is rather useless as long as you have no clue who you are targetting/tracking.

and household identification even without explicit personal identifiers.

Yes. And than you have identified a random household. Thats as meaningless
as the above.

Kiddo, come back when you figure out how you can identify a *specific*
person / household from whats in that database. *Than* you have something
to complain about.

For those lurking and learning, this isn't what people like Rudy think it is, since A-GPS has absolutely nothing directly to do with any of this.

:-)

A-GPS is simply a method for a phone to speed up its own location fix
using network assistance.

:-) And what does that "network assistance" look like ? Riddle me dat batman.

Kiddo, have you *ever* stopped to think about why Apple would have spend
money to create that database you have been free to access and now
complaining about ? What's is purpose ? Can you answer me that ?

No, I don't think so.

And something else to think about : You have tracked the movement of a BSSID in real-time. Where do those updated coordinates come from ? Who / what is providing them ?

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Andy Burns wrote:

The research papers I listed which most have likely read by now explain the >> variety of ways that access points can easily be tracked by use of the
Apple WPS implementation

But people don't care if APs can be tracked, unless *they* can be
associated with specific APs.

Hi Andy,

I'm simply informing you and others on this newsgroup of this problem set.
And I'm asking for solutions (in another thread) for resolving the problem.

I know you're intelligent and well informed, and I realize you're trying to make the point that carrying an access point in your pocket doesn't mean
the access point is you, but my point is that being able to easily track it from anywhere in the world means anyone can essentially atrack you.

Or, um, er... specifically they can track that which is in your pocket.
Your point may be you can leave your pants at someone else's house, and, in that case, it's really allowing the tracking of the location of your pants.

Especially since the GPS location is as accurate as it is for tracking us.
To prove how easy it is to track anyone's movements from place to place,
I'm setting up these three routers to prove that I can easily be tracked:
<https://i.postimg.cc/44WKMKpJ/apple-wps-testing.jpg>

I'm going to simulate renting an apartment (flat to you in the UK) in Palo
Alto at a friend's house who works for Google & then I'm going to "move" to
an apartment in Cupertino (to simulate my movements over the next month).
From: Marian <marianjones@helpfulpeople.com>
Newsgroups: alt.comp.os.windows-10,comp.mobile.android,alt.internet.wireless
Subject: Help! How do we get Apple to care about privacy for entities who
own access points?
Date: Tue, 23 Dec 2025 23:42:17 -0700
Organization: BWH Usenet Archive (https://usenet.blueworldhosting.com)
Message-ID: <10ig209$29kr$1@nnrp.usenet.blueworldhosting.com>

My tests will prove that Apple's WPS implementation is the antithesis of everything that Apple "says" they stand for, in terms of my privacy, in
that anyone in the world can track my movements tied to my use of APs.

Also note that Apple themselves can track any device that uploads the
router AP location information, but that flaw is NOT my concern today.

If I were to summarize my main issues, I would say that they are:
1. Apple's WPS implementation is vastly different than all others
3. Apple has no limits on who can obtain & track BSSID locations
2. Apple does not follow their own public privacy policy

This has nothing whatsoever to do with whether you own or use Apple
products as it affects every entity who manages any Wi-Fi access point.

That's not only basically every home and apartment/flat in the developed
world, but also many businesses, hospitals, government agencies, etc.

The research papers noted Apple's WPS allows easy tracking of smartphones
in hotspot mode, portable travel routers, IoT gadgets, delivery robots,
drones, vehicles with embedded Wi-Fi modules, buses, trains, and rideshare vehicles with onboard Wi-Fi (and individual Starlink devices also).

Apparently, even Starlink terminals could be tracked if their Wi-Fi BSSIDs
are collected by nearby Apple devices.

That's because these all broadcast stable identifiers, so their movement patterns can be reconstructed just like a person's. The tracking risk goes
far beyond fixed home routers.

Apple's WPS implementation makes it trivial to track billions of APs.
I already proved that (just try the FOSS scripts that I modified).

As for whether or not people care that they're being tracked, I care.
That's all that matters. I know more about privacy than most people do.

And I care about privacy.
But I am not the only one in the world who cares about privacy, Andy.

If people didn't care, then Mozilla wouldn't need this opt-out policy.
<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')."

If I didn't care, then I wouldn't need to follow Apple's opt-out policy.
<https://support.apple.com/en-us/102515>
"The owner of a Wi-Fi access point can opt it out of
Apple's Location Services - which prevents its location
from being sent to Apple to include in Apple's crowd-sourced
location database - by changing the access point's SSID (name)
to end with '_nomap.' For example, 'Access_Point' would be
changed to 'Access_Point_nomap.'"

The University of Maryland paper "Surveilling the Masses with Wi-Fi-Based Positioning Systems" shows that Apple's WPS (the Wi-Fi Positioning System
used by iPhones, Macs, and many apps) can be queried at massive scale to retrieve the physical locations of Wi-Fi access points worldwide.

All I did was reproduce what the researchers said was easily possible.
And I proved that it is trivial for anyone in the world to do.
I'd put these in the sig but you said you don't look at sig references.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://par.nsf.gov/servlets/purl/10540853>

Cybernews: *Anyone can tap into your WiFi location data to track you*
explains how Apple's WPS can be exploited for mass surveillance. <https://cybernews.com/privacy/apple-beams-wifi-location-data-privacy-risk/>

Cybersecurity News: *Hackers Can Abuse Apple's Wi-Fi Positioning System* details the University of Maryland study showing global tracking risks.
<https://cybersecuritynews.com/apples-wi-fi-positioning-system/>

Dark Reading: *Apple Geolocation API Exposes Wi-Fi Access Points Worldwide* notes that researchers could query hundreds of millions of APs in days. <https://www.darkreading.com/endpoint-security/apple-geolocation-api-exposes-wi-fi-access-points-worldwide>

Krebs on Security: *Why Your Wi-Fi Router Doubles as an Apple AirTag*
describes how Apple's data was used to track billions of devices globally <https://krebsonsecurity.com/2024/05/why-your-wi-fi-router-doubles-as-an-apple-airtag/>

Register: *Apple Wi-Fi Positioning System open to global tracking abuse*
covers the academic paper "Surveilling the Masses with Wi-Fi-Based
Positioning Systems" by Erik Rye and Dave Levin
<https://www.theregister.com/2024/05/23/apple_wifi_positioning_system/>
--
My posts aim to explore how Apple's WPS actually works beneath the surface,
in ways most users may never understand because Apple doesn't tell them.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

I'm simply informing you and others on this newsgroup of this problem set.

And I'm informing you that you have dreamed up a problem where none exists.

And I'm asking for solutions (in another thread) for resolving the
problem.

Maybe you should start with clarifying the problem, instead of having us
guess what you think it might be.

but my point is that being able to easily track it from anywhere in the world means anyone can essentially atrack you.

Ehhh.... If someone can do "x" that someone can essentially do "x" ? Yeah duh!

But as I already explained to you and you refused to respond to, from whats
in that database you can only track a *random* person. Which, as I
mentioned earlier, is useless.

To prove how easy it is to track anyone's movements from place to place,
I'm setting up these three routers to prove that I can easily be tracked:

You still don't get it, do you. You are still working your way backwards from the answer (you know what your BSSID is) to the question (find your BSSID and read your own location next to it). Anyone can do that.

Doing it the other way around however ...

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

I'm simply informing you and others on this newsgroup of this problem set.

And I'm informing you that you have dreamed up a problem where none exists.

And I'm asking for solutions (in another thread) for resolving the
problem.

Maybe you should start with clarifying the problem, instead of having us guess what you think it might be.

but my point is that being able to easily track it from anywhere in the
world means anyone can essentially atrack you.

Ehhh.... If someone can do "x" that someone can essentially do "x" ? Yeah duh!

But as I already explained to you and you refused to respond to, from whats in that database you can only track a *random* person. Which, as I mentioned earlier, is useless.

To prove how easy it is to track anyone's movements from place to place,
I'm setting up these three routers to prove that I can easily be tracked:

You still don't get it, do you. You are still working your way backwards from the answer (you know what your BSSID is) to the question (find your BSSID and read your own location next to it). Anyone can do that.

Doing it the other way around however ...

Hi Rudolph!

Thank you for your opinion, which I appreciate given I was shocked when,
after reproducing the published research methods, that Apple was not
respecting their own published privacy policy on how to opt out of their
public WPS system that anyone in the world can access at will.

Lest you claim "I don't get it", it's important to reiterate that the insecurity of Apple's Wi-Fi Positioning System (WPS) isn't speculative.
It's not an opinion as it's documented in peer-reviewed research. The
recent paper "Surveilling the Masses with Wi-Fi-Based Positioning Systems"
(Rye & Levin, 2024) demonstrates that Apple's WPS API can be queried at
scale to reconstruct large portions of the global Wi-Fi map, including
access points that the querier has never observed.

The entire database is open to everyone, as you've already seen when you
ran the scripts I so kindly provided for you in this very thread prior.
1. modified working & tested "apple_bssid_locator.py"
2. 'bssid.bat' (looks up an AP)
3. 'bssidcompare.bat' (determines if/where the AP moved)
4. 'bssidgenerate.bat' (generates random BSSIDs to test)
5. 'bssidcheck.bat' (checks which BSSID is in Apple's insecure WPS DB)
6. 'bssidplot.py' (plots results en masse onto a map using Fermium)
7. gps:bssid results (text output directly from Apple's insecure WPS DB)

The key point is that Apple's WPS endpoint returns hundreds of nearby GPS:BSSIDs pairs for any submitted BSSID, not just the one requested.

The researchers claimed that behavior allows iterative expansion, which,
listed in its simplest form (as described) is:
a. Query any BSSID (it can be known, or random)
b. Receive up to ~400 nearby BSSIDs
c. Query the "edge" BSSIDs

Repeat until you have the entire database of GPS:BSSID pairs (which is
trivial to do, and we proved that. It simply costs 120GB of disk space).

This is exactly the technique the researchers used to walk outward across cities and continents. I simply proved to Chris that it's trivial to do.

The researchers claimed you can easily track when those GPS:BSSID pairs
have moved to a new location, which I also proved was trivial (my script
looked for changes of 100KM or more - but any distance is feasible).

The researchers claim a simple public map shows the building address where
that GPS:BSSID pair was before and after it was moved, and I proved that.

To verify the behavior the researchers claimed was the behavior all of us
can trivially observe, I modified the open-source apple_bssid_locator tool
so that it requests the full result set (return_single_result = 0) and logs
all returned BSSID->GPS pairs. The modified script reliably returns
hundreds of nearby access points per query, consistent with the behavior described in the paper.

This isn't "theoretical," and it isn't dependent on privileged access.

It's simply how Apple's WPS API responds today. The fact that random, unobserved BSSIDs can be queried without restriction, and that the API
returns their coordinates and the GPS:BSSID pairs of all adjacent access points, is precisely the privacy issue the researchers highlighted.

Given I read the research papers and I reproduced their results, maybe you might want to rethink your assessment that "I don't get it", Rudolph.

Whether one considers this a vulnerability or a design flaw is a matter of interpretation, but the underlying behavior is not in dispute. The academic paper, the Register article summarizing it, and independent replication all confirm the same thing: Apple's WPS database can be enumerated at scale,
and the API provides enough information to reconstruct the physical
locations of Wi-Fi access points globally.

Even Apple didn't dispute all my facts when I presented them to Apple via
my next-door neighbor who is a VP who entered the issue into Apple's RADAR.

So maybe I do get it when everything I did confirms what the researchers
said, and Apple confirmed everything I did since I gave them the same data
that I gave you as my goal is not only to stay out of Apple's insecure WPS database, but to help potentially hundreds of millions of others do so too!

I'm all about helping everyone - which is why all my tutorials use tools
which are free to use and I provide my scripts when I modify FOSS tools.
--
My posts aim to explore how Apple's WPS actually works beneath the surface,
in ways most users may never understand because Apple doesn't tell them.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

The key point is that Apple's WPS endpoint returns hundreds of nearby GPS:BSSIDs pairs for any submitted BSSID, not just the one requested.

Kiddo, you have changed your story. From a privacy issue to a "I can get
the whole database".

You have not given me/us any explanation to why knowing *a random BSSID* and its location would be a privacy issue, and now not why you think that being able to get all the Apple databases contents would be one.

Lest you claim "I don't get it", it's important to reiterate that the insecurity of Apple's Wi-Fi Positioning System (WPS) isn't speculative.

And as I've told you a number of times before, I'm not going on a wild goose hunt for something you *could* be meaning. You have it as a fact in your
head, *you* explain it. I'm not going to play a ten guesses game with you.

I'm all about helping everyone -

No, you're not.

If you would be than you would take the time to make sure that your intended audience gets the facts instead of some guesswork as well as getting
something thats easy to read and follow and thus understand.

I've told you that many times, but you have disregarded that for years now. Thats not something an /actual/ helpfull person would do.

Though I must say I was pleasantly surprised that your last "tutorial" was about a single subject and not multiple together, poored out after having
gone to a food-blender. Yes, I remember those. :-(

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

The key point is that Apple's WPS endpoint returns hundreds of nearby
GPS:BSSIDs pairs for any submitted BSSID, not just the one requested.

Kiddo, you have changed your story. From a privacy issue to a "I can get the whole database".

You have not given me/us any explanation to why knowing *a random BSSID* and its location would be a privacy issue, and now not why you think that being able to get all the Apple databases contents would be one.

Lest you claim "I don't get it", it's important to reiterate that the
insecurity of Apple's Wi-Fi Positioning System (WPS) isn't speculative.

And as I've told you a number of times before, I'm not going on a wild goose hunt for something you *could* be meaning. You have it as a fact in your head, *you* explain it. I'm not going to play a ten guesses game with you.

I'm all about helping everyone -

No, you're not.

If you would be than you would take the time to make sure that your intended audience gets the facts instead of some guesswork as well as getting something thats easy to read and follow and thus understand.

I've told you that many times, but you have disregarded that for years now. Thats not something an /actual/ helpfull person would do.

Though I must say I was pleasantly surprised that your last "tutorial" was about a single subject and not multiple together, poored out after having gone to a food-blender. Yes, I remember those. :-(

Rudolph, let's keep this focused on the technical issue rather than tone.

For you to tell me "I don't get it" a hundreds times, doesn't mean that I
don't get it when I simply reproduced what researchers said could be done.

In other words, I got it.
I got it the moment I read the security research (which I reproduced).

The papers and news articles you read are not speculation; they are fact.
All I did was reproduce what the security researchers said was easy to do.
And it was.
In fact, it was so easy to reproduce what the security researchers warned
about that I, myself, could easily get the entire Apple WPS database.

Worse, I, myself, could easily track any BSSID in the world.
a. I could pick any address on the planet
b. I could find the BSSID associated with that address
c. And I could track it forever.

That's not random.
I have no intention of tracking people, but I proved it's trivial to do.
Just like the security researchers said it was.

Hence, the privacy concern isn't about a *single* nor random BSSID.

It's about the fact that each Apple's WPS endpoint returns *hundreds* of
nearby BSSID-location pairs for any query, for any querier, and that you
can't get opt out of Apple's WPS database using Apple's published method.

These flaws effectively exposes large portions of Apple's WPS database to anyone who knows how to query it, which is what the researchers said.
Hundreds of millions of people who, like me, thought they opted out
properly, are not opted out (which Apple replied to me in writing is the
case, although we are taking a swag at how many people use the hidden
feature found in almost every single router ever sold in the world).

That's the point I've been making.

If you disagree with the technical argument, I'm happy to discuss that.
But dismissing it as 'guesswork' doesn't address the underlying issue.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

Rudolph, let's keep this focused on the technical issue rather than tone.

Answer my questions, and I will consider it.

So, when are you going to explain how you being able to read BSSID's and coordinates from Apples database is a privacy problem ?

For you to tell me "I don't get it" a hundreds times, doesn't mean that I don't get it when I simply reproduced what researchers said could be done.

Kiddo, being able to repeat what others have detailed doesn't mean you understood what you where doing.

Worse, I, myself, could easily track any BSSID in the world.

Kiddo, I've asked you several times to explain why, according to you, that that is a problem. You have refused to do so every time. No, *YOU DO NOT
GET IT*.

Proof of that ? If you would than you would have been able to explain yourself to me/us. The fact that you don't ...

That's not random.

Yes, it is. Tell me, what is *the name of the person* behind the BSSID's
you have been tracking ?

Ofcourse, you have no idea.

These flaws effectively exposes large portions of Apple's WPS database
to anyone who knows how to query it, which is what the researchers said.

Its not a flaw, its on purpose. Kiddo, you have *NO* idea what that
database is for, but you have already drawn your conclusions. You are, as I mentioned a few times, *WILLFULLY IGNORANT*.

And it doesn't help that *I already asked you* to consider what the purpose
of that database is, and you simply refuse to do so.

I have no intention of tracking people, but I proved it's trivial to do. Just like the security researchers said it was.

Is that true ? So, if I pick a name than you can, assiming he's got a BSSID with him, tell me where that person is traveling ? Yes or no ? And ofcourse, explain your answer. :-)

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

That's not random.

Yes, it is. Tell me, what is *the name of the person* behind the BSSID's you have been tracking ?

Ofcourse, you have no idea.

Ah, but I do.
So would you had you read the research papers, Rudolph.

Cybernews: *Anyone can tap into your WiFi location data to track you*
explains how Apple's WPS can be exploited for mass surveillance. <https://cybernews.com/privacy/apple-beams-wifi-location-data-privacy-risk/>

The researchers already showed anyone in the world is already able to use Apple's WPS db to track Loretta Anne Jameson's AP which is currently
located at 4302 Josey Circle, Shreveport, LA 71109.

When she moves, I'll let you know where she moves her router to.
Likewise with any of her neighbors.

Ronda and Alfred Beel, 4310 Josey Cir, Unit #2-A
Benjamin and Eric Choyica 1/4 and, 4318 Josey Cir, Unit #2-A
Jeffrey Devin, 4306 Josey Cir, Unit #2-A
Flora Ann Jackson Gellion, 4338 Josey Cir, Unit #2-A
Lonzie D. Groniger, 4321 Josey Cir, Unit #2-A
Lutrisher Walton Hill, 4329 Josey Cir, Unit #2-A
Melvin Hawthorn, Jr. 1/2 and, 4823 Josey Cir, Unit #2-A
Mary E. Gebbs Hendy, 4816 Josey Cir, Unit #2-A
Shane Jameson Sr., 4330 Josey Cir, Unit #2-A
Rosemary Ellerbee Jones, 4317 Josey Cir, Unit #2-A
Charles Nesh, 4824 Josey Cir, Unit #2-A
James and Dollie Henson Smythe, 4314 Josey Cir, Unit #2-A
Sherryn Marie Smythe, 4820 Josey Cir, Unit #2-A
Terrince Steedman, 4326 Josey Cir, Unit #2-A
Pamela Tomas, 4828 Josey Cir, Unit #2-A
Trivia Yashica Watken, 4827 Josey Cir, Unit #2-A
etc.

Anyone can do this for any home in the United States.
Which is why this is so dangerous to privacy.
--
I'm here to help others understand the deeper mechanics of WPS that
most people never comprehend (& that Apple marketing never explains).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Unit #2-A

Apologies for the unit 2-a on every name and address in the previous list.
Only the first line was that unit.

I used gVIM to munge the record, slightly, for privacy, since the exact
unit didn't matter for our purposes, but I made an editing redaction error.

The point is anyone in the world can track these people by their GPS:BSSID.
Jeffrey Devin ......................... 4306 Josey Circle
Ronda and Alfred Beel ................ 4310 Josey Circle
James and Dollie Henson Smythe ....... 4314 Josey Circle
Rosemary Ellerbee Jones .............. 4317 Josey Circle
Benjamin and Eric Choyica ............ 4318 Josey Circle
Lonzie D. Groniger .................... 4321 Josey Circle
Terrince Steedman ..................... 4326 Josey Circle
Lutrisher Walton Hill ................ 4329 Josey Circle
Shane Jameson Sr. ..................... 4330 Josey Circle
Flora Ann Jackson Gellion ............ 4338 Josey Circle
Mary E. Gebbs Hendy ................... 4816 Josey Circle
Sherryn Marie Smythe .................. 4820 Josey Circle
Melvin Hawthorn, Jr. ................. 4823 Josey Circle
Charles Nesh .......................... 4824 Josey Circle
Trivia Yashica Watken ................ 4827 Josey Circle
Pamela Tomas .......................... 4828 Josey Circle
etc.

The papers explained how anyone in the world could track every owner of
every home in the United States by their GPS:BSSID using the highly
insecure Apple WPS database like could for the above people (which I have
no plans on doing but which is why I understand how badly designed Apple's
WPS implementation is - which Google's WPS & Mozilla's WPS isn't).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Anyone can do this for any home in the United States.
Which is why this is so dangerous to privacy.

Apologies for the unit 2-a on every name and address in the previous list.
Only the first line was that unit.

I used gVIM to munge the record, slightly, for privacy, since the exact
unit didn't matter for our purposes, but I made an editing redaction error.

The point is anyone in the world can track these people by their GPS:BSSID.
Jeffrey Devin ......................... 4306 Josey Circle
Ronda and Alfred Beel ................ 4310 Josey Circle
James and Dollie Henson Smythe ....... 4314 Josey Circle
Rosemary Ellerbee Jones .............. 4317 Josey Circle
Benjamin and Eric Choyica ............ 4318 Josey Circle
Lonzie D. Groniger .................... 4321 Josey Circle
Terrince Steedman ..................... 4326 Josey Circle
Lutrisher Walton Hill ................ 4329 Josey Circle
Shane Jameson Sr. ..................... 4330 Josey Circle
Flora Ann Jackson Gellion ............ 4338 Josey Circle
Mary E. Gebbs Hendy ................... 4816 Josey Circle
Sherryn Marie Smythe .................. 4820 Josey Circle
Melvin Hawthorn, Jr. ................. 4823 Josey Circle
Charles Nesh .......................... 4824 Josey Circle
Trivia Yashica Watken ................ 4827 Josey Circle
Pamela Tomas .......................... 4828 Josey Circle
etc.

The papers explained how anyone in the world could track every owner of
every home in the United States by their GPS:BSSID using the highly
insecure Apple WPS database like could for the above people (which I have
no plans on doing but which is why I understand how badly designed Apple's
WPS implementation is - which Google's WPS & Mozilla's WPS isn't).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote on 12/28/2025 6:24 PM:

Marian wrote:

Anyone can do this for any home in the United States.
Which is why this is so dangerous to privacy.

Apologies for the unit 2-a on every name and address in the previous list. Only the first line was that unit.

I used gVIM to munge the record, slightly, for privacy, since the exact
unit didn't matter for our purposes, but I made an editing redaction error.

The point is anyone in the world can track these people by their GPS:BSSID. Jeffrey Devin ......................... 4306 Josey Circle
Ronda and Alfred Beel ................ 4310 Josey Circle
James and Dollie Henson Smythe ....... 4314 Josey Circle
Rosemary Ellerbee Jones .............. 4317 Josey Circle
Benjamin and Eric Choyica ............ 4318 Josey Circle
Lonzie D. Groniger .................... 4321 Josey Circle
Terrince Steedman ..................... 4326 Josey Circle
Lutrisher Walton Hill ................ 4329 Josey Circle
Shane Jameson Sr. ..................... 4330 Josey Circle
Flora Ann Jackson Gellion ............ 4338 Josey Circle
Mary E. Gebbs Hendy ................... 4816 Josey Circle
Sherryn Marie Smythe .................. 4820 Josey Circle
Melvin Hawthorn, Jr. ................. 4823 Josey Circle
Charles Nesh .......................... 4824 Josey Circle
Trivia Yashica Watken ................ 4827 Josey Circle
Pamela Tomas .......................... 4828 Josey Circle
etc.

The papers explained how anyone in the world could track every owner of
every home in the United States by their GPS:BSSID using the highly
insecure Apple WPS database like could for the above people (which I have
no plans on doing but which is why I understand how badly designed Apple's WPS implementation is - which Google's WPS & Mozilla's WPS isn't).

I couldn't figure out which of these people are YOU.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

That's not random.

Yes, it is. Tell me, what is *the name of the person* behind the BSSID's >> you have been tracking ?

Ofcourse, you have no idea.

Ah, but I do.

Another claim without anything to support it. Ignored.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

Apologies for the unit 2-a on every name and address in the previous list. Only the first line was that unit.

...

The point is anyone in the world can track these people by their
GPS:BSSID.
Jeffrey Devin ......................... 4306 Josey Circle
Ronda and Alfred Beel ................ 4310 Josey Circle
James and Dollie Henson Smythe ....... 4314 Josey Circle

[snip rest of list]

So, you have a list of person names and, I assume, street adresses - but no (GPS.)BSSIDs. iow, nothing to track any of those persons with.

Kiddo, you *really need to* explain how you convert BSSIDs into a persons name, or a persons name into a BSSID.

And lets not forget, I asked you a simple Yes/No question about it which you still have not answered :

[quote=me]
So, if I pick a name than you can, assiming he's got a BSSID with him, tell
me where that person is traveling ? Yes or no ? And ofcourse, explain
your answer. :-)
[/quote]

Ofcourse, when I pick a name of someone/place I know the BSSID of it would
be *very* evident when you would give me a random BSSID for it ...

The same would happen when I give you a known-to-me BSSID and you come back with some random persons name.

Yeah, your best shot at not falling into that "trap" is by simply refusing
to answer the question.

The only problem with that is that *not* giving an answer is an answer in itself : YOU HAVE NO CLUE.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

So, you have a list of person names and, I assume, street adresses - but no (GPS.)BSSIDs. iow, nothing to track any of those persons with.

Kiddo, you *really need to* explain how you convert BSSIDs into a persons name, or a persons name into a BSSID.

And lets not forget, I asked you a simple Yes/No question about it which you still have not answered :

[quote=me]
So, if I pick a name than you can, assiming he's got a BSSID with him, tell me where that person is traveling ? Yes or no ? And ofcourse, explain your answer. :-)
[/quote]

Ofcourse, when I pick a name of someone/place I know the BSSID of it would be *very* evident when you would give me a random BSSID for it ...

The same would happen when I give you a known-to-me BSSID and you come back with some random persons name.

Yeah, your best shot at not falling into that "trap" is by simply refusing to answer the question.

The only problem with that is that *not* giving an answer is an answer in itself : YOU HAVE NO CLUE.

Hi Rudolph,

Let me address this at the technical level, because the privacy concerns
are getting mixed up with how the data actually works.

1. What a BSSID is and is not
a. A BSSID is the MAC address of a Wi-Fi access point.
b. It identifies hardware at a fixed physical location.
c. It does NOT identify a person.
d. There is no built-in mapping between a person and a BSSID.
e. The only inherent mapping is between the access point
and the building where it is located
f. Buildings have owners & ownership records are public information.
g. So as not to dox people, the names I listed earlier were
slightly altered to avoid posting identifiable data directly
(but those looking at public records should recognize the pattern)

2. How the location association works
a. Appleos WPS database stores BSSID-to-location pairs.
b. In practice, these coordinates almost always correspond
to a specific building.
c. That building is associated with an owner through public
property records (in the USA anyway)
d. Apple devices passively observe nearby BSSIDs.
e. Those observations are uploaded to Appleos WPS database.
f. Apple aggregates these observations into a large, publicly
queryable location database with no controls whatsoever!
g. This is the same mechanism described in the published research.

3. Where the "1 to 1" linkage comes from
a. Apple provides only BSSID-to-location.
b. Yet, that location is almost always a building.
c. Buildings have owners.
d. Property ownership records are public in the United States.
e. Combining these two data sources yields:
BSSID -> address -> homeowner name
f. This derived linkage is not present in Apple's data itself.
g. It is, however, trivial for anyone to construct using
publicly available information (which I easily proved)
h. I am not posting the fully assembled chain in a single message,
because that might dox people too easily for people like you.
But it's close enough to make the point for someone who knows
how to use a web page to obtain the ownership data themselves.

This is the technical explanation. The privacy boundary is simply that I am
not going to publish a combined BSSID + address + homeowner name dataset in
one place, even though the individual components are public.

The underlying point is straightforward: if a BSSID is tied to a fixed
home, and home ownership records are public, then correlating the two is trivial. Anyone familiar with how these systems work already understands
this, and the research literature has demonstrated it clearly.
--
Intelligent people own the imagination to figure out how a tool works.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

Another claim without anything to support it.

And yet I proved it's trivial to obtain the named owner of every building
in the United States (since that's public information) and to obtain the location of every BSSID in that building which, if it's a home, typically
has only one (although mine has half a dozen or more tied to my home).

BSSID <-> Owner (via the building location)
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Andy Burns wrote:

I (can) have every access point location
in the world (over 2 billion) if I felt like getting it (and storing it).

But which of those 2 billion belong to me?

Andy,

I respect your knowledge, so I'm aware you understand what a BSSID is.
You also understand that most people own the home they live in.
And, you understand that if they move, they take their router with them.

Are you disputing any of that?

I know the owner of every home on Josey Circle in Shreveport, LA, right?
That's trivial. Anyone can prove how trivial that is, right?
Jeffrey Devin ......................... 4306 Josey Circle
Ronda and Alfred Beel ................ 4310 Josey Circle
James and Dollie Henson Smythe ....... 4314 Josey Circle
Rosemary Ellerbee Jones .............. 4317 Josey Circle
Benjamin and Eric Choyica ............ 4318 Josey Circle
Lonzie D. Groniger .................... 4321 Josey Circle
Terrince Steedman ..................... 4326 Josey Circle
Lutrisher Walton Hill ................ 4329 Josey Circle
Shane Jameson Sr. ..................... 4330 Josey Circle
Flora Ann Jackson Gellion ............ 4338 Josey Circle
Mary E. Gebbs Hendy ................... 4816 Josey Circle
Sherryn Marie Smythe .................. 4820 Josey Circle
Melvin Hawthorn, Jr. ................. 4823 Josey Circle
Charles Nesh .......................... 4824 Josey Circle
Trivia Yashica Watken ................ 4827 Josey Circle
Pamela Tomas .......................... 4828 Josey Circle
etc.

And, in another post, I showed the BSSID nearest to each of those
buildings, right? (I'm not going to put it together here for reasons that
I'm not trying to dox people.)

So what are you asking me to answer?
a. Are you disputing I have the named owner of every home in the USA?
b. Or are you disputing I have the BSSID of every home in the USA?

If your name was, oh, let's say Jeffrey Devin, and if you put that router
in the home that you own at 4306 Josey Circle, then I can track that AP anywhere in the world if you then moved to another home, and took your
router with you.
c. Are you disputing I can track the location of that AP BSSID, Andy?

Note that by tracking the BSSID and knowing the owner of every home in the
USA (since that's a public record), I could tie it to you "if" you're the owner. If you only rented the home, then I'd need more data to tie it to
you.

But in the USA, overwhelmingly, people own the home they live in.
So it's tied to the owner. Who, in this case, would be you.

Would it not?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

And lets not forget, I asked you a simple Yes/No question about it which
you still have not answered :

...

f. This derived linkage is not present in Apple's data itself.

So, your initial accusation that the contents of Apples database constitutes to a privacy violation is false.

Kiddo, thats what I've been trying to tell you all along, but you have been dancing around, trying to evade having to say that. You infact still do.
:-)

2. How the location association works
a. Apples WPS database stores BSSID-to-location pairs.
b. In practice, these coordinates almost always correspond to a specific building.
c. That building is associated with an owner through public
property records (in the USA anyway)

In short, you need to access *other* publicly available databases to *try
to* link a BSSID to a specific person.

"Try to" as it will still fail when muliple persons live close together (appartment building, GPS is *very* bad at altitude measurement, or even a
row of appartments against each other), or when Apple has "seeded" those coordinates, randomly shifting them away from the actual ones. Just a few meters (inside the precision tolerance) is enough to make them point to a neighbour.

Kiddo, you are WILLFULLY IGNORANT, as you refuse to consider the
implications of what you try to claim.

But ok, now you have found a *random person*. What good does that do ?

My question still stands :

[quote=me]
So, if I pick a name than you can, assiming he's got a BSSID with him, tell
me where that person is traveling ? Yes or no ? And ofcourse, explain
your answer. :-)
[/quote]

If you can answer that one *than* you perhaps have something to complain about.

... but than the question is : complain to whom ? Why have you been accusing Apple of spilling the beans when those "public property records"
are spilling /whole bags/ of them ?

Also, I've been telling you that getting personal information - like
location information - can be bought by anyone who is willing to spend a
buck.

But *if* you can find the home-addres of *a specific person* - which is not
a given - and from there the BSSID of devices owned by that person - which
is also not a given - you have merely found /another way/ to track that person. Congratulations.


And another question you have refused to answer : how does Apples database
get the real-time coordinates of those BSSIDs (so you can track their
movment) ? If its not the persons own devices that upload them, than how does that work ?

... An when a persons own device is doing it, why not point at that person (you?) for being a dumbass for not understanding how his phone works.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

And yet I proved it's trivial to obtain the named owner of every building
in the United States

I've got a name for you :John Smith. Now tell me, where does he live and whats his BSSID ?

Do I have to explain the above to you or are you smart enough to figure it
out for yourself ?

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

In short, you need to access *other* publicly available databases to *try to* link a BSSID to a specific person.

Essentially...
1. Every home in the USA is tied to an owner in a public database
2. Every BSSID in every home in the USA is in the Apple public database

BSSID <-> GPS <-> Address <-> Owner

Only an extremely unimaginative person wouldn't be able to connect the dots (which is why the researchers said that the Apple implementation is flawed)

Remember, Apple's WPS is DIFFERENT than how Google/Mozilla do their WPS.
That DIFFERENCE is what the security researchers pointed out so forcefully.

Apple makes that task of correlating every name to every location trivial because there are absolutely no controls on the Apple WPS database.

None.
You can download the entire Apple database using basic commands.

Basically, you get every BSSID:LOCATION pair in the world.
(Actually every BSSID:LOCATION in Apple's WPS but that's close to all.)

The problem is two fold:
1. Apple's WPS implementation has no controls.
2. Apple won't let you opt out.

That's what I've been saying for weeks now, so if people don't get it after having read the papers and run the scripts, then they'll never ever get it.

Google's WPS has controls; Apple's WPS does not.
Mozilla's WPS allows you to opt out with certainty; Apple's WPS does not.

This isn't speculation.
It's fact.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

R.Wieser wrote:

And yet I proved it's trivial to obtain the named owner of every building >> in the United States

I've got a name for you :John Smith. Now tell me, where does he live and whats his BSSID ?

Do I have to explain the above to you or are you smart enough to figure it out for yourself ?

BSSID <-> GPS <=> Address <-> Owner

Every person who knows anything understands that every owner of every home
in the United States is in a public database and that every BSSID:GPS in
every home in the world (essentially) is in Apple's public database.

For someone to not be able to connect the dots would mean they lack ability
to use tools as simple as a hammer and a nail, as it's that trivial to do.

It's a simple merging of 2 data files, both of which have no controls:
BSSID <-> GPS <=> Address <-> Owner

What's DIFFERENT is Google's WPS has controls; Apple's WPS does not.
And Mozilla's WPS works like it should; Apple's WPS does not.

What Apple is doing is the antithesis of everything Apple "says" it does.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

Essentially... 1. Every home in the USA is tied to an owner in a public database

You have adjusted your claim to mean only a small part of the world. Your claim that everyone all over the world could be followed is therefore false.

Also, the owner doesn't need to live in that house or being the person carrying the BSSID with him. Your claim that everyone all over the world could be followed is therefore false.

2. Every BSSID in every home in the USA is in the Apple public database

Nope. And I'm not even going to explain that to you.

BSSID <-> GPS <-> Address <-> Owner

Only an extremely unimaginative person wouldn't be able to connect the
dots

Kiddo, you have both been shrinking the reach of your claim as well as refusing to consider any of the problems I've mentioned in regard to your above chain - making your "connect the dots" a farce.

Kiddo, I say it again : YOU ARE WILLFULLY IGNORANT. And you know it.

[quote=me]
So, if I pick a name than you can, assiming he's got a BSSID with him, tell
me where that person is traveling ? Yes or no ? And ofcourse, explain
your answer. :-)
[/quote]

You can't do the above, its as simple as that.

And than there are ofcourse all my other hints and questions you have
refused to respond to.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

I've got a name for you :John Smith. Now tell me, where does he live and >> whats his BSSID ?

Do I have to explain the above to you or are you smart enough to figure
it out for yourself ?

BSSID <-> GPS <=> Address <-> Owner

Every person who knows anything understands that every owner of every
home in the United States is in a public database

Every person who know anything knows that

the owner might not live in the house he owns. (1)

there might be multiple - unrelated - people living in the house (2)

the "GPS" coordinates in Apples database just might not be exactly pointing
to the device itself

(1) Good luck with find out where a person who is *not* the owner actually lives.

(2) Good luck with pin-pointing "the person-of-interest".

Kiddo, you keep presenting your "facts" while forcefully refusing to
consider the problems with them. You are WILLFULLY IGNORANT.

Which in itself isn't much of a problem, but you keep posting your fantasies as tutorials. With which you could greatly damage someone who takes your fantasies as facts.

Forgive me if I will keep making that FACT clear to anyone who might stumble over your science-fiction scribblings.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

"R.Wieser" wrote

Arlen,

Apologies for the unit 2-a on every name and address in the previous
list.
Only the first line was that unit.

...

The point is anyone in the world can track these people by their
GPS:BSSID.
Jeffrey Devin ......................... 4306 Josey Circle
Ronda and Alfred Beel ................ 4310 Josey Circle
James and Dollie Henson Smythe ....... 4314 Josey Circle

[snip rest of list]

So, you have a list of person names and, I assume, street adresses - but
no (GPS.)BSSIDs. iow, nothing to track any of those persons with.

I see I fully forgot to point out the most obvious : that list doesn't seem
to contain coordinates of the property. iow, nothing to compare the coordinates outof Apples database with.

Yet another "connect the dots" of yours that, with the information your provided us, simply doesn't, cannot work.

... or you would need to use /yet another/ information source as a bridge.

So, you would have three(?) databases(?) that will *only* when combined -
and only as long as you ignore all the other problems with it I've posted - devulge the info you're after.

But you still want to blame Apple, and Apple alone for leaking your privacy
?

Yeah, right.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

I respect your knowledge, so I'm aware you understand what a BSSID is.
You also understand that most people own the home they live in.

Most, yes; here in the UK it's roughly 2/3 of households, not sure
whether that's less than in the USA?

And, you understand that if they move, they take their router with them.

Most people here will use the router provided by their ISP, they're
probably meant to leave it behind, or send it back when they move home.

I know the owner of every home on Josey Circle in Shreveport, LA, right?

And, in another post, I showed the BSSID nearest to each of those
buildings, right? (I'm not going to put it together here for reasons that
I'm not trying to dox people.)

So what are you asking me to answer?

For a named person, if you already know where they live, you know their location, if you don't know where the live, Apple's database doesn't
help you find out. Even if you find their router's BSSID, why do you
ant to wait years until they move home, just so you can track where they
move to?

a. Are you disputing I have the named owner of every home in the USA?

Situation is a bit different here, there's the electoral roll which will
list everyone's address, but many people opt to tick the "privacy" box
so that isn't public information, there's also the land registry but
homes which have not recently changed hands are not required to be
registered, and you have to pay to see each record.

b. Or are you disputing I have the BSSID of every home in the USA?

I don't think you have it in such a cut-and-dried format, you've tied
things together by implication.

If your name was, oh, let's say Jeffrey Devin, and if you put that router
in the home that you own at 4306 Josey Circle, then I can track that AP anywhere in the world if you then moved to another home, and took your
router with you. c. Are you disputing I can track the location of that
AP BSSID, Andy?

But the BSSIDs are unique, people's names are not, how easy would it be
for you to link to SSNs?

Note that by tracking the BSSID and knowing the owner of every home in the USA (since that's a public record), I could tie it to you "if" you're the owner. If you only rented the home, then I'd need more data to tie it to
you.

But in the USA, overwhelmingly, people own the home they live in.
So it's tied to the owner. Who, in this case, would be you.

For anyone who runs their own business, the companies house data is
another source of addresses,

Would it not?

It would be easier for you to find my address by *not* using Apple's
database ...


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,

And, you understand that if they move, they take their router with them.

Are you disputing any of that?

Wishfull thinking much ? If he doesn't I will.

I know the owner of every home on Josey Circle in Shreveport, LA, right?

Which is pretty useless.

And, in another post, I showed the BSSID nearest to each of those
buildings, right? (I'm not going to put it together here for reasons that I'm not trying to dox people.)

:-) You're just telling us exactly what you've done, so we can repeat it ourselves. In my country thats called "aiding and abedding" - which can easily land you into jail.

a. Are you disputing I have the named owner of every home in the USA?

You already asked that.

b. Or are you disputing I have the BSSID of every home in the USA?

If he doesn't I will. Also, *the* BSSID ? Just a single one ? What are
you ? Poor ?

Note that by tracking the BSSID and knowing the owner of every home in the USA (since that's a public record), I could tie it to you "if" you're the owner.

Thats a rather big "if", don't you think ? It certainly trashes your initial claim that you could track *everyone* (all over the world).

But in the USA, overwhelmingly, people own the home they live in.

Tell that to all the poor city-dwellers who predominanty rent they places.

Who are, by the way, in close proximity and often stacked several layers
ontop of each other. Which ofcourse makes a mockery of any claim that a certain location will al;ways point to a single home.

So it's tied to the owner.

:-) You're "cooking the books" there.

Who, in this case, would be you.

Would it not?

Chances are - for multiple reasons as indicated in the above - he's not.

You're playing the "no true Scotsman" falacy there* : when you do not like a certain result you just discard it - leaving you with a meaningless, small subset, but all confirming what you wish to claim. Duh. Also, blergh.

* https://en.wikipedia.org/wiki/No_true_Scotsman

Bottom line : you *might* be able to track someone when you are given a persons name. - if the stars align just right.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

On Tue, 30 Dec 2025 22:24:03 +0100, "R.Wieser" <address@is.invalid>
wrote:

Arlen,

And, you understand that if they move, they take their router with them.

Are you disputing any of that?

Wishfull thinking much ? If he doesn't I will.

I know the owner of every home on Josey Circle in Shreveport, LA, right?

Which is pretty useless.

And, in another post, I showed the BSSID nearest to each of those
buildings, right? (I'm not going to put it together here for reasons that >> I'm not trying to dox people.)

:-) You're just telling us exactly what you've done, so we can repeat it >ourselves. In my country thats called "aiding and abedding" - which can >easily land you into jail.

a. Are you disputing I have the named owner of every home in the USA?

You already asked that.

b. Or are you disputing I have the BSSID of every home in the USA?

If he doesn't I will. Also, *the* BSSID ? Just a single one ? What are >you ? Poor ?

Note that by tracking the BSSID and knowing the owner of every home in the >> USA (since that's a public record), I could tie it to you "if" you're the >> owner.

Thats a rather big "if", don't you think ? It certainly trashes your
initial claim that you could track *everyone* (all over the world).

But in the USA, overwhelmingly, people own the home they live in.

Tell that to all the poor city-dwellers who predominanty rent they places.

Who are, by the way, in close proximity and often stacked several layers >ontop of each other. Which ofcourse makes a mockery of any claim that a >certain location will al;ways point to a single home.

So it's tied to the owner.

:-) You're "cooking the books" there.

Who, in this case, would be you.

Would it not?

Chances are - for multiple reasons as indicated in the above - he's not.

You're playing the "no true Scotsman" falacy there* : when you do not like a >certain result you just discard it - leaving you with a meaningless, small >subset, but all confirming what you wish to claim. Duh. Also, blergh.

* https://en.wikipedia.org/wiki/No_true_Scotsman

Bottom line : you *might* be able to track someone when you are given a >persons name. - if the stars align just right.

Some random thoughts...

A BSSID is typically based on the interface's MAC address. Each MAC
address is assumed, by many people, to be globally unique, but they
don't have to be.* It helps greatly if a MAC address is unique within
its local network segment, but a duplicate MAC appearing somewhere else shouldn't cause any problems. By extension, a duplicate BSSID appearing somewhere else shouldn't cause any problems that I can think of.

So my question is, would it help Arlen's quest for privacy if he were to
choose a MAC, and thus a BSSID, that already exists somewhere else and
is already present in the database? When someone does a query on that
BSSID, would they get the first result, or all results? I wonder if
Arlen has checked for duplicate BSSID entries in his favorite database.

*Many years ago, where I worked we trialed a piece of software that intentionally used the same IP address and MAC address on every server
in the pool. That violates everything we're taught about network
addressing, but it didn't cause any problems. It simply moved certain
tasks farther up the network stack. We ended up buying and deploying
that software into our production network.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Char,

It helps greatly if a MAC address is unique within its local
network segment,

I would say that!

Examples of 'puters who could not communicate over the LAN because either their ethernet-cards MAC was already present, or they had a hard-set IP that clashed are aplenty.

but a duplicate MAC appearing somewhere else shouldn't cause
any problems.

As long as it would not be a duplicate there, you would be correct. :-)

There are a few problems with your suggestion though : it only works for devices that do not move around, which would make Arlens statement that he
can track anyone a bit of a joke.

If they hoever *do* move around (hello smartphones!) there is a rather good chance that they will, sometimes, enter a network segment where their BSSID
is alread present - which could lead to a denial of service for one, or even all of the devices being copies of each other.

*Many years ago,

...

it didn't cause any problems. It simply moved certain
tasks farther up the network stack

I think it did a bit more. Like negotiating which server would handle the request, and how to mark it that a certain ethernet packet was part of an ongoing conversation with a specific server.

iow, all those servers would need to /activily work together/ so they would not yell over each other and try to hijack each others conversations.

You know, it does sound odd : that sofware (that was bought) would need to
add markers to make sure ongoing conversations would go to the server which first serviced it, in effect duplicating what the ethernet MAC and the
puters IP are for ...

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Arlen,


[quote=me]

Tell that to all the poor city-dwellers who predominanty rent they places.

Who are, by the way, in close proximity and often stacked several
layers ontop of each other.

As my thoughts went over to the "well off" city-dwellers who own the appartments they live in, I realized that they too often live stacked that
way, sometimes in high-rises of 20 stories or more, with penthouses ontop.

Your Apple-database location data in such cases ? Useless.

Regards,
Rudy Wieser




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Char Jackson wrote:

A BSSID is typically based on the interface's MAC address. Each MAC
address is assumed, by many people, to be globally unique, but they
don't have to be.* It helps greatly if a MAC address is unique within
its local network segment, but a duplicate MAC appearing somewhere else shouldn't cause any problems. By extension, a duplicate BSSID appearing somewhere else shouldn't cause any problems that I can think of.

So my question is, would it help Arlen's quest for privacy if he were to choose a MAC, and thus a BSSID, that already exists somewhere else and
is already present in the database? When someone does a query on that
BSSID, would they get the first result, or all results? I wonder if
Arlen has checked for duplicate BSSID entries in his favorite database.

*Many years ago, where I worked we trialed a piece of software that intentionally used the same IP address and MAC address on every server
in the pool. That violates everything we're taught about network
addressing, but it didn't cause any problems. It simply moved certain
tasks farther up the network stack. We ended up buying and deploying
that software into our production network.

Hi Char Jackson,

Happy New Year!

You are one of the people on this newsgroup who know more about routers
than anyone I personally know, including me, although Jeff Lieberman and
Paul and a few others would know as much or almost as much as you do.

So I welcome your question as I am wondering the same things myself!

In the context of OpenWrt running on consumer-grade hardware, it is
important to distinguish between what the configuration layer *allows*
you to request and what the underlying wireless chipset and driver will actually honor. While OpenWrt exposes 'option macaddr' for wireless
interfaces, the ability to override the BSSID (which is simply the MAC
address of the AP's radio interface) is entirely dependent on the
capabilities of the Wi-Fi hardware and its corresponding mac80211 or vendor-specific driver.

Most consumer routers use Broadcom, Qualcomm Atheros, or Mediatek
chipsets whose Wi-Fi MAC addresses are stored in OTP/EEPROM and are
treated as immutable by the firmware. Even when OpenWrt writes an
override into /etc/config/wireless, the driver frequently rejects the
requested MAC because the hardware enforces the burned-in address or
derives multiple interface MACs from a fixed base. As a result, the
BSSID remains tied to the factory-programmed value regardless of user configuration. This is why many OpenWrt users observe that attempts to
spoof the BSSID simply do not take effect on real consumer hardware.

Only a subset of chipsets, typically those using fully mac80211-based
drivers with permissive MAC handling, will accept a user-specified
address for the AP interface. Even then, the override must satisfy the
802.11 requirement for a unicast, locally administered MAC (i.e., the second-least-significant bit of the first octet must be set, and the least-significant bit must be clear). If the address fails these
constraints, the driver will silently normalize or reject it.

Because of these hardware and driver limitations, the idea of selecting
an arbitrary BSSID to "collide" with an existing entry in a Wi-Fi
positioning database is largely theoretical for typical OpenWrt
deployments. Even on hardware that does permit MAC spoofing, WPS systems
such as Apple's treat the BSSID as a unique key and will simply update
the single stored location rather than maintaining multiple entries. As
a consequence, spoofing an existing BSSID does not provide meaningful
privacy benefits and, in practice, is simply not achievable on most
consumer routers, even when they are running the latest OpenWrt firmware.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Char Jackson wrote:

*Many years ago, where I worked we trialed a piece of software that intentionally used the same IP address and MAC address on every server
in the pool. That violates everything we're taught about network
addressing, but it didn't cause any problems. It simply moved certain
tasks farther up the network stack. We ended up buying and deploying
that software into our production network.

Hi Char Jackson,

I appreciate your input because you're very knowledgeable in router setup.

I had left a note in the chimney on Christmas Eve for a consumer router
with DD-WRT or OpenWRT firmware that allows me to change the AP BSSID.

Unfortunately, there is no consumer router brand or model that universally "allows BSSID changes" as far as I'm currently aware. Certainly that
ability to change the BSSID of the access point exists in pro routers.

But what matters is not the router but the Wi-Fi chipset and the driver.

OpenWrt can only spoof a BSSID on hardware whose mac80211 driver
permits overriding the interface MAC address. Most consumer routers do
not permit this because the Wi-Fi MAC is stored in OTP/EEPROM and the
driver enforces it.

The only consumer-grade devices that consistently allow BSSID spoofing
are those using ath9k (Atheros 802.11n) or ath10k/ath11k (Qualcomm
802.11ac/ax) *with specific firmware revisions* that do not lock the MAC. Examples include older TP-Link, Netgear, and Ubiquiti devices based on
Atheros AR9xxx or QCA9xxx chipsets. On these units, OpenWrt can override
the MAC for AP mode, and the BSSID will follow the configured address.

However, even within the same product line, behavior varies.

Many ath10k-based consumer routers ship with board data that locks the MAC
or derives multiple interface MACs from a fixed base, preventing spoofing. Mediatek MT76 devices sometimes allow MAC override on 2.4 GHz but not on
5 GHz. Broadcom consumer routers almost never allow BSSID changes under
OpenWrt because the proprietary firmware enforces the burned-in address.

Therefore, the most accurate answer is that only certain Atheros-based
consumer routers, typically older models using ath9k or early ath10k,
permit true BSSID spoofing. No vendor guarantees this capability, and it
must be verified per chipset and driver rather than per router model.

My next chance is my 86th birthday, where I'll ask for an older router that
can change the BSSID in the outward-facing access point BSSID as no modern consumer router running OpenWrt or DD-WRT can reliably spoof the
outward-facing BSSID.

As far as I'm aware, only certain legacy Atheros ath9k devices could do
this, and they are no longer current hardware, unfortunately for me. :(
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Marian wrote:

Certainly that
ability to change the BSSID of the access point exists in pro routers.

But what matters is not the router but the Wi-Fi chipset and the driver.

Drat.

We all agree the BSSID picked up by Apple/Google devices and then uploaded
to the Apple/Google WPS databases is simply the MAC address of the wireless access point's radio interface as advertised in its beacon frames.

So to change the BSSID, we must change the MAC address of the AP interface.

While OpenWrt exposes:
option macaddr 'AA:BB:CC:DD:EE:FF'
it is ultimately the driver and hardware that decide whether to honor the override. Most modern Wi-Fi chipsets ignore it for AP mode.

Only older Atheros AR9xxx devices using the ath9k driver (circa 2008iV2014) allowed true MAC override in AP mode, which indirectly changed the BSSID.
These were fully mac80211-based radios with no firmware offload and no MAC locking. Examples include early TP-Link WR841N/WR1043ND units and some
Ubiquiti M-series devices. These are now obsolete and unsuitable for modern Wi-Fi.

Modern chipsets behave very differently. Qualcomm ath10k/ath11k, Mediatek
MT76 (MT7603/MT7612/MT7915/MT798x), and all Broadcom-chipset consumer
radios store the Wi-Fi MAC in OTP/EEPROM and enforce it in firmware.

Even when OpenWrt accepts a user-specified MAC, the driver normalizes or rejects it, or regenerates interface MACs from a fixed base. As a result,
the AP interface MAC cannot be changed, and the BSSID remains fixed.

From what I can determine, no modern consumer, prosumer, or WISP-grade
router (including Ubiquiti, MikroTik, OpenWrt, DD-WRT, or anything based on Qualcomm, Mediatek, or Broadcom chipsets) can arbitrarily change the BSSID
that appears in beacon frames.

As far as I can find out in google searches, unfortunately for me, and for anyone who cares about privacy, there is no mechanism in 802.11 to override
the BSSID field independently because the BSSID is not a configurable
parameter as the BSSID is always derived from the AP interface MAC address.

I wish it were that easy...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Andy Burns wrote:

So what are you asking me to answer?

For a named person, if you already know where they live, you know their location, if you don't know where the live, Apple's database doesn't
help you find out. Even if you find their router's BSSID, why do you
ant to wait years until they move home, just so you can track where they move to?

Hi Andy,

Happy New Year!

Thanks for answering as I respect your acumen, as you've taught me a lot
over the years, which I appreciate and we've always worked together.

I think you agreed we know the name of every homeowner in the USA.
And we know the location of that home (if it's a single-family home).
That's not disputable.

What we can dispute is whether the accuracy of the BSSID identifies the
home, and we can dispute the percentage of people who take their router
with them when they move from one home to another home (e.g., I took mine).

We can dispute who is living in the home, and for multi-family dwellings,
we can dispute who the person is that is using that router at that time.

We can also dispute the significance of a router moving from one location
to another, although a large number of moves will be by the router owner.

We do know the brand of router, so we can exclude exchanged equipment.

If we are thoughtful, we can come up with a large list of vetted things we know, and things we can reliably guess & things we will never know, right?

In "my" case, I took all my routers with me when I moved from home A to
home B, and most people I know have done the same, so it's very common.

a. Are you disputing I have the named owner of every home in the USA?

Situation is a bit different here, there's the electoral roll which will list everyone's address, but many people opt to tick the "privacy" box
so that isn't public information, there's also the land registry but
homes which have not recently changed hands are not required to be registered, and you have to pay to see each record.

I won't dispute the UK system, nor any others, as it's not really the point
to narrow it down to an individual because it's already down to the home.

The fundamental main points, which all tie together, are
1. Apple does not respect their published opt-out mechanism
2. Hence, my BSSIDs are in Apple's WPS database even though I've opted out
3. My ownership of the home is a public record I can not make private.
4. Since I live in the home, that's me (and the members of my family).
5. Anyone can look up the location of my home in Apple's WPS
6. That means they can reverse search, if they felt like doing that.
7. Unlike Google's WPS, Apple's WPS has no controls whatsoever on lookup.
8. Unlike Google's WPS, Apple's WPS lookups give 400 nearby AP BSSIDs.
9. This makes it trivial to create a db of every AP in the world
10. And trivial to track the movements of every BSSID in the world
11. Which means they can reverse search by homeowner/home to BSSID movement
12. Which is exactly what the security researchers said was easily doable.

Combined with any other location-based database, they can easily track
almost anything they want to track that is tied to a homeowners movements.

b. Or are you disputing I have the BSSID of every home in the USA?

I don't think you have it in such a cut-and-dried format, you've tied
things together by implication.

Sure. That's exactly what all the security research in the world says.
So I'm saying what experts are saying - which is reasonable.

Only someone who lacks imagination can't think of ways to use a hammer.
This is a hammer. It's a very powerful hammer indeed.

Tie it with a nail and the bad guys can do a lot of mischief.
Which I tried to avoid by opting out of Apple's WPS database.

Circle back to Apple has no intention of following their own privacy rules.

If Apple respected their own privacy policy, I would not have as great a
case against Apple, where what Apple is doing is the antithesis of what
Apple loudly proclaims it does.

Remember, Google isn't doing this.
Neither was Mozilla.

Only Apple.

If your name was, oh, let's say Jeffrey Devin, and if you put that router
in the home that you own at 4306 Josey Circle, then I can track that AP
anywhere in the world if you then moved to another home, and took your
router with you. c. Are you disputing I can track the location of that
AP BSSID, Andy?

But the BSSIDs are unique, people's names are not, how easy would it be
for you to link to SSNs?

I do not have a database of SSNs, but I'm sure if I was a loan officer I'd
have it, right? Or a banker? Or a solar roof installer, or law enforcement.

Once you have the router ap in the home, you can track that router ap
around the world if someone bothers to take their router with them.

I do.
My routers, as you've seen, are ages old and I still have them at home.
<https://i.postimg.cc/44WKMKpJ/apple-wps-testing.jpg>

Those are going to be turned on in Palo Alto on New Year's day.
In a month, we'll move them to Cupertino.

This is a simple test case which proves that anyone in the world
can track any access point in the world, no matter where it goes.

Again, if I could opt out, it wouldn't be so bad for privacy.
But Apple does not respect their own opt-out privacy policy.

Note that by tracking the BSSID and knowing the owner of every home in the >> USA (since that's a public record), I could tie it to you "if" you're the
owner. If you only rented the home, then I'd need more data to tie it to
you.

But in the USA, overwhelmingly, people own the home they live in.
So it's tied to the owner. Who, in this case, would be you.

For anyone who runs their own business, the companies house data is
another source of addresses,

There are lots of ways to tie metadata together where the key points are
really that Apple won't respect its privacy policy and Apple's WPS returns
for too much data (400 BSSID:GPS pairs in every query!) and has no
controls.

Remember, Google isn't doing that.
Neither was Mozilla.

I'm in constant email with Brian Krebs on this and with Dan Veditz
on the Mozilla Security Team, both of whom easily understand the issues.

But I couldn't get Erik Rye or David Levin to respond to my emails yet.

Would it not?

It would be easier for you to find my address by *not* using Apple's database ...

Let's say you go on vacation and you take your router with you.
I can track your movements anywhere in the world if you do that.

But the main point, let's keep in mind, is mainly that:
1. Apple doesn't not respect their own legally binding privacy policy
(unlike Mozilla who respects hidden SSIDs as a very clear opt out)
2. Apple WPS is too easy to abuse (which is very unlike Google's WPS)
(which is what the security researchers stated rather clearly)

Do you disagree with that two-point assessment?
--
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

On Wed, 31 Dec 2025 08:03:36 +0100, "R.Wieser" <address@is.invalid>
wrote:

Char,

It helps greatly if a MAC address is unique within its local
network segment,

I would say that!

Yes, :) Unless of course if it's done intentionally, which should very
rarely be the case.

Examples of 'puters who could not communicate over the LAN because either >their ethernet-cards MAC was already present, or they had a hard-set IP that >clashed are aplenty.

When I was in college/university, someone in the computer lab
intentionally enabled a DHCP server, knowing that there was already an
active DHCP server. With over 300 workstations affected, we were all
dismissed for the day while the lab team figured out what had happened.

but a duplicate MAC appearing somewhere else shouldn't cause
any problems.

As long as it would not be a duplicate there, you would be correct. :-)

I was thinking that the chance of that kind of collision would be
exceedingly low, but statistics were never my strength.

There are a few problems with your suggestion though : it only works for >devices that do not move around, which would make Arlens statement that he >can track anyone a bit of a joke.

If they hoever *do* move around (hello smartphones!) there is a rather good >chance that they will, sometimes, enter a network segment where their BSSID >is alread present - which could lead to a denial of service for one, or even >all of the devices being copies of each other.

*Many years ago,

...

it didn't cause any problems. It simply moved certain
tasks farther up the network stack

I think it did a bit more. Like negotiating which server would handle the >request, and how to mark it that a certain ethernet packet was part of an >ongoing conversation with a specific server.

iow, all those servers would need to /activily work together/ so they would >not yell over each other and try to hijack each others conversations.

You know, it does sound odd : that sofware (that was bought) would need to >add markers to make sure ongoing conversations would go to the server which >first serviced it, in effect duplicating what the ethernet MAC and the >puters IP are for ...

We thought it was odd, as well, but in the end we implemented it and it
worked, so there's that. That was more than 20 years ago, but I remember
the servers having dual NICs, with one dedicated as sort of a mesh,
where they disambiguated and de-duped everything, and the other
interface being for the actual subscriber traffic. Looking back, perhaps
it was overly complicated. I'm sure it has been replaced several times
by now.

Arlen says the whole idea that I tossed out above is a non-starter, so
thanks for the discussion. Happy New Year!

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.internet.wireless

Char Jackson wrote:

thanks for the discussion. Happy New Year!

Hi Char Jackson,

Happy New Year to you too!

I agree the simplest solution is to change the outward-facing SSID BSSID.
And I may have been wrong when I previously assumed no router allows it.

I've scoured the net trying to find a router that allows BSSID changing.
<https://forum.gl-inet.com/t/gl-mt3000-how-to-change-bssid/34977>

With FOSS firmware, the question morphs from which routers to which
chipsets and drivers allow changing the access point BSSID at will.

OpenWrt/DD-WRT can request a custom MAC/BSSID, but the radio driver must
honor it (i.e., option macaddr 'AA:BB:CC:DD:EE:FF').

Some sources claim these routers allow the BSSID override:
1. Netgear R7800 (Qualcomm Atheros IPQ8065 + ath10k radios)
2. TP-Link Archer C7 / A7 (Qualcomm ath9k/ath10k/ath11k)
3. Linksys EA8300 (Qualcomm IPQ4019)
4. Ubiquiti UniFi AC-Lite / AC-LR / AC-Pro (ath9k/ath10k)
5. GL.iNet ATX1800 (Wi-Fi 6, MediaTek MT7915)
Using OpenWRT in this three-step procedure:
STEP 1: Check BSSID
iw dev wlan0 info
STEP 2: Change BSSID
uci set wireless.radio0.macaddr='02:11:22:33:44:55'
uci commit wireless
wifi reload
STEP 3: Recheck BSSID
iw dev wlan0 info

Changing the BSSID means overriding the MAC address of the virtual AP interface, but only certain chipsets & Wi-Fi drivers allow this:
a. ath9k -> apparently always allows MAC override
b. ath10k -> apparently allows MAC override
c. ath11k -> apparently allows MAC override
d. mt76 (MediaTek) -> sometimes allows it; MT7915 is one of the good ones
e. Broadcom -> apparently never allows it
f. Marvell -> apparently never allows it
g. Realtek -> apparently unreliable or unsupported

So the list of potential routers that allow BSSID changes collapses to
'routers with Atheros or certain MediaTek chipsets that are sold today'.
--
There is always a solution that intelligent people, working together,
can discuss so that every problem we ever run into, has a working solution.
--- Synchronet 3.21a-Linux NewsLink 1.2