From Newsgroup: comp.mobile.android

How to test if your access point BSSID is in the highly insecure Apple WPS database and, if it is in Apples insecure WPS database, what else is there.

If you'd like me to test if your access point BSSID is in the Apple WPS database, then simply respond with that BSSID & I'll run the Windows
scripts I just wrote based on research published recently of the flaws in Apple's methods (some of that research is listed in the signature below).

Note that your BSSID should not be in Apple's database if you've opted out
by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap").

None of my access point BSSIDs are in the Apple database, but I have the
optout keywords _optout_nomap appended to all of them, but once I confirm
the process works, I'll be glad to write a tutorial so others can do it
too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.
--
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/>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025/12/5 12:8:8, Marian wrote:

How to test if your access point BSSID is in the highly insecure Apple WPS database and, if it is in Apples insecure WPS database, what else is there.

If you'd like me to test if your access point BSSID is in the Apple WPS database, then simply respond with that BSSID & I'll run the Windows
scripts I just wrote based on research published recently of the flaws in Apple's methods (some of that research is listed in the signature below).

Note that your BSSID should not be in Apple's database if you've opted out
by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap").

None of my access point BSSIDs are in the Apple database, but I have the optout keywords _optout_nomap appended to all of them, but once I confirm
the process works, I'll be glad to write a tutorial so others can do it
too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Can you get any idea of what's in the database, or can you only check it
for a specific given one? (I. e. does it accept wildcards or anything
similar?)

I ask as it'd be interesting to know if it _does_ contain any _nomap
ones, but you can't find that out if you have to specify them exactly.
(Though you could make up a few to try, but that wouldn't be conclusive
unless you succeed.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

"Young man, if you think I am going to climb up there you are greatly
mistaken. I am Melba." - Dame Nellie, in June 1920, on being shown the
tall aerials that would enable her voice to be heard around the world.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

J. P. Gilliver wrote:

Can you get any idea of what's in the database, or can you only check it
for a specific given one? (I. e. does it accept wildcards or anything similar?)

I ask as it'd be interesting to know if it _does_ contain any _nomap
ones, but you can't find that out if you have to specify them exactly. (Though you could make up a few to try, but that wouldn't be conclusive unless you succeed.)

Hi John,

Thanks for asking as we can all work together on this privacy project.

It's worse than I thought. I checked the Apple database for my own BSSID of
an access point that has had "_nomap" on it for years, and it was in the
Apple database!. The real GPS location. It was horrid. I almost fainted.

I don't understand _how_ it got into Apple's database.
Nor how it _stayed_ in Apple's database.
But there's no doubt that it's there. With the GPS to 8 decimal digits!

To me, that's criminal.
But I can't believe that Apple is that horrifically bad. I just can't.

So there must be some kind of a mistake.
But what?

A BSSID is unique.

Just run this on your PC and it will give you the BSSID you connect to:

netsh wlan show networks mode=bssid

I wasn't going to check Google's database, but I just started writing the scripts to check Google's database to see if it was only in Apple's
database. Anyone on the planet can query Apple's database.

