From Newsgroup: alt.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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.comp.os.windows-10

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

From Newsgroup: alt.comp.os.windows-10

Char,

but I remember the servers having dual NICs, with one dedicated
as sort of a mesh, where they disambiguated and de-duped everything,

That makes it likely that my (educated) guess that all servers would need to work together is what happened. :-)

Arlen says the whole idea that I tossed out above is a non-starter,

Arlen says a lot of things, most of it - lets put it nicely - not thought
thru.

Happy New Year!

And happy year to you - and everyone else here. :-)

Regards,
Rudy Wieser




--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Char,

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.

Mine neither, and that is why I saved a copy of the explanation to the "birthday paradox" : The chance that in a rather small group of people two would have the same birthday.

https://www.scientificamerican.com/article/bring-science-home-probability-birthday-paradox/

It turns out that that chance is above 50% for a group of just 23 people. Which is, to me, remarkable.


Ofcourse, the range of possible "birthdays" for BSSIDs is a "bit" (understatement)larger* (but would it be if we would have started with your idea ? I don't think so), but as the BSSID is moving around the "group" becomes much larger too.

* If we choose our BSSIDs ourselves, the actual range drops dramatically.
Take passwords as an example. Most of us have to be forced not to use our own name or birthdate. :-)

Bottom line, those clashes would probably be much more likely than you
think.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Wed, 31 Dec 2025 08:17:06 +0100, "R.Wieser" <address@is.invalid>
wrote:

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

Adding location information to DNS, DHCP, SNMP etc have been proposed.
Go to:
<https://www.rfc-editor.org/search/rfc_search.php>
and search for "location". You will find 165 RFC's involving
location.

An early scheme is RFC 1712
<https://www.rfc-editor.org/info/rfc1712> <https://www.rfc-editor.org/rfc/pdfrfc/rfc1712.txt.pdf>
The location data was limited to "level", which translates to floor
number, and "room" which provides horizontal location data for a
specific "level". Note that the data does not need to be derived from
GPS data. Since it doesn't change (often), it could be entered into
the database when the DNS record was created.

Among the later schemes is RFC 5870 <https://en.wikipedia.org/wiki/Geo_URI_scheme> <https://www.rfc-editor.org/rfc/pdfrfc/rfc5870.txt.pdf>
--
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.comp.os.windows-10

Jeff,

Adding location information to DNS, DHCP, SNMP etc have been proposed.

...

An early scheme is RFC 1712

proposed in 1994. Its now more than 36 years later (which is, for
technology, a loooong time), and nothing like it has been implemented.


Maybe that is because there is no automated way to determine the "floor number". Especially for devices which task it is to do DNS, DHCP and so
on - those do not even contain hardware to determine their own X/Y location.

I must say that that RFC does have a joke smell to it. You know, like the "I'm a teapot" HTTP status, the "evil bit" for ethernet packets and lets not forget "IP over avian carriers" (which, by the way /does/ work).

And although most/all smartphones do have a GPS, those are notoriously bad
at determing elevation (which is not really a surprise, if you look at where the GPS satelites are located in relation to the GPS receiver).

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

[quote=me]

proposed in 1994. Its now more than 36 years later

My apologies, its only 32 years ago.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Dec 23, 2025, Chris wrote
(in article <10idp84$67nc$1@dont-email.me>):

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!

Listen very carefully, I shall say this only once.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

On Thu, 1 Jan 2026 21:05:12 +0100, "R.Wieser" <address@is.invalid>
wrote:

Jeff,

Adding location information to DNS, DHCP, SNMP etc have been proposed.

...

An early scheme is RFC 1712

proposed in 1994. Its now more than 36 years later (which is, for >technology, a loooong time), and nothing like it has been implemented.

I'm 77 years old and am still proposing ideas which could easily be
labeled as science fiction. I've also seen projects that were
proposed, complete with detailed documentation, that didn't function
until funding was found many years later. I suggest you not pass
judgment on technology that you might consider old and instead
concentrate on whether they might actually work. Also, if you wish to
pass judgment on whether some technology is worth doing, there are
seats in the various houses of government awaiting your political
involvement.

Maybe that is because there is no automated way to determine the "floor >number". Especially for devices which task it is to do DNS, DHCP and so
on - those do not even contain hardware to determine their own X/Y location.

Quoting myself: "Note that the data does not need to be derived from
GPS data. Since it doesn't change (often), it could be entered into
the database when the DNS record was created."

