From Newsgroup: comp.mobile.android

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.mobile.android

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.mobile.android

Nuno Silva <nunojsilva@invalid.invalid> wrote:
[...]

Hm, yes? If the identifier is constant and is tied to a location you're
in frequently, like where you live, it can be used to track that.

As others have mentioned, this all has been 'discussed' umpteen times
Sofar, this thread is not bringing any new information, viewpoints,
<whatever>.

A summary of the previous times:

At best, a home router's BSSID is tied to a *household*, *not* to a
*person*, which is 'Arlen''s 'privacy concern'.

'Arlen' has a wife. What is the BSSID's location 'tracking'? 'Arlen'?
His wife? His dog?

Case in point: I'm sometimes 18000km away from the location of my
router. Quite a bit of a (location) tracking error, don't you think?

My advice/request: Let it rest. The rest of us would appreciate not
seeing the same non-arguments over and over again.

[...]
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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.mobile.android

On 2026-09-06 20:10, Frank Slootweg wrote:

Nuno Silva <nunojsilva@invalid.invalid> wrote:
[...]

Hm, yes? If the identifier is constant and is tied to a location you're
in frequently, like where you live, it can be used to track that.

As others have mentioned, this all has been 'discussed' umpteen times Sofar, this thread is not bringing any new information, viewpoints, <whatever>.

A summary of the previous times:

At best, a home router's BSSID is tied to a *household*, *not* to a *person*, which is 'Arlen''s 'privacy concern'.

'Arlen' has a wife. What is the BSSID's location 'tracking'? 'Arlen'?
His wife? His dog?

Case in point: I'm sometimes 18000km away from the location of my
router. Quite a bit of a (location) tracking error, don't you think?

My advice/request: Let it rest. The rest of us would appreciate not
seeing the same non-arguments over and over again.

[...]

The new information, in not a clear form, is that Arlen got Apple to do "something". What, is not clear, but I guess they simple removed his
router from the list, so that he stops complaining to his neighbour (the
one that works for Apple or has high contacts at Apple).
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

Carlos E.R. wrote:

My advice/request: Let it rest. The rest of us would appreciate not
seeing the same non-arguments over and over again.

[...]

The new information, in not a clear form...

Hi Carlos,

<exasperated-sarcasm> because of the ignorance exhibited by some posters...

Let's ignore, for the moment, how *desperate* Franklin Slootweg is to troll
Newsgroups: alt.comp.os.windows-10,comp.mobile.android,alt.comp.microsoft.windows
Subject: This is another request to ask Frank Slootweg to stop trolling this ng
Message-ID: <117kuh5$kt1$1@nnrp.usenet.blueworldhosting.com>

Clearly, Franklin hasn't read the papers, nor the cites, nor even any of
the posts in this thread, since everything he said is dead wrong...

Franklin didn't read a single word that was said in this entire thread.
Not one word.

So, of course, Franklin Slootweg has no idea whatsoever of the topic here.

But you are correct that the *new* information, is super secret & so well diabolically hidden from those like Franklin that they'll never find it.

You must congratulate us on how diabolically clever we were in hiding it. Franklin Slootweg, being a troll, will _never_ find out what's new, Carlos.

But you can, can't you.
HINT: *Simply L@@K at the SUBJECT of this thread for the hidden answer...*

Isn't it amazing how well we hid from Frank what's new in the SUBJECT line!

</exasperated-sarcasm> due to the ungodly ignorance being exhibited here...
--
Some can't ever contribute to a topic but they feel they must still troll.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

....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.mobile.android

(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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

On 2026-09-07 02:31, Maria Sophia wrote:

Carlos E.R. wrote:

My advice/request: Let it rest. The rest of us would appreciate not
seeing the same non-arguments over and over again.

[...]

The new information, in not a clear form...

Hi Carlos,

<exasperated-sarcasm> because of the ignorance exhibited by some posters...

Let's ignore, for the moment, how *desperate* Franklin Slootweg is to troll

That is OT and not in evidence.
I only see a single post of him in this thread, in the Android group. I
don't see why you can be that angry at him.

...

But you can, can't you.
HINT: *Simply L@@K at the SUBJECT of this thread for the hidden answer...*

It is good Usenet manners to explain the SUBJECT in the body.

Isn't it amazing how well we hid from Frank what's new in the SUBJECT line!

</exasperated-sarcasm> due to the ungodly ignorance being exhibited here...

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

From Newsgroup: comp.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

On 2026-09-07, Maria Sophia wrote:

Not a single person who trolled this thread shows any understanding of
it.

The gist of it is that any person you regard as not having understood it
is "trolling" by your book. So this is almost tautological.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

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.mobile.android

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.mobile.android

On 2026-09-07 20:11, Nuno Silva wrote:

On 2026-09-07, Maria Sophia wrote:

Not a single person who trolled this thread shows any understanding of
it.

The gist of it is that any person you regard as not having understood it
is "trolling" by your book. So this is almost tautological.

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

From Newsgroup: comp.mobile.android

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.mobile.android

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.mobile.android

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.mobile.android

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

From Newsgroup: comp.mobile.android

On 2026-09-07, Keith Thompson wrote:

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 once thought like you did and still gave them the benefit of
doubt. (Check the "How does whatsapp work?" thread (subjects changed
halfway several times, rooted at [1]) on comp.mobile.android.) Then they attacked you and Frank in this fashion.

[1] <n1ua9ltc3losq5kj0lfkh8lim4t3bp4npf@4ax.com>

In the end, they destroyed any value their words could have had. In the
past few hours there was another post with nice words to somebody else,
but those words mean nothing, for all it takes is a small bit flip
somewhere and you're suddenly a "troll" to them.

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.)

Yeah, indeed. But which groups are you reading, of the remaining ones?
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android


Removing comp.lang.python on the petition from them.

On 2026-09-08 00:28, Chris wrote:

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.

The thing is, the single thing of hiding the SSID marks the intention
that this AP should not be mapped.

Maybe there is not a paper that says this, but google and Mozilla are
doing so. Apple was not doing it, and apparently they wrote now in their documentation that they not doing it. ie, they wrote that they will
record hidden sites.

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.

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

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

On 2026-09-07 20:11, Nuno Silva wrote:

On 2026-09-07, Maria Sophia wrote:

Not a single person who trolled this thread shows any understanding of
it.

The gist of it is that any person you regard as not having understood it
is "trolling" by your book. So this is almost tautological.

Correct...

