From Newsgroup: comp.lang.python

This is an update to the WPS scripts that I posted a few months ago.

Those scripts proved I could collect a list of every single access
point in Apple's database, just as researchers Eric Rye and Dave
Levin did, using a simple perl script which proved the results of
their paper, and which went further to prove that my own
hidden-broadcast SSIDs were in that database.

I complained to my next-door neighbor, who is a top-level exec
at Apple Maps, where he (to his credit) pushed this wording
through, but it proves, yet again, beyond any semblance of
doubt, that Apple doesn't care about our privacy.

Even Google doesn't stoop this low.
And that's saying something.

https://support.apple.com/en-ie/102515

"The owner of a Wi-Fi access point can opt it out of Apple's
Location Services by changing the access point's SSID (name)
to end with _nomap.

For example, |Access_Pointi would be changed to |Access_Point_nomapi.
This prevents devices from sending the access point s location to
Apple to include in Apple s crowd-sourced location database.

This opt-out doesn t work for hidden networks because they make
their network name only available to known devices, so other
devices can't detect _nomap."

This last sentence is a bold lie, by the way, since they can
certainly detect it, given the field has a null value.
But they lie about that too.

Below is code reproducing my tests... from which the claims are made.

@echo off
setlocal EnableDelayedExpansion
:: C:\app\os\python\apple_bssid_locator\bssid.bat
:: Use: bssid.bat <Enter> (then enter desired BSSID to look up)
:: Sample values:
:: 00:18:f8:c1:4a:65
:: 00:07:89:d7:82:e8
:: 04:09:A5:3B:34:67
::
:: Logs up to 400 BSSID:GPS pairs from Apple's WPS public database
:: Loop until user types q
::
:: Changelog:
:: v1p0 20251205 - Query Apple's highly insecure WPS database
:: v1p1 20251214 - Saves to time-date stamped results.txt log file
:: v1p2 20251215 - Timestamp results.txt so it's not overwritten
:: v1p3 20251219 - Limit the human-readable GPS to 6 decimal places
:: v1p4 20251219 - Show original raw integers + converted decimals
:: v1p5 20251219 - Tried to accomodate Google Maps query to new format
:: v1p6 20251219 - Changed to block-aware parsing with debug output
:: v1p7 20251219 - Enable delayed expansion to fix parsing inside loops

set LOGDIR=%~dp0log
if not exist "%LOGDIR%" mkdir "%LOGDIR%"

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

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

echo.
echo === Nearby Wi-Fi Networks ===
netsh wlan show networks mode=bssid
echo =============================

:loop
echo.
set /p BSSID=Enter the BSSID (or q to quit):

if /I "%BSSID%"=="q" goto end

:: --- Clean up input ---
set "BSSID=%BSSID:"=%"
set "BSSID=%BSSID: =%"

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

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

:: --- Timestamped output file ---
set "outfile=%LOGDIR%\bssid_%safeBSSID%_%ts%.txt"

:: --- Clear previous coordinates ---
set "LAT="
set "LON="

echo === Lookup started at %date% %time% === > "%outfile%"
echo BSSID: %BSSID% >> "%outfile%"
echo. >> "%outfile%"

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

:: --- Display results ---
echo -----------------------------------------------
type "%outfile%"
echo -----------------------------------------------

:: --- Block-aware parsing of coordinates (with delayed expansion) ---
set "CAPTURE="
set "LAT="
set "LON="

for /f "usebackq delims=" %%L in ("%outfile%") do (
if /i "%%L"=="BSSID: %BSSID%" (
set "CAPTURE=1"
set "LAT="
set "LON="
echo [DEBUG] Found block start for %BSSID%
) else if defined CAPTURE (
echo [DEBUG] Line in block: %%L

echo %%L | findstr /i /c:"Latitude (degrees):" >nul
if not errorlevel 1 (
for /f "tokens=2 delims=:" %%A in ("%%L") do set "LAT=%%A"
if defined LAT set "LAT=!LAT: =!"
echo [DEBUG] Parsed LAT candidate = "!LAT!"
)

echo %%L | findstr /i /c:"Longitude (degrees):" >nul
if not errorlevel 1 (
for /f "tokens=2 delims=:" %%B in ("%%L") do set "LON=%%B"
if defined LON set "LON=!LON: =!"
echo [DEBUG] Parsed LON candidate = "!LON!"
)

if defined LAT if defined LON (
goto :gotCoords
)

echo %%L | findstr /i /c:"BSSID:" >nul
if not errorlevel 1 (
set "CAPTURE="
)
)
)

:gotCoords
echo [DEBUG] Final LAT = "!LAT!"
echo [DEBUG] Final LON = "!LON!"

:: --- Validate parsed coordinates ---
if not defined LAT echo [DEBUG][ERROR] Latitude not captured. Check Python output format near "BSSID: %BSSID%".
if not defined LON echo [DEBUG][ERROR] Longitude not captured. Check Python output format near "BSSID: %BSSID%".

:: --- Save results ---
echo === Lookup finished at %date% %time% === >> "%outfile%"
echo. >> "%outfile%"

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

:: --- Append to master log ---
echo [%date% %time%] BSSID: %BSSID% >> "%LOGDIR%\results.log"
echo Latitude: !LAT! >> "%LOGDIR%\results.log"
echo Longitude: !LON! >> "%LOGDIR%\results.log"
echo. >> "%LOGDIR%\results.log"

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

goto loop

:end
echo Exiting. Goodbye!
endlocal

:: end of C:\app\os\python\apple_bssid_locator\bssid.bat
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Thu, 3 Sep 2026 16:30:15 +0930, Maria Sophia wrote:

Those scripts proved I could collect a list of every single access
point in Apple's database, just as researchers Eric Rye and Dave
Levin did, using a simple perl script which proved the results of
their paper, and which went further to prove that my own
hidden-broadcast SSIDs were in that database.

I donrCOt understand what yourCOre complaining about, exactly. Your wi-fi network broadcasts its existence to all and sundry, and yet you feel
upset when somebody collects that information and passes it on.

And hiding SSIDs is a complete waste of time, which gains you nothing
in security or privacy. DonrCOt do it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lawrence D'Oliveiro wrote:

Those scripts proved I could collect a list of every single access
point in Apple's database, just as researchers Eric Rye and Dave
Levin did, using a simple perl script which proved the results of
their paper, and which went further to prove that my own
hidden-broadcast SSIDs were in that database.

I don't understand what you're complaining about, exactly. Your wi-fi
network broadcasts its existence to all and sundry, and yet you feel
upset when somebody collects that information and passes it on.

And hiding SSIDs is a complete waste of time, which gains you nothing
in security or privacy. Don't do it.

Hi Lawrence,

I respect you, but I have to teach you so that you learn what you do not
know, as you don't even know that you don't know what you said is wrong.

Rest assured, I know what I'm talking about. :)

I've discussed this issue with Brian Krebs and Daniel Veditz (of the
Mozilla Security Team) so it's quite well understood by professionals.

The problem is most people who are NOT Wi-Fi pros, are stuck in the stone
age when it comes to thinking about what a hidden broadcast actually does.

Worse, I've had to have this discussion a billion times because almost
nobody else in the world outside of tech people knows anything about it.

The facts is you're thinking about security. Not about privacy.
They're not even close to the same thing.

This is about privacy.
Not security.

Apple literally manually removed my SSIDs from their database, as a result
of my RADAR bug report and Apple literally changed their documentation.
<https://support.apple.com/en-ie/102515>

That's new.
That's solely because of me.

As I had reported months ago, Apple at first pulled the stalling legal
trick of saying it's "not reproducible" but the person I had submit that
RADAR bug report is an executive in the Apple Maps division who happens to
be my next-door neighbor, and he knows full well I know my stuff.

They eventually told me "don't use a hidden SSID", which is the wrong
answer, and they KNOW it's the wrong answer because they literally manually removed my hidden SSID (but only mine!) from their public WPS database.

The entire reason for a hidden SSID is privacy.
If the SSID is hidden, it tells everyone you want to be private
a. Google respects that
b. Mozilla respects that
c. Everyone respects that
d. Except Apple

There's a HUGE difference in what happens to privacy between these events:
A. You set the SSID to null
B. You append _nomap to your SSID
--
Of the million things people need to know about privacy, most know 3.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Fri, 4 Sep 2026 02:27:07 +0930, Maria Sophia wrote:

Lawrence D'Oliveiro wrote:

On Thu, 3 Sep 2026 16:30:15 +0930, Maria Sophia wrote:

Those scripts proved I could collect a list of every single access
point in Apple's database, just as researchers Eric Rye and Dave
Levin did, using a simple perl script which proved the results of
their paper, and which went further to prove that my own
hidden-broadcast SSIDs were in that database.

I don't understand what you're complaining about, exactly. Your
wi-fi network broadcasts its existence to all and sundry, and yet
you feel upset when somebody collects that information and passes
it on.

And hiding SSIDs is a complete waste of time, which gains you nothing
in security or privacy. Don't do it.

The problem is most people who are NOT Wi-Fi pros, are stuck in the
stone age when it comes to thinking about what a hidden broadcast
actually does.

ThatrCOs their problem, though. Trying to offer some kind of sop to their ignorance is not actually making them safer.

This is about privacy.
Not security.

This is about the *perception* of privacy. Like telling people they
donrCOt have to worry about closing their curtains, they just need to
close their eyes -- if they canrCOt see the people outside looking in,
then those looking in canrCOt see them!

The entire reason for a hidden SSID is privacy. If the SSID is
hidden, it tells everyone you want to be private

rCLTells everyonerCY ... privacy is supposed to be something where you
donrCOt rCLtell everyonerCY!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

I donrCOt understand what yourCOre complaining about, exactly. Your wi-fi network broadcasts its existence to all and sundry, and yet you feel
upset when somebody collects that information and passes it on.

Your car broadcasts its license plate number to anyone in sight of it,
yet people are rightfully ticked off at Flock cameras everywhere
recording them.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Paul Rubi:

Your car broadcasts its license plate number to anyone in
sight of it, yet people are rightfully ticked off at Flock
cameras everywhere recording them.

Because machine data acquirement is more powerful.
--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-03 10:09, Lawrence DrCOOliveiro wrote:

On Thu, 3 Sep 2026 16:30:15 +0930, Maria Sophia wrote:

Those scripts proved I could collect a list of every single access
point in Apple's database, just as researchers Eric Rye and Dave
Levin did, using a simple perl script which proved the results of
their paper, and which went further to prove that my own
hidden-broadcast SSIDs were in that database.

I donrCOt understand what yourCOre complaining about, exactly. Your wi-fi network broadcasts its existence to all and sundry, and yet you feel
upset when somebody collects that information and passes it on.

I guess it is because the SSID is terminated in _nomap, which is
documented as a flag to Apple and others to not store this SSID in their
maps. But Apple is/was mapping them all the same.

And hiding SSIDs is a complete waste of time, which gains you nothing
in security or privacy. DonrCOt do it.

Yep.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-04, Carlos E.R. <robin_listas@es.invalid> wrote:

On 2026-09-03 10:09, Lawrence DrCOOliveiro wrote:

On Thu, 3 Sep 2026 16:30:15 +0930, Maria Sophia wrote:

Those scripts proved I could collect a list of every single access
point in Apple's database, just as researchers Eric Rye and Dave
Levin did, using a simple perl script which proved the results of
their paper, and which went further to prove that my own
hidden-broadcast SSIDs were in that database.

I donrCOt understand what yourCOre complaining about, exactly. Your wi-fi
network broadcasts its existence to all and sundry, and yet you feel
upset when somebody collects that information and passes it on.

I guess it is because the SSID is terminated in _nomap, which is
documented as a flag to Apple and others to not store this SSID in their maps. But Apple is/was mapping them all the same.

I got the impression they were claiming that their SSID was hidden,
which makes it irrelevant as to whether it has "_nomap" at the end
of it, but that Apple had somehow discovered and logged it nonetheless.
It seems highly implausible.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia <mariasophia@comprehension.com> wrote:

This is an update to the WPS scripts that I posted a few months ago.

I was wondering how you got on with your "experiment" only the other day.

You said you had installed two routers in friends' houses downtown, move
them around and then track the movement in the database.

I'd like to see the results. How often did you move them, how far, and were
the details tracked in the "apple database"?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lawrence D'Oliveiro wrote:

This is about privacy.
Not security.

This is about the *perception* of privacy. Like telling people they
don't have to worry about closing their curtains, they just need to
close their eyes -- if they canot see the people outside looking in,
then those looking in can't see them!

Hi Lawrence,

I say with all respect that your statement is too wrong to accept as is.
What you just said, I've heard a thousand times before, from many people.

And yet, it's no different than what I've heard by asking the guy next to
me at the gas pump since the 1960's why he puts premium in a Honda Civic.

For over five decades, people have been parroting what someone told them.
None of them actually understand a word that they're obviously parroting.

Same here...

Again, I respect you for your technical acumen which is greater'n mine.
But I can't tell if you know privacy differences between these situations:
a. iPhone owner happens to walk by my house
b. Android owner happens to walk by my house

Do you know the difference in terms of what happens, or not, with respect
to my unique AP BSSID & GPS location (both of which are exactly my house)?

I do.
A. So does Apple.
B. So does Mozilla. And Google.