That means that in 1994, there was no requirement to identify the
location of a router, server, computer, etc using GPS. Merely
entering the location data the SNMP MIB (management information base)
would be sufficient. Obviously, that won't work for moving objects,
but GPS was not fully operational until 1995 and was not useable for
indoor applications until High Sensitivity GPS arrived in about 1999 <https://www.furuno.com/en/gnss/technical/tec_high>
and Selective Availability was disabled in May 2000. If someone
proposes a geographic network equipment location system prior to about
2000, it wouldn't have worked very well.

I must say that that RFC does have a joke smell to it. You know, like the >"I'm a teapot" HTTP status, the "evil bit" for ethernet packets and lets not >forget "IP over avian carriers" (which, by the way /does/ work).

The RFC's I mentioned don't seem to be in the official book of April
Fools RFC's.
<https://www.rfchumor.com>

And although most/all smartphones do have a GPS, those are notoriously bad >at determing elevation (which is not really a surprise, if you look at where >the GPS satelites are located in relation to the GPS receiver).

That's true which is why sports GPS receivers often include a
barometric altimeter: <https://support.garmin.com/en-US/?faq=WlvNrOungC28xGtwB7hLY5>
"With proper calibration, the barometric altimeter of a Garmin watch
or outdoor handheld will report elevation readings ranging from -2,000
to 30,000 feet with an accuracy of +/-10 feet at any given point."
"Elevation calibrated by GPS is accurate to +/-400 feet at any given
point with a strong GPS signal"

Regards,
Rudy Wieser

--
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.comp.os.windows-10

R.Wieser wrote:

And happy year to you - and everyone else here. :-)

Happy New Year!

Every January 1st, I change the moniker on many of my accounts for privacy. Maria Sophia <mariasophia@comprehension.com> is what the moniker is now.

The rest of the headers are completely random from dictionary lookups
(as my "newsreader" is actually a bunch of scripts using telnet & gVim).

I'm not "hiding from you". I change nothing but the headers. Hence, if you can't figure out who I am in less than about ten seconds based on what I
write and how I write it and how I post excellent research often backed up
by detailed annotated screenshots & photos, please don't exclaim a thousand posts from now that you finally eventually figured it out - as when you do
that - it's absurd you think I'm "hiding" from you.

If you have no understanding of privacy, then save us all the trouble and
just put me in your killfile because anyone saying that they "found me" is someone who has nothing to offer because if it's that difficult for anyone
to figure out what is never hidden, then they have no right to exclaim
they're a genius for finally figuring out what was never hidden from them.

Note that while the headers are dictionary lookups, I did take what Andy & Chris suggested into account by adding scripts to identify the fontset.
--
My goal on these Usenet newsgroups is to teach, learn and to help others.
I post so many thousands of times a year, that privacy is inherently key.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: alt.comp.os.windows-10

Jeff,

Maybe that is because there is no automated way to determine the
"floor number". Especially for devices which task it is to do
DNS, DHCP and so on - those do not even contain hardware to
determine their own X/Y location.

Quoting myself: "Note that the data does not need to be derived
from GPS data. Since it doesn't change (often), it could be
entered into the database when the DNS record was created."

Two things about that :

1) You are talking about *users*, the ones who cannot even be arsed to
change a default password.

2) There is no reason to put the truth in there - it has zero function for them.

Worse, privacy-concious people would leave it at its default on purpose (I certainly would).

And than there is the problem how a human would determine the floor number he's on. Besides all the houses/buildings that have a half-sunken/elevated "cellar" (where you have to go up half a flight of stairs to reach the front door) there are also houses where going up/down half a flight of stairs gets you to the next room.

I suggest you not pass judgment on technology that you
might consider old and instead concentrate on whether
they might actually work.

You misunderstood : I did not say it was old, I indicated that it had a
*lot* of time to come to fruition, but that has not happened.

As for "might actually work" ? It doesn't bring any benefits to the user,
so most of them will simply not bother with it.

As I assume that the people who wrote that RFC where aware of the "if /everybody/ has to do it to make it work, than it won't work" saying I have
to assume it was put up as a joke.

That's true which is why sports GPS receivers often include a
barometric altimeter:

Which are also a problem : it relies on air pressure, which varies under the different weather types. /Way/ enough to make the measurement go up/down a number of floors. Its also a relative measurement, and needs to be
calibrated before use.

Regards,
Rudy Wieser


--- Synchronet 3.21a-Linux NewsLink 1.2