Please don't even bother to read this unless you're NUNO SILVA.
(it's about his disgusting propensity to troll without ever adding value)

I'm getting sick & tired of the disgusting trolls infesting this thread.
We're trying to get something done, which none of the trolls are trying.

These disgusting trolls, like Nuno Silva, don't add value.
They subtract value with every post.

Since Carlos is agreeing with the bullshit coming from the known
disgustingly worthless common troll, Nuno Silva, I won't bother with Carlos
on this topic other than to point out that none one of the wortheless
common trolls (Winston, Slootweg, Silva, Rogers, et al.) added even a
single iota of value to this thread topic. Not one of them.

Only one person who postedto this newsgroup understood the topic.
Just one.

Nobody else has any inkling of what they're talking about.
And yet, they claim that them being wrong means I call them a troll.

No.
Not at all.

The record shows I corrected Lawrence, who is not a troll.
I corrected Andy, who is not a troll.
I corrected John, who is not a troll.

But Nuno Silva is a known worthless disgusting troll.
Even so, the fact he's wrong isn't the issue.

The fact he's just trolling is the issue.
Not that he's wrong.

He's wrong, for sure, but he's trolling, which makes being wrong not the
point. He thinks he can troll all he wants, and he can. He does. He will.

But I'll call him out for not adding a single iota of value to this topic.
He's so stupid he can't get that simple observable fact in his head.

I'd treat him respectfully, and I will in the future, when he acts like an adult, but when all he does is troll this newsgroup, then I call him out.

This disgusting troll thinks he can say utter garbage, and then, when it's refuted, he claims (like the Apple trolls do) it's a difference of opinion.

WTF?
This disgustingly worthless troll Nuno Silva knows *NOTHING* about this
topic, and worse, this disgusting troll keeps trolling the ng nonetheless.

*PLEASE STOP YOUR DISGUSTING TROLLS, NUNO SILVA!*
*JUST STOP IT.*

Either add value.
Or shut up.

Since it's obvious you can't possibly ever add value, that means
SHUT UP

I apologize to everyone that the trolls have infested this thread topic.
They can't understand it. So they troll it.

Why?
I don't know why.

They're *desperate* to say "something" (anything!) even as they can't
possibly add even a single iota of value to this particular thread topic.

When those common disgusting worthless trolls infest a thread, we have to expend energy defending against the absurdity that these disgusting trolls
gang up by congratulating each other on the absurdities of their attacks.

Suffice to say that anyone in this thread who can't follow the exact trail
of a BSSID from your router access point to the python scripts run by Jon
and by me, can't possibly even begin to comprehend the issue.

Note that the breadcrumb trail is COMPLETELY DIFFERENT between how Apple
does it and how Google does it, and that's the whole point of the topic.
--
The infesting trolls feel desperate to post even as they can't add value.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

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.

People can't understand what the issue is if they don't understand the breadcrumb trail from your router access point to my Win10 python runs.

They just can't.
Their stone-age knowledge of networking doesn't prepare them for it.

Keith didn't understand that you have to run the python code that was
pointed to in the very first post, Carlos, which Jon found easily.

The instant I read the paper, I found and ran the Python code on Win10.
Why can Jon and I do it, but Keith complains he can't read the paper?

BTW, Keith can whine all he wants that Python code isn't python code.
But it's clear he's just whining about something he didn't even read.

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.

Jesus Christ, Carlos. Have you never once taken a course in basic logic?

Because you don't own a red car, you claim (in effect) red cars can't
exist. Your entire rebuttal consist of that? WTF? It's ridiculous.

For some odd reason, your claim that because you do it one way, that you
think that refutes the fact that BILLIONS of people do it differently.

I wouldn't mind if you made that preposterous argument only once, as I'd
only need to point out your nonsensical bizarre point of view only once.

But you've been foisting that grotesque farcical rebuttal on us since we started investigating this issue, oh, since way back in December 2026.

When will you stop proposing that absurd rebuttal that the fact you don't
own a red car, you think, negates the fact that billions of other people
can own red cars?

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.

Clearly you did not read the paper. Read it Carlos.

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

Do not respond until you've shown you read the paper, please.

The fact that's your major rebuttal indicates you haven't read the paper.
Read it. Please.

No.

If someone hasn't read the paper, they can't possibly understand the issue.


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

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.

The subject says:
a. Apple changed their documentation
b. at my request
c. but it proves they don't care about privacy

Since we provided the old documentation in the past, those trolls (like Winston) who said there's no "proof", were simply trolling us, as they
didn't even read to know it never said that until after I contacted them.

At my request, would be hard for anyone here to verify, although the time points all line up, as you all know I complained about this back in
December, and I stated then, that I had my neighbor file the RADAR report.

I also stated at that time, they removed my hidden BSSID, but I'm likely
the only one in the world who has had that favor (as far as we would know).

The part about privacy is harder for people on this group to comprehend
since they're all seemingly stuck in the stone age of wireless networking.

They don't know how to follow the BSSID/GPS breadcrumb trail from an iOS or Android device (as it's very different!) to the Apple or Google database
(as that's different too!) and eventually to the Python code that Keith
says doesn't exist but which both Jon and I dutifully ran to confirm.

To put it bluntly, everyone but Apple will NOT distribute your BSSID if
it's hidden broadcast. Only Apple refuses to abide by that convention.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Keith Thompson wrote:

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.)

Hi Keith,

Python group dropped in the f'up, where there are only two people on that
group who matter, so I hope they don't lose out because it's being dropped.

Also dropped are the iOS group, as only the trolls (Chris, Wolfan)
responded, so it is a waste to ever include Apple people on any thread.

Also dropped is Android as, at least Android devices won't even *see* the
BSSID when hidden (let alone collect it, save it, upload it, for it to
later be scrubbed because SSID contains, also, the _nomap directive).

So it's really an Apple-only problem anyway, although, everyone owns a
router (so to speak) whether or not they own Android or iOS devices.

The problem isn't caused by Android devices anyway.
The problem is caused by iOS devices alone.

The only reason for the Windows newsgroup is most of the code is batch
code, where the python code does the heavy lifting of delving deeply into
the Apple WPS database, so they work together, Windows and Python.

Although the Python code could just as easily have been run on Linux.
Or macOS.

Anyway, I'll take your concerns to heart, where I think the fact that at
least one person reproduced EXACTLY the claims I made, should be enough for
all to realize everything I've said is not only true, but easily
reproduced.

This is because I'm extremely well educated in the sciences and engineering
so I don't say things which aren't reproducable by others following me.

Nobody, in my decades on Usnent, has ever found a fact I've claimed to be a fact, ever to be wrong, and if, perchance, I make a typo or a forgetful
faux pas, everyone knows I admit to it immediately, as what matters is only
the facts that remain in the Usenet record for generations to read later.

At this point, only the alt.internet.wireless newsgroup remains on the followup. But that's a dead newsgroup, so, while extremely relevant, it
won't go anywhere and this thread will remain the reference that it is.

As a final summary of the situation, as I see it, based on responses,
people can't understand what the issue is if they don't understand the breadcrumb trail from your router access point to my Win10 python runs.

They just can't.
Their stone-age knowledge of networking doesn't prepare them for it.

Jon ran the python code.
I ran it.

Nobody else did (to our knowledge).
So nobody understands what that Python code does.

We both confirmed that it works exactly the way I said it works.
Which, I only know, because I ran the Python code you claim isn't there.

I ran that code the instant I read this paper, in fact.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Knowing that Google doesn't even *see* my hidden-broadcast BSSID, I was horrified to see a dozen of my BSSID/GPS pairs in the Apple WPS database.

That revelation, which started with the Python code, is what started this.
If someone hasn't read the paper, they can't possibly understand the issue.

And, if they haven't set their BSSID to hidden, and run the Python code,
again, they can't possibly understand the issue because all their knowledge
is forever stuck in the stone age of wireless metadata, which, while true, doesn't prepare them for the shock of what that Python code revealed to us.

Their stone-age knowledge of wireless networking doesn't prepare them.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

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.

Removing all but alt.internet.wireless from the f'up since the Apple trolls (Chris, in this instance) are bullshitting us like there's no tomorrow.

The BSSID:GPS breadcrumb trail is very DIFFERENMT between iOS & Android
devices & it's very DIFFRERENT between Python & the Apple/Google databases.

First off, we discussed this in December, in gory detail, and we covered EXACTLY what the Apple documentation said, and we discussed EXACTLY that I
went to a my next-door neighbor, who is an executive at Apple to get it corrected, and we discussed, THEN, that it wasn't documented, for God's
sake.

Moreso, as we know now, it's corrected.
<https://support.apple.com/en-ie/102515>

So the bullshit that Chris (a known Apple religious zealot troll) spewed is classic Apple troll bullshit spewed for no other reason than to defend his Apple God to the death, no matter what, using the first absurdly
preposterous argument he can come up with.

Hell, even if everything I said wasn't true (& in the record) the very fact that Apple documentation says it TODAY proves the veracity of my point.

The Apple religious zealots will stop at nothing to protect Apple's honor.