But to query Google's database, I need to generate a Google Geolocation API account which I haven't done (and which I wasn't planning on doing).

But I was shocked my hidden-broadcast AP BSSID with _nomap was in Apple's database, so I might bite the bullet & create the Google API key after all.

Even so, if what I found out today is correct, Apple is liable for criminal action, so I need to be very clear and doublecheck everything I tested.

If anyone has a BSSID that they feel they don't have to worry about
posting, I can see if it's in Apple's database right away, but I do
understand why people might not post it on Usenet.

If we could find an SSID of a local coffee shop or library, that might work since it would only show us the location of that business on Google Maps.

I need to prove to all of you that the Apple/Google databases are horrid.

All we need to do that is a BSSID of an AP that isn't in your own home
(because I understand nobody wanting their own home to be geolocated).

But that's the whole point.

If it's that easy for anyone to look up where we live based only on our
BSSID, then there's something horrid going on, don't you think?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05, Marian <marianjones@helpfulpeople.com> wrote:

J. P. Gilliver wrote:

Can you get any idea of what's in the database, or can you only check it
for a specific given one? (I. e. does it accept wildcards or anything
similar?)

I ask as it'd be interesting to know if it _does_ contain any _nomap
ones, but you can't find that out if you have to specify them exactly.
(Though you could make up a few to try, but that wouldn't be conclusive
unless you succeed.)

It's worse than I thought. I checked the Apple database for my own BSSID of an access point that has had "_nomap" on it for years, and it was in the Apple database!. The real GPS location. It was horrid. I almost fainted.

Bullshit. Weak lie.
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05 04:08, Marian wrote:

How to test if your access point BSSID is in the highly insecure Apple WPS database and, if it is in Apples insecure WPS database, what else is there.

If you'd like me to test if your access point BSSID is in the Apple WPS database, then simply respond with that BSSID & I'll run the Windows
scripts I just wrote based on research published recently of the flaws in Apple's methods (some of that research is listed in the signature below).

Note that your BSSID should not be in Apple's database if you've opted out
by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap").

None of my access point BSSIDs are in the Apple database, but I have the optout keywords _optout_nomap appended to all of them, but once I confirm
the process works, I'll be glad to write a tutorial so others can do it
too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Your idea of "security" includes me giving you the MAC address of my
WiFi base station?

LOLOLOLOLOLOLOLOLOLOL
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05 04:08, Marian wrote:

How to test if your access point BSSID is in the highly insecure Apple WPS database and, if it is in Apples insecure WPS database, what else is there.

If you'd like me to test if your access point BSSID is in the Apple WPS database, then simply respond with that BSSID & I'll run the Windows
scripts I just wrote based on research published recently of the flaws in Apple's methods (some of that research is listed in the signature below).

Note that your BSSID should not be in Apple's database if you've opted out
by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap").

None of my access point BSSIDs are in the Apple database, but I have the optout keywords _optout_nomap appended to all of them, but once I confirm
the process works, I'll be glad to write a tutorial so others can do it
too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Or, if you want to do it without involving Arlen:

<https://wavedigger.networksurvey.app/?tab=bssid>

I checked mine...

(And I've been using the same router for more than 5 years)

...and surprise, surprise: it's not in there!
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05, Alan <nuh-uh@nope.com> wrote:

On 2025-12-05 04:08, Marian wrote:

How to test if your access point BSSID is in the highly insecure Apple WPS >> database and, if it is in Apples insecure WPS database, what else is there. >>
If you'd like me to test if your access point BSSID is in the Apple WPS
database, then simply respond with that BSSID & I'll run the Windows
scripts I just wrote based on research published recently of the flaws in
Apple's methods (some of that research is listed in the signature below).

Note that your BSSID should not be in Apple's database if you've opted out >> by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap").

None of my access point BSSIDs are in the Apple database, but I have the
optout keywords _optout_nomap appended to all of them, but once I confirm
the process works, I'll be glad to write a tutorial so others can do it
too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Or, if you want to do it without involving Arlen:

<https://wavedigger.networksurvey.app/?tab=bssid>

I checked mine...

(And I've been using the same router for more than 5 years)

...and surprise, surprise: it's not in there!

Yup. Same here. Another nothing burger from little Arlen.
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05 20:11, Alan wrote:

On 2025-12-05 04:08, Marian wrote:

How to test if your access point BSSID is in the highly insecure Apple
WPS
database and, if it is in Apples insecure WPS database, what else is
there.

If you'd like me to test if your access point BSSID is in the Apple WPS
database, then simply respond with that BSSID & I'll run the Windows
scripts I just wrote based on research published recently of the flaws in
Apple's methods (some of that research is listed in the signature below).

Note that your BSSID should not be in Apple's database if you've opted
out
by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap").

None of my access point BSSIDs are in the Apple database, but I have the
optout keywords _optout_nomap appended to all of them, but once I confirm
the process works, I'll be glad to write a tutorial so others can do it
too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Or, if you want to do it without involving Arlen:

<https://wavedigger.networksurvey.app/?tab=bssid>

I checked mine...

(And I've been using the same router for more than 5 years)

...and surprise, surprise: it's not in there!

Mine is.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05, Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-05 20:11, Alan wrote:

On 2025-12-05 04:08, Marian wrote:

How to test if your access point BSSID is in the highly insecure Apple
WPS
database and, if it is in Apples insecure WPS database, what else is
there.

If you'd like me to test if your access point BSSID is in the Apple WPS
database, then simply respond with that BSSID & I'll run the Windows
scripts I just wrote based on research published recently of the flaws in >>> Apple's methods (some of that research is listed in the signature below). >>>
Note that your BSSID should not be in Apple's database if you've opted
out
by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap"). >>>
None of my access point BSSIDs are in the Apple database, but I have the >>> optout keywords _optout_nomap appended to all of them, but once I confirm >>> the process works, I'll be glad to write a tutorial so others can do it
too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Or, if you want to do it without involving Arlen:

<https://wavedigger.networksurvey.app/?tab=bssid>

I checked mine...

(And I've been using the same router for more than 5 years)

...and surprise, surprise: it's not in there!

Mine is.

So one out of several. Not a great batting average.
--
E-mail sent to this address may be devoured by my ravenous SPAM filter.
I often ignore posts from Google. Use a real news client instead.

JR
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Jolly Roger wrote:

<https://wavedigger.networksurvey.app/?tab=bssid>

I checked mine...

(And I've been using the same router for more than 5 years)

...and surprise, surprise: it's not in there!

Mine is.

So one out of several. Not a great batting average.

Those are great team-player posts that add value to the discussion topic!
<https://networksurvey.app/wavedigger>

But that doesn't query the Google WPS database (AFAIK), nor any others.
Just Apple's WPS.

Additional added value is that one can query your router's BSSID against several other crowdsourced WPS databases, including Combain, Milnikov,
WifiDB, Freifunk (in addition to Apple/Wavedigger & Google) using...
<https://github.com/GONZOsint/geowifi>

Major WPS databases include the following:
1. Apple Location Services (which WaveDigger can query)
<https://wavedigger.networksurvey.app/?tab=bssid>
2. Google Location Services:
<https://developers.google.com/maps/documentation/geolocation/overview>
3. WiGLE.net:
<https://api.wigle.net/api/v2/network/search?netid=AA:BB:CC:11:22:33
4. Combain:
<https://combain.com/positioning-solutions/combain-location-api/>
5. WifiDB:
<https://wifidb.net/wifidb/opt/search.php>
6. Freifunk: (only for Germany)
<https://freifunk.net/> <https://berlin.freifunk.net/de/map/>
7: OpenCelliD: (combines cell towers with Wi-Fi access points)
<https://opencellid.org/#zoom=16&lat=37.77889&lon=-122.41942>
8. Skyhook Wireless: (discontinued, acquired by Qualcomm in 2014)
<https://skyhook.com/>
9. Navizon: (discontinued)
10. Milnikov: (discontinued?)
<https://www.milnikov.ru/geo/>
11. OpenWifi: (discontinued)
<https://freifunk.net/>
12. Mozilla MLS: (discontinued)
<https://wiki.mozilla.org/CloudServices/Location>

Note: Apple has historically documented an opt-out using '_nomap for Wi-Fi access points, and that language appeared in Apple Support materials for
years.
<https://cybernews.com/privacy/apple-beams-wifi-location-data-privacy-risk/>

Even as recently as last year, Krebs clarified Apple's opt-out policy:
*Why Your Wi-Fi Router Doubles as an Apple AirTag*
<https://krebsonsecurity.com/2024/05/why-your-wi-fi-router-doubles-as-an-apple-airtag/>
"In late March 2024, Apple quietly updated its website to note
that anyone can opt out of having the location of their wireless
access points collected and shared by Apple by appending '_nomap'
to the end of the Wi-Fi access point's name (SSID).
<https://web.archive.org/web/20240328071851/https://support.apple.com/en-us/102515>
Adding '_nomap' to your Wi-Fi network name also blocks Google
from indexing its location."
<https://support.google.com/maps/answer/1725632?hl=en#zippy=%2Chow-do-i-opt-my-access-point-out-of-google-location-services>

Note that page 14 of this 16-page paper also says:
<https://par.nsf.gov/servlets/purl/10540853>
"Apple has indicated that they are on track to make several changes
to their WPS in order to better protect user privacy. At the time
of writing, they have given AP operators the ability to opt out
of inclusion in Apple's WPS by appending the string _nomap to a
Wi-Fi network¢s SSID. This change brings it in line with Google's
WPS and WiGLE, which have also excluded SSIDs with _nomap (Google)
and _nomap and _optout (WiGLE) since at least 2016"

Note that they said WiGle uses "optout" while everyone else uses
_nomap, but I think WIGle also uses "_nomap" according to this:
<https://wigle.net/phpbb/viewtopic.php?t=2330>

Note it says what I've said all along about hiding the SSID broadcast:
"Note that unless you turn of your beacon your network is still
blasting the presence of your network to anyone within radio distance."
--
Working together as a team, we can all noticably improve our privacy.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025/12/5 19:59:27, Jolly Roger wrote:

On 2025-12-05, Alan <nuh-uh@nope.com> wrote:

On 2025-12-05 04:08, Marian wrote:

[]

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Or, if you want to do it without involving Arlen:

<https://wavedigger.networksurvey.app/?tab=bssid>

I checked mine...

(And I've been using the same router for more than 5 years)

...and surprise, surprise: it's not in there!

Yup. Same here. Another nothing burger from little Arlen.

I checked mine by name, and got
(!)
Invalid BSSID format. Expected 12 hexadecimal digits (e.g.,
AA:BB:CC:DD:EE:FF)
(Probably what the B means?)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

From Newsgroup: comp.mobile.android

Jolly Roger wrote:

It's worse than I thought. I checked the Apple database for my own BSSID of >> an access point that has had "_nomap" on it for years, and it was in the
Apple database!. The real GPS location. It was horrid. I almost fainted.

Bullshit. Weak lie.

It's classic for the Apple trolls to claim everything they can't understand
is a "weak lie" as Jolly Roger just did, but the fact remains that my BSSID
is in Apple's database (and the SSID is hidden & has "_nomap" appended).

This is bad.
Very bad.

It could very well be so bad that lawyers will need to be involved.
Since I take my privacy seriously - and yet - Apple doesn't appear to.

If I need to, I will contact a class-action suit lawyer, but I'm nowhere at that stage just yet, as I need to find out why my BSSID is in Apple's WPS.

I looked up what Apple's policy is and it appears that Apple "claims" to
scrub BSSIDs whose SSID contains the "_nomap" suffix, so my BSSID should
never be in Apple's WPS database under any perceivable circumstances.

*Why Your Wi-Fi Router Doubles as an Apple AirTag*
<https://krebsonsecurity.com/2024/05/why-your-wi-fi-router-doubles-as-an-apple-airtag/>
"In late March 2024, Apple quietly updated its website to note
that anyone can opt out of having the location of their wireless
access points collected and shared by Apple by appending '_nomap'
to the end of the Wi-Fi access point's name (SSID).
<https://web.archive.org/web/20240328071851/https://support.apple.com/en-us/102515>

Given I had "trusted" Apple at its word, I almost fainted when I found that
my BSSID was in Apple's WPS even as the SSID is hidden & it has "_nomap".
So I'm going to check all the other databases to try to get more datapoints
as this seems to be an egregious lack of privacy even for Apple to abuse.

Back to Jolly Roger's comments that everything he can't understand must be
a lie, the strange thing about Apple trolls is they claim everything that
puts Apple in a bad light is a lie, when the reality is that it's the
truth.

We can prove the truth if anyone else wants to give us their BSSID to test.
Or, they can test it themselves, as noted in a prior post, simply by by searching Apple's WPS database for their BSSID whose SSID is set to _nomap.
<https://wavedigger.networksurvey.app/?tab=bssid>

Moving forward, I am emphatically reporting that my SSID is set to hidden
and the SSID has _nomap appended, and yet it's clearly in the Apple WPS.

That's bad.
Really bad.

I will need to check further (to see if it's in the Google database, for example, which requires me to register for an API key from Google), but at
the moment, I'm horribly appalled my hidden/_nomap AP is in Apple's WPS.
--
Working together we can all help each other improve our privacy online.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

J. P. Gilliver wrote:

I checked mine by name, and got

(!)
Invalid BSSID format. Expected 12 hexadecimal digits (e.g., AA:BB:CC:DD:EE:FF)

(Probably what the B means?)

Hi John,

You said you checked yours "by name", where the query that was suggested
seems to be using the BSSID (which is in the format of "AA:BB:CC:DD:EE:FF")
<https://wavedigger.networksurvey.app/?tab=bssid>

Try entering your BSSID (i.e., your MAC address of the access point),
which, on Windows, you can get using netsh using the syntax below:

netsh wlan show networks mode=bssid

There are some WPS databases, as I noted in my prior post, which can take
an SSID input, apparently, if that's what you really want to query on.
<https://wifidb.net/wifidb/opt/search.php>

I haven't tried searching just for an SSID (since a BSSID is unique) and
when I just tested it with an SSID, the gateway timed out, so maybe there
isn't an SSID-only lookup, but that would be useful for those of us who
want to stay out of the rainbow hash tables (& butterfly hash tables).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

It's important to keep in mind how dangerous this Apple WPS system is:
*Why Your Wi-Fi Router Doubles as an Apple AirTag*
<https://krebsonsecurity.com/2024/05/why-your-wi-fi-router-doubles-as-an-apple-airtag/>

This 16-page paper shows the "potential for abuse", which is what we need
to understand if we're to take Apple's WPS system privacy abuse seriously.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://par.nsf.gov/servlets/purl/10540853>

This example below will show most people (whose BSSID is in Apple's WPS database) how they can track their own neighbors, just as a local example
(even though the tracking can happen to anyone anywhere in the world
since Apple puts no restriction on who can track anyone at any time).

For example, with WaveDigger, anyone can query the Apple WPS database:
<https://networksurvey.app/wavedigger>

Since WaveDigger has a special query mode where you can enter a single SSID
or BSSID, and instead of just returning that access point's location, it
also pulls in the surrounding access points that Apple's horribly insecure Wi-Fi Positioning System has observed in the same area, so just try this.

Windows:
1. Press Win+R
2. Type: cmd
3. In the command prompt, type:
netsh wlan show networks mode=bssid
4. Look for your SSID name
5. Under it, find "BSSID" lines
6. Copy the MAC address (format: AA:BB:CC:DD:EE:FF)

Linux:
1. Open a terminal
2. Type: sudo iwlist scan
3. Find your SSID in the output
4. Look for "Address:" lines
5. Copy the MAC address (format: AA:BB:CC:DD:EE:FF)

MacOS:
1. Open a terminal
2. Type: airport -s
3. Find your SSID in the list
4. Copy the BSSID shown (format: AA:BB:CC:DD:EE:FF)

Once you have the BSSID, you can paste it into WaveDigger lookup tool.
1. Open the WaveDigger site:
https://wavedigger.networksurvey.app/?tab=bssid
2. In the "BSSID" field, type your MAC address:
AA:BB:CC:DD:EE:FF
3. Click the "Lookup" or "Search" button.
4. The map will show the location of that access point.
If you enable "include surrounding access points",
it will also list nearby BSSIDs Apple has observed.

Once you have the BSSID of all your neighbors, if one of them moves to a
new house, you can track them if they use their router at the new home.
--
Privacy takes intelligence to understand, but most people give up.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 01:16, Marian wrote:

It's classic for the Apple trolls to claim everything they can't understand is a "weak lie" as Jolly Roger just did, but the fact remains that my BSSID is in Apple's database (and the SSID is hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05 17:02, Carlos E.R. wrote:

On 2025-12-06 01:16, Marian wrote:

It's classic for the Apple trolls to claim everything they can't
understand
is a "weak lie" as Jolly Roger just did, but the fact remains that my
BSSID
is in Apple's database (and the SSID is hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D

The BSSIDs are listed.

There is no easy link between a BSSID and the person or organization
that is using it.

A click using WaveDigger's site to search by location near my building
(as a for instance) returns more than 1,500 BSSIDs...

...and NONE of them actually show as being in my actual building.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

It's classic for the Apple trolls to claim everything they can't understand >> is a "weak lie" as Jolly Roger just did, but the fact remains that my BSSID >> is in Apple's database (and the SSID is hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D

Hi Chris,

Alas... it's shockingly disturbing, so I'm very happy that I had checked!

While the statement is horrifyingly correct that Apple has my BSSID in their WPS database even though I have appended "_nomap" to the SSID (and it's hidden)...
and even though Apple says they respect the opt-out directive...

I don't own the mentality of Sklaven.

I am already documenting everything so that, if I need to, I can present the i nformation to someone in the legal profession who can stop this.

But at this point, I have to take Apple at its word.
So I'm going to need to delve deeper to dig for "some kind of mistake".

It may be that by hiding my SSID broadcast, I prevented Apple from recognizing that the _nomap was appended to the SSID, for example.

Wouldn't that be ironic!

Since I'm a well-educated scientist and engineer, I have a few hypotheses to check out, but one of the next steps in gathering data is to see if the same BSSID is found in the Google WPS databases.

Unfortunately for me (but good for privacy), much unlike Apple (whose queries are unrestricted), Google a least restricts the queries to their WPS database, by requiring an API key.

It's not a huge restriction, but it's bigger than Apple's restrictions are.

And I've already written the tutorial for querying Apple's WPS database.
I need to write the tutorial for querying Google's WPS database too.

I'm either going to use the GitHub tool (which queries them all).
Or I'll use the defined method Google provides to query its WPS data.

1. Create an API key in the Google Cloud Console.
<https://console.cloud.google.com/>

2. Send a POST request to Google¢s Geolocation API endpoint:
<https://www.googleapis.com/geolocation/v1/geolocate?key=YOUR_API_KEY>

Include the BSSID in the request body Example JSON payload:
{
"wifiAccessPoints": [
{
"macAddress": "11:22:33:AA:BB:CC"
}
]
}

You can use curl from the command line to send the request:
curl -X POST \
-H "Content-Type: application/json" \
-d '{
"wifiAccessPoints": [
{"macAddress": "11:22:33:AA:BB:CC"}
]
}' \
"https://www.googleapis.com/geolocation/v1/geolocate?key=YOUR_API_KEY"

3. If Google has that BSSID in its database, you¢ll get back GPS
latitude/longitude coordinates.

If it's been excluded (because of _nomap or other reasons),
the response will likely be an error or no location data.

Here's a command line script that will make that query for us:

python geolocate.py

Where "geolocate.py" would be something like the following script:
# geolocate.py Python Script to Query Google WPS database
# USAGE: C:\> python.exe geolocate.py
import requests

# Replace with your own Google Geolocation API key
API_KEY = "YOUR_API_KEY"

# Replace with the BSSID you want to test
bssid = "11:22:33:AA:BB:CC"

url = f"https://www.googleapis.com/geolocation/v1/geolocate?key={API_KEY}"

payload = {
"wifiAccessPoints": [
{"macAddress": bssid}
]
}

response = requests.post(url, json=payload)

if response.status_code == 200:
print("Response from Google Geolocation API:")
print(response.json())
else:
print("Error:", response.status_code, response.text)

Note that each API call counts as one request against your daily quota, regardless of how many BSSIDs you include. To cut down on the request count, you can provide multiple wifiAccessPoints entries (each with a BSSID).

That means if you batch 10 BSSIDs into a request, it consumes only 1 quota unit,
not 10 (although, for individuals, in practice, the quota is large enough
at 2,500 per day before costing you a fee).

{
"wifiAccessPoints": [
{"macAddress": "11:22:33:AA:BB:CC"},
{"macAddress": "AA:BB:CC:11:22:33"},
{"macAddress": "12:34:56:78:90:AB"}
]
}
--
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 01:55, Marian wrote:

Linux:
1. Open a terminal
2. Type: sudo iwlist scan
3. Find your SSID in the output
4. Look for "Address:" lines
5. Copy the MAC address (format: AA:BB:CC:DD:EE:FF)

~# iw dev wlan1 link
Connected to AA:BB:CC:DD:EE:FF (on wlan1) <===
SSID: ....
freq: 5580
RX: 3443127087 bytes (2936179 packets)
TX: 47463826 bytes (444078 packets)
signal: -33 dBm
tx bitrate: 433.3 MBit/s VHT-MCS 9 80MHz short GI VHT-NSS 1

bss flags: short-preamble short-slot-time
dtim period: 3
beacon int: 100
~#
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 02:53, Marian wrote:

It may be that by hiding my SSID broadcast, I prevented Apple from recognizing
that the _nomap was appended to the SSID, for example.

Maybe.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-06 01:16, Marian wrote:

It's classic for the Apple trolls to claim everything they can't understand is a "weak lie" as Jolly Roger just did, but the fact remains that my BSSID is in Apple's database (and the SSID is hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D

Mine isn't listed and I did nothing to hide.

As has been said before, trying to hide makes one suspect, because
*other* factors stand out.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Marian <marianjones@helpfulpeople.com> wrote:

J. P. Gilliver wrote:

Can you get any idea of what's in the database, or can you only check it
for a specific given one? (I. e. does it accept wildcards or anything
similar?)

I ask as it'd be interesting to know if it _does_ contain any _nomap
ones, but you can't find that out if you have to specify them exactly.
(Though you could make up a few to try, but that wouldn't be conclusive
unless you succeed.)

Hi John,

Thanks for asking as we can all work together on this privacy project.

It's worse than I thought. I checked the Apple database for my own BSSID of an access point that has had "_nomap" on it for years, and it was in the Apple database!. The real GPS location. It was horrid. I almost fainted.

lol. Just goes to show all your paranoia is wasted. We can now all know
exactly where you are and what you're doing at all times[1]. Mwahaha!!

All we need to do that is a BSSID of an AP that isn't in your own home (because I understand nobody wanting their own home to be geolocated).

There are maps which "geolocate" everyone's home.

But that's the whole point.

If it's that easy for anyone to look up where we live based only on our BSSID, then there's something horrid going on, don't you think?

The only horrid[2] thing is how inept you are. You spend all your time
trying to protect your privacy and fail at the simplest level.

[1] we literally can't, because a MAC only links a property. There's no
other info inherent in that.
[2] horrid == tragically funny
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 14:32, Frank Slootweg wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-06 01:16, Marian wrote:

It's classic for the Apple trolls to claim everything they can't understand >>> is a "weak lie" as Jolly Roger just did, but the fact remains that my BSSID >>> is in Apple's database (and the SSID is hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D

Mine isn't listed and I did nothing to hide.

As has been said before, trying to hide makes one suspect, because
*other* factors stand out.

I am curious, though, about why some people are listed and some are not. What's the criteria? Maybe just chance. A passerby having the proper non intentional software working properly, I'd guess.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Marian <marianjones@helpfulpeople.com> wrote:

Carlos E.R. wrote:

It's classic for the Apple trolls to claim everything they can't understand >>> is a "weak lie" as Jolly Roger just did, but the fact remains that my BSSID >>> is in Apple's database (and the SSID is hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D

Hi Chris,

You're replying to Carlos.

Alas... it's shockingly disturbing, so I'm very happy that I had checked!

While the statement is horrifyingly correct that Apple has my BSSID in their WPS database even though I have appended "_nomap" to the SSID (and it's hidden)...
and even though Apple says they respect the opt-out directive...

I don't own the mentality of Sklaven.

I am already documenting everything so that, if I need to, I can present the i
nformation to someone in the legal profession who can stop this.

"A fool and his money are soon parted."

But at this point, I have to take Apple at its word.
So I'm going to need to delve deeper to dig for "some kind of mistake".

It may be that by hiding my SSID broadcast, I prevented Apple from recognizing
that the _nomap was appended to the SSID, for example.

Wouldn't that be ironic!

"Hoisted by your own petard." Tragic.

An alternative is that the "_nomap" flag only works going forward and
doesn't require Apple/Google/etc to remove existing db entries already captured.

Since I'm a well-educated scientist and engineer

You are neither.

<snip>

Just hack the MAC or get a new router.

If you were in the EU/UK you could demand them to delete the information
under GDPR. But apparently you prefer your version of "freedom" and this
isn't the american way.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

You're replying to Carlos.

Thanks for pointing out that I often confuse Carlos with you for some odd reason, which I apologize for. As I've explained many times, I wrote my own newsreader long ago so that I could pop up the edits in vi (later gVim).

So I don't see anything in the header unless I take pains to look.
However, the "attribute" line shows up, so I can see some identifiers.

"A fool and his money are soon parted."

I agree, and, you'll note, that in the last three decades of using
computers, the only apps/programs I've ever need to pay for are:
a. The company paid for MS Office (which I'm still using)
b. The company paid for Adobe Acrobat writer (which I'm still using)
c. Every year I buy at Costco on sale in December their TurbuTax

That's it. Even all my phones have been free lately.
All I had to do was pay the sales tax on them.

I even get many tens of thousands of dollars of Amazon items for free.
<https://amazon.com/vine/about>

Many people calculate that the Amazon Vine members are two in a million.

Amazon gives me tens of thousands of dollars of "stuff" for free
(although the deal is that they require me to write reviews for them).

Of course, I have to pay income taxes on the MSRP of everything I get from Amazon so while there are no price limits per se, that limits what I get.

In summary, I get much of what other people pay for, for free.
As you stated, if you're intelligent, everything turns out to be free.

Never make the mistake to think that I'm anything like you are.

Wouldn't that be ironic!

"Hoisted by your own petard." Tragic.

Well, never make the mistake of ever thinking I'm anything like you.
I care deeply that other people get the benefit of all that I learn.

In this case, I'm determined to find out the answer and then make sure
people on the Internet LEARN the answer that I work hard to find out.

That's where I differ from most people.
I'm trying to always spread the knowledge.

An alternative is that the "_nomap" flag only works going forward and
doesn't require Apple/Google/etc to remove existing db entries already captured.

I won't try to dig up the references, but I'm of the understanding that
Google will "scrub" the nomap BSSIDs within weeks of them disappearing.

The real question is what is Apple's policy when *both* nomap and a hidden
SSID are encountered since Apple is well aware of both circumstances.

Personally, I consider this class-action-suit worthy.
But I'm not a lawyer. When I find one who is interested, we'll find out.

But that's for the future.
For now, we need to figure out what has happened.

Since I'm a well-educated scientist and engineer

You are neither.

Heh heh heh...

The good news is my ego is not tied up in what you think of me.
My ego is tied up in how much valuable info I impart to others.

Never think I'm anything like you.

Just hack the MAC or get a new router.

It's not easy to "hack the mac" so that's out of the question.
I got my router for free but I have no intention of changing it out.

If you were in the EU/UK you could demand them to delete the information under GDPR. But apparently you prefer your version of "freedom" and this isn't the american way.

I get the political dig, where I don't disagree that, in the USA, the government favors the corporation being ruled by supply & demand.

The US government feels, for the most part, that if Apple breaks the rules, people will stop buying Apple products, but it turns out that Apple is brilliant at counteracting that with their marketing propaganda.

But at this point, all we know is Apple put my BSSID in its WPS database
even though I clearly told Apple not to put my BASSID in its WPS database.

That's all we know for sure.
A lot more digging needs to be done before I go to the lawyers.
I've never sued anyone in my life (nor ever have I been sued).

SO this will be uncharted territory for me.
But what I care about is what drives me.

Apple has no business morally or legally holding my BSSID in their db.
Apple's brazen lies will have huge legal moral and privacy implications.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

All we need to do that is a BSSID of an AP that isn't in your own home
(because I understand nobody wanting their own home to be geolocated).

There are maps which "geolocate" everyone's home.

Since access points with "_nomap" are clearly in the Apple WPS database,
this raises serious privacy concerns because the system can be abused to
track homes and individuals globally (as reported by researchers).

For you to claim all security researchers are wrong is classic.
I, for one, trust the security professionals (and I read their papers).

<https://www.cs.umd.edu/~dml/papers/wifi-surveillance-sp24.pdf>
"In this work, we show that Apple's WPS implementation
can easily be abused to create a serious privacy threat
on a global scale."

If it's that easy for anyone to look up where we live based only on our
BSSID, then there's something horrid going on, don't you think?

The only horrid[2] thing is how inept you are.

Well, it's a good thing you Apple trolls are the only people claiming I'm "inept", especially given I happen to be well informed on privacy issues.

I think the main reason you love to claim that I'm "inept" is because you
are desperate to defend Apple's actions to the death, no matter what.

Keeping your unique BSSID/GPS/SSID/dBm/timestamp/etc metadata out of the
Apple WPS database simply by adding "_nomap" should be one of those things.

For anyone to claim we have no right to privacy is to deny a fundamental
human freedom. Privacy is not a luxury; it is a cornerstone of autonomy and dignity.

When companies like Apple advertise an opt-out mechanism such as _nomap and then fail to honor it, they are not just ignoring a technical request; they
are disregarding the principle that individuals have the right to control
their own data.

To dismiss that right is to erode trust, weaken consent, and normalize surveillance as the default condition of modern life.

You spend all your time
trying to protect your privacy and fail at the simplest level.

Apple advertised that they would respect the _nomap suffix as an extremely clear and very obvious indication that we wished to not be in their db.

That Apple put my BSSID in their database is an indication of their lack of moral rectitude.

[1] we literally can't, because a MAC only links a property. There's no
other info inherent in that.

To claim we have no right to privacy is wrong; the real issue is that our rights are being undermined by systems designed without meaningful consent.

[2] horrid == tragically funny

The legal and moral issue here is Apple brazenly lied to all of us.
Yes. Apple lied even to you, Chris.

And the rights I'm trying to protect are the rights of all of us.
Yes, even your rights, Chris.

You have a right to privacy.
Just as I do. And more importantly, all of us have a right to privacy.

The fact is Apple has no legal standing to include my BSSID on many levels
a. Explicit promise
b. Breach of expectations
c. Moral dimensions

Explicit promise: Apple advertised that _nomap would prevent inclusion in
their crowdsourced Wi'Fi geolocation database.

Breach of expectation: If my router is still listed, Apple has failed to
honor its own stated privacy safeguard.

Moral dimension: This isn't just about technical compliance; it's about respecting user autonomy and consent.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

It may be that by hiding my SSID broadcast, I prevented Apple from recognizing
that the _nomap was appended to the SSID, for example.

Maybe.

Hi Carlos,

I thank you for making me think about it, where the fact remains that we
need to explain why a hidden SSID with "_nomap" is in the Apple WPS db.

The BSSID is always in the broadcast packet but that the SSID field is
"null" (or blank).

Since the broadcast happens ten times a second, there's no doubt Apple
products (of which I own many) are seeing the "BSSID", and, since these
Apple devices are in my own home, they're seeing the "SSID in the clear" whenever a PC or mobile device handshakes with the access point.

So, clearly, Apple *knows* that the SSID is hidden, and, Apple likely even knows the SSID, but Apple may have chosen to ignore these obvious facts.

Hence, I take this loss of my privacy by Apple very seriously.
What I need to do, moving forward, is gather more data points.

What would be useful to know is if it's only me or if it's everyone.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Marian <marianjones@helpfulpeople.com> wrote:

Chris wrote:

You're replying to Carlos.

Thanks for pointing out that I often confuse Carlos with you for some odd reason, which I apologize for. As I've explained many times, I wrote my own newsreader long ago so that I could pop up the edits in vi (later gVim).

So I don't see anything in the header unless I take pains to look.
However, the "attribute" line shows up, so I can see some identifiers.

Not true. Your replies always have the person's name. See above where is
says "> Chris wrote". That's in the *body* of your reply so you can see it.

"A fool and his money are soon parted."

I agree, and, you'll note, that in the last three decades of using
computers, the only apps/programs I've ever need to pay for are:
a. The company paid for MS Office (which I'm still using)
b. The company paid for Adobe Acrobat writer (which I'm still using)
c. Every year I buy at Costco on sale in December their TurbuTax

Why use proprietary tools when appropriate free and open source
alternatives exist?

That's it. Even all my phones have been free lately.
All I had to do was pay the sales tax on them.

"Free" as in you have to pay $$$ every month to get them. Your iphone was
also not free, remember. Cheap, but not free. We've been through this.

Why are you such an incorrigible liar?

I even get many tens of thousands of dollars of Amazon items for free.
<https://amazon.com/vine/about>

Many people calculate that the Amazon Vine members are two in a million.

Amazon gives me tens of thousands of dollars of "stuff" for free
(although the deal is that they require me to write reviews for them).

No they don't. You've already admitted that it is the vendors which give
you the items. Amazon is exploiting you. And yet you claim not to be a
slave...

Remember, if the service is free then you're the product.

Of course, I have to pay income taxes on the MSRP of everything I get from Amazon so while there are no price limits per se, that limits what I get.

It gets worse. jfc.

In summary, I get much of what other people pay for, for free.
As you stated, if you're intelligent, everything turns out to be free.

Junk is still junk. The price doesn't matter.

Never make the mistake to think that I'm anything like you are.

Wouldn't that be ironic!

"Hoisted by your own petard." Tragic.

Well, never make the mistake of ever thinking I'm anything like you.
I care deeply that other people get the benefit of all that I learn.

But you never learn. You only look for things that support your dogma.

In this case, I'm determined to find out the answer and then make sure
people on the Internet LEARN the answer that I work hard to find out.

You won't find the answer. You'll just keep making baseless assertions as that's all you can do.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Marian wrote:

I wasn't going to check Google's database, but I just started writing the scripts to check Google's database to see if it was only in Apple's
database. Anyone on the planet can query Apple's database.

But to query Google's database, I need to generate a Google Geolocation API account

You might remember I gave you a little curl-based script for that many
years ago, it needs two WiFi MACs and works better if you tell it their relative strengths ... yes it needs an APIKEY
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

However, the "attribute" line shows up, so I can see some identifiers.

Not true. Your replies always have the person's name. See above where is
says "> Chris wrote". That's in the *body* of your reply so you can see it.

That's exactly what I said.

Me: I see the attribute (i.e., Chris wrote).
You: Not true
Me: Yes true.

I agree, and, you'll note, that in the last three decades of using
computers, the only apps/programs I've ever need to pay for are:
a. The company paid for MS Office (which I'm still using)
b. The company paid for Adobe Acrobat writer (which I'm still using)
c. Every year I buy at Costco on sale in December their TurbuTax

Why use proprietary tools when appropriate free and open source
alternatives exist?

Well, you know I test free and open source tools all the time, Chris.

a. I've tested all the free MS Office alternatives.
b. I've tested all the free Adobe Acrobat writer alternatives.
c. I've tested all the free TurboTax alternatives.

For example, I've tested every single free PDF tool ever suggested on these newsgroups (including those suggested on comp.editors & comp.text.pdf).
<https://i.postimg.cc/jSNb7bkF/pspdf.jpg>

As a result of those extensive tests, I've never needed to buy Adobe tools
in decades (and the ones I have that are payware, my company bought).
[x] Print booklet format (pdfbook, pdfbooklet, enbooken, acrobat reader)
[x] Add or concatenate pages (pdftk, acrobat payware)
[x] Add signature (Adobe Reader Fill-and-sign sign-yourself tool)
[x] Archive sites (wkhtmltopdf, Acrobat payware,fastone scroll capture)
[x] Compress PDFs (ImageMagick, PDFgear, rlvision)
[x] Convert PDF to MSOffice (PDFgear, Calibre for MS Word only)
[x] Convert PDF to MSWord (Calibre, PDFgear)
[x] Convert PDF to epub format (Calibre)
[x] Convert PDF to PostScript (Calibre, Poppler)
[x] Converts PDFs to HTML (poppler)
[x] Convert PDF to raster (Imagemagick,GhostScript,Poppler-pdftocairo)
[x] Convert PDF to vector (Inkscape, Poppler-pdftocairo)
[x] Converts PDFs to PPM/PGM/PBM image formats (poppler)
[x] Add text to existing pdf (Irfanview/Paint.NET plugins + Ghostscript)
[x] Minor text editing (Adobe Reader commenting, PDF-XChange Editor)
[x] Generate PDF using markup language (LaTeX via pdfTeX or LuaTeX)
[x] Embeds files into a PDF as attachments (poppler)
[x] Extract images (PDFExchangeEditor,PDF Shaper,PDFgear,poppler,muPDF)
[x] Extract text (poppler) or mine textual & metadata (pdfminersix)
[x] Extracts embedded files (attachments) from a PDF (poppler)
[x] Fastest PDF readers (Sumatra or Foxit)
[x] Globally search & replace PDF text (Libre Office)
[x] List fonts used in a PDF (poppler)
[x] Metadata display on command line (poppler)
[x] Metadata removal (LibreOffice Writer, PDFgear offline)
[x] OCR, PDF-Xchange, freeOCR (paperfile.net), GOCR (jocr.sourceforge.net)
[x] Offline encrypt PDF with a password (pdfencrypt)
[x] Online shrink PDF <adobe.com/acrobat/online/compress-pdf.html>
[x] PDF text to audio file (Balabolka)
[x] Delete pages (pdfsam, pdftk, PDF-XChange Editor, PDF Arranger)
[x] Renumber pages (Acrobat Reader)
[x] Reorder pages (pdftk, PDF-XChange Editor, PDF Arranger)
[x] Rotate pages (pdftk, mutool, PDF-XChange Editor, PDF Arranger)
[x] Remove restrictions (Ghostscript,Ghostview,ps2edit,pdfwrite,pdf2djvu)
[x] Separates a PDF into individual pages (poppler)
[x] Split PDFs (PDFgear, Poppler, Ghostscript)
[x] Merge PDFs (pdfsam, pdftk, PDFgear, Poppler, Ghostscript)
[x] Tile PDFs (i.e., to print large posters) (Posterazor)
[x] Redact sensitive information (PDF-Xchange Editor, Adobe Acrobat Pro)
[x] Add watermarks or background layers (pdftk, PDFgear, PDFsam)
[x] Add bookmarks/TOC (jpdfbookmarks, LaTeX(hyperref), PDF-ExchangeEditor
[x] Flatten form fields (Ghostscript, Acrobat Pro)
[x] Embed audio/video into PDFs (Acrobat Pro, LaTeX (media9 package)
[x] Generate PDF from Markdown or HTML (Pandoc, wkhtmltopdf)
[x] Create fillable forms (LibreOffice Draw, Scribus, LaTeX (AcroTeX))
[x] Batch rename, convert, split, etc. (PDFsam, Poppler, Ghostscript)
[x] Extract annotations/comments (PDF-XChange Editor, Adobe Acrobat)
[x] Convert to OCR (Tesseract OCR, PDF-Xchange, ABBYY FineReader)
[x] Add hyperlink buttons (LibreOffice,LaTeX,PDF-XChange Editor)
[x] Compare two PDFs side-by-side (DiffPDF, Acrobat Pro)
[x] Digitally sign with certificate-based signature (Foxit PDF Editor)
[x] Free PDF samples
<https://examplefile.com/document/pdf>
<https://onlinetestcase.com/pdf-file/>
<https://sample-files.com/documents/pdf/>
<https://graydart.com/sample/documents/pdf>
<https://freetestdata.com/document-files/pdf/>
<https://getsamplefiles.com/sample-document-files/pdf>
<https://learningcontainer.com/sample-pdf-files-for-testing/>
[?] What other tasks do you do to edit or modify a PDF file?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Marian <marianjones@helpfulpeople.com> wrote:

Donald changing his nym non-randomly to avoid killfiles noted. This was
never about privacy.

You spend all your time
trying to protect your privacy and fail at the simplest level.

Apple advertised that they would respect the _nomap suffix as an extremely clear and very obvious indication that we wished to not be in their db.

That Apple put my BSSID in their database is an indication of their lack of moral rectitude.

Firstly, the _nomap is on your user-defined SSID. Secondly, what is
collected is the BSSID/MAC which in most cases cannot be edited.

You can choose to hide your SSID. So if you've hidden your SSID the nomap option is superfluous as it won't show up anyway.

There isn't, as far as I can see, an obligation to *remove* a MAC from the
WPS db if they *never see* the nomap request.

[1] we literally can't, because a MAC only links a property. There's no
other info inherent in that.

To claim we have no right to privacy is wrong;

There you go changing the narrative to suit your ends. No-one has made that claim.

the real issue is that our
rights are being undermined by systems designed without meaningful consent.

A MAC like an IP or a physical address is public information. There's no requirement for consent.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns <usenet@andyburns.uk> wrote:

Marian wrote:

I wasn't going to check Google's database, but I just started writing the
scripts to check Google's database to see if it was only in Apple's
database. Anyone on the planet can query Apple's database.

But to query Google's database, I need to generate a Google Geolocation API >> account

You might remember I gave you a little curl-based script for that many
years ago, it needs two WiFi MACs and works better if you tell it their relative strengths ... yes it needs an APIKEY

He barely remembers his name from week to week.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025/12/6 20:51:53, Chris wrote:
[]

There isn't, as far as I can see, an obligation to *remove* a MAC from the WPS db if they *never see* the nomap request.

[]
I'm only watching this from the sidelines, as a (not-very-interested)
observer.
This is the first I've heard of a "nomap request".
I'd been assuming Arlen/Marian's addition of "_nomap" to his (B?)SSID
_was_ the "request", and was (by its nature) continuous.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

From Newsgroup: comp.mobile.android

On 2025/12/6 0:24:4, Marian wrote:

J. P. Gilliver wrote:

I checked mine by name, and got

(!)
Invalid BSSID format. Expected 12 hexadecimal digits (e.g.,
AA:BB:CC:DD:EE:FF)

(Probably what the B means?)

Hi John,

You said you checked yours "by name", where the query that was suggested seems to be using the BSSID (which is in the format of "AA:BB:CC:DD:EE:FF")
<https://wavedigger.networksurvey.app/?tab=bssid>

Try entering your BSSID (i.e., your MAC address of the access point),
which, on Windows, you can get using netsh using the syntax below:

netsh wlan show networks mode=bssid

I did that, and pasted the resulting string into https://wavedigger.networksurvey.app/?tab=bssid [and got

(!)
BSSID not found in Apple's database. This may be a new or unregistered
access point.]

But I thought your whole beef was that your BSSID was in the database,
despite your having added "_nomap" to it. But you _can't_ add "_nomap"
to a string of hex pairs.

There are some WPS databases, as I noted in my prior post, which can take
an SSID input, apparently, if that's what you really want to query on.
<https://wifidb.net/wifidb/opt/search.php>

If by that you mean I can use its name, I tried that page, just filling
in its name - and nothing _seemed_ to happen when I clicked submit. Then
after 20 seconds or so (when I retried, anyway), it came up with

Search Results: 0 Points ( Save Link | Map | JSON | KMZ | GPX )

. (So both wavedigger and wifidb didn't find me. Since they look like
they're US-limited, I'm not surprised.)

I haven't tried searching just for an SSID (since a BSSID is unique) and
when I just tested it with an SSID, the gateway timed out, so maybe there isn't an SSID-only lookup, but that would be useful for those of us who
want to stay out of the rainbow hash tables (& butterfly hash tables).

--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

Old professors don't fade away - they just lose their faculties.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 11:06, Marian wrote:

Chris wrote:

However, the "attribute" line shows up, so I can see some identifiers.

Not true. Your replies always have the person's name. See above where is
says "> Chris wrote". That's in the *body* of your reply so you can see it.

That's exactly what I said.

Me: I see the attribute (i.e., Chris wrote).
You: Not true
Me: Yes true.

Except the attribute in the post was "Carlos wrote"...

...and then you proceeded assume it was Chris.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

J. P. Gilliver wrote:

This is the first I've heard of a "nomap request".

All the major players publish that they respect the "_nomap" request, where we've been discussing the _nomap keyword on these newsgroups since, oh, at least a decade or more.

As I recall, Google was forced to add it to allow people to opt out, and
then all the "well-behaved" entities (Apple, WiGLE, Mozilla, etc.) followed suit one by one when the uproar got too high (they even had to send a
message to Congress, as I recall, explaining how people can opt out).

Microsoft, being Microsoft, added _optout (as did WiGLE initially), but of course, it was pointed out to them you can't end with both opt out keywords
so it was always assumed Microsoft would accept _optout_nomap syntax.

Having said that, I went to a Christmas party yesterday where a very high
level Apple employee was hosting, who told me to send him the information.

I haven't received any results from the layers I contacted (not
surprisingly) but this Apple VP knows me extremely well so he knows I'm not full of shit. Being that everyone on the mountain uses WISP, he knows Wi-Fi even better than I do, so we'll find out what will happen from Apple.

I did receive responses from security researchers and Mozilla security personnel, but so far I haven't heard a word from the queries I sent to
both Apple & Google through their privacy email mechanisms.

At this point, I feel it's criminally and ethically irresponsible for Apple
to have my BSSID in their WPS database given I did everything I could to
opt out of it.

As Chris noted, it could be they only looked at the broadcast packets
(which occur every 100ms or so) which don't contain the SSID - but they
clearly know from those broadcast packets that the SSID is hidden.

I think this is a clear case for a class action lawsuit; but I'll give
Apple all the information and I will require that Apple explain HOW my
BSSID got into their WPS database, since that will let me know if it's just
me or everyone who tries to opt out of Apple's insecure WPS database.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

But to query Google's database, I need to generate a Google Geolocation API >>> account

You might remember I gave you a little curl-based script for that many
years ago, it needs two WiFi MACs and works better if you tell it their
relative strengths ... yes it needs an APIKEY

He barely remembers his name from week to week.

Hi Andy,

Chris' personal attack was so childish as to prove my point about Apple
trolls being nothing like normal human beings because they feel they must defend everything Apple does to the death, no matter what, by attacking us.

Hence, I wasn't going to respond until I tested it, but Chris' childish ad hominem attack forced me to respond before I test it, but rest assured all intelligent people have excellent memory because you need an excellent
memory to understand millions of datapoints in order to pass college exams.

Hence, I remember us discussing this on both the Android and iPhone
newsgroups in gory detail, where at that time the Google API wouldn't give
any answer unless we already knew an SSID/MAC/dBM/etc for contextual data.

Moving forward, I have the process to search the Google database, but I hesitate to create the Google API for the obvious privacy reasons.

However, you are correct that the Apple WPS lookup is completely insecure. Anyone in the world, without a key, can look up any BSSID they want.
And they'll get a map that lands exactly unequivocally at the end of your driveway up the steps to your door to your house (ask me how I know this).

For the Google WPS lookup, it's my understanding that not only did you need
the API key, but you used to need to provide contextual data along with the BSSID. We discussed this many times in the past, so I'll just summarize
that it used to require signal strength (RSSI) & signal-to-noise ratio and optionally, multiple nearby Wi-Fi access points.

But it's my understanding the current lookup doesn't require contextual
data to find out if you're in the Google WPS database.
a. You can send a BSSID in a request to the Google Geolocation API.
b. If Google has location data for that BSSID in its database,
the API will return approximate latitude/longitude coordinates
(plus an accuracy radius).
c. If Google does not have data for that BSSID, it returns nothing.

It's my understranding we need to form the request which requires the key: https://www.googleapis.com/geolocation/v1/geolocate?key=YOUR_API_KEY

Then we form the payload which contains the BSSID in question:
{
"wifiAccessPoints": [
{ "macAddress": "11:22:33:aa:bb:cc" }
]
}

And finally we send the request.
curl -X POST \
-H "Content-Type: application/json" \
-d
'{"wifiAccessPoints":[{"macAddress":"11:22:33:aa:bb:cc"}]}' \

"https://www.googleapis.com/geolocation/v1/geolocate?key=YOUR_API_KEY"

We could send the request using python.
import requests
API_KEY = "YOUR_API_KEY"
bssid = "11:22:33:aa:bb:cc"
url = f"https://www.googleapis.com/geolocation/v1/geolocate?key={API_KEY}"
payload = {"wifiAccessPoints": [{"macAddress": bssid}]}
response = requests.post(url, json=payload)
print(response.json())

If Google has location data for that BSSID, you¢ll get back:
{
"location": { "lat": 40.12345678, "lng": -120.12345678 },
"accuracy": 30
}

Right now, I'm working on getting a response from Apple management.
I've received responses from Mozilla and Krebs but nobody else.

I'll worry about Google later as I know people at Google also,
but Google is a much harder company to crack into than Apple is.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

J. P. Gilliver wrote:

BSSID not found in Apple's database. This may be a new or unregistered
access point.

Practically, the only way your BSSID won't be in Apple's WPS database is
either no Apple mobile device ever got close enough to upload it in recent
time (assume a week or two), or, you've appended "_nomap" to your SSID.

Or, if, as you noted below, this system only works in select countries.

But I thought your whole beef was that your BSSID was in the database, despite your having added "_nomap" to it. But you _can't_ add "_nomap"
to a string of hex pairs.

This is Apple's policy. I followed it. Yet my BSSID is in their database.

<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.'"

I can't explain more than that since I should NOT be in Apple's database.

There are some WPS databases, as I noted in my prior post, which can take
an SSID input, apparently, if that's what you really want to query on.
<https://wifidb.net/wifidb/opt/search.php>

If by that you mean I can use its name, I tried that page, just filling
in its name - and nothing _seemed_ to happen when I clicked submit. Then after 20 seconds or so (when I retried, anyway), it came up with

Search Results: 0 Points ( Save Link | Map | JSON | KMZ | GPX )

. (So both wavedigger and wifidb didn't find me. Since they look like
they're US-limited, I'm not surprised.)

You have to enter a BSSID into the URL like this:
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=11-22-33-AA-BB-CC>
If you're not in Apple's WPS database, consider yourself safe (for now).

I received a response from a security professional and from Mozilla but not
yet from Apple so I asked an Apple VP who is my neighbor to help me out.

The highest-level Google neighbor is a VP in HR which isn't a good
connection; the rest are engineers at Google but not management personnel.

I'll tackle Google later. Right now I demand that Apple explain to my satisfaction why my access point is in their database when I opted out.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025/12/7 6:53:28, Marian wrote:

J. P. Gilliver wrote:

This is the first I've heard of a "nomap request".

All the major players publish that they respect the "_nomap" request, where we've been discussing the _nomap keyword on these newsgroups since, oh, at least a decade or more.

The post to which the above line was replying implied that there was a
specific request one had to make, beyond just adding _nomap to your
SSID. (Such as doing something on a web page or similar.)

[]

I think this is a clear case for a class action lawsuit; but I'll give
Apple all the information and I will require that Apple explain HOW my
BSSID got into their WPS database, since that will let me know if it's just me or everyone who tries to opt out of Apple's insecure WPS database.

Any timescale for when your class action will be issued? (And I wouldn't
accept "it's just you" claims; see the [UK Post Office] "Horizon" scandal.)
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

"Bugger," said Pooh, feeling very annoyed.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

J. P. Gilliver <G6JPG@255soft.uk> wrote:

On 2025/12/6 20:51:53, Chris wrote:

[]

There isn't, as far as I can see, an obligation to *remove* a MAC from the >> WPS db if they *never see* the nomap request.

[]

I'm only watching this from the sidelines, as a (not-very-interested) observer.

This is the first I've heard of a "nomap request".

I'd been assuming Arlen/Marian's addition of "_nomap" to his (B?)SSID
_was_ the "request", and was (by its nature) continuous.

Correct. It is the request.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025/12/7 11:5:16, Chris wrote:

J. P. Gilliver <G6JPG@255soft.uk> wrote:

On 2025/12/6 20:51:53, Chris wrote:

[]

There isn't, as far as I can see, an obligation to *remove* a MAC from the >>> WPS db if they *never see* the nomap request.

[]

I'm only watching this from the sidelines, as a (not-very-interested)
observer.

This is the first I've heard of a "nomap request".

I'd been assuming Arlen/Marian's addition of "_nomap" to his (B?)SSID
_was_ the "request", and was (by its nature) continuous.

Correct. It is the request.

In that case, I can't see how they could claim not to have seen it; if
the SSID was in their system before it had the _nomap added, then surely
_with_ the _nomap added, it is a new SSID; the same if they'd _not_ had
it, and thus added it as a new one anyway. In both cases, at the point
they added it, they would see it.

The only way I can see they could claim not to have seen it, would be if
people had SSIDs ending with _nomap _before_ they implemented that
convention - but before that, why would people have had such SSIDs anyway!
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G()ALIS-Ch++(p)Ar++T+H+Sh0!:`)DNAf

You can't abdicate and eat it
- attributed to Wallis Simpson, in Radio Times 14-20 January 2012.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

J. P. Gilliver wrote:

All the major players publish that they respect the "_nomap" request, where >> we've been discussing the _nomap keyword on these newsgroups since, oh, at >> least a decade or more.

The post to which the above line was replying implied that there was a specific request one had to make, beyond just adding _nomap to your
SSID. (Such as doing something on a web page or similar.)

There are "some" horrid opt-out situations where you must give them your
BSSID to opt out of their databases (much like the "do not call"
registration was in the past), which I consider an invasion of privacy.

Microsoft does not use the _nomap suffix. Instead, you must provide
the MAC address of your Wi-Fi access point to Microsoft¡¦s block list.
<https://account.microsoft.com/privacy/location-services-opt-out>

<https://www.qualcomm.com/site/privacy/skyhookprivacy>
"MAC Addresses: If users wish to opt out of Skyhook's use
of the Wi-Fi access point's MAC address to provide location,
users may opt-out by clicking here.
<https://www.qualcomm.com/site/privacy/qualcommtpsoptout>
If users choose to opt out, Skyhook will blacklist that MAC address
to not use that MAC address information in the future.

I think this is a clear case for a class action lawsuit; but I'll give
Apple all the information and I will require that Apple explain HOW my
BSSID got into their WPS database, since that will let me know if it's just >> me or everyone who tries to opt out of Apple's insecure WPS database.

Any timescale for when your class action will be issued? (And I wouldn't accept "it's just you" claims; see the [UK Post Office] "Horizon" scandal.)

I sent email to a few lawyers associated with Google & Apple lawsuits.
They have been, so far, ignored, but that's to be expected at this stage.

I actually think there must be a "good answer" that will negate the need
for a lawsuit, as I can't believe Apple put me and people like me in their database knowingly. It must be a bug because it's against Apple's policy.

Mainly, I'll await what Apple tells me as I suspect there's an egregious
bug in Apple's system for SSIDs which are hidden but, it's extremely
important to note, Apple makes zero mention of hidden SSIDs in their documentation (as far as I can tell from very extensive searches).

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

I'm in contact with Mozilla security researchers who did tell me they purposefully didn't collect BSSIDs from SSIDs which were hidden.
<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')."

I am also in contact with one security researcher who is famous world wide, where he may write an article, but it's too early for me to go deeper.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-05 21:17, Carlos E.R. wrote:

On 2025-12-05 20:11, Alan wrote:

On 2025-12-05 04:08, Marian wrote:

How to test if your access point BSSID is in the highly
insecure Apple WPS database and, if it is in Apples insecure WPS
database, what else is there.

If you'd like me to test if your access point BSSID is in the
Apple WPS database, then simply respond with that BSSID & I'll
run the Windows scripts I just wrote based on research published
recently of the flaws in Apple's methods (some of that research
is listed in the signature below).

Note that your BSSID should not be in Apple's database if you've
opted out
by appending "_nomap" to your access point SSID (e.g., "my.ssid_nomap"). >>>
None of my access point BSSIDs are in the Apple database, but I
have the optout keywords _optout_nomap appended to all of them,
but once I confirm the process works, I'll be glad to write a
tutorial so others can do it too.

Let me know which BSSIDs you wish me to look up for you in Apple's WPS.

Or, if you want to do it without involving Arlen:

<https://wavedigger.networksurvey.app/?tab=bssid>

I checked mine...

(And I've been using the same router for more than 5 years)

...and surprise, surprise: it's not in there!

Mine is.

Curio: it is a new router that I put in service on October 9, so only
two months ago. The SSID is of course the same one as the old one, but
not the BSSID. That was a fast update.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 18:13, Marian wrote:

Carlos E.R. wrote:

It may be that by hiding my SSID broadcast, I prevented Apple from recognizing
that the _nomap was appended to the SSID, for example.

Maybe.

Hi Carlos,

I thank you for making me think about it, where the fact remains that we
need to explain why a hidden SSID with "_nomap" is in the Apple WPS db.

The BSSID is always in the broadcast packet but that the SSID field is
"null" (or blank).

Since the broadcast happens ten times a second, there's no doubt Apple products (of which I own many) are seeing the "BSSID", and, since these
Apple devices are in my own home, they're seeing the "SSID in the clear" whenever a PC or mobile device handshakes with the access point.

So, clearly, Apple *knows* that the SSID is hidden, and, Apple likely even knows the SSID, but Apple may have chosen to ignore these obvious facts.

Hence, I take this loss of my privacy by Apple very seriously.
What I need to do, moving forward, is gather more data points.

What would be useful to know is if it's only me or if it's everyone.

Sorry, I can't help with that. But yes, Apple should take the hint that
if the SSID is hidden, they should not list the associated BSSID either.

If you have a free unused/old router or access point, you could set it
up with a hidden _nomap SSID, and without connecting any of your phones
to it, wait to see if the BSSID appears listed after a month or two. It
would be interesting to check every day with a script, to see how fast
they update.


But you yourself posted recently a list of databases, and the procedures
to not get listed are quite different. _nomap in most of them, but
actually writing to them to get yourself unlisted on some of them. Not
very nice of them!
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 21:51, Chris wrote:

Marian <marianjones@helpfulpeople.com> wrote:

Donald changing his nym non-randomly to avoid killfiles noted. This was
never about privacy.

You spend all your time
trying to protect your privacy and fail at the simplest level.

Apple advertised that they would respect the _nomap suffix as an extremely >> clear and very obvious indication that we wished to not be in their db.

That Apple put my BSSID in their database is an indication of their lack of >> moral rectitude.

Firstly, the _nomap is on your user-defined SSID. Secondly, what is
collected is the BSSID/MAC which in most cases cannot be edited.

You can choose to hide your SSID. So if you've hidden your SSID the nomap option is superfluous as it won't show up anyway.

There isn't, as far as I can see, an obligation to *remove* a MAC from the WPS db if they *never see* the nomap request.

This is true, but they see that the SSID is hidden. This should be a
hint no not list the BSSID either. This can be a bug, not malice.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 18:13, Marian wrote:

Chris wrote:

All we need to do that is a BSSID of an AP that isn't in your own home
(because I understand nobody wanting their own home to be geolocated).

There are maps which "geolocate" everyone's home.

Since access points with "_nomap" are clearly in the Apple WPS database,
this raises serious privacy concerns because the system can be abused to track homes and individuals globally (as reported by researchers).

For you to claim all security researchers are wrong is classic.
I, for one, trust the security professionals (and I read their papers).

<https://www.cs.umd.edu/~dml/papers/wifi-surveillance-sp24.pdf>
"In this work, we show that Apple's WPS implementation
can easily be abused to create a serious privacy threat
on a global scale."

If it's that easy for anyone to look up where we live based only on our
BSSID, then there's something horrid going on, don't you think?

The only horrid[2] thing is how inept you are.

Well, it's a good thing you Apple trolls are the only people claiming I'm "inept", especially given I happen to be well informed on privacy issues.

I think the main reason you love to claim that I'm "inept" is because you
are desperate to defend Apple's actions to the death, no matter what.

Keeping your unique BSSID/GPS/SSID/dBm/timestamp/etc metadata out of the Apple WPS database simply by adding "_nomap" should be one of those things.

For anyone to claim we have no right to privacy is to deny a fundamental human freedom. Privacy is not a luxury; it is a cornerstone of autonomy and dignity.

I'm unsure about that.

The only reference to privacy in the "Universal Declaration of Human
Rights" is this:

Article 12

No one shall be subjected to arbitrary interference with his privacy,
family, home or correspondence, nor to attacks upon his honour and
reputation. Everyone has the right to the protection of the law against
such interference or attacks.



You would have to prove that your house BSSID being listed is a breach
of your fundamental right to privacy, because an AP is not directly
linked to your person.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-07 09:25, Marian wrote:

J. P. Gilliver wrote:

I'll tackle Google later. Right now I demand that Apple explain to my satisfaction why my access point is in their database when I opted out.

That's easy: they do not see you SSID because it is hidden, so they do
not see the _nomap in it.

They should take the "hidden" part as indicative of not wanting to be
listed, though. This can be a bug, not actual malice.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-06 01:24, Marian wrote:

There are some WPS databases, as I noted in my prior post, which can take
an SSID input, apparently, if that's what you really want to query on.
<https://wifidb.net/wifidb/opt/search.php>

Doesn't find mine.

There is also a map, which can display my city in Spain, but it freezes
when it reaches a resolution that might display wifis.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

J. P. Gilliver <G6JPG@255soft.uk> wrote:

On 2025/12/7 11:5:16, Chris wrote:

J. P. Gilliver <G6JPG@255soft.uk> wrote:

On 2025/12/6 20:51:53, Chris wrote:

[]

There isn't, as far as I can see, an obligation to *remove* a MAC from the >>>> WPS db if they *never see* the nomap request.

[]

I'm only watching this from the sidelines, as a (not-very-interested)
observer.

This is the first I've heard of a "nomap request".

I'd been assuming Arlen/Marian's addition of "_nomap" to his (B?)SSID
_was_ the "request", and was (by its nature) continuous.

Correct. It is the request.

In that case, I can't see how they could claim not to have seen it; if
the SSID was in their system before it had the _nomap added, then surely _with_ the _nomap added, it is a new SSID; the same if they'd _not_ had
it, and thus added it as a new one anyway. In both cases, at the point
they added it, they would see it.

Not if the SSID is hidden.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

If you have a free unused/old router or access point, you could set it
up with a hidden _nomap SSID, and without connecting any of your phones
to it, wait to see if the BSSID appears listed after a month or two. It would be interesting to check every day with a script, to see how fast
they update.

Ask some friends who use iPhones to come round for a coffee, the more
devices hoovering up data the better? They may only add BSSIDs to the
DB if they've seen them via multiple devices.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

Marian wrote:

  <https://wifidb.net/wifidb/opt/search.php>

Doesn't find mine.

Nor mine, by SSID name (not hidden or _nomap suffix)

I wouldn't really expect anyone to have wardriven around here with a
laptop running Vistumbler, but you never know ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

In that case, I can't see how they could claim not to have seen it; if
the SSID was in their system before it had the _nomap added, then surely
_with_ the _nomap added, it is a new SSID; the same if they'd _not_ had
it, and thus added it as a new one anyway. In both cases, at the point
they added it, they would see it.

Not if the SSID is hidden.

But they can always see that the SSID is hidden in the AP beacon frames.
Also in the AP probe response frames (e.g., to a wildcard probe).

Wi-Fi access points typically broadcast beacon frames every 102.4
milliseconds (about 10 times per second), at least by default.

Those beacon frames, for a hidden SSID, contain a null/blank SSID.
It's what Mozilla security researchers told me they key on for this:
<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')."

More to the point, if they bother to look at the access point responses to
the client authentication requests, they can see the SSID in cleartext.

The AP responds with the SSID in cleartext in response to probe requests
but only when a client actively probes with the correct SSID. This could
happen now, later, or even never.

In summary, Apple's WPS would know the SSID only if it looks at
1. AP probe response frames sent in reply to a client probe request
This is the only AP frame that reveals the SSID string when hidden.

The hidden SSID is not sent in cleartext in AP frames such as
2. AP beacon frames broadcast every 102.4ms
3. AP authentication/association responses sent during client connection

Hence, if you connected your desktop PC to the access point a month ago and
if you never needed to reconnect, there are no frames containing the SSID.

It's only if you connected while the Apple WPS system is listening that the
AP probe response will contain the SSID in cleartext.

Note I have plenty of Apple devices, so that's a given it will happen.
Also note I have autoconnect turned off, but family members have it on.

Since hidden SSIDs don't appear in beacons, the device can't discover them passively. To find them, the client must send directed probe requests with
each SSID in its saved list.

So the difference is: with autoconnect ON, the SSID leaks continuously
through AP probe responses; with autoconnect OFF, the SSID only leaks at
the moment of a manual connection.

This means, in practice, with any client device set to the typical
defaults, the Apple WPS system *does* know what the SSID is even if the
random iOS/Android mobile device only is looking at the AP frames (and not
at the client frames).
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

There isn't, as far as I can see, an obligation to *remove* a MAC from the >> WPS db if they *never see* the nomap request.

This is true, but they see that the SSID is hidden. This should be a
hint no not list the BSSID either. This can be a bug, not malice.

I'm in direct communications with the wonderfully responsive Mozilla team
and what Carlos just said is EXACTLY how they see the situation themselves.

<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')."
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

Firstly, the _nomap is on your user-defined SSID. Secondly, what is
collected is the BSSID/MAC which in most cases cannot be edited.

You can choose to hide your SSID. So if you've hidden your SSID the nomap option is superfluous as it won't show up anyway.

There isn't, as far as I can see, an obligation to *remove* a MAC from the WPS db if they *never see* the nomap request.

I've noticed you lack the kind of imagination that I have, so I may need to explain for the thousandth time that there is a REASON for the hidden SSID.

Think about it.

1. If you HIDE the SSID, the goal is for passive scanners to get the hint.
A hidden SSID means you don't want to be in any of the databases.
It's very clear. And the Mozilla security team agrees with me.
<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')."

2. If you add "_nomap", then that means you want it to be scrubbed.
But that's a completely DIFFERENT concept than being uploaded.

Hiding it was intended to prevent the upload.
Adding _nomap was intended to have it scrubbed if it was ever uploaded.

You don't appear to own the imagination to figure out they're different.

the real issue is that our
rights are being undermined by systems designed without meaningful consent.

A MAC like an IP or a physical address is public information. There's no requirement for consent.

You appear to fundamentally lack imagination which is required to
understand why the Apple WPS system is particularly egregious to personal privacy given there are no controls whatsoever on scraping its content.

Your unimaginative argument that 'MAC addresses are public' completely
ignores the fact that when aggregated at scale, they become a powerful
tracking tool. A single MAC address is just a hardware identifier; but a database of millions of them tied to GPS coordinates is essentially a map
of people's movements and residences.

Imagine this scenario:
1. A company collects BSSIDs (MACs) from Wi-Fi routers in a city.
2. Over time, they build a database:
a. MAC A -> seen at 123 Elm Street in 2022
b. MAC A -> seen at 456 Oak Avenue in 2023
3. From this, they infer the household at 123 Elm Street likely
moved to 456 Oak Avenue.

Now scale that up: Track migration patterns of entire neighborhoods.
Correlate MACs with census data, property records, or advertising IDs.

What was just public information becomes a de facto surveillance system, without meaningful consent from the people being tracked.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns <usenet@andyburns.uk> wrote:

Carlos E.R. wrote:

Marian wrote:

  <https://wifidb.net/wifidb/opt/search.php>

Doesn't find mine.

Nor mine, by SSID name (not hidden or _nomap suffix)

I wouldn't really expect anyone to have wardriven around here with a
laptop running Vistumbler, but you never know ...

Mine is and I would it expect it to be as it's not hidden nor nomapped.

This isn't about wardriving. It is routine collection by Apple (and google) devices that are nearby.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Marian wrote:

If you HIDE the SSID, the goal is for passive scanners to get the hint.

What if you have multiple SSIDs on your access point, but one hasn't got _nomap suffix? e.g. some providers here "piggyback" their own wifi onto customers devices for their other customers to use ...
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On December 6, I wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-06 01:16, Marian wrote:

It's classic for the Apple trolls to claim everything they can't understand is a "weak lie" as Jolly Roger just did, but the fact
remains that my BSSID is in Apple's database (and the SSID is
hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D

Mine isn't listed and I did nothing to hide.

I stand corrected (by myself :-)). It turns out my BSSID *is* listed
(in <https://wavedigger.networksurvey.app/?tab=bssid>).

Apparently my router reported (slightly) different MAC addresses than
the MAC address (BSSID) of my SSID. When I used 'Arlen''s 'netsh wlan
...' method [1], I got the correct BSSID.

The reported location is quite accurate - within some 10 metres or so
- but useless, because I live in a city and in an appartment building,
so there are hundreds of other Wi-Fi Access Points close by.

As has been said before, trying to hide makes one suspect, because
*other* factors stand out.

[1] I think I had tried that [2] before, but it first failed saying to
'Run as administrator', then it failed saying it needs 'Location
services', but it still failed. Later it turned out that it also needed
'Let apps access your location' to be switched on. (All on Windows 11.
Settings -> Privacy & security -> Location.)

[2] Something similar to "netsh wlan show networks mode=bssid". I think
'Arlen' also posted a 'netsh' command which only reports the BSSID of
the SSID you're connected to, instead of all the visible ones, but I
didn't find that again.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns wrote:

If you HIDE the SSID, the goal is for passive scanners to get the hint.

What if you have multiple SSIDs on your access point, but one hasn't got _nomap suffix? e.g. some providers here "piggyback" their own wifi onto customers devices for their other customers to use ...

Hi Andy,

You're smart and imaginative, where I agree with you and I've been
wondering how this could have happened, since it did happen.

There must be an explanation.

I'm wondering if repeaters and/or bridges can cause this to happen?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

You would have to prove that your house BSSID being listed is a breach
of your fundamental right to privacy, because an AP is not directly
linked to your person.

The simplistic argument that 'MAC addresses are not "directly" linked'
ignores the fact that when aggregated at scale, they become a powerful
tracking tool. A single MAC address is just a hardware identifier; but a database of millions of them tied to GPS coordinates is essentially a map
of people's movements and residences.

Imagine this scenario:
1. A company collects BSSIDs (MACs) from Wi-Fi routers in a city.
2. Over time, they build a database:
a. MAC A -> seen at 123 Elm Street in 2022
b. MAC A -> seen at 456 Oak Avenue in 2023
3. From this, they infer the household at 123 Elm Street likely
moved to 456 Oak Avenue.

Now scale that up: Track migration patterns of entire neighborhoods.
Correlate MACs with census data, property records, or advertising IDs.

What was just public information becomes a de facto surveillance system, without meaningful consent from the people being tracked.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

Sorry, I can't help with that. But yes, Apple should take the hint that
if the SSID is hidden, they should not list the associated BSSID either.

If you have a free unused/old router or access point, you could set it
up with a hidden _nomap SSID, and without connecting any of your phones
to it, wait to see if the BSSID appears listed after a month or two. It would be interesting to check every day with a script, to see how fast
they update.

Andy Burns wrote:

Ask some friends who use iPhones to come round for a coffee, the more devices hoovering up data the better? They may only add BSSIDs to the
DB if they've seen them via multiple devices.

I appreciate the input from both Carlos & Andy in that both of you seem to understand the problem set, which is I didn't consent to be tracked.
a. I hid my SSID (which is a clear non-consent active action), and,
b. I added _nomap to all my SSIDs (which is another active non consent).
And yet, I'm in the Apple WPS database down to the middle of the house. (Wavedigger maps are accurate to 8 digits pinpointing the exact home!)

The fact is that I have plenty of Apple devices in the home, maybe even
more than Android devices, so I don't need to bring in more iPhones. :)

We're all smart people so we can see that "something" is wrong.
But what?

It could be Apple (e.g., a bug).
Or, it could be me (as Andy has intimated in a prior post).

I've met with my neighbor who is a VP at Apple who knows me extremely well
so he takes my claims seriously, so we'll find out soon if it's a bug.

Or, it could be "something that I did"; but what?

I'm thinking that I need to look more deeply at how repeaters and bridges
pass BSSIDs. I'm not really all that familiar with how BSSIDs propagate.

I'll dig a bit to see if maybe a repeater/bridge threw me under the bus.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Frank Slootweg wrote:

On December 6, I wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-06 01:16, Marian wrote:

It's classic for the Apple trolls to claim everything they can't
understand is a "weak lie" as Jolly Roger just did, but the fact
remains that my BSSID is in Apple's database (and the SSID is
hidden & has "_nomap" appended).

So all your efforts to hide yourself are for nothing. You are listed.
You might as well not bother to hide! :-D

Mine isn't listed and I did nothing to hide.

I stand corrected (by myself :-)). It turns out my BSSID *is* listed
(in <https://wavedigger.networksurvey.app/?tab=bssid>).

Apparently my router reported (slightly) different MAC addresses than
the MAC address (BSSID) of my SSID. When I used 'Arlen''s 'netsh wlan
...' method [1], I got the correct BSSID.

The reported location is quite accurate - within some 10 metres or so
- but useless, because I live in a city and in an appartment building,
so there are hundreds of other Wi-Fi Access Points close by.

As has been said before, trying to hide makes one suspect, because
*other* factors stand out.

[1] I think I had tried that [2] before, but it first failed saying to
'Run as administrator', then it failed saying it needs 'Location
services', but it still failed. Later it turned out that it also needed
'Let apps access your location' to be switched on. (All on Windows 11. Settings -> Privacy & security -> Location.)

[2] Something similar to "netsh wlan show networks mode=bssid". I think 'Arlen' also posted a 'netsh' command which only reports the BSSID of
the SSID you're connected to, instead of all the visible ones, but I
didn't find that again.

I'll agree with and/or commend anyone who makes logically defensible
sentient statements, where I applaud Frank for reporting two facts:

1. His BSSID was listed in the Apple WPS database, and,
2. The "reported location is quite accurate - within 10 meters"

My experience is almost exactly the same as Frank's in that:
1. My BSSID is listed (even as it's HIDDEN & contains "_nomap")
2. The locations is virtually exact (from 6 to 8 decimal places)

Notice something interesting:
a. When you search using the URL, you get only six decimal places
b. When you search using python, you get up to eight decimal places

Here is a redacted set of images showing the decimal place issue:
<https://i.postimg.cc/C5Pcb6RQ/decimal.jpg>

Maybe those last two decimal places are why Frank sees an inaccuracy in location that is absolutely absent from my results, although everyone knows
I live in the boonies so even as much as 10 meters off is still exactly me.

UPDATE: I just checked my actual numbers.
6 decimal places: ~11 cm resolution.
8 decimal places: ~1 mm resolution.
The specific difference between them is only about 4cm.

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

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

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

As has been said before, trying to hide makes one suspect, because
*other* factors stand out.

I am curious, though, about why some people are listed and some are not. What's the criteria? Maybe just chance. A passerby having the proper non intentional software working properly, I'd guess.

I will disagree with anyone who makes an illogical statement such as that
which Frank made above, but I'll help answer any valid question such as
what Carlos asked.

Regarding Frank's assessment that hiding the SSID and putting _nomap on the SSID "makes one suspect"... Suggesting that opting out makes you 'suspect' flips the logic. In a system where consent is assumed unless you opt out, taking the opt-out step is the rational, privacy-protective choice.

In a system where the user must opt out, what I'm doing is establishing
clear instructions to the WPS databases that I do not consent to tracking.
a. I hid my SSID (which is a clear non-consent active action), and,
b. I added _nomap to all my SSIDs (which is another active non consent).
And yet, Apple ignored *both* those messages of clear opt-out intent!

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

But not Apple.
Clearly Apple ignored all my requests to opt out of their WPS database.

That's a problem.
A big problem.

What makes Apple *different* from Google is there are zero controls.
Anyone can download millions of tracking datapoints with Apple's WPS setup. (That's what the security researchers were warning us about after all.)

Scenario:
1. The Johnson family lives in Denver, Colorado.
Their home router has a unique BSSID 44:55:66:77:88:99

2. The Johnsons move to Atlanta, Georgia, and bring their router
with them. As soon as they plug it in, the same BSSID is detected.

3. A data broker can infer that the Johnsons moved across the country.
Advertisers could target them with "new homeowner" services ads.
A stalker or abusive ex could quickly discover their new address

The BSSID is persistent across locations.
That persistence means your router acts like a digital homing beacon.
It follows you wherever you go.

Now run that kind of tracking on millions of BSSIDs en masse, which is what security researched showed the insecure Apple WPS database can be used for.

As for Carlos' question of why some people are in the highly insecure Apple
WPS database, A router's BSSID is only logged if an Apple device (like an iPhone, iPad, or Mac) scans it and reports it back to Apple's servers. If
no device running Apple's WPS software has ever passed near your router, it won't be listed.

In my case, I have plenty of Apple mobile devices inside my home.
So they threw me under the bus even if nobody else did it for Apple.

The paper by Erik Rye & Dave Levin tracked BSSIDs over a year, where they mention that Apple doesn't seem to be scrubbing old BSSIDs out of the db.
"we were able to track BSSIDs longitudinally over the course of a year"
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-08 15:04, Marian wrote:

Carlos E.R. wrote:

Sorry, I can't help with that. But yes, Apple should take the hint
that if the SSID is hidden, they should not list the associated BSSID
either.

If you have a free unused/old router or access point, you could set it
up with a hidden _nomap SSID, and without connecting any of your
phones to it, wait to see if the BSSID appears listed after a month or
two. It would be interesting to check every day with a script, to see
how fast they update.

Andy Burns wrote:

Ask some friends who use iPhones to come round for a coffee, the more
devices hoovering up data the better?  They may only add BSSIDs to the
DB if they've seen them via multiple devices.

I appreciate the input from both Carlos & Andy in that both of you seem to understand the problem set, which is I didn't consent to be tracked.
a. I hid my SSID (which is a clear non-consent active action), and, b. I added _nomap to all my SSIDs (which is another active non consent).
And yet, I'm in the Apple WPS database down to the middle of the house. (Wavedigger maps are accurate to 8 digits pinpointing the exact home!)

The fact is that I have plenty of Apple devices in the home, maybe even
more than Android devices, so I don't need to bring in more iPhones. :)

We're all smart people so we can see that "something" is wrong. But what?

It could be Apple (e.g., a bug).
Or, it could be me (as Andy has intimated in a prior post).

I've met with my neighbor who is a VP at Apple who knows me extremely well
so he takes my claims seriously, so we'll find out soon if it's a bug.

Or, it could be "something that I did"; but what?

I'm thinking that I need to look more deeply at how repeaters and bridges pass BSSIDs. I'm not really all that familiar with how BSSIDs propagate.

I'll dig a bit to see if maybe a repeater/bridge threw me under the bus.

Doubtful.

The SSID is the same, so would have the _nomap, but I'm unsure about the
BSSID keeping or not.

In any case, you can find out if the SSID is published or hidden by any
of those repeaters/bridges. Just move near to each one of them, and
query the laptop information. Make sure it is connected to it by
comparing the strength of the signal.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-09 05:19, Marian wrote:

Carlos E.R. wrote:

   As has been said before, trying to hide makes one suspect, because
*other* factors stand out.

I am curious, though, about why some people are listed and some are
not. What's the criteria? Maybe just chance. A passerby having the
proper non intentional software working properly, I'd guess.

I will disagree with anyone who makes an illogical statement such as that which Frank made above, but I'll help answer any valid question such as
what Carlos asked.

Regarding Frank's assessment that hiding the SSID and putting _nomap on the SSID "makes one suspect"... Suggesting that opting out makes you 'suspect' flips the logic. In a system where consent is assumed unless you opt out, taking the opt-out step is the rational, privacy-protective choice.

Yes, but it also signals "I have something to hide!". It makes you "interesting".


...

3. A data broker can infer that the Johnsons moved across the country.
   Advertisers could target them with "new homeowner" services ads.
   A stalker or abusive ex could quickly discover their new address

Yes, but there are other information avenues that give away that
information to the public. Starting with the Johnsons talking on
twitter. The mobile phone will also notice and register this information (gps), and it will be at least available in aggregate form.

The BSSID is persistent across locations.
That persistence means your router acts like a digital homing beacon.
It follows you wherever you go.

Now run that kind of tracking on millions of BSSIDs en masse, which is what security researched showed the insecure Apple WPS database can be used for.

As for Carlos' question of why some people are in the highly insecure Apple WPS database, A router's BSSID is only logged if an Apple device (like an iPhone, iPad, or Mac) scans it and reports it back to Apple's servers. If
no device running Apple's WPS software has ever passed near your router, it won't be listed.
In my case, I have plenty of Apple mobile devices inside my home.
So they threw me under the bus even if nobody else did it for Apple.

The paper by Erik Rye & Dave Levin tracked BSSIDs over a year, where they mention that Apple doesn't seem to be scrubbing old BSSIDs out of the db.
"we were able to track BSSIDs longitudinally over the course of a year"

Ok.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-08 17:04, Marian wrote:

Frank Slootweg wrote:

On December 6, I wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

...

Notice something interesting:
a. When you search using the URL, you get only six decimal places
b. When you search using python, you get up to eight decimal places

Here is a redacted set of images showing the decimal place issue: <https://i.postimg.cc/C5Pcb6RQ/decimal.jpg>

Maybe those last two decimal places are why Frank sees an inaccuracy in location that is absolutely absent from my results, although everyone knows
I live in the boonies so even as much as 10 meters off is still exactly me.

But you said yourself you own Apple phones. Those will have reported you
from inside the house, so very accurate. In my case, they report the
location at the pavement where they see the signal, not the actual location.

UPDATE: I just checked my actual numbers. 6 decimal places: ~11 cm resolution.
8 decimal places: ~1 mm resolution.
The specific difference between them is only about 4cm.

What's really different is if you live in the boonies, the BSSID is you.

No, it is still your home.

If you're in the city, the BSSID might be you and people close to you.

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

--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-08 14:50, Marian wrote:

Carlos E.R. wrote:

You would have to prove that your house BSSID being listed is a breach
of your fundamental right to privacy, because an AP is not directly
linked to your person.

The simplistic argument that 'MAC addresses are not "directly" linked' ignores the fact that when aggregated at scale, they become a powerful tracking tool. A single MAC address is just a hardware identifier; but a database of millions of them tied to GPS coordinates is essentially a map
of people's movements and residences.

Imagine this scenario:
1. A company collects BSSIDs (MACs) from Wi-Fi routers in a city. 2.
Over time, they build a database:   a. MAC A -> seen at 123 Elm Street
in 2022   b. MAC A -> seen at 456 Oak Avenue in 2023
3. From this, they infer the household at 123 Elm Street likely
  moved to 456 Oak Avenue.

Now scale that up: Track migration patterns of entire neighborhoods. Correlate MACs with census data, property records, or advertising IDs.
What was just public information becomes a de facto surveillance system, without meaningful consent from the people being tracked.

Yes, this is true.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

Now scale that up: Track migration patterns of entire neighborhoods.
Correlate MACs with census data, property records, or advertising IDs.
What was just public information becomes a de facto surveillance system,
without meaningful consent from the people being tracked.

Yes, this is true.

Hi Carlos,

Thank you for understanding the problem set.

I'd like to make a critical point about your understanding of the issues.
a. The security researchers are the ones flagging this serious issue
b. It's only with the Apple WPS database (not with the Google WPS db)
c. That's because Apple allows millions of BSSIDs to be collected in days

Another point I'd like to make is that the Apple trolls do not UNDERSTAND
what you and the security researchers (and I) understand (see above).

The Apple trolls are spending all our valuable time with lame excuses attempting to defend Apple's insecure WPS database to the death, no matter what.

Chris, for example, just claimed I'd never write the code to track people.
And yet, I already wrote it. I posted it on the weekend. So it's there.

From: Marian <marianjones@helpfulpeople.com>
Newsgroups: alt.comp.os.windows-10,alt.internet.wireless,alt.comp.microsoft.windows,alt.comp.os.windows-11
Subject: Tutorial: Query the Apple database with Python for your access point BSSID
Date: Sat, 6 Dec 2025 10:55:40 -0700
Message-ID: <10h1qmr$2alo$1@nnrp.usenet.blueworldhosting.com>

If you feed any number of BSSIDs to that python script, it
feeds back the GPS locations to 8 decimal places of the BSSID.

If I can write that code in seconds, imagine what a nefarious malevolent
team could do who cares to track millions upon millions of people by BSSIDs. --- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

Regarding Frank's assessment that hiding the SSID and putting _nomap on the >> SSID "makes one suspect"... Suggesting that opting out makes you 'suspect' >> flips the logic. In a system where consent is assumed unless you opt out,
taking the opt-out step is the rational, privacy-protective choice.

Yes, but it also signals "I have something to hide!". It makes you "interesting".

I never disagree with any sensibly valid point of view, so people never
waste their time when they bring up a counterpoint with me, as I do
understand what your're saying but we have to look at the scale of consent.

There must be millions upon millions of people who do not consent to
tracking, even as there must be billions who consent to tracking their AP.

So I understand your point of view which is that every person who hides
their SSID is more interesting, to some people, than those who do not hide their SSID. Likewise with everyone who opts out of tracking with the
"_nomap".

Yet, both are well known to be the classic way to not consent to tracking.
<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')."

So if I'm "interesting" for opting out of consent for tracking, then there
must be a gazillion other ways I opt out from browser cookies to the TSA.

To wit, I recently traveled to Germany where TSA in the USA wanted to take
my photo at the beginning of the security check. I refused.

They looked at me. They said "fine". They compared my face to my ID.
That was it.

I guess my face isn't all that interesting. :)

3. A data broker can infer that the Johnsons moved across the country.
   Advertisers could target them with "new homeowner" services ads.
   A stalker or abusive ex could quickly discover their new address

Yes, but there are other information avenues that give away that
information to the public. Starting with the Johnsons talking on
twitter. The mobile phone will also notice and register this information (gps), and it will be at least available in aggregate form.

Sure. There's a reason, for example, that I turn off bluetooth on my phone
when I enter a store. People are tracked by ways they don't even know.

The paper by Erik Rye & Dave Levin tracked BSSIDs over a year, where they
mention that Apple doesn't seem to be scrubbing old BSSIDs out of the db.
"we were able to track BSSIDs longitudinally over the course of a year"

Ok

I think the problem here that the security researchers outlined, is that Apple's WPS is far more dangerous than the other WPS implementations.

The main reason is Apple allows anyone to make any number of queries.
And, Apple allows anyone to obtain millions of BSSIDs in a few days.

NOTE: I am aware the Apple trolls will claim that "I" must prove what the researchers said by writing those scripts, but I don't want to track people
and I'm not a security researcher who gets paid to do it.

I just ask the Apple trolls to come up with a single security researcher
who agrees with their point of view that Apple's WPS is perfectly designed.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

Maybe those last two decimal places are why Frank sees an inaccuracy in
location that is absolutely absent from my results, although everyone knows >> I live in the boonies so even as much as 10 meters off is still exactly me.

But you said yourself you own Apple phones. Those will have reported you from inside the house, so very accurate. In my case, they report the location at the pavement where they see the signal, not the actual location.

Hi Carlos,

As always, I agree with anyone who opines a sensibly logical position, so I agree with you that the "closer" the Apple device is to the access point,
the more accurate the GPS location will be (given to 8 decimal places).

Not only do I have plenty of Apple devices, but I have plenty of routers.
<https://i.postimg.cc/qMhQRkJN/linksys-wrt-54g.jpg>

Since we're all on WISP, we have radios galore which repurpose as APs.
<https://i.postimg.cc/5t4Nhkwx/transceiver01.jpg>

So if anyone wanted to query the database every five minutes, for example,
if I carried an iPhone or iPad with me around the house, they could track
me from one side of the house to the other, to the barn, to the stables, to
the pool, to the end of the driveway, etc. The accuracy is that close.

Of course, that's only as good as how frequently the WPS database is
updated when a new GPS location is received that is different from the old.

UPDATE: I just checked my actual numbers. 6 decimal places: ~11 cm
resolution.
8 decimal places: ~1 mm resolution.
The specific difference between them is only about 4cm.

What's really different is if you live in the boonies, the BSSID is you.

No, it is still your home.

Actually, it's the location of the access point, which may not even be
inside the home since it can be at the poolhouse or in the stables.
<https://i.postimg.cc/RZXNZBCQ/transceiver02.jpg>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-08 14:50, Marian wrote:

[...]

Imagine this scenario:
1. A company collects BSSIDs (MACs) from Wi-Fi routers in a city. 2.
Over time, they build a database:   a. MAC A -> seen at 123 Elm Street
in 2022   b. MAC A -> seen at 456 Oak Avenue in 2023
3. From this, they infer the household at 123 Elm Street likely
  moved to 456 Oak Avenue.

Now scale that up: Track migration patterns of entire neighborhoods. Correlate MACs with census data, property records, or advertising IDs.
What was just public information becomes a de facto surveillance system, without meaningful consent from the people being tracked.

Yes, this is true.

No, it's not. As you said, it's not people, but households and, as
others have said, it's not even households, but *devices* (Access
Points).

The *Access Point* has moved and that could be for all kinds of
reasons. The AP might be re-used by someone else. The household may have
been split up (someone(s) moved out), so the household did not move.
Etc., etc..

Devices are not people, at least not yet.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Frank Slootweg <this@ddress.is.invalid> wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-08 14:50, Marian wrote:

[...]

Imagine this scenario:
1. A company collects BSSIDs (MACs) from Wi-Fi routers in a city. 2.
Over time, they build a database:   a. MAC A -> seen at 123 Elm Street >>> in 2022   b. MAC A -> seen at 456 Oak Avenue in 2023
3. From this, they infer the household at 123 Elm Street likely
  moved to 456 Oak Avenue.

Now scale that up: Track migration patterns of entire neighborhoods.
Correlate MACs with census data, property records, or advertising IDs.
What was just public information becomes a de facto surveillance system, >>> without meaningful consent from the people being tracked.

Yes, this is true.

No, it's not. As you said, it's not people, but households and, as
others have said, it's not even households, but *devices* (Access
Points).

The *Access Point* has moved and that could be for all kinds of
reasons. The AP might be re-used by someone else. The household may have
been split up (someone(s) moved out), so the household did not move.
Etc., etc..

Devices are not people, at least not yet.

Correct.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Frank Slootweg wrote:

The Access Point has moved and that could be for all kinds of
reasons.

Some access points are inside trains/buses/planes/ships/cars

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

Devices are not people, at least not yet.

Correct.

If I had a pill in my pocket, you'd say it's a pill. It's not a cure. It's
a pill. You can't see that if it's penicillin, it can cure you of strep
throat.

You and Frank never were accepted into a college for a reason, Chris.
You don't own the IQ to understand a pill in my pocket is more than just a pill.

To you (and Frank), all pills are the same.
Who is that strange?

Only you are when making absurd defenses for Apple decisions.
Nobody on the planet who is a security professional agrees with you two.

Nobody.

If they did, you'd find them.
And you can't.

Because your assessment that penicillin can't cure step throat because it's "just a pill" is absurd.

Note: The "pill" is the analogy for the "bssid", which is more powerful
than the item appears to be to people who don't understand what it does.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Frank Slootweg wrote:

As you said, it's not people,

If I had a pill in my pocket, you'd say it's a pill. It's not a cure. It's
a pill. To you, every pill is the same. It's just a pill, to you.

You can't see that if it's penicillin, it can cure you of strep throat.


Nobody on the planet who is a security professional agrees with you two.
If they did, you'd find them.
And you can't.

Because your assessment that a pill can't cure step throat because it's
"just a pill" is patently absurd.

Note: The "pill" is the analogy for the "bssid", which is more powerful
than the item appears to be to people who don't understand what it does.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns wrote:

The Access Point has moved and that could be for all kinds of
reasons.

Some access points are inside trains/buses/planes/ships/cars

Hi Andy,

Some access points are mobile hotspots (hell, some phones are set up as a mobile hotspot), but the main claim the security professionals are making
is that Apple's WPS does two things that nobody else's WPS seems to do.
a. It makes *billions* of BSSID:location pairs available to all, and,
b. It makes the query of those billions of locations available to all.

It's hard for me to understand the "logic" from Chris & Frank that a BSSID
is "just a number", just as they would claim that a "white pill" is just a pill.

What they can't comprehend is that the pill that is penicillin, is more
than just a pill as if you understood the combination, it does something.

To them, a BSSID paired with a location is the same everywhere in the
world. They can't fathom that it's more than just a simple white pill.

Is there ANYONE out there on this newsgroup who understand this concept?
Do you?
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Marian <marianjones@helpfulpeople.com> wrote:

Chris wrote:

Devices are not people, at least not yet.

Correct.

If I had a pill in my pocket, you'd say it's a pill. It's not a cure. It's
a pill. You can't see that if it's penicillin, it can cure you of strep throat.

You and Frank never were accepted into a college for a reason, Chris.
You don't own the IQ to understand a pill in my pocket is more than just a pill.

What is it with you and these weird analogies?? Who cares if you have a
pill in your pocket...?

To you (and Frank), all pills are the same.
Who is that strange?

Only you are when making absurd defenses for Apple decisions.
Nobody on the planet who is a security professional agrees with you two.

Nobody.

If they did, you'd find them.
And you can't.

Because your assessment that penicillin can't cure step throat because it's "just a pill" is absurd.

I mean, it really can't. Penicillin is largely ineffectual following over-prescription. Plus, a single pill wouldn't cure anything; you need a course of at least a week of something like methicillin or phenoxicilin.

Note: The "pill" is the analogy for the "bssid", which is more powerful
than the item appears to be to people who don't understand what it does.

So what is the penicillin in your analogy...??

I think you've taken too many pills, Donald.



--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns <usenet@andyburns.uk> wrote:

Frank Slootweg wrote:

The Access Point has moved and that could be for all kinds of
reasons.

Some access points are inside trains/buses/planes/ships/cars

Yes, the assumption has been that we're talking about 'fixed' access
points.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-10 03:54, Marian wrote:

Carlos E.R. wrote:

Regarding Frank's assessment that hiding the SSID and putting _nomap
on the
SSID "makes one suspect"... Suggesting that opting out makes you
'suspect'
flips the logic. In a system where consent is assumed unless you opt
out,
taking the opt-out step is the rational, privacy-protective choice.

Yes, but it also signals "I have something to hide!". It makes you
"interesting".

I never disagree with any sensibly valid point of view, so people never
waste their time when they bring up a counterpoint with me, as I do understand what your're saying but we have to look at the scale of consent.

There must be millions upon millions of people who do not consent to tracking, even as there must be billions who consent to tracking their AP.

Huh, no. Maybe 80% of users do not even know they have that option.
Their ISP gives them a router, they just plug it in, done.

Only geeks and technical people know.

... trimming

Ok
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2025-12-10 20:10, Frank Slootweg wrote:

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-08 14:50, Marian wrote:

[...]

Imagine this scenario:
1. A company collects BSSIDs (MACs) from Wi-Fi routers in a city. 2.
Over time, they build a database:   a. MAC A -> seen at 123 Elm Street
in 2022   b. MAC A -> seen at 456 Oak Avenue in 2023
3. From this, they infer the household at 123 Elm Street likely
  moved to 456 Oak Avenue.

Now scale that up: Track migration patterns of entire neighborhoods.
Correlate MACs with census data, property records, or advertising IDs.
What was just public information becomes a de facto surveillance system, >>> without meaningful consent from the people being tracked.

Yes, this is true.

No, it's not. As you said, it's not people, but households and, as
others have said, it's not even households, but *devices* (Access
Points).

The *Access Point* has moved and that could be for all kinds of
reasons. The AP might be re-used by someone else. The household may have
been split up (someone(s) moved out), so the household did not move.
Etc., etc..

Devices are not people, at least not yet.

Ok, yes, we know that a device moved. We know that it could be a
household, or it could be a car with a wifi hot spot. More data would be needed to make certain it is a household, like for example, the SSID was static for years, then moved. Still, it can be that the AP was recycled.

There is no certainty, but a possibility.
--
Cheers, Carlos.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

There must be millions upon millions of people who do not consent to
tracking, even as there must be billions who consent to tracking their AP.

Huh, no. Maybe 80% of users do not even know they have that option.
Their ISP gives them a router, they just plug it in, done.

Only geeks and technical people know.

I always agree with any sensibly stated viewpoint, where I must also agree
with you that most people probably have no idea they can opt out of
tracking.

Worse, even we geeky people don't necessarily realize there are different
ways to opt out of each database, even as most use "_nomap" but not all.

For example, Microsoft & Qualcomm force us to give them our BSSID just to
opt out!
<https://account.microsoft.com/privacy/location-services-opt-out>
<https://www.qualcomm.com/site/privacy/qualcommtpsoptout>

The horrid thing is nobody but Mozilla (whom I'm in contact with
separately) tells us what their policy is for hidden SSID optouts.
<https://en.wikipedia.org/wiki/Mozilla_Location_Service>
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

You don't own the IQ to understand a pill in my pocket is more than just a >> pill.

What is it with you and these weird analogies?? Who cares if you have a
pill in your pocket...?

The point is a pill in my pocket is more than just a pill once you have
some context such that it is a penicillin pill, just as a bssid is more
than just a bssid when you have context such as the exact location of it.

Neither you nor Frank own the IQ to understand there is context involved.

Since you can't understand the power of the context, neither of you
understands that a bssid is you just as penicillin can cure strep throat.

Because your assessment that penicillin can't cure step throat because it's >> "just a pill" is absurd.

I mean, it really can't. Penicillin is largely ineffectual following over-prescription. Plus, a single pill wouldn't cure anything; you need a course of at least a week of something like methicillin or phenoxicilin.

You are aware my undergrad degree is in microbiology, Chris, are you not? (Hell, you joked about my textbooks many times so I know you know this.)

Note: Penicillin does not kill bacteria; it prevents them from growing.
It does that by interfering with their peptidoglycan cell wall structure.

Note: The "pill" is the analogy for the "bssid", which is more powerful
than the item appears to be to people who don't understand what it does.

So what is the penicillin in your analogy...??

Oh Jesus. My main point is you and Frank have such a low IQ that you can't fathom that a bssid attached to your exact location is more than a bssid.

Your substandard IQ doesn't allow you to comprehend the contextual power.

The analogy with the pill was simply that you and Frank own such a low IQ
that you can't comprehend that not every pill does the same thing, Chris.

Not every pill will prevent strep bacteria from growing.
You and Frank don't own the necessary IQ to understand contextual power.

That's why you say a BSSID with your GPS location is "just a number".
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. <robin_listas@es.invalid> wrote:

On 2025-12-10 03:54, Marian wrote:

Carlos E.R. wrote:

Regarding Frank's assessment that hiding the SSID and putting _nomap
on the
SSID "makes one suspect"... Suggesting that opting out makes you
'suspect'
flips the logic. In a system where consent is assumed unless you opt
out,
taking the opt-out step is the rational, privacy-protective choice.

Yes, but it also signals "I have something to hide!". It makes you
"interesting".

I never disagree with any sensibly valid point of view, so people never
waste their time when they bring up a counterpoint with me, as I do
understand what your're saying but we have to look at the scale of consent. >>
There must be millions upon millions of people who do not consent to
tracking, even as there must be billions who consent to tracking their AP.

Huh, no. Maybe 80% of users do not even know they have that option.
Their ISP gives them a router, they just plug it in, done.

Only geeks and technical people know.

I agree, although I'd say the number is nearer 99%. I have never ever seen
a "_nomap" SSID and I have been aware of it for easily over 5 years.

And when querying wifi networks almost none are changed from the ISP
default.


--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

Only geeks and technical people know.

I agree, although I'd say the number is nearer 99%. I have never ever seen
a "_nomap" SSID and I have been aware of it for easily over 5 years.

And when querying wifi networks almost none are changed from the ISP
default.

What's disconcerting is that I agree with both Carlos & Chris in that
almost nobody appears to even "know" about the opting out mechanism.

Yet, it seems every single day of my life, I see more news about it.
*Apple Tracks EVERYONE Through WiFi*
*How to Opt OUT of Apple WiFi Tracking*
<https://somegadgetguy.com/2024/05/24/apple-tracks-everyone-through-wifi-how-to-opt-out-of-apple-wifi-tracking/>

The "good" news is you can opt out of most (but not all) these services.

Microsoft: https://account.microsoft.com/privacy/location-services-opt-out
Qualcomm-Skyhook: https://www.qualcomm.com/site/privacy/qualcommtpsoptout
Apple: _nomap > https://support.apple.com/en-us/102515
Google: _nomap > https://support.google.com/maps/answer/1725632
WiGLE: _nomap or _optout > https://wigle.net/phpbb/viewtopic.php?t=2330
OpenWLANMap: _nomap > https://github.com/openwifi-su/OpenWLANMap-App
Mozilla: _nomap,hide > https://en.wikipedia.org/wiki/Mozilla_Location_Service
Unwired Labs: https://unwiredlabs.com/optout
Milnikov: https://www.milnikov.ru/geo/ (opt out seems to be dead)

There must be more than those though.
--- Synchronet 3.21a-Linux NewsLink 1.2