On 2023-03-08 16:00, Carlos E.R. wrote:
> On 2023-03-08 21:47, Alan Browne wrote:

>>
>> er ... here: https://wigle.net/
>>
>
> Ok, nice. It requires login to show data about points. Not sure if I
> want to do that.

Burner.

> Amazing the precision of the map itself. From the national geographic
> institute (of Spain), it is the first time I see it used in a site.

The location is where the "driveby" roamer recorded the hit. Not the
precise location of the WiFi.

Why most are in the street.

One could theoretically hone this down somewhat (hits on street behind,
hit on perpendicular street, signal level weighting) - not sure if they
do any of that - most likely not.

--
“Donald Trump and his allies and supporters are a clear and present
danger to American democracy.”
- J Michael Luttig - 2022-06-16
- Former US appellate court judge (R) testifying to the January 6
committee

Alan Browne wrote:

> I believe you need to create an account in order to search by SSID.

Hi Carlos,

I'll try to be succinct...

The Google database requires an account and two nearby SSIDs to query the
data, the second one being required as a minor hurdle to prevent abuse.

However, if you're intelligent about it, you can query on Android.
But not on iOS.

Probably only 1 out of thousands of people would know how to do it.
I know how.

If Carlos wants to do it, I'll tell him how, but he has to be on Android.

Carlos... do you want to try it?
a. It's free
b. It's easy
c. But it only works on Android (not on iOS).
--
Steve can explain why as it's listed in his iOS/Android comparison doc.

On 2023-03-08, Carlos E.R. <robin_listas@es.invalid> wrote:
> On 2023-03-08 21:47, Alan Browne wrote:
>> On 2023-03-08 15:15, Carlos E.R. wrote:
>>>
>>> Where, exactly, is that list? I can not find a link there.
>>>
>>> I want to find out if mine is there.
>>
>> er ... here: https://wigle.net/
>>
>
> Ok, nice. It requires login to show data about points. Not sure if I
> want to do that.

I don't see much harm in creating one using bogus details.

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

JR

Jolly Roger wrote:

>> Ok, nice. It requires login to show data about points. Not sure if I
>> want to do that.
>
> I don't see much harm in creating one using bogus details.

Hi Carlos,
I'll try to be succinct...

If you want to create quick and easy bogus details, here's an approach that
I use (which probably only 1 in 10 would think about using to obtain them).

First thing I do is test the forum site to see if they actually care about
the email address (most do, probably 9 out of 10, but some don't test it).

If the forum actually cares, then there are many bogus email accounts, but
to be succinct, most of them won't work (e.g., mailinator & the like).

So what works 9 out of 10 times, but to be succinct, is to go in with a
proxy and create a proxy email account that you'll only use once. (Or, do
what I do, which is use that proxy email account only for web forums.)

Works every time.

In article <di5ndjxcbp.ln2@Telcontar.valinor>, Carlos E.R.
<robin_listas@es.invalid> wrote:

> >> His claim is that indexers (some? all?) do not collect wifis with hidden
> >> SSIDs. And that is his privacy reason for setting ssid to hide.
> >
> > the geolocation database correlates bssid and location data, along with
> > other stuff such as signal strength.
> >
> > the ssid is unimportant because it's not unique and can change at any
> > time. being hidden makes absolutely no difference whatsoever.
>
> Ok, but it seems that if the SSID is hidden, the Android AP doesn't
> register it at all, so neither will it register the BSSID.

it will see the bssid. the ssid does not matter.

> >> Now, someone may verify this be creating an AP with hidden SSID, close
> >> to another with normal SSID, and wait (years?) to see which appear on
> >> public access wifi databases.
> >
> > that was done 15 years ago when wifi geolocation first began, and
> > doesn't take years to verify either.
>
> The google car takes years to pass again.

that's for street view, a totally different product.