Yet, what matters for the people on this newsgroup who are not Apple
religious zealots who defend Apple to the death no matter what, using the
first preposterous excuse they can think off... the facts remain facts.

Likely only one out of ten million people know what I'm saying below...
(which is why having a stone-age knowledge of networking, doesn't help)

1. Only Apple iOS devices, by default, upload a hidden-broadcast BSSID.
Specifically, Apple devices see them, they save them, they collect them
into a packet, they upload them, & Apple never scrubs them, by default.

2. Google Android devices, by default, don't even see them (AFAIK).
Certainly Google devices don't upload them to the Google WPS database.

3. Both Apple and Google devices, by default, will upload a non-hidden
broadcast BSSID/GPS pair, but both will scrub those with _nomap.

4. Far worse, and the topic of the paper, Google will NOT allow just anyone
to read their WPS database, and Google has restrictions on number of
outputs and quality of request, and in number of requests per day, etc.

5. Apple has NONE of those controls! None. Zip. Nada. (That's the main
point of the paper for God's sake!).

6. Worse, Apple will give me (and they have) every single BSSID:GPS pair in
the world - that's BILLIONS (which the researchers themselves gathered
using the Python code that Jon & I both used to test it for ourselves).

I only collected tens of thousands, but anyone with almost no technical
skills whatsoever, can clearly track every single BSSID:GPS pair in the
world, from anywhere in the world, using the Python code Jon and I ran.

Those of you who only own the stone-age networking knowledge we all learned decades ago won't be prepared to understand what I just explained to you.

Only Apple does this.
Nobody else (to my knowledge).

The BSSID:GPS breadcrumb trail is very DIFFERENMT between iOS & Android
devices & it's very DIFFRERENT between Python & the Apple/Google databases.
--
People can't understand what the issue is if they don't understand the breadcrumb trail from your router access point to my Win10 python runs.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

I guess the challenge here is how can they know not to add the MAC address >> if the SSID with the "_nomap" request invisible.

The thing is, the single thing of hiding the SSID marks the intention
that this AP should not be mapped.

Maybe there is not a paper that says this, but google and Mozilla are
doing so. Apple was not doing it, and apparently they wrote now in their documentation that they not doing it. ie, they wrote that they will
record hidden sites.

Carlos, to his credit, is correct.

Chris is a known Apple religious zealot who is reaching at straws to defend
his Apple God to the death, using the first absurd denial he can come up
with.

Chris claimed there's no proof that we proved already long ago what Apple documentation said, which is bullshit but even so, we know what it says
now. <https://support.apple.com/en-ie/102515>

The Apple religious zealots can spew all the nutcase bullshit they want to spew, but none of their defenses of Apple's honor changes that
documentation.

Only I got that documentation changed.
Not them.

And that's because Apple *knew* I was right.
They're not stupid.

They're a lot of bad things, but stupid is never one of them.
They knew I had threatened legal consequences if they didn't change it.

Or fix it.
But they decided NOT to fix it.

We covered the EXACT documentation, long ago, where both Mozilla and Google clearly stated they won't even COLLECT the BSSID if it's hidden broadcast.

I provided it already, elsewhere in this thread, so that's a given.
It's well known that a hidden-broadcast is an indicator of desired privacy.

The difference is:
a. Apple ignores that privacy indicator
b. Google/Mozilla respect it

Likely only one out of ten million people know what I'm saying below...
(which is why having a stone-age knowledge of networking, doesn't help)

1. Only Apple iOS devices, by default, upload a hidden-broadcast BSSID.
Specifically, Apple devices see them, they save them, they collect them
into a packet, they upload them, & Apple never scrubs them, by default.

2. Google Android devices, by default, don't even see them (AFAIK).
Certainly Google devices don't upload them to the Google WPS database.

3. Both Apple and Google devices, by default, will upload a non-hidden
broadcast BSSID/GPS pair, but both will scrub those with _nomap.

4. Far worse, and the topic of the paper, Google will NOT allow just anyone
to read their WPS database, and Google has restrictions on number of
outputs and quality of request, and in number of requests per day, etc.

5. Apple has NONE of those controls! None. Zip. Nada. (That's the main
point of the paper for God's sake!).

6. Worse, Apple will give me (and they have) every single BSSID:GPS pair in
the world - that's BILLIONS (which the researchers themselves gathered
using the Python code that Jon & I both used to test it for ourselves).

I only collected tens of thousands, but anyone with almost no technical
skills whatsoever, can clearly track every single BSSID:GPS pair in the
world, from anywhere in the world, using the Python code Jon and I ran.

Those of you who only own the stone-age networking knowledge we all learned decades ago won't be prepared to understand what I just explained to you.

Only Apple does this.
Nobody else (to my knowledge).

The BSSID:GPS breadcrumb trail is very DIFFERENMT between iOS & Android
devices & it's very DIFFRERENT between Python & the Apple/Google databases.
--
People can't understand what the issue is if they don't understand the breadcrumb trail from your router access point to my Win10 python runs.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

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.

Hi Carlos,

I disagree.

The answer to *this* question, will tell you why what you said is wrong:

Q: Will Google's WPS database contain a BSSID:GPS pair for an access point
whose SSID broadcast is set to hidden (i.e., empty or null)?
A: Please answer "yes", or "no".

I know the answer to that question.
You clearly do not.

Once you know the answer to that question, you'll see why what you said,
is dead wrong.

I could ask the same question of the Mozilla MLS, but it's now defunct,
but they document this (and we published that documentation elsewhere).

Only Apple ignores the clear privacy intent of setting a hidden SSID.
Nobody else.

Just Apple. (to our knowledge)
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

Or, worse, trackable information like your car's number plate?

Hi Chris,
I get it you are desperate to defend Apple to the death, no matter what...
But that analogy of the car license plate in a Flock system is absurd.

For anyone to claim that, means they didn't read the paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Once you read that paper, you'll understand that the only analogy that
works is if the Apple Flock system allows anyone in the world to not only
track every single one of the billions of license:gps pairs in the world
with zero restrictions on that Python code, but if that wasn't bad enough,
the Apple flock system outputs the nearest 400 license:GPS pairs every
time.

Jon and I easily could track the movements of every single license plate in
the world, using Apple's Flock camera system, if we felt like it, Chris.

But we could NOT do it with Google's or Mozilla's Flock camera system.

To understand why that is the case, read this paper before responding:
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

R.Wieser 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?

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>

First, let's address Andy's point because Andy didn't read the paper,
so Andy thinks it's about individuals, and not about the masses.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Let's simply apply Flock license-plate readers to that paper by
way of an analogy, but we have to modify the protections, which,
let's be clear, is the entire point of that paper.
A. Flock has protection
B. Google has protection
C. Apple has no protection

With that in mind, let's answer Andy's question using a Flock database.

Does a FLOCK camera need to know who the driver of the vehicle is?
Yes? or No?

What matters is the vehicle is in that spot, at that time, right?
Worse, what matters is ANYONE in the world can run the python script.
So anyone in the world knows all vehicle's locations at that time, right?

Oh, it gets worse.
Not only do they know all vehicle's location, but they get the nearest 400 vehicles every time they query just one vehicle. Google doesn't do that.

Only Apple does that.
But wait, it gets worse.

I wrote the Python code that gets the farthest away BSSID, and then gets the next 400 nearest vehicles. And the next. And the next, And the next.

Just like the researchers said, I could collect the location of every
single vehicle in the world, which is why it's *mass* surveillance.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Andy... it's not "individual" surveillance in that title.
It's "mass" surveillance.

Big difference.
Now back to Rudy's offer of providing the message ID.

1. https://olduse.net/
2. https://article.olduse.net
3. Drat.
Message-ID: <10h1qmr$2alo$1@nnrp.usenet.blueworldhosting.com>
NOT FOUND

Let's try https://usenetarchives.com/
Drat. Failed.

Let's try https://www.ardent-tool.com/other/Links.html
https://csiph.com/search
Bingo!

https://csiph.com/group/alt.comp.os.windows-10/a/10h1qmr%242alo%241@nnrp.usenet.blueworldhosting.com
All my tutorials use freeware so that EVERYONE can use them, but I
wrote this tutorial before I found out about this Apple WPS query:
<https://wavedigger.networksurvey.app/?tab=bssid>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<https://cyberinsider.com/apples-wi-fi-based-positioning-system-is-a-privacy-nightmare/>
*Apple's Wi-Fi-Based Positioning System is a Privacy Nightmare*
"Researchers from the University of Maryland have uncovered a
significant privacy vulnerability in Apple's Wi-Fi-based Positioning
System (WPS). This vulnerability enables attackers to track devices
globally by exploiting the way Apple's WPS operates, raising
serious privacy concerns."
Back to alt.comp.os.windows-10 | Previous | Next iX Next in thread | Find similar | Unroll thread

Thread
Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-06 10:55 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Mario Tomasella <juhgtyui@invalid.invalid> - 2025-12-06 20:08 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-06 14:00 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-07 01:45 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-08 20:47 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-14 02:05 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-14 02:52 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-15 05:21 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-15 12:48 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-17 02:34 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-17 02:52 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-17 03:29 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-18 14:29 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Winston <wbe@UBEBLOCK.psr.com.invalid> - 2025-12-18 16:43 -0500
Re: Tutorial: Query the Apple database with Python for your access point BSSID Paul <nospam@needed.invalid> - 2025-12-19 00:01 -0500
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-21 17:55 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Jeff Liebermann <jeffl@cruzio.com> - 2025-12-21 20:25 -0800
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-21 21:49 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Chris <ithinkiam@gmail.com> - 2025-12-22 15:08 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-22 09:30 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-22 10:39 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Paul <nospam@needed.invalid> - 2025-12-19 04:06 -0500
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-22 10:20 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Andy Burns <usenet@andyburns.uk> - 2025-12-19 10:14 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-19 12:01 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-21 21:32 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-22 09:12 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-22 10:52 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-22 19:34 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-24 11:00 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-24 21:38 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-26 19:23 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-27 19:27 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-27 19:44 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-28 10:11 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-28 10:41 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-28 22:10 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-28 17:12 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-28 17:24 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-28 17:24 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Hank Rogers <Hank@nospam.invalid> - 2025-12-28 19:03 -0600
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-29 08:09 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-29 01:16 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-29 11:32 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-29 04:14 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-29 13:43 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-30 12:07 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-29 07:32 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-29 01:23 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-29 11:46 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-29 04:26 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-29 14:11 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-21 20:35 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Andy Burns <usenet@andyburns.uk> - 2025-12-22 06:28 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-22 10:44 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Andy Burns <usenet@andyburns.uk> - 2025-12-22 06:41 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Chris <ithinkiam@gmail.com> - 2025-12-22 09:27 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-22 10:48 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Andy Burns <usenet@andyburns.uk> - 2025-12-22 18:00 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Char Jackson <none@none.invalid> - 2025-12-22 15:42 -0600
Re: Tutorial: Query the Apple database with Python for your access point BSSID Hank Rogers <Hank@nospam.invalid> - 2025-12-22 19:40 -0600
Re: Tutorial: Query the Apple database with Python for your access point BSSID Chris <ithinkiam@gmail.com> - 2025-12-23 10:00 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Char Jackson <none@none.invalid> - 2025-12-24 00:43 -0600
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-24 06:38 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID WolfFan <akwolffan@zoho.com> - 2026-01-01 15:34 -0500
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-29 01:31 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Andy Burns <usenet@andyburns.uk> - 2025-12-30 17:11 +0000
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-31 12:47 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-30 22:24 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Char Jackson <none@none.invalid> - 2025-12-30 17:18 -0600
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-31 08:03 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-31 00:51 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Char Jackson <none@none.invalid> - 2025-12-31 20:24 -0600
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-31 20:30 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2026-01-01 07:57 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Maria Sophia <mariasophia@comprehension.com> - 2026-01-01 18:37 -0500
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2026-01-01 08:21 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2025-12-31 08:17 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-31 00:57 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Marian <marianjones@helpfulpeople.com> - 2025-12-31 01:17 -0700
Re: Tutorial: Query the Apple database with Python for your access point BSSID Jeff Liebermann <jeffl@cruzio.com> - 2026-01-01 11:07 -0800
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2026-01-01 21:05 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2026-01-01 21:12 +0100
Re: Tutorial: Query the Apple database with Python for your access point BSSID Jeff Liebermann <jeffl@cruzio.com> - 2026-01-01 14:09 -0800
Re: Tutorial: Query the Apple database with Python for your access point BSSID "R.Wieser" <address@is.invalid> - 2026-01-02 09:13 +0100
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 01:46, Nuno Silva wrote:

On 2026-09-07, Keith Thompson wrote:

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 once thought like you did and still gave them the benefit of
doubt. (Check the "How does whatsapp work?" thread (subjects changed
halfway several times, rooted at [1]) on comp.mobile.android.) Then they attacked you and Frank in this fashion.

[1] <n1ua9ltc3losq5kj0lfkh8lim4t3bp4npf@4ax.com>

In the end, they destroyed any value their words could have had. In the
past few hours there was another post with nice words to somebody else,
but those words mean nothing, for all it takes is a small bit flip
somewhere and you're suddenly a "troll" to them.

Him. It is only one person doing this.

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.)

Yeah, indeed. But which groups are you reading, of the remaining ones?

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

From Newsgroup: comp.mobile.android

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

Or, worse, trackable information like your car's number plate?

Hi Chris,
I get it you are desperate to defend Apple to the death, no matter what... But that analogy of the car license plate in a Flock system is absurd.

It's notable to everyone here that you are consistently and obstinately not answering the core question. Why is the collection of public information
that does not relate to an individual a privacy risk?

The Flock issue is off topic here so the only thing I'll say is that this a consequence of lack of American's trust in government. That leaves the door open to commercial companies to collect data and sell it to government
agencies with little to no oversight.

In the UK we have the ANPR system which does the same thing, but is run by
and for the law enforcement agencies. It's use is controlled and regulated. There are no issues.

For anyone to claim that, means they didn't read the paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Once you read that paper,

I have and have understood it better than you.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

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.

Removing all but alt.internet.wireless from the f'up

If you can't even set follow-ups correctly how can we trust any of your technical assertions? [Narrator: We can't. He has all the traits of a
troll. Although, he has stopped nymshifting]