Mozilla respects a hidden access point broadcast (i.e., it's set to null).
So does Google (surprisingly).
i. But not Apple.
ii. And yet, Apple loudly & vociferously proclaims to care about privacy.

That's the part that is the most hurtful.
Apple brazenly lies, with a huge "what me?" seemingly innocent smile.

Yet, Apple immediately removed my BSSID/GPS from their WPS database.
Because they know what I know about the lack of privacy in that regard.

It may well be I'm the only one in the world who is honored so by Apple.
But that's not my point as I care about everyone's privacy. Not just mine.

Another question for you, Lawrence, again, because I respect your acumen.

Do you know the difference between these two situations:
a. iPhone owner happens to walk by my house & it uploads my BSSID/GPS?
b. Android owner happens to walk by my house & it uploads my BSSID/GPS?

What happens then?
Do you know?

I do.
Anyone who can't answer those queries, can't possibly understand the issue.
--
Privacy is a million things, of which most people only understand about 3.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-05, Maria Sophia <mariasophia@comprehension.com> wrote:

Lawrence D'Oliveiro wrote:

This is about privacy.
Not security.

This is about the *perception* of privacy. Like telling people they
don't have to worry about closing their curtains, they just need to
close their eyes -- if they can-ot see the people outside looking in,
then those looking in can't see them!

Hi Lawrence,

I say with all respect that your statement is too wrong to accept as is.
What you just said, I've heard a thousand times before, from many people.

And yet, it's no different than what I've heard by asking the guy next to
me at the gas pump since the 1960's why he puts premium in a Honda Civic.

For over five decades, people have been parroting what someone told them. None of them actually understand a word that they're obviously parroting.

Same here...

Again, I respect you for your technical acumen which is greater'n mine.
But I can't tell if you know privacy differences between these situations:
a. iPhone owner happens to walk by my house
b. Android owner happens to walk by my house

Do you know the difference in terms of what happens, or not, with respect
to my unique AP BSSID & GPS location (both of which are exactly my house)?

I do.
A. So does Apple.
B. So does Mozilla. And Google.

Mozilla respects a hidden access point broadcast (i.e., it's set to null).
So does Google (surprisingly).
i. But not Apple.
ii. And yet, Apple loudly & vociferously proclaims to care about privacy.

That's the part that is the most hurtful.
Apple brazenly lies, with a huge "what me?" seemingly innocent smile.

Yet, Apple immediately removed my BSSID/GPS from their WPS database.
Because they know what I know about the lack of privacy in that regard.

It may well be I'm the only one in the world who is honored so by Apple.
But that's not my point as I care about everyone's privacy. Not just mine.

Another question for you, Lawrence, again, because I respect your acumen.

Do you know the difference between these two situations:
a. iPhone owner happens to walk by my house & it uploads my BSSID/GPS?
b. Android owner happens to walk by my house & it uploads my BSSID/GPS?

What happens then?
Do you know?

I do.
Anyone who can't answer those queries, can't possibly understand the issue.

Do you have any intention of letting anyone else know what the issue is?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Jon Ribbens wrote:

Anyone who can't answer those queries, can't possibly understand the issue.

Do you have any intention of letting anyone else know what the issue is?

Hi Jon,

Lil' ole' me can easily track a BSSID anywhere in the world, down to a
meter or so accuracy, if I want to under the common circumstances which
I've outlined in this thread (and in others).

I move my router around a lot, and I don't want just anyone being able to
track all my movements down to a meter accuracy when I do that. Do you?

You were correct in your prior post to Carlos, when you said (verbatim):
"I got the impression they were claiming that their SSID was hidden,
which makes it irrelevant as to whether it has "_nomap" at the end
of it, but that Apple had somehow discovered and logged it nonetheless.
It seems highly implausible."

But, of course, there's more detail (which I provided in my responses).

I explained it in gory detail, and even provided a link to the research.
I provided some of the python scripts too (although they're not the point).

We've discussed this ad infinitum on the Apple & Android & Windows ngs in
the past, although I don't remember how much we brought in Python folks.

What's *new* is Apple told me in my email that there was no way to have WPS privacy from Google/Mozilla if I wished to have WPS privacy from Apple.

It's a catch-22 situation.
Which would you pick?

HINT: If we read the research paper, it's a no brainer which one to pick.
--
Of the million things to be considered for privacy, most people know 3.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Sep 4, 2026 at 8:34:25rC>PM EDT, "Jon Ribbens" <jon+usenet@unequivocal.eu> wrote:

On 2026-09-05, Maria Sophia <mariasophia@comprehension.com> wrote:

Lawrence D'Oliveiro wrote:

This is about privacy.
Not security.

This is about the *perception* of privacy. Like telling people they
don't have to worry about closing their curtains, they just need to
close their eyes -- if they can-ot see the people outside looking in,
then those looking in can't see them!

Hi Lawrence,

I say with all respect that your statement is too wrong to accept as is.
What you just said, I've heard a thousand times before, from many people.

And yet, it's no different than what I've heard by asking the guy next to
me at the gas pump since the 1960's why he puts premium in a Honda Civic.

For over five decades, people have been parroting what someone told them.
None of them actually understand a word that they're obviously parroting.

Same here...

Again, I respect you for your technical acumen which is greater'n mine.
But I can't tell if you know privacy differences between these situations: >> a. iPhone owner happens to walk by my house
b. Android owner happens to walk by my house

Do you know the difference in terms of what happens, or not, with respect
to my unique AP BSSID & GPS location (both of which are exactly my house)? >>
I do.
A. So does Apple.
B. So does Mozilla. And Google.

Mozilla respects a hidden access point broadcast (i.e., it's set to null). >> So does Google (surprisingly).
i. But not Apple.
ii. And yet, Apple loudly & vociferously proclaims to care about privacy. >>
That's the part that is the most hurtful.
Apple brazenly lies, with a huge "what me?" seemingly innocent smile.

Yet, Apple immediately removed my BSSID/GPS from their WPS database.
Because they know what I know about the lack of privacy in that regard.

It may well be I'm the only one in the world who is honored so by Apple.
But that's not my point as I care about everyone's privacy. Not just mine. >>
Another question for you, Lawrence, again, because I respect your acumen.

Do you know the difference between these two situations:
a. iPhone owner happens to walk by my house & it uploads my BSSID/GPS?
b. Android owner happens to walk by my house & it uploads my BSSID/GPS?

What happens then?
Do you know?

I do.
Anyone who can't answer those queries, can't possibly understand the issue.

Do you have any intention of letting anyone else know what the issue is?

There is no issue. This person is a known Apple Troll whose only goal in life is to "make Apple look bad".

In today's episode, he is convinced that the SSID on a router can track you. So if you sell your old router AND the person who bought it does not change
the SSID, he thinks that proves that you have moved and now live at the
current address where the router is.

Of COURSE, the person who bought it is going to change the SSID. Or may even keep the factory default because OF COURSE you are going to reset the router
to factory defaults when you sell it. AND what if you setup your NEW router with the same SSID that you had on the old one? What happens now? Do I now live in 2 places at once?

Either way, there is No Problem.

And what if I change the SSID of my router weekly? Have 4 different people come thru my address each month?

This whole thing is beyond absurd AND is typical of the BS this troll posts. Apple did not change ANYTHING "at his request". Apple only removed his SSID from their DB to get him to STFU and go away.

He will reply with more gibberish and hand waving, claiming I don't understand "the issue". That is his standard M.O.

The last time I replied to a topic this moron started, he was asking "What music playing apps do you use on iOS/iPadOS that are (1) free and (2) continue to play when the screen shuts off". He did not even know that the included music playing app on iOS/iPadOS does both AND he did not even know what it was called. Not to mention that click-wheel iPods from 2005 were doing this also.


In short, he knows NOTHING about Apple, iOS, iPhones or anything else even vaguely related to Apple. Look at his previous "PSA" on how to transfer files from Windows to an iPad. He jumps thru multiple hoops by installing software
on both the Windows PC and the iPad. He does not know that the INCLUDED Files App on iOS/iPadOS can connect to Windows PCs. And Macs and Linux. And can transfer files in both directions.

Again, all in his goal of making Apple "look bad". But he so fucking stupid that he does not realize that it is only himself who looks bad.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Chris wrote:

Maria Sophia <mariasophia@comprehension.com> wrote:

This is an update to the WPS scripts that I posted a few months ago.

I was wondering how you got on with your "experiment" only the other day.

You said you had installed two routers in friends' houses downtown, move
them around and then track the movement in the database.

I'd like to see the results. How often did you move them, how far, and were the details tracked in the "apple database"?

Hi Chris,

Thanks for remembering that I ran a 3-router experiment early in the year.

That experiment was run in the first month of the year, which was before
Apple changed their documentation saying that they will track us forever.
<https://support.apple.com/en-ie/102515>

Those BSSIDs are now in Apple's WPS database, so the experiment worked.
Now, anywhere in the world I move those routers, anyone can track them.

Instantly.
Down to a meter or so resolution.
With no controls whatsoever.

Think about that.
What if I were hiding from an ex-wife or disgruntled Apple poster?

Anyone on the planet can track my router location from anywhere in the
world down to meter-like accuracy, and I simply cannot stop them.

The only thing I can do, once my BSSID is in Apple's WPS database, is throw that router over the next bridge because I can't change the BSSID on it.

I can be tracked forever, if my location is associated with that router.

Just like the research paper said it would be.
I simply reproduced exactly what the research paper said was possible.

Worse, I proved hiding the BSSID broadcast was a catch-22 situation.
a. It kept the BSSID out of Google/Mozilla hands (they're well behaved)
b. Yet, it's permanently in the Apple WPS database

Which do you pick to be in, given you can't solve both issues at once?

HINT: Apple's WPS database has no protection whatsoever, as proved by:
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

My research *started* with that paper, and took it to the next level.
--
Of the million things to know about privacy, most people only know 3.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Nick Charles wrote:

In short, he knows NOTHING about Apple, iOS, iPhones or anything else

Heh heh heh...

While I realize Apple religious zealots will attack people personally
because they defend the mothership to the death, no matter what, without
ever even understand the issue at hand, what matters for this thread, is we discussed this at length on Apple ngs using the *old* Apple documentation.

We reproduced the work of researchers from Levin & Rye in this paper
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

We posted the python scripts.
And we chose a location in Louisiana to track router movements by BSSID.
And we listed the results, by BSSID, GPS and home address.
We quite easily found the registered owners of each of those residences.

Do you remember that?
I do.

We proved that everything said in the paper above was correct, down to the
very fact that Apple let lil'ole'me collect tens of thousands of
identifying pairs of BSSID's and GPS locations (which map to addresses).

We proved, even at that time, months ago, that anyone could track the
movements of that BSSID forever, from anywhere in the world, to anywhere
else in the world, without any protection whatsoever by Apple.

This is what the paper said would be the case.
And it was.

What's *different* is the paper did not cover hidden broadcast BSSIDs.
I did.

That's the test which Chris is talking about, and which Apple knows about.
a. Apple _removed_ my BSSIDs _after_ I told them about this.
b. And Apple _changed_ the documentation, _after_ I told them about this.

That's pretty good for someone whom the Apple trolls claims "knows NOTHING about Apple", especially since I proved every single claim that I had made.
--
Of the million things we need to know about privacy, most people know 3.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Anton Shepelev wrote:

Your car broadcasts its license plate number to anyone in
sight of it, yet people are rightfully ticked off at Flock
cameras everywhere recording them.

Because machine data acquirement is more powerful.

The flock camera analogy only works if anyone in the world can access it.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

While I understand the analogies being presented, and certainly I
understand the purpose is to claim "no big deal" as a result, I must beg to differ because the analogies, while reasonable, fall flat on some regards.

What if, for example, the government allowed you to put a black cloth over
your license plate, and that is a clear indication that you don't want it
to be recorded by Flock cameras (& by extension, your movements recorded).

What if Google cameras respected that black cloth as did Mozilla cameras.
But what if Apple cameras refused to respect that common leave-me-alone
black cloth?

Think about that.
What if *only* Apple cameras lifted up that black cloth, on purpose.
So that they could get your unique vehicle VIN that tracks you everywhere.

Pretty bad, huh?
But wait... it gets worse.

What if the Google camera, if it happens to get your license plate, which
is tied to your unique VIN, but the Google camera sees *another* indicator
that you do not want them to put that license plate into their database.

Let's say that's a sticker, on the plate, that says, oh, let's say _nomap.

What does Apple do?
Versus what Google and Mozilla do?

But wait, if that's not bad enough, there's still more. A lot more in fact.

What if anyone in the world could look up that license plate & related VIN
from anywhere in the world, and there are absolutely no controls on that?

What?

Do you see the difference?

Allow me to provide an example:
a. Let's say my ex-wife is in Germany, back in the home country
b. But, she wants to track my vehicle everywhere I go
c. As described in the aforementioned research paper, she can.

It's no different than you choosing the license plate of your ex-wife (or whomever) and tracking them anywhere in the world, with no controls on
that.

Do you see why understanding the problem set makes the flock camera issue
only superficially an analogy.

The flock camera could only be an analogy if anyone in the world could
track your movements down to a meter resolution, with no controls on that.
--
What people need to know about privacy is complex, so they simplify it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-05, Maria Sophia <mariasophia@comprehension.com> wrote:

Jon Ribbens wrote:

Anyone who can't answer those queries, can't possibly understand the
issue.

Do you have any intention of letting anyone else know what the issue
is?

Hi Jon,

Lil' ole' me can easily track a BSSID anywhere in the world, down to a
meter or so accuracy, if I want to under the common circumstances which
I've outlined in this thread (and in others).

Ok. I think BSSID means "MAC address of the WiFi access point".
I don't know what circumstances you can track them, and you don't
seem to have said in this thread.

I move my router around a lot, and I don't want just anyone being able
to track all my movements down to a meter accuracy when I do that. Do
you?

I suppose if someone had reason to target me specifically, and they had
a real-time way of tracking BSSIDs, and for some reason I can't imagine
I was taking a WiFi access point with me, I... oh, wait. In that
circumstance I would not take a WiFi access point with me, for the
same reason I wouldn't have my mobile phone radio enabled, or would not
have a mobile phone with me at all, depending on the threat model.

You were correct in your prior post to Carlos, when you said (verbatim):
"I got the impression they were claiming that their SSID was hidden,
which makes it irrelevant as to whether it has "_nomap" at the end
of it, but that Apple had somehow discovered and logged it nonetheless.
It seems highly implausible."

But, of course, there's more detail (which I provided in my responses).

I saw no response from you to that post. But from what you're saying
in the post I'm replying to now, I wasn't correct - I now think you're
saying that Apple store the BSSIDs of access points of WiFi networks
with hidden SSIDs, because they *don't* know the SSID and therefore
can't tell if it has "_nomap" appended, and so don't exclude it.

I'm not sure what I think about that, and I don't know what any of the
other companies that map SSIDs do in the same situation. I'm not sure
why Apple would store location data of BSSIDs with no visible SSID -
it doesn't seem like it would help the geolocation feature much, since
hiding the SSID is pretty rare.

I explained it in gory detail, and even provided a link to the research.
I provided some of the python scripts too (although they're not the point).

You haven't done any of that in this thread so far as I can see.

We've discussed this ad infinitum on the Apple & Android & Windows ngs in
the past, although I don't remember how much we brought in Python folks.

What's *new* is Apple told me in my email that there was no way to
have WPS privacy from Google/Mozilla if I wished to have WPS privacy
from Apple.

Sorry, what does WPS have to do with it? And why is it a binary option?
A non-hidden SSID with "_nomap" would presumably provide privacy from
all those companies? Or do some of them not support that? Or is having
a non-hidden SSID not acceptable to you? If so, what are the options
for privacy you are referring to?

It's a catch-22 situation.
Which would you pick?

I mean I literally do pick a non-hidden SSID without "_nomap" on it,
that I've kept constant for decades. I've never even seen a SSID with
"_nomap" on it. There is no-one I regard as a threat, let alone someone
who would be a threat and who would know my SSID let alone my BSSIDs.

HINT: If we read the research paper, it's a no brainer which one to pick.

What research paper?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia <mariasophia@comprehension.com> writes:
[...]

Heh heh heh...

While I realize Apple religious zealots will attack people personally

[SNIP]

Can you please restrict this to newsgroups where it's relevant?

In particularly, there's in this thread nothing about Python or
Windows 10.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On Sat, 5 Sep 2026 06:15:55 +0600, Maria Sophia wrote:

Do you know the difference between these two situations:
a. iPhone owner happens to walk by my house & it uploads my BSSID/GPS?
b. Android owner happens to walk by my house & it uploads my BSSID/GPS?

If there is any difference, it would not be wise to rely on it.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

Maria Sophia <mariasophia@comprehension.com> wrote:

This is an update to the WPS scripts that I posted a few months ago.

I was wondering how you got on with your "experiment" only the other day. >>
You said you had installed two routers in friends' houses downtown, move
them around and then track the movement in the database.

I'd like to see the results. How often did you move them, how far, and were >> the details tracked in the "apple database"?

Hi Chris,

Thanks for remembering that I ran a 3-router experiment early in the year.

That experiment was run in the first month of the year, which was before Apple changed their documentation saying that they will track us forever.
<https://support.apple.com/en-ie/102515>

Those BSSIDs are now in Apple's WPS database, so the experiment worked.

That wasn't the experiment.

Now, anywhere in the world I move those routers, anyone can track them.

That's not answering my question. Did you move them and what did you see? Remember your claim was that you could track people from California to
Florida using only their router.

Instantly.

Evidence?

Down to a meter or so resolution.
With no controls whatsoever.

What did you test?

Think about that.
What if I were hiding from an ex-wife or disgruntled Apple poster?

Just get a different router.

Anyone on the planet can track my router location from anywhere in the
world down to meter-like accuracy, and I simply cannot stop them.

No-one knows which, of the billions of entries in the databases, is *your* router. No big deal.

The only thing I can do, once my BSSID is in Apple's WPS database, is throw that router over the next bridge because I can't change the BSSID on it.

I can be tracked forever, if my location is associated with that router.

Just like the research paper said it would be.
I simply reproduced exactly what the research paper said was possible.

Worse, I proved hiding the BSSID broadcast was a catch-22 situation.
a. It kept the BSSID out of Google/Mozilla hands (they're well behaved)
b. Yet, it's permanently in the Apple WPS database

Which do you pick to be in, given you can't solve both issues at once?

HINT: Apple's WPS database has no protection whatsoever, as proved by:
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

My research *started* with that paper, and took it to the next level.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia wrote:

Anyone on the planet can track my router location from anywhere in the
world down to meter-like accuracy, and I simply cannot stop them.

The only thing I can do, once my BSSID is in Apple's WPS database, is throw that router over the next bridge because I can't change the BSSID on it.

I can be tracked forever, if my location is associated with that router.

I don't remember whether you addressed this ... how does someone who
hasn't visited your address (i.e they already know where you live)
discover what the BSSID of your router is?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Andy Burns <usenet@andyburns.uk> wrote:

Maria Sophia wrote:

Anyone on the planet can track my router location from anywhere in the
world down to meter-like accuracy, and I simply cannot stop them.

The only thing I can do, once my BSSID is in Apple's WPS database, is throw >> that router over the next bridge because I can't change the BSSID on it.

I can be tracked forever, if my location is associated with that router.

I don't remember whether you addressed this ... how does someone who
hasn't visited your address (i.e they already know where you live)
discover what the BSSID of your router is?

Apparently it's a complete invasion of privacy in the same way google maps having actual pictures of his house and the phone book having his name,
address *and* phone number isn't.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Jon Ribbens wrote:

Lil' ole' me can easily track a BSSID anywhere in the world, down to a
meter or so accuracy, if I want to under the common circumstances which
I've outlined in this thread (and in others).

Ok. I think BSSID means "MAC address of the WiFi access point".
I don't know what circumstances you can track them, and you don't
seem to have said in this thread.

Hi Jon,

Thanks for your questions as it shows you're trying to understand this.

Your questions are all good questions, from someone who is encountering
this issue for the first time in their lives, but let's be clear that an
entire course in networking for privacy is beyond my personal skill sets.

If you don't know what a BSSID is by now then it will take too much work
here to explain it "fully" to you. Suffice to say it's like a vehicle identification number on a car. It goes everywhere the router goes.

Every access point has a unique BSSID that stays with the router forever.

(Yes, I know in extremely expensive routers, not home routers, that the
BSSID can be changed, and yes, I know, in those extremely rare situations,
the BSSID may actually not be unique, but only one out of a million people
know those facts, so suffice to say for this thread the BSSID is unique).

The Apple trolls absurdly claimed that changing the SSID changes the BSSID,
but the fact remains the BSSID remains the same no matter what the SSID is.

I move my router around a lot, and I don't want just anyone being able
to track all my movements down to a meter accuracy when I do that. Do
you?

I suppose if someone had reason to target me specifically, and they had
a real-time way of tracking BSSIDs, and for some reason I can't imagine
I was taking a WiFi access point with me, I... oh, wait. In that
circumstance I would not take a WiFi access point with me, for the
same reason I wouldn't have my mobile phone radio enabled, or would not
have a mobile phone with me at all, depending on the threat model.

Read the paper which we referenced multiple times in this thread so that I don't have to re-hash over and over again how mass surveillance is possible with the Apple WPS database design.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Anyone who can run a python script (which I will provide to them upon
request) can track anyone in the world who moves from one place to another
(and who happens to take their router with them to their new location).

Nobody disputes that fact, which is what the paper itself explained.
I simply reproduced their "billions of BSSID/GPS pairs" with thousands.

It doesn't bother you that I can track the movements of billions of people
if they happen to move from one locale to another using the same router?

You think this tracking isn't happenging asa we speak?
You think Apple is doing something about it?

That's 1/2 the point of this thread.
1. Apple is doing NOTHING about it (as described in the paper)
2. So anyone in the world can track the movements of billions of routers
2. Worse, Apple isn't honoring the established meaning of the hidden
broadcast (which even Google honors, by way of stark contrast).

So much for Apple "cares about your privacy" bullshit, huh?
It's shocking that google cares about privacy more than Apple does.

You were correct in your prior post to Carlos, when you said (verbatim):
"I got the impression they were claiming that their SSID was hidden,
which makes it irrelevant as to whether it has "_nomap" at the end
of it, but that Apple had somehow discovered and logged it nonetheless. >> It seems highly implausible."

But, of course, there's more detail (which I provided in my responses).

I saw no response from you to that post. But from what you're saying
in the post I'm replying to now, I wasn't correct - I now think you're
saying that Apple store the BSSIDs of access points of WiFi networks
with hidden SSIDs, because they *don't* know the SSID and therefore
can't tell if it has "_nomap" appended, and so don't exclude it.

There are two fundamental issues, only one of which is in this paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

I've summarized what's in that paper likely a half dozen times in this
thread, and I've added a second issue that is not discussed in that paper.

I've talked that second issue over with security professionals like Brain
Krebs and Daniel Veditz, so there is no doubt of the veracity of my claims.

To summarize complex issues in a few simple sentences, they might be:
1. Apple allows anyone on the world to track the movements of everyone
in the world (if they take their router with them when they move).
2. Apple puts zero controls on that tracking by anyone, of everyone.
3. In addition, Apple does not respect the known meaning of a hidden
broadcast, and worse, Apple *refuses* to honor what even Google does.
4. Anyone can prove these statements are true on a Windows PC running
Python using the scripts I have provided for that express purpose.

I'm not sure what I think about that, and I don't know what any of the
other companies that map SSIDs do in the same situation. I'm not sure
why Apple would store location data of BSSIDs with no visible SSID -
it doesn't seem like it would help the geolocation feature much, since
hiding the SSID is pretty rare.

Remember the Apple trolls posted to this thread that changing the SSID
would solve the issue, but the main issue is about the BSSID, not the SSID.
a. The BSSId is unique (see above for rare exceptions).
b. The GPS location is also unique
c. The SSID only plays a role tangentially, and as such is a minor player

Assume, for an analogous purpose that a flock camera allowed anyone in the world to track everyone in the world, not only by the license plate (which
can be changed) but by the VIN number, which cannot be changed.

Then assume Flock knows this, but refuses to add any security whatsoever.
a. Worse, assume all the other camera outfits DO add security.
b. Not only that, the other camera outfits add lookup protection.

That's a decent analogy of what's going on that is more easily understood.

I explained it in gory detail, and even provided a link to the research.
I provided some of the python scripts too (although they're not the point).

You haven't done any of that in this thread so far as I can see.

Did you read the paper?
What does that paper say?

Do you know what a hidden broadcast SSID is?
What is the purpose of a hidden broadcast in your opinion?

I've explained both perhaps a half dozen times in this thread.
Explaining another half dozen times won't help until you do the above.

It's unfair of you to claim I haven't provided you an entire courese in
basic networking, when you didn't even click on the links we provided.

We've discussed this ad infinitum on the Apple & Android & Windows ngs in
the past, although I don't remember how much we brought in Python folks.

What's *new* is Apple told me in my email that there was no way to
have WPS privacy from Google/Mozilla if I wished to have WPS privacy
from Apple.

Sorry, what does WPS have to do with it? And why is it a binary option?
A non-hidden SSID with "_nomap" would presumably provide privacy from
all those companies? Or do some of them not support that? Or is having
a non-hidden SSID not acceptable to you? If so, what are the options
for privacy you are referring to?

Wrong WPS.
Read the paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

It's a catch-22 situation.
Which would you pick?

I mean I literally do pick a non-hidden SSID without "_nomap" on it,
that I've kept constant for decades. I've never even seen a SSID with "_nomap" on it. There is no-one I regard as a threat, let alone someone
who would be a threat and who would know my SSID let alone my BSSIDs.

What you need to think about is what the paper explains about the SSID.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Then, you need to consider what happens when that SSID broadcast is hidden.

Only one out of a million people (or so) has thought about those two things (but it goes further since now you need to consider what Google/Apple do).

Google does one thing (which, surprisingly, is the right thing to do).
Apple does the opposite (and, not surprisingly, refuses to change it).

If you don't follow the trail from your router to some guy in Russia who is tracking the movements of everyone in the world, you can't understand it.

Read the paper (which explains half the issues brought up here).
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

HINT: If we read the research paper, it's a no brainer which one to pick.

What research paper?

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>
--
Most people can only parrot what clever marketing told them to believe.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Keith Thompson wrote:

In particularly, there's in this thread nothing about Python or
Windows 10.

The code supplied for you to run is Python which ran on Windows 10.
I know this because I got help in the code from Windows/Python ngs.

So, together, the Windows & Python newsgroup honed the working code.
Do you need me to supply the code for you again so you can run it?

One script will arbitrarily choose a BSSID, and then scrape the Apple WPS database for that BSSID, and change it until it gets a hit (takes seconds).

Once we have a BSSID in the Apple WPS database, another python script runs periodically to ring a bell when that BSSID moves more than 100 meters.

We proved that earlier this year by moving the three old Linksys routers
from one section of town to another to simulate people moving from one apartment to another (where it could track them anywhere in the world).

In addition, another python script run from Windows 10 exactly reproduced
the findings of the research paper, only for thousands of BSSID's, not
billions (which I simply do not have the time or patience to gather).
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

The fact every BSSID/GPS pair can be obtained by anyone at any time with
zero restrictions can be proven by anyone who runs that python code.

If that doesn't bother you, then start thinking about what we proved by
running the same Python code on Windows 10 to show the hidden broadcast
BSSIDs not only show up in the unprotected Apple WPS database, but Apple refuses to solve that privacy problem (which even Google will honor).

When I discussed this with the Apple Maps' executive, the answer came back, literally from Apple lawyers, was that they'll change the documentation.

And they did.
<https://support.apple.com/en-ie/102515>
--
Anyone with a Windows 10 computer & Python can reproduce all of the above.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lawrence DoOliveiro wrote:

Do you know the difference between these two situations:
a. iPhone owner happens to walk by my house & it uploads my BSSID/GPS?
b. Android owner happens to walk by my house & it uploads my BSSID/GPS?

If there is any difference, it would not be wise to rely on it.

There is a *huge* difference, Lawrence.

For half of that huge difference, all you need to do is read this paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

For the other half of that huge difference, all you need to read is this.
<https://ichnaea.readthedocs.io/en/stable/api/geosubmit2.html>
"The BSSID of the Wifi network. Hidden Wifi networks
must not be collected."

Then, read how much Apple "cares about your privacy" by reading this!
<https://support.apple.com/en-ie/102515>

For contrast, read this:
<https://wiki.mozilla.org/CloudServices/Location/FAQ>
<https://wiki.mozilla.org/WIFI>

HINT:
Mozilla/MLS would not collect data from Wi-Fi networks with hidden SSIDs. <https://bugzilla.mozilla.org/show_bug.cgi?id=1177952>

Daniel Veditz confirmed that Mozilla MLS, like Google WPS, does not even *collect* the BSSID/GPS pair for hidden-broadcast SSIDs.

Notice the difference between 'collect', 'save on device" and 'upload' to servers, because collecting means it can't be uploaded and hence not saved
into a global database for everyone in the world to easily track the router movements from anywhere in the world to anywhere else in the world, in
almost real time with meter-like accuracy with no restrictions at all.

Most people don't understand a word I'm saying above, so I need to be clear that "collecting" is different from "uploading" which itself is different
from "saving" which itself is different from "allowing anyone in the entire world to access the unique BSSID/SSID pair" sans restrictions.

If you think through the fate of the two situations I keep presenting to
you, you'll see where they diverge in such a way as to be shockingly scary.

With the Python scripts we worked on in December of last year, even I can
track any router's movements in the world, with zero restrictions.

Want to test it?
Give me your router AP BSSID in your own home.

I'll tell you where you live.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Chris wrote:

What if I were hiding from an ex-wife or disgruntled Apple poster?

Just get a different router.

Chris,

I realize your only goal is to defend Apple's honor to the death, no matter what, but I only needed to prove two things, both of which are now obvious.

1. Apple's WPS database can be used by anyone in the world to track the
location of a router AP (by BSSID/GPS) without any restrictions.

2. Apple's refuses to honor the documented intent of a hidden-broadcast.

The fact you're desperate to dispute those facts in order to protect the
honor of your religious God is evident in the fact that the researchers
proved the first point, and Apple's *new* documentation proves the second.

Three simple questions for you, Chris:

Q1: What do you dispute about point #1 above, after reading this paper?
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Q2: What do you dispute about point #2 above, after reading this new link?
<https://support.apple.com/en-ie/102515>

Only a religious zealot could possibly deny the veracity of those 2 facts.

Want to know what my third question asked of you is, Chris:

Q3: Would you kindly give me the BSSID of your home router AP please?

When/if you do so, not only will I provide the exact location of that
router (to the resolution of GPS) but I can track its movement, forever.

With no restrictions on that tracking (see point #1 above, for proof).
--
Everyone disputing this is doing so only on their religious belief system.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-05, Maria Sophia <mariasophia@comprehension.com> wrote:

Jon Ribbens wrote:

Lil' ole' me can easily track a BSSID anywhere in the world, down to a
meter or so accuracy, if I want to under the common circumstances which
I've outlined in this thread (and in others).

Ok. I think BSSID means "MAC address of the WiFi access point".
I don't know what circumstances you can track them, and you don't
seem to have said in this thread.

Hi Jon,

Thanks for your questions as it shows you're trying to understand this.

Your questions are all good questions, from someone who is encountering
this issue for the first time in their lives, but let's be clear that an entire course in networking for privacy is beyond my personal skill sets.

If you don't know what a BSSID is by now then it will take too much work
here to explain it "fully" to you. Suffice to say it's like a vehicle identification number on a car. It goes everywhere the router goes.

Well, yes, it's the MAC address, like I already said.

I suppose if someone had reason to target me specifically, and they had
a real-time way of tracking BSSIDs, and for some reason I can't imagine
I was taking a WiFi access point with me, I... oh, wait. In that
circumstance I would not take a WiFi access point with me, for the
same reason I wouldn't have my mobile phone radio enabled, or would not
have a mobile phone with me at all, depending on the threat model.

Read the paper which we referenced multiple times in this thread so that I don't have to re-hash over and over again how mass surveillance is possible with the Apple WPS database design.

You hadn't referenced it at the time I wrote my post, or at least
by the time you wrote the post I was responding to.

It mostly seems to be an attack against people who don't realise
they are targets, or are not thinking about the implications - c.f.
soldiers who upload their daily runs to public web sites thus
revealing if/where they are deployed.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems* <https://arxiv.org/abs/2405.14975>

Anyone who can run a python script (which I will provide to them upon request) can track anyone in the world who moves from one place to another (and who happens to take their router with them to their new location).

Nobody disputes that fact, which is what the paper itself explained.
I simply reproduced their "billions of BSSID/GPS pairs" with thousands.

It doesn't bother you that I can track the movements of billions of people
if they happen to move from one locale to another using the same router?

As I say that's a pretty unusual thing to do (travelling with a router). Google's API does seem more sensible though (give it MAC addresses, it
tells you where you probably are, rather than giving you the recorded individual locations of all those MAC addresses).

You think this tracking isn't happenging asa we speak?
You think Apple is doing something about it?

That's 1/2 the point of this thread.
1. Apple is doing NOTHING about it (as described in the paper)

Have you, er, read the paper? It says Apple *is* doing things about it
(page 14, section 10 paragraph 3).

2. So anyone in the world can track the movements of billions of routers
2. Worse, Apple isn't honoring the established meaning of the hidden
broadcast (which even Google honors, by way of stark contrast).

This is the bit I keep asking about and you keep not responding.
Is your actual/main complaint that Apple is storing BSSIDs that
correspond to hidden SSIDs? And you're saying only Apple do this,
not Google etc?

So much for Apple "cares about your privacy" bullshit, huh?
It's shocking that google cares about privacy more than Apple does.

Apple cares about the privacy of *its customers*.

There are two fundamental issues, only one of which is in this paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems* <https://arxiv.org/abs/2405.14975>

I've summarized what's in that paper likely a half dozen times in this thread, and I've added a second issue that is not discussed in that paper.

I've talked that second issue over with security professionals like Brain Krebs and Daniel Veditz, so there is no doubt of the veracity of my claims.

To summarize complex issues in a few simple sentences, they might be:
1. Apple allows anyone on the world to track the movements of everyone
in the world (if they take their router with them when they move).
2. Apple puts zero controls on that tracking by anyone, of everyone.

I imagine the issue here is that if they change their API then older
devices that are no longer receiving updates will stop being able to do wifi-positioning.

3. In addition, Apple does not respect the known meaning of a hidden
broadcast, and worse, Apple *refuses* to honor what even Google does.
4. Anyone can prove these statements are true on a Windows PC running
Python using the scripts I have provided for that express purpose.

I'm not sure what I think about that, and I don't know what any of the
other companies that map SSIDs do in the same situation. I'm not sure
why Apple would store location data of BSSIDs with no visible SSID -
it doesn't seem like it would help the geolocation feature much, since
hiding the SSID is pretty rare.

Remember the Apple trolls posted to this thread that changing the SSID
would solve the issue, but the main issue is about the BSSID, not the SSID.
a. The BSSId is unique (see above for rare exceptions).
b. The GPS location is also unique
c. The SSID only plays a role tangentially, and as such is a minor player

The "Apple trolls" are presumably correct inasmuch as if you change the
SSID to end in "_nomap" then it solves the issue.

I explained it in gory detail, and even provided a link to the research. >>> I provided some of the python scripts too (although they're not the
point).

You haven't done any of that in this thread so far as I can see.

Did you read the paper?
What does that paper say?

You hadn't linked the paper at the time I wrote my post.
The paper doesn't quite say what you're claiming, I think,
although I see your general point (or at least, the paper's
authors' general point).

Do you know what a hidden broadcast SSID is?
What is the purpose of a hidden broadcast in your opinion?

To waste power in client devices, as far as I can see, since it
means they have to be constantly pinging for the network rather
than just connecting to it when they see the SSID broadcast.

So in some senses it makes the user tracking problem *much worse*,
since it means the attacker can hang around public places watching
for client devices (which, unlike access points, tend to move around
with the user) that are pinging for the attack target's hidden SSID.

Hang around a diner near Langley, Virginia, watching for people
carrying devices pinging the hidden SSID "CIA UNCLASSIFIED"...

I've explained both perhaps a half dozen times in this thread.
Explaining another half dozen times won't help until you do the above.

I'm starting to think that by "this thread" you don't mean "the set
of Usenet articles referenced in the References headers" and are
including other historic threads...

Google does one thing (which, surprisingly, is the right thing to do).
Apple does the opposite (and, not surprisingly, refuses to change it).

I think you are still failing to explain what those two things are,
and I'm getting tired of guessing. If you are claiming the paper
describes this difference, please say where. If it doesn't, please
just say what it is.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia wrote:

Chris wrote:

What if I were hiding from an ex-wife or disgruntled Apple poster?

Just get a different router.

Chris,

I realize your only goal is to defend Apple's honor to the death, no matter what, but I only needed to prove two things, both of which are now obvious.

1. Apple's WPS database can be used by anyone in the world to track the
location of a router AP (by BSSID/GPS) without any restrictions.

This is the same as:

5e) A few maggots are going at it eating an apple, and nearby there
is a pumpkin in the field.



I felt that since everyone was throwing analogies out there I'd try my
hand too.

There's only so far analogies can take you when you actually believe
they are the same without a shred of proof.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Chris wrote:

I don't remember whether you addressed this ... how does someone who
hasn't visited your address (i.e they already know where you live)
discover what the BSSID of your router is?

Apparently it's a complete invasion of privacy in the same way google maps having actual pictures of his house and the phone book having his name, address *and* phone number isn't.

Hi Andy and Chris,

I'm going to give you an example of how absurd your attempt at ridiculing
the documented situation is, using your own analogies, by way of impact.

Your questions are good ones, but it's getting tiresome to answer them over
and over and over and over and over and over again, so please think first.

The question is the wrong question, as it's kind of like asking what's so dangerous about everyone in the world having your social security number.

You're essentially ridiculing privacy because, to you, a social security
number issued to you by the gov'ment, well, it's "just a number" after all.

One third of your argument ridiculing privacy is that you argue your government-issued ID unique to you should be available to everyone.

To you, it's just a number.
It's not you.

It's just a number: 123.45.6789
How dangerous can a simple number be to your privacy, you argue.

That's the 1st third of your argument, attempting to ridicule privacy in
your desperate attempt to absolve your religious God of any responsibility.

By ridiculing the fact that a social security number is "just a number",
you also forget that in this case, that number is associated with your
exact GPS location (within the accuracy known for GPS, which is meters).

Even that doesn't change your opinion that a social security number, tied
to an exact GPS location, is "just a number" and "just a location on a
map".

So that's the 2nd third of your argument, which is that your location is
"just a map" and everyone in the world should be able to easily locate you.

You go further to ridicule that having a social security number and a GPS location of where the person who owns that social security number is "just
a number and a map", you then try to ridicule the fact that anyone in the
world can access your social security number and where you are, from
anywhere else in the world.

That's the 3rd third of your argument attempting to absolve Apple of all responsibility for the design of the Apple WPS system as described here.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Did you read that paper?
Of course not.

Otherwise, you couldn't make your absurd accusations that a unique
government id tied to you, along with your exact location, is "just a
number" and "just a map".

To further show the absurdity of your attempt at ridiculing this issue, not only can anyone in the world track your movements by social security number
and by location, but they can track EVERYONE in the world by their social security number (or whatever unique government ID) by running a python
script on Windows 10 (assuming, I think we calculated, 2GB of storage).

That's the reason the paper says "mass surveillance".
You missed that point.

Why did you miss that point?
Because you didn't even click on the link.

You ridiculed that paper.
Without even reading it.

Wait, there's more.

In your attempt to ridicule the fact that anyone in the world can track everyone in the world using a simple Windows 10 PC and a Python script
which we worked on together late last year, but now you're trying to
ridicule the fact that there are absolutely no restrictions on that lookup.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

But wait. There's more.

Not only are there no restrictions on the lookup of your government ID
number to your GPS location, but it collects the governemtn ID number and
the GPS locations of the closes 400 people to your location at any given
time.

Yes. Not one. Not two. Not ten. Not 100. But 400 of the closest people.

Now anyone in the world can track your exact location by your government ID without any restrictions, and, they can track the next 400 closest
government IDs and locations, forever, again, with no restrictions.

Oh, there's more. Much more.

What if you do NOT want someone to even collect your government ID and
location and that of the next 400 closest governmetn Id's and locations?

What then?

What if, oh, say, you put black tape over your government ID.
What if you do that?

<https://ichnaea.readthedocs.io/en/stable/api/geosubmit2.html>
"Hidden Wifi networks must not be collected."

Will Google honor that black tape? Yes.
Will Mozilla location services honor that black tape? Yes.

Will Apple?

When I started this Windows10/Python testing in December, we did not know
the answer to that question, officially (as I knew the answer instantly).

Why did I know the answer instantly?
Because I ran the Python code on Windows 10.

I was shocked by what I found.
But I didn't know the "official" answer from Apple until I presented my
next door neighbor with the results, and he filed the RARAR bug report.

The answer came back, so now we know the official answer.
<https://support.apple.com/en-ie/102515>

In summary, until people show an understanding of the problem set, they
should hold off in their attempted ridicule that your unique government identification number is "just a number" and your unique GPS location at
any given time is "just a map".
--
Most people can't process even simple things that they do not understand.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lane W wrote:

1. Apple's WPS database can be used by anyone in the world to track the
location of a router AP (by BSSID/GPS) without any restrictions.

This is the same as:

5e) A few maggots are going at it eating an apple, and nearby there
is a pumpkin in the field.

While I get your attempt to ridicule all that you can't comprehend, and I
can tell you haven't clicked on a single reference provided in this thread,
all I want to ask you, to prove the absurdity of your ignorance, is this:

*Give me your home router AP BSSID.*

I will return, to you, in seconds, not only the location of your router,
but I will give you the next 400 nearest router AP locations to you.

Then, after that, I can track not only everywhere you take that router, forever, sans any restrictions, but those of your next 400 neighbors.

Take me up on that before you try to ridicule what you don't comprehend.

Q: What is your home router AP BSSID please?
A: ?
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia wrote:

Lane W wrote:

1. Apple's WPS database can be used by anyone in the world to track the
location of a router AP (by BSSID/GPS) without any restrictions.

This is the same as:

5e) A few maggots are going at it eating an apple, and nearby there
is a pumpkin in the field.

While I get your attempt to ridicule all that you can't comprehend, and I
can tell you haven't clicked on a single reference provided in this thread, all I want to ask you, to prove the absurdity of your ignorance, is this:

*Give me your home router AP BSSID.*

I will return, to you, in seconds, not only the location of your router,
but I will give you the next 400 nearest router AP locations to you.

Then, after that, I can track not only everywhere you take that router, forever, sans any restrictions, but those of your next 400 neighbors.

Take me up on that before you try to ridicule what you don't comprehend.

Q: What is your home router AP BSSID please?
A: ?

I'm homeless and don't have a home router, so there's something further
for you to laugh at me about.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Jon Ribbens wrote:

If you don't know what a BSSID is by now then it will take too much work
here to explain it "fully" to you. Suffice to say it's like a vehicle
identification number on a car. It goes everywhere the router goes.

Well, yes, it's the MAC address, like I already said.

Hi Jon,

To your credit, you are the first person who has responded, who has shown
that he actually *read* the paper before trying to respond intelligently.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

That's good.
Nobody else even bothered to click on the link, before responding.

Hence, everyone else simply parroted their stone-age knowledge level.
You, at least, did *read* the paper, which I congratulate you for doing.

But you did not *understand* what the paper said by the BSSID.
See below where you completely whooshed on which BSSID is what matters.

I must be careful here not to fault you like I fault the Apple trolls,
because I think you are sincerely trying to understand the problem set.

So I simply caution you, as I did Lawrence & Andy, all of whom I respect
for acumen, that you have to follow the trail of the *router* AP BSSID.

You can not "randomize the BSSID" of the router AP (except in the most expensive commercial routers, which are not the topic of this thread).

Think very deeply about that simple fact before responding, as the crux of
the problem is no different than a governmment-issued identification
number.

You can't easily change your unique government-issued ID number just as you can't easily change the router-issued BSSID of your home router AP.

Think about that the same way the paper presented the mass surveillance.
1. I wrote a Python script that ran on Windows 10 that guessed at a set
of random government-issued identification numbers, e.g., 123.45.6789
2. Within minutes, I had a hit on a random government ID, which came
back with a GPS location and 400 nearby government IDs and locations.
3. Then, I ran another Python script on Windows 10 that extended that,
taking the furthest-away governemtn ID/location pair, and did it again.
4. Within an hour, I had thousands of government IDs and locations.
(the researchers gathered billions, as I recall, but I stopped there.)

Now that I have every government-issued ID and GPS location in the world in
my 2TB database (which we calculated would be the size it would have been), what is the paper saying about "mass surveillance" possibilities?

HINT: I can track the future location of every one of those billions of government ID/GPS location pairs, without any restrictions on my scripts!

Want to prove that?
What's your home router BSSID?

I will not only tell you exactly where that router is located (I even wrote
the Python code to give me a dot on an OSM map for your location) but I can trivially easily forever track that router's location forever, without any restrictions on my part (which is the point of the paper, after all).

That's what the paper says.
I went further (i.e., to hidden broadcast issues).

But that alone is what the paper says you can do, and I proved it, and I supplied the python scripts (and will supply them to anyone who asks me).

I suppose if someone had reason to target me specifically, and they had
a real-time way of tracking BSSIDs, and for some reason I can't imagine
I was taking a WiFi access point with me, I... oh, wait. In that
circumstance I would not take a WiFi access point with me, for the
same reason I wouldn't have my mobile phone radio enabled, or would not
have a mobile phone with me at all, depending on the threat model.

Read the paper which we referenced multiple times in this thread so that I >> don't have to re-hash over and over again how mass surveillance is possible >> with the Apple WPS database design.

You hadn't referenced it at the time I wrote my post, or at least
by the time you wrote the post I was responding to.

It mostly seems to be an attack against people who don't realise
they are targets, or are not thinking about the implications - c.f.
soldiers who upload their daily runs to public web sites thus
revealing if/where they are deployed.

It's not "an attack" so much as explaining, with examples, of why we should care that mass surveillance is so easy with the Apple WPS implementation.

The soldier part is just an example.
I have a more potent example.

Give me your MAC address of your home router AP.

Not only can I instantly tell you where that reouter is, but I can tell you
the location and BSSID of the nearest 400 routers to your location.

We proved that in the Python scripts I had provided and had run on WIn10.
Test me.

Give me your BSSID.

Note: I don't expect you to do it, which alone proves the point.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Anyone who can run a python script (which I will provide to them upon
request) can track anyone in the world who moves from one place to another >> (and who happens to take their router with them to their new location).

Nobody disputes that fact, which is what the paper itself explained.
I simply reproduced their "billions of BSSID/GPS pairs" with thousands.

It doesn't bother you that I can track the movements of billions of people >> if they happen to move from one locale to another using the same router?

As I say that's a pretty unusual thing to do (travelling with a router). Google's API does seem more sensible though (give it MAC addresses, it
tells you where you probably are, rather than giving you the recorded individual locations of all those MAC addresses).

I think your claim that it's "pretty unusual" for people to take their
router with them when they move from one apartment to another is skewed.

If I ask 100 people who recently moved, do you really think it would be
only 1 or 2 people who took their home router with them when they moved?

You think this tracking isn't happenging asa we speak?
You think Apple is doing something about it?

That's 1/2 the point of this thread.
1. Apple is doing NOTHING about it (as described in the paper)

Have you, er, read the paper? It says Apple *is* doing things about it
(page 14, section 10 paragraph 3).

See my first response to you in this post, where I want to be careful to
not chastise you for misunderstanding what that paragraph actually says.

You can NOT randomize the MAC address of the router AP, Jon.

Sure, for expensive commercial routers, with thousands of access points,
they can randomize their MAC addresses, but it's not on most home routers.

To be clear, it is on some (expensive) home routers.
I am well aware of that.

But we're talking about surveilling the masses, not the people who actually know how networking works (which nobody on this thread so far has shown).

2. So anyone in the world can track the movements of billions of routers
2. Worse, Apple isn't honoring the established meaning of the hidden
broadcast (which even Google honors, by way of stark contrast).

This is the bit I keep asking about and you keep not responding.
Is your actual/main complaint that Apple is storing BSSIDs that
correspond to hidden SSIDs? And you're saying only Apple do this,
not Google etc?

First off, I don't have a complaint. That's absurd. I have facts.
This entire thread is people disputing those facts, without ever even
bothering to read the links which were provided for them to read.

The absurdity of this thread is nobody has read or understood the links
which were provided, and yet, they ask me (repeatedly) to explain them.

Why can nobody understand the point that Eric & Dave made in this paper?
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Why can nobody understand what's different about what Apple documented?
<https://support.apple.com/en-ie/102515>

Why can nobody undestqand the concept inherent in a hidden-broadcast?
<https://ichnaea.readthedocs.io/en/stable/api/geosubmit2.html>
"The BSSID of the Wifi network.
Hidden Wifi networks must not be collected."

Why is it that I feel it's trivial to understand that 1+1=2 when everyone
else is trying to claim that I need to explain why 1+2=2 when, if they
simply read (and understood) what I've explained, they would understand?

Can *nobody* actually read those references except me, and understand them?

So much for Apple "cares about your privacy" bullshit, huh?
It's shocking that google cares about privacy more than Apple does.

Apple cares about the privacy of *its customers*.

I realize you're trying to understand these concepts so I have to be
careful when I point out that this affects every single person in the world
who owns a router (and company, but let's restrict this to just people).

The issues are exactly the same no matter what company made that router.

There are two fundamental issues, only one of which is in this paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

I've summarized what's in that paper likely a half dozen times in this
thread, and I've added a second issue that is not discussed in that paper. >>
I've talked that second issue over with security professionals like Brain
Krebs and Daniel Veditz, so there is no doubt of the veracity of my claims. >>
To summarize complex issues in a few simple sentences, they might be:
1. Apple allows anyone on the world to track the movements of everyone
in the world (if they take their router with them when they move).
2. Apple puts zero controls on that tracking by anyone, of everyone.

I imagine the issue here is that if they change their API then older
devices that are no longer receiving updates will stop being able to do wifi-positioning.

The issue is clearly obvious that the Apple WPS design is flawed.

I have dozens of emails from Apple, all of which show that they *know* that their design is flawed.

They're simply trying to protect themselves legally with me by having their emails redirected to their lawyers, who are whom I was responding with.

They *know* what they're doing is wrong.

3. In addition, Apple does not respect the known meaning of a hidden
broadcast, and worse, Apple *refuses* to honor what even Google does.
4. Anyone can prove these statements are true on a Windows PC running
Python using the scripts I have provided for that express purpose.

I'm not sure what I think about that, and I don't know what any of the
other companies that map SSIDs do in the same situation. I'm not sure
why Apple would store location data of BSSIDs with no visible SSID -
it doesn't seem like it would help the geolocation feature much, since
hiding the SSID is pretty rare.

Remember the Apple trolls posted to this thread that changing the SSID
would solve the issue, but the main issue is about the BSSID, not the SSID. >> a. The BSSId is unique (see above for rare exceptions).
b. The GPS location is also unique
c. The SSID only plays a role tangentially, and as such is a minor player

The "Apple trolls" are presumably correct inasmuch as if you change the
SSID to end in "_nomap" then it solves the issue.

No it does not. Did you read any of the Mozilla references?
Simply *collecting* the BSSID is the starting point.

The problem exists no matter what the SSID is.

I explained it in gory detail, and even provided a link to the research. >>>> I provided some of the python scripts too (although they're not the
point).

You haven't done any of that in this thread so far as I can see.

Did you read the paper?
What does that paper say?

You hadn't linked the paper at the time I wrote my post.
The paper doesn't quite say what you're claiming, I think,
although I see your general point (or at least, the paper's
authors' general point).

I appreciate that you're the only person in this thread who has ever shown
any indication that you actually clicked on the link, so I must be careful
to let you know that I understand that you went to that trouble to "try" to understand what the paper actually said.

Remember, I go further than what the paper said, because the paper didn't discuss hidden broadcast implications, but do keep in mind I wrote the
scripts so I can track any router AP anywhere in the world myself, just as
the paper claimed I could.

With my congratulations to you and with my appreciation that you are the
only one who has shown they have read the paper, I must point out that I
think you misunderstood which BSSID the paper is talking about.

For most home routers, the owner has no way of changing the AP BSSID.

Do you know what a hidden broadcast SSID is?
What is the purpose of a hidden broadcast in your opinion?

To waste power in client devices, as far as I can see, since it
means they have to be constantly pinging for the network rather
than just connecting to it when they see the SSID broadcast.

No. Every mobile device has the on/off ability to NOT autoconnect.

Privacy never was something that everyone could understand, but let's hope
the people on this ng have the capacity to understand the complexities.

So in some senses it makes the user tracking problem *much worse*,
since it means the attacker can hang around public places watching
for client devices (which, unlike access points, tend to move around
with the user) that are pinging for the attack target's hidden SSID.

That's why you set the mobile device to NOT autoconnect after all.

Remember, privacy doesn't mean you don't have to understand networking.

Hang around a diner near Langley, Virginia, watching for people
carrying devices pinging the hidden SSID "CIA UNCLASSIFIED"...

I'm very happy you understand networking at that level, Jon.

This is an extremely well known phenomenon, which has been the topic of discussion in numerous hackers' conferences, where the presenter puts on
the projector screen the names and locations of all such requests.

Anyone who doesn't understand what we're conversing about, can't really add value to the conversation, so I'm glad you know it at that level.

I've explained both perhaps a half dozen times in this thread.
Explaining another half dozen times won't help until you do the above.

I'm starting to think that by "this thread" you don't mean "the set
of Usenet articles referenced in the References headers" and are
including other historic threads...

All the python scripts I wrote I put into the public domain so you're
welcome to ask for any of those scripts, which I posted to these ngs.

Google does one thing (which, surprisingly, is the right thing to do).
Apple does the opposite (and, not surprisingly, refuses to change it).

I think you are still failing to explain what those two things are,
and I'm getting tired of guessing. If you are claiming the paper
describes this difference, please say where. If it doesn't, please
just say what it is.

Again, I have to first say that I appreciate that you read the paper, and I presume you read the Mozilla documentation I presented, and I presume you
also read the Apple documentation which the Apple lawyers wrote after my discussions with them way back in December of last year (public knowledge).

The paper shows that Apple's WPS implementation is highly flawed.

If you've ever tried Google's WPS implementation, you'll see that it's not.
Nor is Mozilla's MLS implementation (now deprecated).

This is known public information that I have to assume you already know, as
it would take me a while to write the Python scripts to query Google's implementation, which also requires a key which is well known data.

SO, while I do appreciate that you're 'trying' to understand, to have me document what Google has already documented, would be a waste of energy.

It's absurd for anyone to dispute what I say without actually looking up
the extremely well known fact that the Google lookup requires not only a
key from Google but also it's limited in what it outputs, and also it's
limited in how many lookups you can do in a certain time period.

Apple's WPS lookup is not.
That's why they wrote that paper, after all... :)
--
What is disconcerting is nobody seems to look anything up even as everyone
in the world knows what I'm explaining in this thread, over & over again.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Lane W wrote:

Q: What is your home router AP BSSID please?
A: ?

I'm homeless and don't have a home router, so there's something further
for you to laugh at me about.

I asked for your home router BSSID to prove a point that you won't give it
to me, where if you did, I'd instantly know its location at any given time.

The fact anyone can do that with simply python scripts running on Windows, shows how flawed Apple's WPS implementation is compared to that of Google.

You can't do it with Google's WPS implementation.
Nor that of Mozilla location services (now deprecated).

Just Apple's.

Which is why the Apple engineers had the Apple lawyers contacting me.
Apple *knows* what they're doing is wrong.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia <mariasophia@comprehension.com> writes:

Keith Thompson wrote:

In particularly, there's in this thread nothing about Python or
Windows 10.

The code supplied for you to run is Python which ran on Windows 10.
I know this because I got help in the code from Windows/Python ngs.

There is no Python code in this thread or in the article you
cited on arxiv.org. I have seen no discussion of the Python
language. Your first article that started this thread included
a Windows batch file. That batch file does invoke "python.exe apple_bssid_locator.py" (something I didn't even notice at first)
but that Python script has not been posted here. You did offer
to provide a Python script (presumably that one) upon request.
That doesn't make this a discussion of Python.

The comp.lang.python newsgroup is for discussion of the Python
language. A vague reference to some Python script about which
you've said nothing beyond its name does not qualify.

This thread constitutes most of the recent traffic in
comp.lang.python.

Please stop.

So, together, the Windows & Python newsgroup honed the working code.
Do you need me to supply the code for you again so you can run it?

You haven't supplied it once. If you did, I personally would not be
interested in running it, but it might at least be topical in
comp.lang.python *if* anyone actually discusses the code.

[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Firstly, I do not like crossposting to so many groups. What group
are you actually reading this thread in, so that I can limit the
crossposts please?

On 2026-09-05, Maria Sophia <mariasophia@comprehension.com> wrote:

Jon Ribbens wrote:

If you don't know what a BSSID is by now then it will take too much work >>> here to explain it "fully" to you. Suffice to say it's like a vehicle
identification number on a car. It goes everywhere the router goes.

Well, yes, it's the MAC address, like I already said.

Hi Jon,

To your credit, you are the first person who has responded, who has shown that he actually *read* the paper before trying to respond intelligently.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems* <https://arxiv.org/abs/2405.14975>

That's good.
Nobody else even bothered to click on the link, before responding.

Hence, everyone else simply parroted their stone-age knowledge level.
You, at least, did *read* the paper, which I congratulate you for doing.

But you did not *understand* what the paper said by the BSSID.
See below where you completely whooshed on which BSSID is what matters.

I must be careful here not to fault you like I fault the Apple trolls, because I think you are sincerely trying to understand the problem set.

So I simply caution you, as I did Lawrence & Andy, all of whom I respect
for acumen, that you have to follow the trail of the *router* AP BSSID.

You can not "randomize the BSSID" of the router AP (except in the most expensive commercial routers, which are not the topic of this thread).

Think very deeply about that simple fact before responding, as the crux of the problem is no different than a governmment-issued identification
number.

You can't easily change your unique government-issued ID number just as you can't easily change the router-issued BSSID of your home router AP.

Yes, I do know all of the above.

Think about that the same way the paper presented the mass surveillance.
1. I wrote a Python script that ran on Windows 10 that guessed at a set
of random government-issued identification numbers, e.g., 123.45.6789
2. Within minutes, I had a hit on a random government ID, which came
back with a GPS location and 400 nearby government IDs and locations.
3. Then, I ran another Python script on Windows 10 that extended that,
taking the furthest-away governemtn ID/location pair, and did it again.
4. Within an hour, I had thousands of government IDs and locations.
(the researchers gathered billions, as I recall, but I stopped there.)

Now that I have every government-issued ID and GPS location in the world in my 2TB database (which we calculated would be the size it would have been), what is the paper saying about "mass surveillance" possibilities?

HINT: I can track the future location of every one of those billions of government ID/GPS location pairs, without any restrictions on my scripts!

Want to prove that?
What's your home router BSSID?

I will not only tell you exactly where that router is located (I even wrote the Python code to give me a dot on an OSM map for your location) but I can trivially easily forever track that router's location forever, without any restrictions on my part (which is the point of the paper, after all).

Yes, I know that too now, after reading the paper. I downloaded the
code at https://github.com/darkosancanin/apple_bssid_locator (which
was originally uploaded in 2015) and ran it locally with my own AP
MAC address and confirmed it showed my home location very accurately.

It does concern me that there is an attack model here which is that
a mildly technically-inclined stalker can very easily get the BSSID
of their victim and, as you say, find out where they've gone if they
move house to get away from them.

It mostly seems to be an attack against people who don't realise
they are targets, or are not thinking about the implications - c.f.
soldiers who upload their daily runs to public web sites thus
revealing if/where they are deployed.

It's not "an attack" so much as explaining, with examples, of why we
should care that mass surveillance is so easy with the Apple WPS implementation.

We should care because it enables attacks.

Give me your BSSID.

Note: I don't expect you to do it, which alone proves the point.

As above, I already tried it.

As I say that's a pretty unusual thing to do (travelling with a router).
Google's API does seem more sensible though (give it MAC addresses, it
tells you where you probably are, rather than giving you the recorded
individual locations of all those MAC addresses).

I think your claim that it's "pretty unusual" for people to take their
router with them when they move from one apartment to another is skewed.

If I ask 100 people who recently moved, do you really think it would be
only 1 or 2 people who took their home router with them when they moved?

I could quibble with that inasmuch as ISPs tend to provide the APs when
you order the connection, so a new connection usually implies a new AP
(in the UK, anyway). But I was talking about travelling with an AP,
e.g. on business, not moving house.

You think this tracking isn't happenging asa we speak?
You think Apple is doing something about it?

That's 1/2 the point of this thread.
1. Apple is doing NOTHING about it (as described in the paper)

Have you, er, read the paper? It says Apple *is* doing things about it
(page 14, section 10 paragraph 3).

See my first response to you in this post, where I want to be careful to
not chastise you for misunderstanding what that paragraph actually says.

You can NOT randomize the MAC address of the router AP, Jon.

Yes, I wasn't talking about randomizing the MAC addresses of APs,
I was talking about Apple taking steps to mitigate the attacks enabled
by their BSSID-lookup API. Apparently adding the "_nomap" exception was
one of the things Apple changed.

I agree that they shouldn't be storing BSSID data unless they see an
SSID broadcast without "_nomap" on the end (i.e. the SSID is not
hidden). And although I've briefly explored various lines of thought,
I can't immediately see why they would be reluctant to make that change.

But... it makes very little difference to the actual possible attacks.
Almost nobody hides their SSID, and even fewer append "_nomap". Anyone
who actually seriously cares about these things would take the trouble
to ensure that their BSSID does change if their location changes (even
if that means going as far as buying a new AP). The people who are
vulnerable are the people who don't know they're vulnerable.

2. So anyone in the world can track the movements of billions of routers >>> 2. Worse, Apple isn't honoring the established meaning of the hidden
broadcast (which even Google honors, by way of stark contrast).

This is the bit I keep asking about and you keep not responding.
Is your actual/main complaint that Apple is storing BSSIDs that
correspond to hidden SSIDs? And you're saying only Apple do this,
not Google etc?

First off, I don't have a complaint. That's absurd. I have facts.

You certainly don't seem to be happy with the status quo, which means
that by definition you have a complaint. My point is that for some
reason you are being opaque about what change you want to see.

The absurdity of this thread is nobody has read or understood the links
which were provided, and yet, they ask me (repeatedly) to explain them.

Why can nobody understand the point that Eric & Dave made in this paper?
*Surveilling the Masses with Wi-Fi-Based Positioning Systems* <https://arxiv.org/abs/2405.14975>

Why can nobody understand what's different about what Apple documented? <https://support.apple.com/en-ie/102515>

Why can nobody undestqand the concept inherent in a hidden-broadcast? <https://ichnaea.readthedocs.io/en/stable/api/geosubmit2.html>
"The BSSID of the Wifi network.
Hidden Wifi networks must not be collected."

Why is it that I feel it's trivial to understand that 1+1=2 when everyone else is trying to claim that I need to explain why 1+2=2 when, if they
simply read (and understood) what I've explained, they would understand?

I think that many people understand that 1+1=2, but you are then going
on to make some further claim that you are explaining very badly.

Also, the links you are providing do not always back up what you are
saying, or it is not clear what conclusion you are expecting people to
draw from them. For example, that last quote about "Hidden WIFi networks
must be be collected" is simply a policy of the Mozilla Location Service.
It isn't any sort of law or agreed standard.

So much for Apple "cares about your privacy" bullshit, huh?
It's shocking that google cares about privacy more than Apple does.

Apple cares about the privacy of *its customers*.

I realize you're trying to understand these concepts so I have to be
careful when I point out that this affects every single person in the
world who owns a router (and company, but let's restrict this to just people).

The issues are exactly the same no matter what company made that router.

Yes, I think you missed my point, which is that Apple is not generally
the provider of the routers, so Apple is not primarily concerned with
the privacy of their owners. Apple is primarily concerned with the
privacy of its customers, in respect of them being its customers.
(i.e. does their use of an Apple product threaten their privacy?)

I imagine the issue here is that if they change their API then older
devices that are no longer receiving updates will stop being able to do
wifi-positioning.

The issue is clearly obvious that the Apple WPS design is flawed.

I have dozens of emails from Apple, all of which show that they *know*
that their design is flawed.

They're simply trying to protect themselves legally with me by having
their emails redirected to their lawyers, who are whom I was
responding with.

They *know* what they're doing is wrong.

I think all of the above is likely true, but there is some reason they
cannot (quickly) change their API, probably related to the millions of
devices out there which either can not or do not receive new software
updates.

Remember the Apple trolls posted to this thread that changing the
SSID would solve the issue, but the main issue is about the BSSID,
not the SSID.
a. The BSSId is unique (see above for rare exceptions).
b. The GPS location is also unique
c. The SSID only plays a role tangentially, and as such is a minor player >>

The "Apple trolls" are presumably correct inasmuch as if you change the
SSID to end in "_nomap" then it solves the issue.

No it does not. Did you read any of the Mozilla references?
Simply *collecting* the BSSID is the starting point.

The problem exists no matter what the SSID is.

Sorry, I don't get what you mean. If the broadcast SSID ends with
"_nomap" then Apple won't store the BSSID, and won't respond with
its location. Are you saying that isn't true? If it is true, then
what is "the problem"?

With my congratulations to you and with my appreciation that you are the
only one who has shown they have read the paper, I must point out that I think you misunderstood which BSSID the paper is talking about.

For most home routers, the owner has no way of changing the AP BSSID.

I don't know why you think I misunderstood that.

Do you know what a hidden broadcast SSID is?
What is the purpose of a hidden broadcast in your opinion?

To waste power in client devices, as far as I can see, since it
means they have to be constantly pinging for the network rather
than just connecting to it when they see the SSID broadcast.

No. Every mobile device has the on/off ability to NOT autoconnect.

Privacy never was something that everyone could understand, but let's
hope the people on this ng have the capacity to understand the
complexities.

I think even fewer people are going to be manually connecting their
devices to a hidden-SSID WiFi network every time they come into range
than have hidden-SSID WiFi networks in the first place.

I think you are still failing to explain what those two things are,
and I'm getting tired of guessing. If you are claiming the paper
describes this difference, please say where. If it doesn't, please
just say what it is.

Again, I have to first say that I appreciate that you read the paper, and I presume you read the Mozilla documentation I presented, and I presume you also read the Apple documentation which the Apple lawyers wrote after my discussions with them way back in December of last year (public knowledge).

I read the paper (albeit not in complete detail), and I skimmed the
Apple documentation, although I'm not clear on which bit you are saying
they added because of you - I assume the "This opt-out doesnrCOt work for hidden networks" bit?

The paper shows that Apple's WPS implementation is highly flawed.

If you've ever tried Google's WPS implementation, you'll see that it's
not. Nor is Mozilla's MLS implementation (now deprecated).

The paper discusses the difference between Apple and Google's
implementation, and I agree that Google's looks better.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

What if I were hiding from an ex-wife or disgruntled Apple poster?

Just get a different router.

Chris,

Unfortunately you're being your disingenuous self and refusing to respond
to genuine questions. I suspect your experiment at your friends' houses
never happened. Which is a shame as it would have been interesting.

Q3: Would you kindly give me the BSSID of your home router AP please?

You already have it. Should be easy to find in your database.

When/if you do so, not only will I provide the exact location of that
router

It would be simpler just to ask for my address...

but I can track its movement, forever.

Won't be difficult as it never moves. I suspect the only time it'll move is when I throw it out.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-06 02:06, Jon Ribbens wrote:

Firstly, I do not like crossposting to so many groups. What group
are you actually reading this thread in, so that I can limit the
crossposts please?

I understand, but that could be a problem to people that are already
reading on a "different" group.

Your comments are easier to understand that Arlen (aka Maria) posts. He
is not clearly explaining the issues and wants people to read a lot of documentation, instead of just posting an actual summary of the
situation with explanations.

Ie, what was Apple doing, why is that bad, what have they changed, is
that enough and why, what are the actual dangers to people.

Complete, and short text.

On 2026-09-05, Maria Sophia <mariasophia@comprehension.com> wrote:

Jon Ribbens wrote:

...

As I say that's a pretty unusual thing to do (travelling with a router). >>> Google's API does seem more sensible though (give it MAC addresses, it
tells you where you probably are, rather than giving you the recorded
individual locations of all those MAC addresses).

I think your claim that it's "pretty unusual" for people to take their
router with them when they move from one apartment to another is skewed.

If I ask 100 people who recently moved, do you really think it would be
only 1 or 2 people who took their home router with them when they moved?

I could quibble with that inasmuch as ISPs tend to provide the APs when
you order the connection, so a new connection usually implies a new AP
(in the UK, anyway). But I was talking about travelling with an AP,
e.g. on business, not moving house.

Most people here get a free (rented, not purchased) router with AP from
their ISP. When they move house, the old router has to be returned to
the ISP (nominally), and they get a new router automatically when
contracting a connection at the new location. So they don't have a problem.

Some of those might have a secondary AP of their own.

Only people that buy a router or AP have a problem. And most do not
care. I don't. Only those that are using _nomap or perhaps those that
hide the SSID.



...
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

Maria Sophia <mariasophia@comprehension.com> writes:
[...]

Heh heh heh...

While I realize Apple religious zealots will attack people personally

[SNIP]

Can you please restrict this to newsgroups where it's relevant?

In particularly, there's in this thread nothing about Python or
Windows 10.

I'm sorry, but no can do: Usenet/NetNews doesn't allow an empty
'Newsgroups:' header.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-06, Carlos E.R. <robin_listas@es.invalid> wrote:

On 2026-09-06 02:06, Jon Ribbens wrote:

Firstly, I do not like crossposting to so many groups. What group
are you actually reading this thread in, so that I can limit the
crossposts please?

I understand, but that could be a problem to people that are already
reading on a "different" group.

Your comments are easier to understand that Arlen (aka Maria) posts. He
is not clearly explaining the issues and wants people to read a lot of documentation, instead of just posting an actual summary of the
situation with explanations.

Ie, what was Apple doing, why is that bad, what have they changed, is
that enough and why, what are the actual dangers to people.

Complete, and short text.

Ok, well to summarise what I have gathered then, which may or may not
be Maria's opinion but reflects my opinion at this point: there are two completely separate issues here, which are unrelated except that they
are both to do with WiFi location databases.


1. Apple are storing the location of "hidden" WiFi Access Points.
(My opinion: low priority.)

Multiple organisations are gathering and storing the physical
co-ordinates of the MAC addresses ("BSSIDs") of WiFi Access Points
around the world, whenever they are seen transmitting by, e.g. mobile
phones. (Any WiFi-enabled device can see this information; it does not
need to be connected to the network in question, nor does it need to
know its password.)

The purpose of these databases of BSSID locations is to assist devices
such as mobile phones in locating themselves. Maybe the device is
indoors and cannot get a GPS signal, but also my understanding is that
GPS can fix an accurate location much faster if it starts already
knowing vaguely where on the planet it is.

There is broad agreement that these databases should not include BSSIDs
which are broadcasting WiFi network names ("SSIDs") which end in the
string "_nomap".

Allegedly: Apple are adhering to this exclusion, but are not also
excluding BSSIDs which are not broadcasting any SSID at all (i.e.
"hidden" networks). Other organisations (e.g. Google) do exclude such
"hidden" networks.

My complete speculation: older Apple software, written before they added
the "_nomap" exclusion, doesn't care at all about the SSID, so just
reports from the phone to the central database the BSSID and location.
The database thus has no way of excluding "hidden" networks, without
excluding all reports from older devices. The "_nomap" exclusion is
achieved by later software versions reporting the SSID if it is seen,
and any BSSIDs associated with "_nomap" SSIDs then being blacklisted,
maybe for 6 months or something like that. The likelihood of any
particular BSSID *only* being seen by old Apple devices and *never* new
ones is very low, and hence the "_nomap" exclusion more-or-less works.

My opinion: this failure to exclude "hidden" networks is unfortunate and
should be fixed, and maybe Apple are indeed fixing it, but it's possible
it may take some years to achieve due to the multitude of devices
running old software.


2. Apple's API is trivial to abuse.
(My opinion: high priority.)

The Apple API to query their BSSID location database is remarkably unrestricted. It has little or no rate limiting, doesn't ask for an API
key, and reports not only the location of the BSSID but also potentially
a great many other BSSIDs in the locality. It is not beyond even an
individual person's ability to get a list of most of the Access Points
in the world and all their locations.

This makes it very easy for people to abuse this data in various ways,
from stalkers tracking victims to state actors tracking military
targets.

Google's API by contrast essentially reverses the process, and instead
of the phone asking "Where is BSSID <x>?", it says "I can see BSSIDs
<x>, <y>, and <z>, where am I?".

My opinion: the lack of restrictions on the Apple API is unacceptable,
and if Apple are unwilling to do something about it then governments
should pass laws (or enforce existing laws) to make them to do so.

My opinion: it would be difficult for Apple to rapidly switch completely
to using an API more similar to Google's API, since this would remove functionality from devices running old software. However they could
certainly aim to do this eventually, and there are steps they could take immediately to improve the situation (e.g. rate limiting, and not
providing so many additional answers when asked about an individual
BSSID). I cannot see any obvious reason why they couldn't make
significant improvements almost immediately.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-06 17:37, Jon Ribbens wrote:

On 2026-09-06, Carlos E.R. <robin_listas@es.invalid> wrote:

On 2026-09-06 02:06, Jon Ribbens wrote:

Firstly, I do not like crossposting to so many groups. What group
are you actually reading this thread in, so that I can limit the
crossposts please?

I understand, but that could be a problem to people that are already
reading on a "different" group.

Your comments are easier to understand that Arlen (aka Maria) posts. He
is not clearly explaining the issues and wants people to read a lot of
documentation, instead of just posting an actual summary of the
situation with explanations.

Ie, what was Apple doing, why is that bad, what have they changed, is
that enough and why, what are the actual dangers to people.

Complete, and short text.

Ok, well to summarise what I have gathered then, which may or may not
be Maria's opinion but reflects my opinion at this point: there are two completely separate issues here, which are unrelated except that they
are both to do with WiFi location databases.

Thanks.

1. Apple are storing the location of "hidden" WiFi Access Points.
(My opinion: low priority.)

Only Apple?

Multiple organisations are gathering and storing the physical
co-ordinates of the MAC addresses ("BSSIDs") of WiFi Access Points
around the world, whenever they are seen transmitting by, e.g. mobile
phones. (Any WiFi-enabled device can see this information; it does not
need to be connected to the network in question, nor does it need to
know its password.)

Yes.

The purpose of these databases of BSSID locations is to assist devices
such as mobile phones in locating themselves. Maybe the device is
indoors and cannot get a GPS signal, but also my understanding is that
GPS can fix an accurate location much faster if it starts already
knowing vaguely where on the planet it is.

Yes. And they can give an approximate location without using the GPS chip.

There is broad agreement that these databases should not include BSSIDs
which are broadcasting WiFi network names ("SSIDs") which end in the
string "_nomap".

Right.

Allegedly: Apple are adhering to this exclusion, but are not also
excluding BSSIDs which are not broadcasting any SSID at all (i.e.
"hidden" networks). Other organisations (e.g. Google) do exclude such "hidden" networks.

And if it is hidden they would not see if the SSID ends in _nomap.

But is there a consensus that hidden SSIDs should not be listed? In
writing? Maybe there is such a consensus now.

My complete speculation: older Apple software, written before they added
the "_nomap" exclusion, doesn't care at all about the SSID, so just
reports from the phone to the central database the BSSID and location.
The database thus has no way of excluding "hidden" networks, without excluding all reports from older devices. The "_nomap" exclusion is
achieved by later software versions reporting the SSID if it is seen,
and any BSSIDs associated with "_nomap" SSIDs then being blacklisted,
maybe for 6 months or something like that. The likelihood of any
particular BSSID *only* being seen by old Apple devices and *never* new
ones is very low, and hence the "_nomap" exclusion more-or-less works.

My opinion: this failure to exclude "hidden" networks is unfortunate and should be fixed, and maybe Apple are indeed fixing it, but it's possible
it may take some years to achieve due to the multitude of devices
running old software.

Right.

Related: What did Arlen (aka Maria) achieve? That Apple agreed to remove
all hidden and _nomap entries, or that they removed only his entry?

2. Apple's API is trivial to abuse.
(My opinion: high priority.)

The Apple API to query their BSSID location database is remarkably unrestricted. It has little or no rate limiting, doesn't ask for an API
key, and reports not only the location of the BSSID but also potentially
a great many other BSSIDs in the locality. It is not beyond even an individual person's ability to get a list of most of the Access Points
in the world and all their locations.

Aha.

This makes it very easy for people to abuse this data in various ways,
from stalkers tracking victims to state actors tracking military
targets.

Well, only of the limited subset of people that carry their AP when they
move.

Google's API by contrast essentially reverses the process, and instead
of the phone asking "Where is BSSID <x>?", it says "I can see BSSIDs
<x>, <y>, and <z>, where am I?".

Ah. Yes, I can see this is better.

My opinion: the lack of restrictions on the Apple API is unacceptable,
and if Apple are unwilling to do something about it then governments
should pass laws (or enforce existing laws) to make them to do so.

Ok.

My opinion: it would be difficult for Apple to rapidly switch completely
to using an API more similar to Google's API, since this would remove functionality from devices running old software. However they could
certainly aim to do this eventually, and there are steps they could take immediately to improve the situation (e.g. rate limiting, and not
providing so many additional answers when asked about an individual
BSSID). I cannot see any obvious reason why they couldn't make
significant improvements almost immediately.

Ok, yes.

Thank you for the explanation. Easy to understand, and I agree with your conclusions.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Andy,

I don't remember whether you addressed this ... how does someone
who hasn't visited your address (i.e they already know where you live) discover what the BSSID of your router is?

You forget that you're talking to Arlen here. He ignores everything that
does not further his narrative, and than goes full-out on the crumbs that remain.

What you mention there has been explained to him in the thread here

[Tutorial: Query the Apple database with Python for your access point BSSID] <10h1qmr$2alo$1@nnrp.usenet.blueworldhosting.com>

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

After having read the prior responses in this Jon/Carlos tangent...

I apologize if I haven't explained the situation to the liking of people
who haven't clicked on the references, but I am happy that Jon and Carlos
(and Andy and Lawrence, all of whom I respect) are trying to understand.

I especially wish to thank Jon Ribbens and Carlos & any others who have bothered to read the links provided, because they explain the issue well.

If people haven't read the references, then they're stuck in the stone age
of understanding, which, well, which I'm not the one to drag them out of.

I just don't have the skills to explain that an SSID is not a BSSID
(as witnessed by those who claimed changing the SSID changes the BSSID).

These are basic networking concepts.

Regarding locations, I don't have the skills to explain what a set of GPS coordinates means, if people claim it's "just a map". I don't even know
_how_ to _begin_ to explain that your home address is NOT "just a map".

I don't even know how to explain to people who claim that the router never travels as their belief system is so absurd as to warn me that if they
don't understand that people take their routers with them when they move,
then that kind of person will never be able to understand, well, anything.

I apologize that I don't have the skills set to bring folks out of the
stone age, when they claim a home address is "just a location on a map".

People who make those claims will never be able to comprehend why it is so trivial for Jon & me to surveil their movements using the Apple WPS db.

In summary, if people haven't read this paper, I don't have the skill set
to explain the very simple concepts which are described in that paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

The paper is about surveillance of masses (not individuals, per se),
knowing every single location of billions of router BSSIDs around the
world, from anywhere in the world, by anyone in the world, with zero restrictions, which is only possible using Apple's WPS database (not
Google's, which has huge restrictions on both the input and output).

Apple has zero restrictions on the input.
And a restriction of the nearest 400 BSSIDs/GPS pairs on the output.

But... that restriction is meaningless, as I wrote and ran the Python code
on Windows that took the furthest away of those 400 to run it again.

And again. And again. And again. I stopped at something like thousands.
So now I have the nearest ten thousand BSSIDs starting at my home.

Notice I have the GPS location of each of those unique ten thousand BSSIDs.

And, since apartments basically do not exist in this suburban area, I
actually know the names and address of the owners of record of those homes.

If any of those ten thousand people ever move, and take their router with
them, I will instantly know exactly where they moved to, within seconds.

Not only that, but I will instantly know the nearest 400 BSSIds, so if they moved, oh, say, into someone else's home, I'll know exactly who that is.

To be very clear, this is only possible because of how Apple designed it. Google and Mozilla designed their systems completely differently.

Only Apple's design is this bad in terms of privacy.

As for the hidden-BSSID issue, I was unaware of that until I found, to my horror, my own hidden BSSIDs in Apple's WPS database. That was a shock!

At the time, I looked up Apple's public policy, and it was silent on the
issue of what Apple does when it encounters a hidden-broadcast BSSID.

When I brought it up to my next-door neighbor, who runs Apple Maps, he said he'd check it out, which, after a few weeks of emails back and forth, we
found out that Apple has no intention of honoring the intent of a hidden broadcast (even as we know Google & Mozilla certainly honor that intent).

The Apple lawyers made that very clear to me, as I was shut out from
talking to the engineers once the lawyers were informed of the issue.

I had given up, but recently, I happened to look at Apple's documentation,
and I realized Apple proved they had no intent of honoring the long-held intention of a hidden broadcast, by simply changing their documentation.
<https://support.apple.com/en-ie/102515>

Clearly, I know what I'm talking about, so my well informed assessment,
based on those verifiable facts, is Apple doesn't care about our privacy.
--
On Usenet we can have intelligent discussions with well-meaning people.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Keith Thompson wrote:

So, together, the Windows & Python newsgroup honed the working code.
Do you need me to supply the code for you again so you can run it?

You haven't supplied it once. If you did, I personally would not be interested in running it, but it might at least be topical in comp.lang.python *if* anyone actually discusses the code.

Hi Keith Thompson,

Thank you for bringing up your point of view, as all points are valid here. This is Usenet where we welcome deep detailed discussion of tech topics.

Jon Ribbens clearly ran the code so we have proof that it was referenced properly enough for him to have run it on his machine to prove the point.

Nonetheless, it's good you're *asking* for the Python code, which I only
ran on Windows 10, and which I'm happy to supply to you for all to review.

Please keep in mind the progression of this topic started with this paper:
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

As Jon Ribbens did, I simply ran the Python code in that article on my PC.

Since all the dozens of access points on my property have always had both a hidden broadcast & a _nomap prefix, I was horrified to see them on the map!

At that time, we discussed this issue at length, where the following code resulted which I will provide to the team to try themselves on their PC.

12/17/2025 02:28 PM 2,934 bssid.bat.txt
12/17/2025 02:28 PM 4,309 bssidcheck.bat.txt
12/17/2025 02:28 PM 1,979 bssidcompare.bat.txt
12/17/2025 02:28 PM 316 bssidgenerate.bat.txt
12/17/2025 02:28 PM 4,312 bssidgenerate.ps1.txt
12/17/2025 02:28 PM 1,348 bssidplot.py.txt
12/17/2025 02:28 PM 27,527 bssid_results.txt

Let's start with the first on that list, and proceed from there, so that
anyone with this code can track every single router location in the world.

Here is bssid.bat

@echo off
setlocal EnableDelayedExpansion
:: C:\app\os\python\apple_bssid_locator\bssid.bat
:: Use: bssid.bat <Enter> (then enter desired BSSID to look up)
:: Sample values:
:: 00:18:f8:c1:4a:65
:: 00:07:89:d7:82:e8
:: 04:09:A5:3B:34:67
::
:: Logs up to 400 BSSID:GPS pairs from Apple's WPS public database
:: Loop until user types q
::
:: Changelog:
:: v1p0 20251205 - Query Apple's highly insecure WPS database
:: v1p1 20251214 - Saves to time-date stamped results.txt log file
:: v1p2 20251215 - Timestamp results.txt so it's not overwritten
:: v1p3 20251219 - Limit the human-readable GPS to 6 decimal places
:: v1p4 20251219 - Show original raw integers + converted decimals
:: v1p5 20251219 - Tried to accomodate Google Maps query to new format
:: v1p6 20251219 - Changed to block-aware parsing with debug output
:: v1p7 20251219 - Enable delayed expansion to fix parsing inside loops

set LOGDIR=%~dp0log
if not exist "%LOGDIR%" mkdir "%LOGDIR%"

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

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

echo.
echo === Nearby Wi-Fi Networks ===
netsh wlan show networks mode=bssid
echo =============================

:loop
echo.
set /p BSSID=Enter the BSSID (or q to quit):

if /I "%BSSID%"=="q" goto end

:: --- Clean up input ---
set "BSSID=%BSSID:"=%"
set "BSSID=%BSSID: =%"

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

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

:: --- Timestamped output file ---
set "outfile=%LOGDIR%\bssid_%safeBSSID%_%ts%.txt"

:: --- Clear previous coordinates ---
set "LAT="
set "LON="

echo === Lookup started at %date% %time% === > "%outfile%"
echo BSSID: %BSSID% >> "%outfile%"
echo. >> "%outfile%"

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

:: --- Display results ---
echo -----------------------------------------------
type "%outfile%"
echo -----------------------------------------------

:: --- Block-aware parsing of coordinates (with delayed expansion) ---
set "CAPTURE="
set "LAT="
set "LON="

for /f "usebackq delims=" %%L in ("%outfile%") do (
if /i "%%L"=="BSSID: %BSSID%" (
set "CAPTURE=1"
set "LAT="
set "LON="
echo [DEBUG] Found block start for %BSSID%
) else if defined CAPTURE (
echo [DEBUG] Line in block: %%L

echo %%L | findstr /i /c:"Latitude (degrees):" >nul
if not errorlevel 1 (
for /f "tokens=2 delims=:" %%A in ("%%L") do set "LAT=%%A"
if defined LAT set "LAT=!LAT: =!"
echo [DEBUG] Parsed LAT candidate = "!LAT!"
)

echo %%L | findstr /i /c:"Longitude (degrees):" >nul
if not errorlevel 1 (
for /f "tokens=2 delims=:" %%B in ("%%L") do set "LON=%%B"
if defined LON set "LON=!LON: =!"
echo [DEBUG] Parsed LON candidate = "!LON!"
)

if defined LAT if defined LON (
goto :gotCoords
)

echo %%L | findstr /i /c:"BSSID:" >nul
if not errorlevel 1 (
set "CAPTURE="
)
)
)

:gotCoords
echo [DEBUG] Final LAT = "!LAT!"
echo [DEBUG] Final LON = "!LON!"

:: --- Validate parsed coordinates ---
if not defined LAT echo [DEBUG][ERROR] Latitude not captured. Check
Python output format near "BSSID: %BSSID%".
if not defined LON echo [DEBUG][ERROR] Longitude not captured. Check
Python output format near "BSSID: %BSSID%".

:: --- Save results ---
echo === Lookup finished at %date% %time% === >> "%outfile%"
echo. >> "%outfile%"

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

:: --- Append to master log ---
echo [%date% %time%] BSSID: %BSSID% >> "%LOGDIR%\results.log"
echo Latitude: !LAT! >> "%LOGDIR%\results.log"
echo Longitude: !LON! >> "%LOGDIR%\results.log"
echo. >> "%LOGDIR%\results.log"

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

goto loop

:end
echo Exiting. Goodbye!
endlocal

:: end of C:\app\os\python\apple_bssid_locator\bssid.bat
--
bssid.bat
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia wrote:

12/17/2025 02:28 PM 2,934 bssid.bat.txt
12/17/2025 02:28 PM 4,309 bssidcheck.bat.txt
12/17/2025 02:28 PM 1,979 bssidcompare.bat.txt
12/17/2025 02:28 PM 316 bssidgenerate.bat.txt
12/17/2025 02:28 PM 4,312 bssidgenerate.ps1.txt
12/17/2025 02:28 PM 1,348 bssidplot.py.txt
12/17/2025 02:28 PM 27,527 bssid_results.txt

bssidcheck.bat


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

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

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

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

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

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

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

call :process_bssid
goto loop

:: End INTERACTIVE MODE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

goto :eof
:: End PROCESS ONE BSSID


:end

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

echo Exiting. Goodbye!
:: end of C:\app\os\python\apple_bssid_locator\bssidcheck.bat
--
bssidcheck.bat
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

12/17/2025 02:28 PM 2,934 bssid.bat.txt
12/17/2025 02:28 PM 4,309 bssidcheck.bat.txt
12/17/2025 02:28 PM 1,979 bssidcompare.bat.txt
12/17/2025 02:28 PM 316 bssidgenerate.bat.txt
12/17/2025 02:28 PM 4,312 bssidgenerate.ps1.txt
12/17/2025 02:28 PM 1,348 bssidplot.py.txt
12/17/2025 02:28 PM 27,527 bssid_results.txt

bssidcompare.bat

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

setlocal enabledelayedexpansion

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

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

set INFILE=results.txt

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

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

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

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

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

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

echo.
echo Comparison complete.
endlocal

:: end of C:\app\os\python\apple_bssid_locator\bssidcompare.bat
--
bssidcompare.bat
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

12/17/2025 02:28 PM 2,934 bssid.bat.txt
12/17/2025 02:28 PM 4,309 bssidcheck.bat.txt
12/17/2025 02:28 PM 1,979 bssidcompare.bat.txt
12/17/2025 02:28 PM 316 bssidgenerate.bat.txt
12/17/2025 02:28 PM 4,312 bssidgenerate.ps1.txt
12/17/2025 02:28 PM 1,348 bssidplot.py.txt
12/17/2025 02:28 PM 27,527 bssid_results.txt

bssidgenerate.bat

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

echo Running PowerShell script:
echo %SCRIPT%
echo.

powershell -NoLogo -NoProfile -ExecutionPolicy Bypass -File "%SCRIPT%"
--
bssidgenerate.bat
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

12/17/2025 02:28 PM 2,934 bssid.bat.txt
12/17/2025 02:28 PM 4,309 bssidcheck.bat.txt
12/17/2025 02:28 PM 1,979 bssidcompare.bat.txt
12/17/2025 02:28 PM 316 bssidgenerate.bat.txt
12/17/2025 02:28 PM 4,312 bssidgenerate.ps1.txt
12/17/2025 02:28 PM 1,348 bssidplot.py.txt
12/17/2025 02:28 PM 27,527 bssid_results.txt

bssidgenerate.ps1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

$maxVal = 0xFFFFFF

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

$val = $startVal + $i

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

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

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

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

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

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

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

# end of C:\app\os\python\apple_bssid_locator\bssidgenerate.ps1
--
bssidgenerate.ps1
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

12/17/2025 02:28 PM 2,934 bssid.bat.txt
12/17/2025 02:28 PM 4,309 bssidcheck.bat.txt
12/17/2025 02:28 PM 1,979 bssidcompare.bat.txt
12/17/2025 02:28 PM 316 bssidgenerate.bat.txt
12/17/2025 02:28 PM 4,312 bssidgenerate.ps1.txt
12/17/2025 02:28 PM 1,348 bssidplot.py.txt
12/17/2025 02:28 PM 27,527 bssid_results.txt

bssidplot.py

import folium
# This is C:\app\os\python\bssidplot.py
# USAGE: python bssidplot.py
# v1p0 20251214
# Plots en masse GPS:BSSID pairs from results.txt using FOSS Folium
# v1p1 20251215
# Generates bssid_map.html from results.txt using Folium
# v1p2 20251215
# Brings up the bssid_map.html plot using the default web browser

import folium

# Read results.txt
points = []
with open("results.txt") as f:
for line in f:
parts = line.strip().split("\t")
if len(parts) == 3:
mac, lat, lon = parts
points.append((mac, float(lat), float(lon)))

if not points:
print("No points found in results.txt")
exit()

# Center map on the first point
start_lat, start_lon = points[0][1], points[0][2]
m = folium.Map(location=[start_lat, start_lon], zoom_start=15)

# Add markers
for mac, lat, lon in points:
folium.Marker(
location=[lat, lon],
popup=f"{mac}\n({lat}, {lon})",
icon=folium.Icon(color="blue", icon="wifi", prefix="fa")
).add_to(m)

# Save map
m.save("bssid_map.html")
print("Map saved to bssid_map.html")

# Open map in Microsoft Edge
import subprocess
import os
map_path = os.path.abspath("bssid_map.html")
import subprocess
subprocess.Popen(['cmd', '/c', 'start', '', map_path])
# end of C:\app\os\python\bssidplot.py
--
bssidplot.py
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

12/17/2025 02:28 PM 2,934 bssid.bat.txt
12/17/2025 02:28 PM 4,309 bssidcheck.bat.txt
12/17/2025 02:28 PM 1,979 bssidcompare.bat.txt
12/17/2025 02:28 PM 316 bssidgenerate.bat.txt
12/17/2025 02:28 PM 4,312 bssidgenerate.ps1.txt
12/17/2025 02:28 PM 1,348 bssidplot.py.txt
12/17/2025 02:28 PM 27,527 bssid_results.txt

bssid_results.txt

BSSID's can be checked using this Apple WPS query:
<https://wavedigger.networksurvey.app/?tab=bssid>

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

Click on these links:
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-B6-A6-97>
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-38-43-72>
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-8E-DE-DC>
<https://wavedigger.networksurvey.app/?tab=bssid&bssid=F4-F2-6D-87-0A-CE>
etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

BSSID: fa:aa:a0:e3:5f:38
Latitude: 32.45890808
Longitude: -93.81495666
-----------------------------------------------
--
bssid_results.txt
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Jon Ribbens wrote:

I will not only tell you exactly where that router is located (I even wrote >> the Python code to give me a dot on an OSM map for your location) but I can >> trivially easily forever track that router's location forever, without any >> restrictions on my part (which is the point of the paper, after all).

Yes, I know that too now, after reading the paper. I downloaded the
code at https://github.com/darkosancanin/apple_bssid_locator (which
was originally uploaded in 2015) and ran it locally with my own AP
MAC address and confirmed it showed my home location very accurately.

Hi Jon Ribbens,

You are intelligent, and I've been a bit brutal to those who have been idiotically trolling this newsgroup without even reading the subject line,
so I want to first thank you for actually reading the paper & testing it.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

You are at the stage where you ran the apple_bssid_locator.py script
and you found that your own BSSID/GPS pair was clearly in the results.

I had run the same code as you just did, where I was horrified a dozen
of mine were in the results since _all_ of them had _nomap on the SSID!

Luckily, I live near to plenty of Silicon Valley executives, where
my next-door neighbor happens to an executive in the Apple Maps group.

When I brought the topic up to him, he at first considered it a likely
bug, and then his engineers tried to snow me by saying the issue
wasn't reproducible, but I kept hammering him on an honest answer.

In the end, he said I could only talk to the lawyers, who, in the end,
said they'd "fix" the documentation, which, let's be clear, is the topic.

Apple did fix the documentation.
Apple has no intention of honoring what EVERY other company already honors!

Subsequently, I had discussions with Daniel Veditz and Brian Krebs, and
they agreed with the tests, so at this point, there isn't much we can do.

At this point, you seem to be the only one who displays any indication
that they understood the topic of this paper & what it means for privacy
(given you ran the python code and it clearly told you where you lived).

I appreciate that you followed up by running the apple_bssid_locator.py
script, where I went another step further to modify that script so that
it not only reports a single output, but the next nearest 400 BSSIDs.

With the code below and the code I posted in response to Keith Roberts
who claimed, apparently, that you hadn't run the code you did run,
you can literally track any router BSSID location anywhere in the world.

Forever...

Here is the improved apple_bssid_locator.py for you to test, where I
simply ask of you to run it, and for you to explain to the newsgroups
what it does, as people seem to be saying I can't explain things well.

Maybe you can do better than I at explaining what this code does?

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

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

import argparse
import requests
import webbrowser
import AppleWLoc_pb2

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

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

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

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

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

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

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

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

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

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

if __name__ == '__main__':
main()

# end of C:\app\os\python\apple_bssid_locator\apple_bssid_locator.py
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

With the code supplied above, anyone can easily track the movements of
every access point BSSID in the world (that is in Apple's WPS database).
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Note the word "mass" indicates we can not only track a single BSSID's location, but we can track every single BSSID in the world's location.

It's trivial to do, but only with Apple's WPS database.
It cannot be done with any other WPS database that I am aware of.

To his credit, Jon Ribbens proved the veracity of these statements by
tracking his own BSSID location using the Python code in that article.

====================================================================
From: Jon Ribbens <jon+usenet@unequivocal.eu>
Newsgroups: comp.lang.python,misc.phone.mobile.iphone,comp.mobile.android,alt.internet.wireless,alt.comp.os.windows-10
Subject: Re: Apple changed their documentation at my request but it proves they don't care about privacy
Date: Sun, 6 Sep 2026 00:06:34 -0000 (UTC)
Message-ID: <slrn119pbka.8k8.jon+usenet@raven.unequivocal.eu>

HINT: I can track the future location of every one of those billions of government ID/GPS location pairs, without any restrictions on my scripts!

Want to prove that?
What's your home router BSSID?

I will not only tell you exactly where that router is located (I even wrote the Python code to give me a dot on an OSM map for your location) but I can trivially easily forever track that router's location forever, without any restrictions on my part (which is the point of the paper, after all).

Yes, I know that too now, after reading the paper. I downloaded the
code at https://github.com/darkosancanin/apple_bssid_locator (which
was originally uploaded in 2015) and ran it locally with my own AP
MAC address and confirmed it showed my home location very accurately.

It does concern me that there is an attack model here which is that
a mildly technically-inclined stalker can very easily get the BSSID
of their victim and, as you say, find out where they've gone if they
move house to get away from them.
====================================================================

For others to benefit from, in my records is this initial version of apple_bssid_locator.py where when I ran it, I was horrified to find
that every one of my dozens of hidden access point BSSIDs were there!

I suggest each user on this thread who wishes to better understand the
nature of the problem set (as described by the paper), run this code.

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

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

import argparse
import requests
import webbrowser
import AppleWLoc_pb2

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

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

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

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

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

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

f.write(f"{mac}\t{raw_lat}\t{raw_lon}\t{lat:.8f}\t{lon:.8f}\n")

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

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

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

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

if __name__ == '__main__':
main()

# end of C:\app\os\python\apple_bssid_locator\apple_bssid_locator.py
--
apple_bssid_locator.py
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia <mariasophia@comprehension.com> writes:

Keith Thompson wrote:

So, together, the Windows & Python newsgroup honed the working code.
Do you need me to supply the code for you again so you can run it?

You haven't supplied it once. If you did, I personally would not be
interested in running it, but it might at least be topical in
comp.lang.python *if* anyone actually discusses the code.

Hi Keith Thompson,

Thank you for bringing up your point of view, as all points are valid here. This is Usenet where we welcome deep detailed discussion of tech topics.

Usenet welcomes technical discussion of topics that are relevant to the newsgroups in which they are posted.

Jon Ribbens clearly ran the code so we have proof that it was referenced properly enough for him to have run it on his machine to prove the point.

I don't know or care where Jon Ribbens obtained any Python code.
Perhaps you provided it to him directly. It wasn't posted here.

Nonetheless, it's good you're *asking* for the Python code, which I only
ran on Windows 10, and which I'm happy to supply to you for all to review.

I don't know how you misunderstood what I wrote so badly.

I haven't asked for Python code. I've observed that you haven't
posted any Python code, and therefore your posts should not be
in comp.lang.python. If you want to talk about Python here in comp.lang.python, that's great. If you don't, I wish you'd go away.

Please keep in mind the progression of this topic started with this paper:
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

As Jon Ribbens did, I simply ran the Python code in that article on my PC.

Are you claiming that there's Python code in that paper? There is none
in the PDF. (I didn't read it in any depth because it's not something I
care about.)

I see you've posted some Python source code later in this thread, along
with Windows batch and PowerShell. Since you haven't said anything
about the code (how it's written, what features it uses, how it could be improved), I suggest that it's (a) far too late to excuse you behavior
so far, and (b) still inappropriate for comp.lang.python.

Feel free to have the last word and pretend you've won.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 09/06/2026 2:23 PM, Carlos E.R. wrote:

Related: What did Arlen (aka Maria) achieve? That Apple agreed to remove
all hidden and _nomap entries, or that they removed only his entry?

He achieved nothing.
It's all weasel words.
- nothing but a vague attempt(regardless of the size of multiple
missives) to sound impressive and/or meaningful without any concrete proof.
--
...w-i|#-o-#-n|#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

....winston wrote on 9/7/2026 1:01 AM:

On 09/06/2026 2:23 PM, Carlos E.R. wrote:

Related: What did Arlen (aka Maria) achieve? That Apple agreed to
remove all hidden and _nomap entries, or that they removed only his
entry?

He achieved nothing.
It's all weasel words.
-a- nothing but a vague attempt(regardless of the size of multiple missives) to sound impressive and/or meaningful without any concrete proof.

Some folks in the midwest would say he has a paper ass, I guess.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

(Snipping for brevity for inline replies, sorry that this removes the
context, but in this case it probably is preferrable, please refer to
the parent post for the full context:)

(And thanks for the post, Jon, it does indeed make things clearer to
understand at least for me.)

On 2026-09-06, Jon Ribbens wrote:

The purpose of these databases of BSSID locations is to assist devices
such as mobile phones in locating themselves. Maybe the device is
indoors and cannot get a GPS signal, but also my understanding is that
GPS can fix an accurate location much faster if it starts already
knowing vaguely where on the planet it is.

There was already a mechanism to do this at least since "3G" using
mobile data connections, right?

2. Apple's API is trivial to abuse.
(My opinion: high priority.)

(I think this is one of the aspects that was made only implicit in most
of the thread, and it would have helped if it was made more explicit...)

[...]

My opinion: the lack of restrictions on the Apple API is unacceptable,
and if Apple are unwilling to do something about it then governments
should pass laws (or enforce existing laws) to make them to do so.

I'm leaning towards existing laws being more than sufficient, in
developed countries.

My opinion: it would be difficult for Apple to rapidly switch completely
to using an API more similar to Google's API, since this would remove functionality from devices running old software. However they could
certainly aim to do this eventually, and there are steps they could take immediately to improve the situation (e.g. rate limiting, and not
providing so many additional answers when asked about an individual
BSSID). I cannot see any obvious reason why they couldn't make
significant improvements almost immediately.

Not to mention Apple is not necessarily known for allowing older systems
to remain in use, so it'd be curious if they chose precisely a situation
like this to behave differently.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-06, Carlos E.R. <robin_listas@es.invalid> wrote:

On 2026-09-06 17:37, Jon Ribbens wrote:

1. Apple are storing the location of "hidden" WiFi Access Points.
(My opinion: low priority.)

Only Apple?

I think that is what Maria is saying, and I have no information to the contrary.

Allegedly: Apple are adhering to this exclusion, but are not also
excluding BSSIDs which are not broadcasting any SSID at all (i.e.
"hidden" networks). Other organisations (e.g. Google) do exclude such
"hidden" networks.

And if it is hidden they would not see if the SSID ends in _nomap.

But is there a consensus that hidden SSIDs should not be listed? In
writing? Maybe there is such a consensus now.

To me it's fairly intuitive that if someone has taken the unusual step
of explicitly marking their network as "hidden", then its location
should not be included in these databases - especially given the fact
that the "_nomap" SSID method doesn't work for "hidden" networks.

Related: What did Arlen (aka Maria) achieve? That Apple agreed to
remove all hidden and _nomap entries, or that they removed only his
entry?

My impression is that as a result of Maria's communications with them,
Apple updated their documentation to note that "hidden" networks are
still listed in their database, and removed Maria's own BSSID(s) from
the database.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-07 12:18, Jon Ribbens wrote:

On 2026-09-06, Carlos E.R. <robin_listas@es.invalid> wrote:

On 2026-09-06 17:37, Jon Ribbens wrote:

1. Apple are storing the location of "hidden" WiFi Access Points.
(My opinion: low priority.)

Only Apple?

I think that is what Maria is saying, and I have no information to the contrary.

Allegedly: Apple are adhering to this exclusion, but are not also
excluding BSSIDs which are not broadcasting any SSID at all (i.e.
"hidden" networks). Other organisations (e.g. Google) do exclude such
"hidden" networks.

And if it is hidden they would not see if the SSID ends in _nomap.

But is there a consensus that hidden SSIDs should not be listed? In
writing? Maybe there is such a consensus now.

To me it's fairly intuitive that if someone has taken the unusual step
of explicitly marking their network as "hidden", then its location
should not be included in these databases - especially given the fact
that the "_nomap" SSID method doesn't work for "hidden" networks.

Related: What did Arlen (aka Maria) achieve? That Apple agreed to
remove all hidden and _nomap entries, or that they removed only his
entry?

My impression is that as a result of Maria's communications with them,
Apple updated their documentation to note that "hidden" networks are
still listed in their database, and removed Maria's own BSSID(s) from
the database.

AH! Understood.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-07 11:47, Nuno Silva wrote:

(Snipping for brevity for inline replies, sorry that this removes the context, but in this case it probably is preferrable, please refer to
the parent post for the full context:)

(And thanks for the post, Jon, it does indeed make things clearer to understand at least for me.)

On 2026-09-06, Jon Ribbens wrote:

The purpose of these databases of BSSID locations is to assist devices
such as mobile phones in locating themselves. Maybe the device is
indoors and cannot get a GPS signal, but also my understanding is that
GPS can fix an accurate location much faster if it starts already
knowing vaguely where on the planet it is.

There was already a mechanism to do this at least since "3G" using
mobile data connections, right?

Yes. It was possible since GSM was invented, but somebody had to figure
out that, and design a methodology. Initially, it involved a written
request to the mobile network provider to do calculations using dumps of
logs from each tower that could be involved.

And at some time it was automated, and phones could find their rough
location instantly.

2. Apple's API is trivial to abuse.
(My opinion: high priority.)

(I think this is one of the aspects that was made only implicit in most
of the thread, and it would have helped if it was made more explicit...)

[...]

My opinion: the lack of restrictions on the Apple API is unacceptable,
and if Apple are unwilling to do something about it then governments
should pass laws (or enforce existing laws) to make them to do so.

I'm leaning towards existing laws being more than sufficient, in
developed countries.

My opinion: it would be difficult for Apple to rapidly switch completely
to using an API more similar to Google's API, since this would remove
functionality from devices running old software. However they could
certainly aim to do this eventually, and there are steps they could take
immediately to improve the situation (e.g. rate limiting, and not
providing so many additional answers when asked about an individual
BSSID). I cannot see any obvious reason why they couldn't make
significant improvements almost immediately.

Not to mention Apple is not necessarily known for allowing older systems
to remain in use, so it'd be curious if they chose precisely a situation
like this to behave differently.

Oh, they have to support their existing supported hardware at least, and
phase them out slowly. Years.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-07 01:16, Maria Sophia wrote:

After having read the prior responses in this Jon/Carlos tangent...

I apologize if I haven't explained the situation to the liking of people
who haven't clicked on the references, but I am happy that Jon and Carlos (and Andy and Lawrence, all of whom I respect) are trying to understand.

I especially wish to thank Jon Ribbens and Carlos & any others who have bothered to read the links provided, because they explain the issue well.

If people haven't read the references, then they're stuck in the stone age
of understanding, which, well, which I'm not the one to drag them out of.

I just don't have the skills to explain that an SSID is not a BSSID
(as witnessed by those who claimed changing the SSID changes the BSSID).

These are basic networking concepts.

We didn't ask to have it explained. Knowing this is not about skills,
though. A mathematician can have very high skills, yet know nothing
about networks. Even a skilled computer programmer may not know about
them, and be a world master on IBM big iron assembler programming (and
being paid handsomely - a tiny fact I happen to know) and not know
offhand what the BSSID is.

Regarding locations, I don't have the skills to explain what a set of GPS coordinates means, if people claim it's "just a map". I don't even know
_how_ to _begin_ to explain that your home address is NOT "just a map".

I don't even know how to explain to people who claim that the router never travels as their belief system is so absurd as to warn me that if they
don't understand that people take their routers with them when they move, then that kind of person will never be able to understand, well, anything.

No, we don't travel with our routers.

My router belongs to the ISP and I have to return it when I move, then I
will get a new one at my destination. You should be intelligent enough
to accept this. Maybe doesn't happen in your nook of the world, but you
must understand that you are posting to an international medium.

I apologize that I don't have the skills set to bring folks out of the
stone age, when they claim a home address is "just a location on a map".

Don't be insulting. You can say the same things without insulting people
or being patronizing.

...

When I brought it up to my next-door neighbor, who runs Apple Maps, he said he'd check it out, which, after a few weeks of emails back and forth, we found out that Apple has no intention of honoring the intent of a hidden broadcast (even as we know Google & Mozilla certainly honor that intent).

The Apple lawyers made that very clear to me, as I was shut out from
talking to the engineers once the lawyers were informed of the issue.

I had given up, but recently, I happened to look at Apple's documentation, and I realized Apple proved they had no intent of honoring the long-held intention of a hidden broadcast, by simply changing their documentation.
<https://support.apple.com/en-ie/102515>

Ok, finally. The crux of the issue.

Clearly, I know what I'm talking about, so my well informed assessment,
based on those verifiable facts, is Apple doesn't care about our privacy.

--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Nuno Silva <nunojsilva@invalid.invalid> wrote:
[...]

On 2026-09-06, Jon Ribbens wrote:

The purpose of these databases of BSSID locations is to assist devices
such as mobile phones in locating themselves. Maybe the device is
indoors and cannot get a GPS signal, but also my understanding is that
GPS can fix an accurate location much faster if it starts already
knowing vaguely where on the planet it is.

There was already a mechanism to do this at least since "3G" using
mobile data connections, right?

But, unless I misunderstand the context, the device might not *have* a "mobile data connection". For example a SIM-less tablet/laptop/etc.
might still want to determine its position.

[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-07 13:34, Carlos E.R. wrote:

On 2026-09-07 11:47, Nuno Silva wrote:

(Snipping for brevity for inline replies, sorry that this removes the
context, but in this case it probably is preferrable, please refer to
the parent post for the full context:)

(And thanks for the post, Jon, it does indeed make things clearer to
understand at least for me.)

On 2026-09-06, Jon Ribbens wrote:

The purpose of these databases of BSSID locations is to assist devices
such as mobile phones in locating themselves. Maybe the device is
indoors and cannot get a GPS signal, but also my understanding is that
GPS can fix an accurate location much faster if it starts already
knowing vaguely where on the planet it is.

There was already a mechanism to do this at least since "3G" using
mobile data connections, right?

Yes. It was possible since GSM was invented, but somebody had to figure
out that, and design a methodology. Initially, it involved a written
request to the mobile network provider to do calculations using dumps of logs from each tower that could be involved.

And at some time it was automated, and phones could find their rough location instantly.

I asked ChatGPT for more info. Take with a pinch of salt.

Q: How was it found that the location of a mobile phone (GSM) could be calculated from the data logged by nearby towers? I think it was a
doctorate paper?

A: Yes rCo and I think I know what phenomenon yourCOre remembering. It wasnrCOt a single discovery in one doctoral thesis, but there were
important early academic/industry papers and theses showing that GSM
network measurements could be turned into a geographical position.

The key insight is surprisingly simple: a GSM phone is constantly
measuring the surrounding base stations, not just the tower it is
currently connected to.
What information is available?

A GSM handset/network can provide things such as:

Cell ID rCo which base station/cell the phone is using.
RSSI / received signal strength rCo how strongly it receives
neighbouring cells.
Timing Advance (TA) rCo effectively an estimate of how far the phone
is from its serving base station, in discrete distance steps.
Measurements from several neighbouring base stations.

If you know where the base stations are, these measurements constrain
where the phone can be.

For example, if tower A gives a Timing Advance corresponding roughly to
2 km:

Phone
*
/ \
/ \
/ \
/ \
/ ~2 km \
/ \
O \
Tower A \

The phone should lie somewhere around a circle of roughly 2 km radius.

With another tower:

O Tower B
/ \
/ \
/ \
/ \
/ * \ raE possible position
/ \
/ \
O---------------

Tower A

And with three or more measurements, you can narrow it down considerably.
But there's an even more interesting version

You don't necessarily need an explicit distance measurement.

The phone reports the signal strengths of surrounding cells. Because
radio signals generally get weaker with distance, you can construct an approximate relationship like:

signal strength raA estimated distance raA geographical position

This is called RSS-based positioning, and with three or more stations it
can resemble trilateration.

However, radio propagation is messy rCo buildings, reflections, terrain, antenna patterns, etc. mean that RSS isn't a reliable direct distance measurement. That's why another approach became very important: fingerprinting.

You can drive around an area recording:

Location Cell A Cell B Cell C Cell D --------------------------------------------------
40.123, -3.21 -55 -72 -81 -90
40.124, -3.21 -58 -69 -79 -88
40.125, -3.21 -63 -65 -76 -91
...

Then, when an unknown phone produces:

Cell A = -60
Cell B = -67
Cell C = -77
Cell D = -89

you look for the place in the database whose "radio signature" most
closely matches it.

That's GSM fingerprinting, and it's actually a very powerful idea.
And your memory of a doctorate/thesis is plausible

There are quite a few doctoral works in this area.

One particularly relevant early work is Christopher Drane, Malcolm
Macnaughtan and Craig Scott, rCLPositioning GSM Telephones,rCY published in IEEE Communications Magazine in 1998. Interestingly, the authors say
they had achieved accurate position measurements using GSM as early as
May 1996.

There is also Jian Zhu's 2006 Georgia Tech PhD dissertation,
Indoor/Outdoor Location of Cellular Handsets Based on Received Signal Strength, specifically investigating handset positioning from the
received signal strengths of surrounding base stations.

And a later PhD dissertation, Zaenab Shakir (Florida Institute of
Technology, 2020), deals explicitly with geolocation from signal level measurements and Timing Advance inside the cellular network.

There is also a particularly interesting doctoral thesis by Lauri Wirola
on the evolution of cellular positioning standards, covering methods
based on cell coverage combined with time delay, time difference and
received signal strength.
One subtle point

If what you remember is specifically "someone discovered that you could reconstruct the location of a phone from the logs of the towers, without
GPS", then I suspect you're remembering something slightly different
from ordinary GSM triangulation.

There are techniques where the network's existing logs/measurements rCo serving cell, neighbouring-cell measurements, Timing Advance, handovers,
etc. rCo can be accumulated over time and used to infer a person's route/location.

That gets particularly interesting because you don't need to know the
phone's GPS position at all. The cellular network itself becomes a kind
of enormous, distributed positioning system.

If you tell me roughly when you encountered the paper (1990s / 2000s /
2010s) or whether it was about GSM specifically, mobile-phone
surveillance, or anonymised phone records, I can try to track down the
exact PhD paper you're remembering.


Sources:

PPubMed Central (PMC)
A Modular Localization System as a Positioning Service for Road
Transport - PMC
CCiteSeerX
Positioning GSM Telephones
GGeorgia Tech Repository
Indoor/Outdoor Location of Cellular Handsets Based on Received
Signal Strength
SScholarship Repository
"Geolocation Based on Signal Level Measurement and Time Advance
Inside " by Zaenab Shakir
TTampere University Research Portal
Studies on location technology standards evolution in wireless
networks - Tampere University Research Portal
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Jon Ribbens wrote:

I donot understand what youore complaining about, exactly. Your wi-fi
network broadcasts its existence to all and sundry, and yet you feel
upset when somebody collects that information and passes it on.

I guess it is because the SSID is terminated in _nomap, which is
documented as a flag to Apple and others to not store this SSID in their
maps. But Apple is/was mapping them all the same.

I got the impression they were claiming that their SSID was hidden,
which makes it irrelevant as to whether it has "_nomap" at the end
of it, but that Apple had somehow discovered and logged it nonetheless.
It seems highly implausible.

Hi Jon,

I appreciate your intelligence as you got everything right tactically.
You even got the fact of how shocking the truth is, correct!

You said what Apple is doing is, to you, "highly implausible".
I would agree, had I not been horrified to find out Apple is doing it!

The fact Apple is doing it shocked me, which is what started this quest.
At that time, Apple said nothing about whether they're doing it.

But I have letters from Apple lawyers saying they will document it.
And they did.

So...

It's not only not "highly implausible", but Apple now *says* they do it!
<https://support.apple.com/en-ie/102515>

That documentation, which I have in my email records dated months before it
was documented, from Apple lawyers, saying that they'd document it, makes
it pretty plausible after all.

The fact Apple documents it, when they didn't document it when I first
brought this to their attention (and to that of the newsgrops), is pretty
good evidence that it's not only NOT "highly implausible" but shockingly
true.

The fact it's true is the shocking part.
Is it not?
--
The great thing about Usenet is people work together to help all learn.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-07, Carlos E.R. wrote:

On 2026-09-07 13:34, Carlos E.R. wrote:

On 2026-09-07 11:47, Nuno Silva wrote:

On 2026-09-06, Jon Ribbens wrote:

The purpose of these databases of BSSID locations is to assist devices >>>> such as mobile phones in locating themselves. Maybe the device is
indoors and cannot get a GPS signal, but also my understanding is that >>>> GPS can fix an accurate location much faster if it starts already
knowing vaguely where on the planet it is.

There was already a mechanism to do this at least since "3G" using
mobile data connections, right?

Yes. It was possible since GSM was invented, but somebody had to
figure out that, and design a methodology. Initially, it involved a
written request to the mobile network provider to do calculations
using dumps of logs from each tower that could be involved.

And at some time it was automated, and phones could find their rough
location instantly.

I asked ChatGPT for more info. Take with a pinch of salt.

(What you included is interesting too, but to be clear what I was
referring to is the "supl" APN type, which AFAIK is intended to be used
for positioning information? But it's not something I've researched at
all, the extent of my knowledge was searching to try to understand the
values in that comma-separated list many years ago.)
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Carlos E.R. wrote:

These are basic networking concepts.

We didn't ask to have it explained. Knowing this is not about skills, though. A mathematician can have very high skills, yet know nothing
about networks. Even a skilled computer programmer may not know about
them, and be a world master on IBM big iron assembler programming (and
being paid handsomely - a tiny fact I happen to know) and not know
offhand what the BSSID is.

Hi Carlos,

The facts are incontrovertible, where only Jon went to the trouble to
reproduce them (AFAwK). Everyone else simply used their stone-age knowledge
of networking (which we all knew decades ago) to apply to this thread.

Winston just did that, multiple times in this thread, as if stating his own stone-age knowledge of networking has anything to do whatsoever with the
topic. Franklin Slootweg tried the same worthless trolling as Winston did.

Please note that there's nothing wrong with people's stone-age knowledge of networking, but their stone-age knowledge, while true, doesn't apply here.

If all they can do in response to the facts posted in this thread is repeat their stone-age thought processes, then they can't possibly add value.

Then you have the trolls like Keith Thompson claiming that running python
on Windows to prove what Apple & Android devices do by default with respect
to Wi-Fi protocols has absolutely nothing to do with running python on
windows to prove how Apple & Google devices differ from how they handle
Wi-Fi metadata.

WTF?

These people are all applying their stone-age knowledge of networking, but without taking into account the verified *new* information in this thread.

Not a single person who trolled this thread shows any understanding of it.

I don't even know how to explain to people who claim that the router never >> travels as their belief system is so absurd as to warn me that if they
don't understand that people take their routers with them when they move,
then that kind of person will never be able to understand, well, anything.

No, we don't travel with our routers.

My router belongs to the ISP and I have to return it when I move, then I will get a new one at my destination. You should be intelligent enough
to accept this. Maybe doesn't happen in your nook of the world, but you
must understand that you are posting to an international medium.

WTF?
What kind of absurd arguments are you claiming Carlos?

I don't like broccoli, so nobody on the planet likes broccoli?

More to the point, I don't bring the paintings on my wall with me when I
move, but that doesn't mean that nobody brings their paintings with them.

The fact you get your access point from the ISP, while true, is an absurd
way of your attempt to refute the facts proposed in this respected paper.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

I do take my many access points with me, Carlos. Dozens of them.
And even if I didn't, it would still refute NOTHING in that research paper.

The fact that's your major rebuttal indicates you haven't read the paper.
Read it. Please.

I had given up, but recently, I happened to look at Apple's documentation, >> and I realized Apple proved they had no intent of honoring the long-held
intention of a hidden broadcast, by simply changing their documentation.
<https://support.apple.com/en-ie/102515>

Ok, finally. The crux of the issue.

It's not hidden.
It is, after all, in the SUBJECT line of this thread, Carlos.

Every person who tried it, found out every single statement to be true.
--
My role on Usenet is to always add value that other people aren't aware of.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Carlos E.R. wrote:

1. Apple are storing the location of "hidden" WiFi Access Points.
(My opinion: low priority.)

Only Apple?

I think that is what Maria is saying, and I have no information to the
contrary.

Allegedly: Apple are adhering to this exclusion, but are not also
excluding BSSIDs which are not broadcasting any SSID at all (i.e.
"hidden" networks). Other organisations (e.g. Google) do exclude such
"hidden" networks.

And if it is hidden they would not see if the SSID ends in _nomap.

But is there a consensus that hidden SSIDs should not be listed? In
writing? Maybe there is such a consensus now.

To me it's fairly intuitive that if someone has taken the unusual step
of explicitly marking their network as "hidden", then its location
should not be included in these databases - especially given the fact
that the "_nomap" SSID method doesn't work for "hidden" networks.

Related: What did Arlen (aka Maria) achieve? That Apple agreed to
remove all hidden and _nomap entries, or that they removed only his
entry?

My impression is that as a result of Maria's communications with them,
Apple updated their documentation to note that "hidden" networks are
still listed in their database, and removed Maria's own BSSID(s) from
the database.

AH! Understood.

Hi Jon & Carlos,

The two of you show potential in being able to understand the problem set. Below are a few very important details that you don't know yet.

You're pretty far ahead of everyone else though.
Vert far ahead, in fact, in terms of understanding the problem set.

Everyone else is in the stone age, but you're in the modern era.
So this is just listing a few more important details you need to know.

I appreciate that Jon Ribbens not only reproduced my own horror when I
found my own BSSID in Apple's database (and in no other databases!), but
that he explained correctly to Carlos that only Apple does this.

While every one of us likely has the same stone-age knowledge of Wi-Fi networking, the information in this thread is new to almost all of you.

It was even new to me, last December, when, much to my horror, after I read this paper, I found my own hidden-broadcast BSSID/GPS pairs in Apple's db!
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

I was horrified!

The instant I read that paper, I did what almost all of us would do, which
is I ran the code to see if what the researches said was true.

It was true!
I was shocked.

As Jon has said elsewhere in this thread, what Apple does is
"highly implausible"

Especially for a company that claims
"we value your privacy"

But the facts are shown, in this thread, easily reproduced as Jon and I
have done so, that no application of our stone-age wireless networking
prepares us for the shock that Apple ignores all common privacy
conventions.

Shockingly, even Google respects the hidden-broadcast BSSID.
And those who know me know I don't congratulate Google easily.

But to Jon in particular, and Lawrence, and maybe also Andy, what you don't suspect most likely, is HOW the hidden-broadcast is handled by
Apple/Google.

What almost nobody will know unless they researched it with the security professionals, as I have done so, is they handle it different.

Mozilla is documented to say they won't even COLLECT it.
a. Let alone save it on the device. Let alone upload it to a cloud db.
b. Let alone

Likewise, Android devices never even *see* it (Winston's absurd denial to
that fact being brought out as this is the point of me explaining that Winston's stone-age understanding is two or three decades old).

If Android devices can't even *see* it, they don't collect it, save it on device, upload it, store it in a database (or even cull it from the
database), nor can they let anyone in the world see it as it's not there.

Only Apple does it the way Apple does it.

Not only does Apple see it, but they collect it.
a. They save it on device.
b. They upload it to the cloud
c. They do not cull it (even though the SSID ends with _nomap!

Worse. unlike Google/Mozilla and everyone else we know of,
Apple does not protect it from being tracked by anyone in the world.

That's pretty bad.
Is it not?
--
When I write a thread, it's about something important most people
can't even fathom, so it takes intelligence to understand the topic.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Carlos E.R. wrote:

And hiding SSIDs is a complete waste of time, which gains you nothing
in security or privacy. Donot do it.

Yep.

There are two fundamental issues which are making this task more difficult:
1. The common trolls are *desperate* to infest this thread
(and yet, not a single one of the trolls can possibly add value),
2. And, people who are NOT trolls, like Carlos above, still do not
(yet) understand the topic because they're applying old knowledge.

Anyone who thinks he'll understand this topic who only knows the stone-age networking basics (which we all know) will *never* understand this topic.

Anyone who says "yep" to that statement, fundamentally doesn't understand
that hiding the broadcast works for every outfit on the planet we know of.

Except Apple.

When I write a thread, it's about something important most people
can't even fathom, so it takes intelligence to understand the topic.

None of the common trolls, Hank or Franlin or Wolfan, et al. has the intelligence to even begin to understand this topic.

Yet, these trolls, like Nuno Silva, feel *desperate* to say "something", (anything!) because they simply cannot comprehend the topic at hand.

However, some people are intelligent, who, unlike Nuno or Winston or
Franklin or Hank, et al., have the intelligence to comprehend the topic.

Only the people who possess the minimum intelligence, can add value here.
Not the common trolls like Winston, Slootweg, Nuno Silva, Wolfan, et al.

Carlos, to his credit, is *trying* to bring his level of knowledge out of
the stone age of networking, which, let's be clear, we all start with that.

But this topic is not from the stone age of networking.
This topic is new.

If people can't follow the trail of the BSSID from the home router to the
mass surveillance team somewhere in Russia (or at R122 at Fort Mead), then they have not understood how *different* things are in the modern day.

Three fundamental modern facts need to be understood before someone, like Carlos did above, simply claims "yep" to something completely incorrect.

1. Apple iOS devices see & collect & store & upload BSSID/GPS pairs
*COMPLETELY DIFFERENTLY* than do Google Android devices.

If you don't know that difference, you know nothing about this topic.
You're in the stone age of knowledge.

That isn't bad. It just means you have to seek to understand before
you say "yep" to obviously incorrect assessments of the situation.

2. Apple stores, vets, culls, and distributes its internal WPS cloud db
*COMPLETELY DIFFERENTLY* than does Google/Mozilla (and others).

If you don't know that difference, you know nothing about this topic.
You're in the stone age of knowledge.

That isn't bad. It just means you have to seek to understand before
you say "yep" to obviously incorrect assessments of the situation.

If anyone is stuck in the stone age of knowledge level, that's fine, as there's nothing wrong with the stone-age knowledge that, oh, say,
Winston spewed.

But spewing stone-age knowledge does not help when we all know the
stone-age knowledge of networking.

What would help is if people understood the path of the BSSID/GPS pair.
--
When I write a thread, it's about something important most people
can't even fathom, so it takes intelligence to understand the topic.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-07 20:06, Maria Sophia wrote:

Carlos E.R. wrote:

These are basic networking concepts.

We didn't ask to have it explained. Knowing this is not about skills,
though. A mathematician can have very high skills, yet know nothing
about networks. Even a skilled computer programmer may not know about
them, and be a world master on IBM big iron assembler programming (and
being paid handsomely - a tiny fact I happen to know) and not know
offhand what the BSSID is.

Hi Carlos,

The facts are incontrovertible, where only Jon went to the trouble to reproduce them (AFAwK). Everyone else simply used their stone-age knowledge of networking (which we all knew decades ago) to apply to this thread.

Winston just did that, multiple times in this thread, as if stating his own stone-age knowledge of networking has anything to do whatsoever with the topic. Franklin Slootweg tried the same worthless trolling as Winston did.

Please note that there's nothing wrong with people's stone-age knowledge of networking, but their stone-age knowledge, while true, doesn't apply here.

If all they can do in response to the facts posted in this thread is repeat their stone-age thought processes, then they can't possibly add value.

Then you have the trolls like Keith Thompson claiming that running python
on Windows to prove what Apple & Android devices do by default with respect to Wi-Fi protocols has absolutely nothing to do with running python on windows to prove how Apple & Google devices differ from how they handle
Wi-Fi metadata.

WTF?

Wrong.

Keith Thompson argues that your post is off topic in comp.lang.python,
because you are not discussing python code. You simply posted a link
that contains a reference to a Python program and said you run it. You
are not discussing the code itself or making any question about it.

And he is right, IMNSHO.

These people are all applying their stone-age knowledge of networking, but without taking into account the verified *new* information in this thread.

Not a single person who trolled this thread shows any understanding of it.

I don't even know how to explain to people who claim that the router never >>> travels as their belief system is so absurd as to warn me that if they
don't understand that people take their routers with them when they move, >>> then that kind of person will never be able to understand, well, anything. >>

No, we don't travel with our routers.

My router belongs to the ISP and I have to return it when I move, then I
will get a new one at my destination. You should be intelligent enough
to accept this. Maybe doesn't happen in your nook of the world, but you
must understand that you are posting to an international medium.

WTF?
What kind of absurd arguments are you claiming Carlos?

It is fact, Arlen.

I don't like broccoli, so nobody on the planet likes broccoli?

More to the point, I don't bring the paintings on my wall with me when I move, but that doesn't mean that nobody brings their paintings with them.

I did not say "nobody". That's you reading what is not in what I said.

The fact you get your access point from the ISP, while true, is an absurd
way of your attempt to refute the facts proposed in this respected paper.

I don't refute anything, except that you can only track a minority of
users worldwide.

*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

I do take my many access points with me, Carlos. Dozens of them.
And even if I didn't, it would still refute NOTHING in that research paper.

The fact that's your major rebuttal indicates you haven't read the paper. Read it. Please.

No.

I had given up, but recently, I happened to look at Apple's documentation, >>> and I realized Apple proved they had no intent of honoring the long-held >>> intention of a hidden broadcast, by simply changing their documentation. >>> <https://support.apple.com/en-ie/102515>

Ok, finally. The crux of the issue.

It's not hidden.
It is, after all, in the SUBJECT line of this thread, Carlos.

Every person who tried it, found out every single statement to be true.

It is good Usenet manners to explain the subject in the body.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

On 2026-09-07 20:45, Maria Sophia wrote:

Carlos E.R. wrote:

And hiding SSIDs is a complete waste of time, which gains you nothing
in security or privacy. DonN++t do it.

Yep.

There are two fundamental issues which are making this task more difficult:
1. The common trolls are *desperate* to infest this thread
(and yet, not a single one of the trolls can possibly add value),
2. And, people who are NOT trolls, like Carlos above, still do not
(yet) understand the topic because they're applying old knowledge.

...

The point we are saying is not what you claim it to be. It is not about
Apple storing and publishing BSSIDs of hidden SSIDs. This is bad
behaviour by them. Ok. But our point is that you gain nothing by making
your AP hidden in the first place.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Jon Ribbens <jon+usenet@unequivocal.eu> wrote:

On 2026-09-06, Carlos E.R. <robin_listas@es.invalid> wrote:

On 2026-09-06 17:37, Jon Ribbens wrote:

1. Apple are storing the location of "hidden" WiFi Access Points.
(My opinion: low priority.)

Only Apple?

I think that is what Maria is saying, and I have no information to the contrary.

Allegedly: Apple are adhering to this exclusion, but are not also
excluding BSSIDs which are not broadcasting any SSID at all (i.e.
"hidden" networks). Other organisations (e.g. Google) do exclude such
"hidden" networks.

And if it is hidden they would not see if the SSID ends in _nomap.

But is there a consensus that hidden SSIDs should not be listed? In
writing? Maybe there is such a consensus now.

To me it's fairly intuitive that if someone has taken the unusual step
of explicitly marking their network as "hidden", then its location
should not be included in these databases - especially given the fact
that the "_nomap" SSID method doesn't work for "hidden" networks.

I guess the challenge here is how can they know not to add the MAC address
if the SSID with the "_nomap" request invisible.

Related: What did Arlen (aka Maria) achieve? That Apple agreed to
remove all hidden and _nomap entries, or that they removed only his
entry?

My impression is that as a result of Maria's communications with them,
Apple updated their documentation to note that "hidden" networks are
still listed in their database, and removed Maria's own BSSID(s) from
the database.

That's purely a correlation. It could be a coincidence. And is there any evidence that the documentation did change? We only have his say so.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.lang.python

Maria Sophia <mariasophia@comprehension.com> writes:
[...]

Then you have the trolls like Keith Thompson claiming that running python
on Windows to prove what Apple & Android devices do by default with respect to Wi-Fi protocols has absolutely nothing to do with running python on windows to prove how Apple & Google devices differ from how they handle
Wi-Fi metadata.

WTF?

[...]

That is, of course, not at all what I wrote.

I'll give you the benefit of the doubt by assuming that you actually
understood my point, which is that you are writing multiple long
posts on comp.lang.python with no content about programming in
Python, and that that's inappropriate. Assuming that you're
intelligent enough to understand that, I can only conclude that
you are deliberately lying about me.

(On the other hand, if you actually believe what you wrote above,
that raises more serious concerns about your veracity.)

The fact that you would lie about something so easily verifiable
does not fill me with confidence that you're being truthful about
whatever issue you're talking about with respect to Apple and Wi-Fi.
It's obviously something that you consider very important, so you
might consider not behaving in a manner that will piss off reasonable
people and lead them to question your honesty.

I lack both the background and the interest to directly verify or
refute your claims. For all I know, everything you've been saying
might be perfectly accurate. But because of the reputation you've
constructed for yourself here, I can't be sure of that.

I urge everyone participating in this thread to *at least* drop comp.lang.python from the "Newsgroups:" header line, even if Maria
adds it back. (I've left it in place for this followup, since I'm
discussing topicality in comp.lang.python.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
--- Synchronet 3.22a-Linux NewsLink 1.2