the geolocation database is crowdsourced by *everyone* with a
smartphone or tablet who comes within range of wifi access points. in
an urban area, that's a *lot* of people.

note that there is no need for any of those people to associate with a
wifi network. if it's within range, the wifi access point will be seen
and its info with the user's location will be sent.

the more people who pass by, the sooner it will be in the system and
the more accurate its location will be, which can be *very* accurate.

the original skyhook wireless database (15+ years ago) began when there
weren't that many smartphones, so they *also* used people driving
around with a wifi scanner that they provided. preference was given to
those taking a variety of longer trips, versus commuting the same route
every day. there was a signup page on their website.

> > the geolocation database is typically updated within a day or two at
> > the most, many times less than that if it's in a busy area with a lot
> > of people.
>
> Ok, tell me how can I read the database that lists my own access point,
> then I will add a guest AP with hidden SSID and I can search for it a
> week later.

you will need to have a new access point that's not (yet) in the
database, or its data is stale (i.e., was previously used in another
location). an old 802.11g/n that's been collecting dust should work
fine.

you also will need to conduct the test in an area where there aren't
any other wifi access points so that you know *only* yours is being
used for the test. this is *very* important.

however, there will need to be people passing by so that they can 'see'
it and the database can be updated.

use a weather app or similar that only checks for approximate location
(.e., does not try to use the gps). be sure cellular, bluetooth and gps
are disabled. there is no need to associate with the wifi network. it
just has to be within range.

if your location can be determined, then your wifi access point is in
the database because it's the only method that's active. all other
location methods have been disabled.

bonus points for testing this with both android and ios devices (two
separate databases).

for extra credit, relocate the access point to a new location and test
it again.

if you check your location immediately, you should get the old location
because the database hasn't been updated yet.

wait a couple of days for the database to update and check again. it
should show the new location.

In article <tub0lk$ieke$1@paganini.bofh.team>, Andy Burnelli
<nospam@nospam.net> wrote:

> Jolly Roger wrote:
>
> ...

> Hi Carlos,
> I'll try to be succinct...

how about you try to fix your worthless buggy scripts, which can't even
get the attributions correct.

nospam wrote:

>> Ok, but it seems that if the SSID is hidden, the Android AP doesn't
>> register it at all, so neither will it register the BSSID.
>
> it will see the bssid. the ssid does not matter.

Unfortunately nospam doesn't get it that nobody cares about the SSID.
It's the mere _action_ of hiding the SSID that makes this work.

The switch could have been any toggle for all that the SSID matters:
Google Database = on/off

> the geolocation database is crowdsourced by *everyone* with a
> smartphone or tablet who comes within range of wifi access points. in
> an urban area, that's a *lot* of people.

Let's qualify that nospam is talking about stupid people when he uses the
word *everyone* because some people have their phone set up for privacy.

It's likely 1 out of thousands though that know how to do that.
Particularly for the iPhone where it's likely ten times worse.

Stupid people abound.

> note that there is no need for any of those people to associate with a
> wifi network. if it's within range, the wifi access point will be seen
> and its info with the user's location will be sent.

At least nospam understands that it's the many rude phone owners who are
uploading your location to the public databases without your permission.

> the more people who pass by, the sooner it will be in the system and
> the more accurate its location will be, which can be *very* accurate.

It's easy to check if for sure if you're in the system on Android for free.
How would you check if you're in the system on iOS for free, nospam?

> the original skyhook wireless database (15+ years ago) began when there
> weren't that many smartphones, so they *also* used people driving
> around with a wifi scanner that they provided. preference was given to
> those taking a variety of longer trips, versus commuting the same route
> every day. there was a signup page on their website.

WiGle does that now, I think.

> you will need to have a new access point that's not (yet) in the
> database, or its data is stale (i.e., was previously used in another
> location). an old 802.11g/n that's been collecting dust should work
> fine.

I believe that's bad advice as it's much easier to do what Carlos asked.