<all but the android and iphone ngs removed >

First off, we discussed this in December, in gory detail, and we covered EXACTLY what the Apple documentation said, and we discussed EXACTLY that I went to a my next-door neighbor, who is an executive at Apple to get it corrected, and we discussed, THEN, that it wasn't documented, for God's
sake.

The story of the Apple exec is just hearsay.

Moreso, as we know now, it's corrected.
<https://support.apple.com/en-ie/102515>

Evidence? Someone with your technical skill and "highly educated" should be able to demonstrate it beyond having to rely on other people's memory.

You are claiming that you are the reason it changed. Again simply hearsay.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia <mariasophia@comprehension.com> wrote:

Nobody, in my decades on Usnent, has ever found a fact I've claimed to be a fact, ever to be wrong, and if, perchance, I make a typo or a forgetful
faux pas, everyone knows I admit to it immediately, as what matters is only the facts that remain in the Usenet record for generations to read later.

<hollow laughter> you regularly make this claim and have to be reminded
each time that neither are you never wrong - such a claim is absurd in the extreme - and that you almost never admit to any errors. What you do do -
as patently evidenced here - is attack, deflect, lie and deny.

As an aside, usenet is not the source of truth you think it is. It is no
longer indexed anywhere and finding anything historical is difficult.
Archives are constantly being deleted or moved.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 05:38, Maria Sophia wrote:

Carlos E.R. wrote:

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.

People can't understand what the issue is if they don't understand the breadcrumb trail from your router access point to my Win10 python runs.

They just can't.
Their stone-age knowledge of networking doesn't prepare them for it.

Keith didn't understand that you have to run the python code that was
pointed to in the very first post, Carlos, which Jon found easily.

He did understand it very well.

He retorts that you are not asking questions about the code or saying
anything about the code itself, thus your post is off topic in the
python group. And you are ignoring this.

The remainder of your post is irrelevant, as it doesn't consider his issue.


Thus removing the python group on their request from this post.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 06:38, Maria Sophia wrote:

Carlos E.R. wrote:

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.

Hi Carlos,

I disagree.

The answer to *this* question, will tell you why what you said is wrong:

Q: Will Google's WPS database contain a BSSID:GPS pair for an access point
whose SSID broadcast is set to hidden (i.e., empty or null)?
A: Please answer "yes", or "no".

I know the answer to that question.
You clearly do not.

I do, as a matter of fact.

Once you know the answer to that question, you'll see why what you said,
is dead wrong.

I could ask the same question of the Mozilla MLS, but it's now defunct,
but they document this (and we published that documentation elsewhere).

Only Apple ignores the clear privacy intent of setting a hidden SSID.
Nobody else.

Just Apple. (to our knowledge)

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

From Newsgroup: comp.mobile.android

On 2026-09-08 09:10, Chris wrote:

Maria Sophia <mariasophia@comprehension.com> wrote:

Chris wrote:

Or, worse, trackable information like your car's number plate?

Hi Chris,
I get it you are desperate to defend Apple to the death, no matter what... >> But that analogy of the car license plate in a Flock system is absurd.

It's notable to everyone here that you are consistently and obstinately not answering the core question. Why is the collection of public information
that does not relate to an individual a privacy risk?

The Flock issue is off topic here so the only thing I'll say is that this a consequence of lack of American's trust in government. That leaves the door open to commercial companies to collect data and sell it to government agencies with little to no oversight.

And the lack of data protection laws like the GDPR in Europe.

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

In the UK we have the ANPR system which does the same thing, but is run by and for the law enforcement agencies. It's use is controlled and regulated. There are no issues.

For anyone to claim that, means they didn't read the paper.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Once you read that paper,

I have and have understood it better than you.

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

From Newsgroup: comp.mobile.android

On 2026-09-08 07:07, Maria Sophia wrote:

R.Wieser 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?

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>

First, let's address Andy's point because Andy didn't read the paper,
so Andy thinks it's about individuals, and not about the masses.
*Surveilling the Masses with Wi-Fi-Based Positioning Systems*
<https://arxiv.org/abs/2405.14975>

Arlen, in this long post of yours you did not address the point R.Wieser
made.

Ok, suppose I run the scripts, and have in my power the BSSIDs and SSIDs
of the entire world. I still do not know which one is yours, Arlen. I
can not track you.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08, Maria Sophia wrote:

Carlos E.R. wrote:

On 2026-09-07 20:11, Nuno Silva wrote:

On 2026-09-07, Maria Sophia wrote:

Not a single person who trolled this thread shows any understanding of >>>> it.

The gist of it is that any person you regard as not having understood it >>> is "trolling" by your book. So this is almost tautological.

Correct...

Please don't even bother to read this unless you're NUNO SILVA.
(it's about his disgusting propensity to troll without ever adding
value)

I don't have an issue at all if you want to change names, as far as
you're not misleading people, but please don't go pick names that are
already in use. I see you've posted a bunch of posts referring to you as
"Nuno Silva", but of course that's not exactly a name that's not in
use. Please stick to Maria or Arlen or Whatever. Or pick something new.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08, Maria Sophia wrote:

Carlos E.R. wrote:

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.

People can't understand what the issue is if they don't understand the breadcrumb trail from your router access point to my Win10 python runs.

They just can't.
Their stone-age knowledge of networking doesn't prepare them for it.

Keith didn't understand that you have to run the python code that was
pointed to in the very first post, Carlos, which Jon found easily.

There being some python code in itself is not a reason to crosspost to comp.lang.python, at least not beyond the initial post.

The instant I read the paper, I found and ran the Python code on Win10.
Why can Jon and I do it, but Keith complains he can't read the paper?

BTW, Keith can whine all he wants that Python code isn't python code.
But it's clear he's just whining about something he didn't even read.

Newsgroups aren't a MIME-Type for linked resources. Even if you disagree
with his assessment, at least you could just understand it, instead of
trying to frame that as something else.

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.

Jesus Christ, Carlos. Have you never once taken a course in basic
logic?

That, coming from you, is rich. In the past few days you've shown you
either know nothing of logic or you just make use of it when it supports
what you're saying, but you throw it away the second it is inconvenient.

Are you perchance in politics?

Because you don't own a red car, you claim (in effect) red cars can't
exist. Your entire rebuttal consist of that? WTF? It's ridiculous.

For some odd reason, your claim that because you do it one way, that you think that refutes the fact that BILLIONS of people do it differently.

Yet you call everybody who puts contacts on an android system contact
store "rude". But maybe others are very careful with what applications
they run on the system?

I wouldn't mind if you made that preposterous argument only once, as I'd
only need to point out your nonsensical bizarre point of view only once.

But you've been foisting that grotesque farcical rebuttal on us since we started investigating this issue, oh, since way back in December 2026.

Ooh, somebody got a DMC-12! :-P

[...]

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.

Clearly you did not read the paper. Read it Carlos.

[...]

Do not respond until you've shown you read the paper, please.

And the others are the ones who aren't adults.

If someone hasn't read the paper, they can't possibly understand the
issue.

Basic logic again. It's perfectly possible peoplee can understand the
issue without reading the paper. So in the *same post* you're chastising
others for "not knowing" basic logic, and you fail at the same.

I love the smell of hypocrisy in the morning...
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08, Carlos E.R. wrote:

On 2026-09-08 01:46, Nuno Silva wrote:

[...]

In the end, they destroyed any value their words could have had. In the
past few hours there was another post with nice words to somebody else,
but those words mean nothing, for all it takes is a small bit flip
somewhere and you're suddenly a "troll" to them.

Him. It is only one person doing this.

(That was singular they, I do not care what their gender is, other than
using the appropriate wording. Given that seems to be a female name and
people are referring using "he" and Arlen did seem to me like a male
name, I just erred on the side of caution and went with they/them.)

(But nevermind me, I'm apparently just trolling.)
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 11:18, Nuno Silva wrote:

On 2026-09-08, Carlos E.R. wrote:

On 2026-09-08 01:46, Nuno Silva wrote:

[...]

In the end, they destroyed any value their words could have had. In the
past few hours there was another post with nice words to somebody else,
but those words mean nothing, for all it takes is a small bit flip
somewhere and you're suddenly a "troll" to them.

Him. It is only one person doing this.

(That was singular they, I do not care what their gender is, other than
using the appropriate wording. Given that seems to be a female name and people are referring using "he" and Arlen did seem to me like a male
name, I just erred on the side of caution and went with they/them.)

(But nevermind me, I'm apparently just trolling.)

It is an 80 year he. We refer to him as Arlen, as that was a long lived
alias he used. Currently he is going as Maria, and uses a domain that
does exist but is not his own. I strongly dislike posing as a woman,
thus I never refer to him as Maria.

He claims to change names for security, thwart machine trackers or
something I forgot (some organization tracking him?). But of course it
serves to evade kill files, and for this reason alone he can be
considered a troll.

Sometimes he has used more than one name in the same thread. Or
different alias in a new group.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-07, Chris <ithinkiam@gmail.com> wrote:

Jon Ribbens <jon+usenet@unequivocal.eu> wrote:

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.

That's the core of the issue - I would guess that Android devices are
only uploading BSSIDs to the Google database when they see that Access
Point broadcast an SSID, and that SSID doesn't end with "_nomap".

iPhones on the other hand, I would guess are uploading BSSIDs to the
Apple database as soon as they see that Access Point broadcasting
anything, regardless of whether they have seen an SSID from it.

If it works the way I am suggesting, then it means that Google's
database would automatically exclude "hidden" networks, and Apple's
wouldn't - and not only that, Apple would have no way of immediately
excluding them. They would need to issue updated iPhone software,
and then wait until almost all iPhones in the world that were still
in use were using the new software.

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.

We can't prove what prompted Apple to change their documentation, but
we certainly can prove that it did indeed change, using archive.org.
In December 2025 the page did not mention hidden networks, and today
it does.

https://web.archive.org/web/20251221213139/https://support.apple.com/en-ie/102515
https://support.apple.com/en-ie/102515
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos,

Ok, suppose I run the scripts, and have in my power the BSSIDs and SSIDs
of the entire world.

And thats another of Arlens problems : You can't just retrieve records from that database.

You could plug your own BSSID into the database and get a number of other, near BSSIDs which you than also query (rinse and repeat), hoping to spread
it like a water-ripple, any kind of "dead space" stops that ripple.

IOW, if there is any distance between the town you're in and the next town over you won't see that one in your results. And as good-old 'Murrica has a LOT of "dead space" (neighbours lliving miles apart) the chance that Arlens "the entire world" is nothing more than *very* wishfull thinking.

I had intended, in that other thread, to put that forward to Arlen. But
seeing that he could not even grasp that the translation from a persons name to that persons (routers) BSSID was already wrought with problems I thought better of it.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 13:03, R.Wieser wrote:

Carlos,

Ok, suppose I run the scripts, and have in my power the BSSIDs and SSIDs
of the entire world.

And thats another of Arlens problems : You can't just retrieve records from that database.

You could plug your own BSSID into the database and get a number of other, near BSSIDs which you than also query (rinse and repeat), hoping to spread
it like a water-ripple, any kind of "dead space" stops that ripple.

IOW, if there is any distance between the town you're in and the next town over you won't see that one in your results. And as good-old 'Murrica has a LOT of "dead space" (neighbours lliving miles apart) the chance that Arlens "the entire world" is nothing more than *very* wishfull thinking.

Aha. Right.

I had intended, in that other thread, to put that forward to Arlen. But seeing that he could not even grasp that the translation from a persons name to that persons (routers) BSSID was already wrought with problems I thought better of it.

Regards,
Rudy Wieser

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

From Newsgroup: comp.mobile.android

Jon Ribbens <jon+usenet@unequivocal.eu> wrote:

On 2026-09-07, Chris <ithinkiam@gmail.com> wrote:

Jon Ribbens <jon+usenet@unequivocal.eu> wrote:

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.

That's the core of the issue - I would guess that Android devices are
only uploading BSSIDs to the Google database when they see that Access
Point broadcast an SSID, and that SSID doesn't end with "_nomap".

iPhones on the other hand, I would guess are uploading BSSIDs to the
Apple database as soon as they see that Access Point broadcasting
anything, regardless of whether they have seen an SSID from it.

If it works the way I am suggesting, then it means that Google's
database would automatically exclude "hidden" networks, and Apple's
wouldn't - and not only that, Apple would have no way of immediately excluding them. They would need to issue updated iPhone software,
and then wait until almost all iPhones in the world that were still
in use were using the new software.

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.

We can't prove what prompted Apple to change their documentation, but
we certainly can prove that it did indeed change, using archive.org.
In December 2025 the page did not mention hidden networks, and today
it does.

https://web.archive.org/web/20251221213139/https://support.apple.com/en-ie/102515
https://support.apple.com/en-ie/102515

I agree. And I did the same. The fact that Arlen couldn't very easily
evidence his assertion, despite my challenge above, speaks volumes.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris wrote:

Jon Ribbens <jon+usenet@unequivocal.eu> wrote:

On 2026-09-07, Chris <ithinkiam@gmail.com> wrote:

Jon Ribbens <jon+usenet@unequivocal.eu> wrote:

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.

That's the core of the issue - I would guess that Android devices are
only uploading BSSIDs to the Google database when they see that Access
Point broadcast an SSID, and that SSID doesn't end with "_nomap".

iPhones on the other hand, I would guess are uploading BSSIDs to the
Apple database as soon as they see that Access Point broadcasting
anything, regardless of whether they have seen an SSID from it.

If it works the way I am suggesting, then it means that Google's
database would automatically exclude "hidden" networks, and Apple's
wouldn't - and not only that, Apple would have no way of immediately
excluding them. They would need to issue updated iPhone software,
and then wait until almost all iPhones in the world that were still
in use were using the new software.

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.

We can't prove what prompted Apple to change their documentation, but
we certainly can prove that it did indeed change, using archive.org.
In December 2025 the page did not mention hidden networks, and today
it does.

https://web.archive.org/web/20251221213139/https://support.apple.com/en-ie/102515
https://support.apple.com/en-ie/102515

I agree. And I did the same. The fact that Arlen couldn't very easily evidence his assertion, despite my challenge above, speaks volumes.

Why do you call him/her Arlen if his/her preferred name is Maria? Are
you from the 70s?

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Lane W wrote:

I agree. And I did the same. The fact that Arlen couldn't very easily
evidence his assertion, despite my challenge above, speaks volumes.

Why do you call him/her Arlen if his/her preferred name is Maria? Are
you from the 70s?

I've answered this question a thousand times, and it simply won't stick.

Do you think I care about privacy?
Yes, or No?

Do you think I say privacy is a million things, of which most people know 3
for no good reason? I used to have a security clearance at Fort Mead (which dates me, as the NSA is no longer at Fort Mead, as far as I can recall).

I know privacy.
I can always learn more.

But headers are a component of privacy just as much as is rotating the time zones (which you likely didn't notice) and the IP address (via rotating
VPN).

I care about privacy.

For privacy, typically on the first of the year, but it can be any time I
feel it's needed, I send a thread to every newsgroup I frequent, letting
them know that the headers are randomized (much like a BSSID should be).

This is to foil robotic aggregators, not you.
Robots. Not people.
The trolls can't fathom that privacy concept.

The trolls can't fathom that you have to actually rob a bank to be a bank robber, and not that you just happen to wear a mask for privacy reasons.

The header is the wrapping paper.
It's the gift of the immense content in the body that has great value.

But aggregators "can" track your posts across the Internet.
I post to many (many!) forums (web forums like XDA, Telegram, etc.)

I don't want my ID to be tracked, so I change the header.
But not the body.

The body is always the same well-educated engineer/scientist.
The same phone (since 2021) and the same unique screenshots.
The same PC (since 2009) and again, the same unique screenshots.
The same Santa Cruz Mountains location.
The same excellent grammar, spelling, and punctuation.
Same newsserver (although they change over time as they come and go).
Hell, the same educational degrees, both undergrad and graduate.

Hell, the same source for the images, and I even re-use images, so anyone wanting to track me not by the headers, could track, oh, say, these jpegs.
<https://i.postimg.cc/hjj3tFR9/scrcpy34.jpg> Manage Android from Windows
<https://i.postimg.cc/pr8NPNKs/scrcpy33.jpg> sndcpy is the default now
<https://i.postimg.cc/zGNNXftK/scrcpy32.jpg> ADB port errors creep up
<https://i.postimg.cc/KvTvtMS8/scrcpy31.jpg> HNS stop/start solution
<https://i.postimg.cc/WbpYsfqg/scrcpy30.jpg> Windows Update is the problem
<https://i.postimg.cc/Hs1ZZ5H0/scrcpy29.jpg> net stop hns & net start hns
<https://i.postimg.cc/pdyTjwnT/scrcpy28.jpg> Android assigns random ports
<https://i.postimg.cc/25XrGW9R/scrcpy27.jpg> Nobody can find locked ports
<https://i.postimg.cc/Dz1rcpDX/scrcpy26.jpg> Windows Update locks ports
<https://i.postimg.cc/tgvzsMRm/scrcpy25.jpg> Connect over Wi-Fi sans USB
<https://i.postimg.cc/Hnw59ZHm/scrcpy24.jpg> Compare Vysor to scrcpy
<https://i.postimg.cc/mrz6gJpC/scrcpy23.jpg> Android SMS/MMS on Windows
<https://i.postimg.cc/c4Wq5x9j/scrcpy22.jpg> Vysor IP address option
<https://i.postimg.cc/9FJMKYch/scrcpy21.jpg> Windows Drive: === Android
<https://i.postimg.cc/Y9jbTtcN/scrcpy20.jpg> Start /b as a CMD works! :)
<https://i.postimg.cc/3R6nTz7s/scrcpy19.jpg> Start /b TARGET fails :(
<https://i.postimg.cc/Y93b1z0n/scrcpy18.jpg> Free Automation APKs
<https://i.postimg.cc/bvRXdbxg/scrcpy17.jpg> AutoIT & IFFT & Automate
<https://i.postimg.cc/5NrK7jtg/scrcpy16.jpg> powershell hide-console trick
<https://i.postimg.cc/g2yNftw0/scrcpy15.jpg> Trick to pin batch shortcut
<https://i.postimg.cc/XqZsmVFM/scrcpy14.jpg> AppPath & shortcut TARGET
<https://i.postimg.cc/CxXH6N2r/scrcpy13.jpg> No scrcpy console window!
<https://i.postimg.cc/yYKNnHxD/scrcpy12.jpg> REG test of showwin.lnk
<https://i.postimg.cc/7LWJhWxq/scrcpy11.jpg> Shortcut test of showwin.lnk
<https://i.postimg.cc/fyWw2nXh/scrcpy10.jpg> The console came up :(
<https://i.postimg.cc/66Gn2t2g/scrcpy09.jpg> REG test of showwin.bat
<https://i.postimg.cc/nV6K0Cfn/scrcpy08.jpg> CMD test of showwin.bat
<https://i.postimg.cc/hjkVFyqJ/scrcpy07.jpg> Android mnt as drive letter
<https://i.postimg.cc/Sx1hgWmY/scrcpy06.jpg> Press two hardware buttons
<https://i.postimg.cc/wvsbcNBz/scrcpy05.jpg> Drag APK from Windows
<https://i.postimg.cc/Y00vx4yp/scrcpy04.jpg> Extraneous cmd window (&)
<https://i.postimg.cc/Vvrq0K0m/scrcpy03.jpg> The efficient setup explained
<https://i.postimg.cc/tTmdgKTB/scrcpy02.jpg> An efficient program setup
<https://i.postimg.cc/N0G1TXcZ/scrcpy01.jpg> Mirror Android on any PC

Who does that, but me.
Yet, the trolls, who can never add value, say that by wanting privacy,
I'm a troll. They say that crap all the time, which says a lot about them.

I'm not hiding from anyone in the body.

Everything is the same in the body.
It's only the header that is randomized.

Hell, few people notice but I try to end each line perfectly, even as most people might let the 80-character line wrap do it for them (that's because
I wrote my own newsreader which uses gvim macros to equalize line content).

What's sadly hilarious is that, after hundreds of posts of EXACTLY the same
me in every say, the trolls (especially on Apple ngs) excitedly claim
I FOUND YOU!!!!!!

It's like you put this big fat egg in the middle of the lawn for the
mentally challenged people, and they shout out with glee that they found
what was never even for a moment hidden from people with a normal IQ.
--
Privacy is a million little things, of which most people only know 3.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

The Flock issue is off topic here so the only thing I'll say is that this a >> consequence of lack of American's trust in government. That leaves the door >> open to commercial companies to collect data and sell it to government
agencies with little to no oversight.

And the lack of data protection laws like the GDPR in Europe.

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

I congratulate the folks in the EU for *forcing* plenty of improvements
that the US capitalist system simply won't regulate, if for no other reason that the likes of Apple and Google are too formidable for the US to buck.

We've discussed *many* of these improvements, from stating how long devices will be fully supported to correcting advertising lies about battery life.

In this case, I'd love to have a government contact who *cares* about this problem, where think about how hard it is to explain to a non-techical
person?

It took, oh, maybe scores upon scores of posts to get people to even
comprehend why their stone-age wifi knowledge doesn't prepare them for
this.

Even now, I suspect zero people, except me, on this thread, can outline the path of your home router BSSID to Apple's and Google database, and then,
from there, to the Python code that both Jon and I proved scrapes Apple's.

HINT: The path of the BSSID is *COMPLETELY DIFFERENT* between Apple:Google.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 17:47, Lane W wrote:

Why do you call him/her Arlen if his/her preferred name is Maria? Are
you from the 70s?

Because he is not Maria.

He is a nameshifter, he changes his name eventually. We have known him
for a long time as Arlen in the past, so that's the name we stick to,
not the name he uses at the current time.

I strongly dislike that he is using a woman's name, so I refuse to call
him by that.

He is not a man that discovers his true self is feminine and changes his
name. I would respect that.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

I strongly dislike that he is using a woman's name, so I refuse to call
him by that.

Hi Carlos,

Since almost nobody on these technical newsgroups are females, IMHO, I
think I'll use Maria only for a few years and change it to, oh, Sally.

That would be another clear and obvious indication that I'm not hiding for
even a moment FROM YOU, but from robot header aggregation tools, which is
more and more of a problem even as I recognized the issue two decades ago.

And while I get why you associate nymshifting with the disgusting trolls,
you need to take an elementary course in Logic (or Occam's Razor at least).

A person has to rob a bank to be called a disgusting bank robber, right?
Just putting a mask on his face for privacy does not make him a criminal.

In fact, your disgusting habit of absurdly claiming everyone who uses a
fake name is a troll is starting to grate on me as it's disingenuous.

You may be truly a Carlos, but your oft-repeated claim that anyone who
doesn't use their real name in Usenet posts is a troll is patently absurd.

I randomize the headers by a *lot* of things, time zone being one of them.
So is the IP address. And, at times, the newsreader (usually when they go suddenly defunct such as with netfront, mixmin, aioe, dizum, et al.)

But if it takes you or anyone more than a split second to realize only I
post like I do, with perfect English grammer, punctuation & sentence
structure, and from Santa Cruz Mountains, with a Silicon Valley heritage,
and with the same phone with a unique homescreen (since 2021) and the same
PC with a unique desktop (since 2009) with the same privacy focus, and even down to the same way I put a period after the double-quote, you're a moron.

Hell, who posts this kind of screenshots for decades on end, sans changing?
<https://i.postimg.cc/xdSMtBkn/vysor36.jpg> scrcpy vs Vysor resolution
<https://i.postimg.cc/TYvqdxCT/vysor35.jpg> iOS & Android PC mirroring
<https://i.postimg.cc/k5gv0yw8/vysor34.jpg> Apple iOS & Android mirroring
<https://i.postimg.cc/Njg6Xx3V/vysor33.jpg> Preparing Vysor on device
<https://i.postimg.cc/xjz3V8Gs/vysor32.jpg> ScrCpy vs Vysor PC mirror
<https://i.postimg.cc/k4K8dZqv/vysor31.jpg> Random MAC address is static
<https://i.postimg.cc/nchSVcmS/vysor30.jpg> Static/Reserved IP address
<https://i.postimg.cc/XqrD5Hqm/vysor29.jpg> Removing Apple iTunes crap
<https://i.postimg.cc/KYbVWDp3/vysor28.jpg> Nuking Apple shitware 1 by 1
<https://i.postimg.cc/MGbkZFfY/vysor27.jpg> The bloatware is everywhere
<https://i.postimg.cc/hP6R2xqV/vysor26.jpg> iTunes crapware won't install
<https://i.postimg.cc/fTy57WSY/vysor25.jpg> Best iOS drivers installed
<https://i.postimg.cc/3wmtyL46/vysor24.jpg> Apple Device working properly
<https://i.postimg.cc/tCvS8nGr/vysor23.jpg> iPad is connected to Win10
<https://i.postimg.cc/Kz7pW9mL/vysor22.jpg> Apple Win10 iOS drivers suck
<https://i.postimg.cc/QdVPMkqG/vysor21.jpg> Apple iPad on Win10 over USB
<https://i.postimg.cc/J7cSYhhg/vysor20.jpg> Classic Apple error 2502
<https://i.postimg.cc/yxP5DL5B/vysor19.jpg> Classic Apple error 2503
<https://i.postimg.cc/V6X28fWJ/vysor18.jpg> Apple Mobile Device Support
<https://i.postimg.cc/ZqB1wF9F/vysor17.jpg> Install Apple AMDS engine
<https://i.postimg.cc/Jzdf3dhz/vysor16.jpg> Classic Apple Error Code 2503
<https://i.postimg.cc/c4TyCJyY/vysor15.jpg> Apple Mobile Device Support
<https://i.postimg.cc/SRhF22xL/vysor14.jpg> Connect over the Internet
<https://i.postimg.cc/bv4jPFXB/vysor13.jpg> Vysor Camera virtual webcam
<https://i.postimg.cc/XvPnJY5x/vysor10.jpg> Vysor Windows Virtual Camera
<https://i.postimg.cc/wxL9qHjc/vysor11.jpg> Vysor searches for Android/iOS
<https://i.postimg.cc/2S2zsw8s/vysor09.jpg> Classic Apple Error code 2503
<https://i.postimg.cc/sg6r6gTy/vysor12.jpg> Vysor easily finds Android
<https://i.postimg.cc/yYCYcxbb/vysor08.jpg> Apple Mobile Device Support
<https://i.postimg.cc/Y2WCvYbF/vysor07.jpg> iOS requires Apple AMDS kluge
<https://i.postimg.cc/ydJYXZKw/vysor06.jpg> Remote mirror over the net
<https://i.postimg.cc/d0V03fxQ/vysor05.jpg> Vysor Internet mirroring
<https://i.postimg.cc/XY3qSqKC/vysor04.jpg> Vysor ADB USB setup switches
<https://i.postimg.cc/v8gc5pHc/vysor03.jpg> Vysor remote sharing
<https://i.postimg.cc/V6TPYG3h/vysor02.jpg> Vysor console operation
<https://i.postimg.cc/QNwjsCDM/vysor01.jpg> Vysor Android/iOS PC mirroring

Only the trolls claim I troll.
As you have to actually troll to be called a troll.

Just desiring privacy from robotic aggregation, while you may believe
nobody has that right of privacy, does not make my valuable posts trolls.

However, it can be said that responding to your incessant trolls, may
count, so stop trolling this newsgorup with your off-content bullshit.

Stick to the technical subject so we don't need to defend against your incessant trolls.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On Tue, 8 Sep 2026 19:51:29 +0300, Maria Sophia
<mariasophia@comprehension.com> wrote:

But aggregators "can" track your posts across the Internet.
I post to many (many!) forums (web forums like XDA, Telegram, etc.)

"Ads You See Online Are Now Police Surveillance" <https://www.youtube.com/watch?v=cq36YXrfyJE>
"This video explores how advertising data became a powerful
surveillance tool."

We're all doomed.
--
Jeff Liebermann jeffl@cruzio.com
PO Box 272 http://www.LearnByDestroying.com
Ben Lomond CA 95005-0272 AE6KS 831-336-2558

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Lane,

Why do you call him/her Arlen if his/her preferred name is Maria?

Arlen Holder is a so-called nym-shifter, who changes his nym
once-in-a-while - ostensibly so he cannot be tracked (by the people who
scrape the newsgroups for information).

Although you jumped on the gender identity bandwagon, Arlens current name
has got zero to do with it. Current, as in the last number of years he has gone thru a number of them. Male as well as female ones.

Something you could have known if you would either have visited these newsgroups a bit longer or just had asked for it.

Are you from the 70s?

You know what a hypocrite is ? Thats someone who tells someone not to do {something}, while doing that {something} themselves. You know, the "do
as I say, not as I do" kind of person.

In your case : being judgemental while telling someone else not to be so. Funny, that.

Regards,
Rudy Wieser


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

R.Wieser wrote:

Lane,

Why do you call him/her Arlen if his/her preferred name is Maria?

Arlen Holder is a so-called nym-shifter, who changes his nym
once-in-a-while - ostensibly so he cannot be tracked (by the people who scrape the newsgroups for information).

Although you jumped on the gender identity bandwagon, Arlens current name
has got zero to do with it. Current, as in the last number of years he has gone thru a number of them. Male as well as female ones.

Something you could have known if you would either have visited these newsgroups a bit longer or just had asked for it.

How would I have asked for this information differently than I did,
receiving exactly what I wanted to know? Would my reputation have
remained sparkling if I had asked for it in your manner?

Are you from the 70s?

You know what a hypocrite is ? Thats someone who tells someone not to do {something}, while doing that {something} themselves. You know, the "do
as I say, not as I do" kind of person.

I've found that people who mangle transwomen by calling them male
pronouns are the manure of the earth. It's a repeating pattern that I've noticed.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 19:20, Maria Sophia wrote:

Carlos E.R. wrote:

I strongly dislike that he is using a woman's name, so I refuse to call
him by that.

Hi Carlos,

Since almost nobody on these technical newsgroups are females, IMHO, I
think I'll use Maria only for a few years and change it to, oh, Sally.

That would be another clear and obvious indication that I'm not hiding for even a moment FROM YOU, but from robot header aggregation tools, which is more and more of a problem even as I recognized the issue two decades ago.

And while I get why you associate nymshifting with the disgusting trolls,
you need to take an elementary course in Logic (or Occam's Razor at least).

A person has to rob a bank to be called a disgusting bank robber, right?
Just putting a mask on his face for privacy does not make him a criminal.

In fact, your disgusting habit of absurdly claiming everyone who uses a
fake name is a troll is starting to grate on me as it's disingenuous.

No, I never said such a thing. Citation, please?

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

From Newsgroup: comp.mobile.android

Carlos E.R. wrote:

He is not a man that discovers his true self is feminine and changes his >name. I would respect that.

Or one could just use initials and make folks guess...sweetie... ;)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 19:36, Lane W wrote:

R.Wieser wrote:

Lane,

Why do you call him/her Arlen i

...

I've found that people who mangle transwomen by calling them male
pronouns are the manure of the earth. It's a repeating pattern that I've noticed.

Not the case. I would respect that.
--
Cheers, Carlos.
ESEfc-Efc+, EUEfc-Efc|;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-09-08 19:56, AJL wrote:

Carlos E.R. wrote:

He is not a man that discovers his true self is feminine and changes
his name. I would respect that.

Or one could just use initials and make folks guess...sweetie... ;)

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