> you also will need to conduct the test in an area where there aren't
> any other wifi access points so that you know *only* yours is being
> used for the test. this is *very* important.

That would work for me as I'm in the boonies. Not feasible for some people.

> however, there will need to be people passing by so that they can 'see'
> it and the database can be updated.

Takes a day or few for a Google public location database to be updated.
But there are many of these location databases so each one may differ.

> use a weather app or similar that only checks for approximate location
> (.e., does not try to use the gps). be sure cellular, bluetooth and gps
> are disabled. there is no need to associate with the wifi network. it
> just has to be within range.

Agree that "an app" that consults the public database would be needed.

> if your location can be determined, then your wifi access point is in
> the database because it's the only method that's active. all other
> location methods have been disabled.

There's an easier way to be sure of this, nospam.
But you haven't thought of it.

Most people wouldn't.
You need to be smart.

But it only works on Android.

> bonus points for testing this with both android and ios devices (two
> separate databases).

See above. There's a better way but only for Android, and, get this... it's
actually listed tangentially in Steve's iOS:Android document as something
that is impossible to do on iOS and yet which is trivially easy on Android.

> for extra credit, relocate the access point to a new location and test
> it again.

All that work just because nospam can't figure out an easier method.
But that easier method only works on Android. It won't work on iOS.

> if you check your location immediately, you should get the old location
> because the database hasn't been updated yet.

Unfortunately, the clusterfuck of moving the AP is only needed for iOS.

> wait a couple of days for the database to update and check again. it
> should show the new location.

As far as I know, Carlos is on Android so it's muuuuch easier than that.

In article <tub2io$ikop$1@paganini.bofh.team>, Andy Burnelli
<nospam@nospam.net> wrote:

>
> Unfortunately nospam doesn't get it that nobody cares about the SSID.

then there's no need to hide the ssid, by your own admission.

> Stupid people abound.

yes, i can see that.

> Takes a day or few for a Google public location database to be updated.
> But there are many of these location databases so each one may differ.

the two main ones are apple and google.

with the demise of windows phone, microsoft's database is not
particularly important, if it even exists anymore.

there are others, for different purposes.

>
> Agree that "an app" that consults the public database would be needed.

that's not how it works.

nospam wrote:

>> Takes a day or few for a Google public location database to be updated.
>> But there are many of these location databases so each one may differ.
>
> the two main ones are apple and google.

How do you query the Apple database without using Apple Maps, nospam?

>> Agree that "an app" that consults the public database would be needed.
>
> that's not how it works.

Funny, you just said that it worked that way and now you say it doesn't.

"use a weather app or similar that only checks for approximate location
(.e., does not try to use the gps). be sure cellular, bluetooth and gps
are disabled. there is no need to associate with the wifi network. it
just has to be within range."

How is "a weather app" suddenly _not_ "an app" nospam?

In article <tub5u9$ivql$1@paganini.bofh.team>, Andy Burnelli
<nospam@nospam.net> wrote:

>
> >> Agree that "an app" that consults the public database would be needed.
> >
> > that's not how it works.
>
> Funny, you just said that it worked that way and now you say it doesn't.

i didn't say any such thing.

On 2023-03-08 10:27, Andy Burnelli wrote:
> Alan Browne wrote:
>
>> 10+ years ago I used hidden SSID's until I realized it's not useful.
>
> For those who aren't aware of the genesis of Alan Browne's statement that
> he used to hide his SSID's (for _security_ purposes), but no longer does...
> You can find a million web articles saying the same thing... a. People
> long ago thought hiding the SSID was useful for _security_...
> b. But what happened in the interim was better tools for discovery came out
> c. Such that it's no longer advised to hide the SSID for _security_.
>
> Worse, given most people are stupid so they don't even know what happens
> next, if you do hide your SSID, instantly you have to do more stuff for
> privacy (I'm not even going to get into that as most people are stupid).

You're just an asshole.