In the sense that your WiFi LAN would continue to function, yes. I don't think it would achieve anything useful though or have any effect on your 'privacy' or security.
Using different makes of router would at least slow down anyone trying to hack into your network. Possibly for several minutes.
I don't know that Google do record the MACs associated with SSIDs, but there's nothing stopping them from doing so. They could store that information for ever - but not necessarily make it available to mobile phones trying to locate themselves, or to anyone else.
As expected, when I re-ran using the Iron browser instead of Chrome and both "Authentication" and "Cache (E-=Tags)" changed.
But I would have to think that somebody somewhere (Google?) is diligently creating links between those IDs and people's names/addresses/phone numbers.
Am I on the right track with that ?
Seems like even if somebody gets a new browser and uses it only over VPN, any sites (Amazon, for instance) that the user divulges personal information to can now create a link to that browser instance's unique ID - regardless of whether the user is connecting over a VPN.
Oops.... Was a little to quick on the trigger with that one.
Now I see that the IP-Check.info is a site "JonDonym" (as in "John Doe"??) that offers a Proxy app aimed at mitigating those issues - and sells a "Premium" service for better throughput through the proxy.
Haven't read it all yet, but even they do not claim 100% anonymisation... although the seem to make a case for it to be pretty close.
Yes. I was trying to say that it's there, but it says Google broke them. The fact that it supposedly worked at one time means the Google database is accessible on the net somewhere.
Do apps use an API to access this Google database containing the GPS coordinates of your home router and phone (if you've used the phone as an AP)?
Notice that, if the phone was used as an access point, then it seems to me that Google actually knows the last location of your phone, even if you yourself are not reporting it, because YOUR LOCATION is reported by all the stooopid people standing next to you on the checkout line.
It would be nice if we can confirm those observations above though.
Reading that, but not understanding it all, is that document supposed to be the API that you and I can use to find out the last location of any given MAC address or is that a document for people developing apps?
(OT) They define the Cell-ID here (which is something we had wondered about): cellId (required): Unique identifier of the cell. On GSM, this is the Cell ID (CID); CDMA networks use the Base Station ID (BID). WCDMA networks use the UTRAN/GERAN Cell Identity (UC-Id), which is a 32-bit value concatenating the Radio Network Controller (RNC) and Cell ID. Specifying only the 16-bit Cell ID value in WCDMA networks may return inaccurate results.
YOU ARE SIMPLY AMAZING!!!!!!!!!!!!!!!!!!!!!!!!!!!! This is wonderful!
I don't understand it yet, but the concept that we can query the Google database is fantastic, and I would like to ask you some questions.
What if the phone has been used as an access point at the same time that someone stoopid was next to you when you were using the phone as an access point?
This seems like *exactly* what I was asking about!
I don't understand the "considerIP" fallback issue but it's simple enough to set to false, so, I'll just show the documentation on it below: From
"considerIp: Defaults to true. Set considerIp to false to disable fall back. Specifies whether to fall back to IP geolocation if wifi and cell tower signals are not available. Note that the IP address in the request header may not be the IP of the device.
Ah. That's something "special". This is the first I'm hearing of a "Google API Key" (I saw it in the document when you first mentioned the doc.)
I wonder (to myself) if I can easily get my own Google API Key? Reading
How much identifying information do I have to give Google to get an API key?
I saw your followup that Google documents insist on two WiFi MACs:
Interesting that dual-band routers will give you away more so than single-band routers! It's not that they're triangulating by requiring more than one MAC address.
A bit of an edge case, presumably they don't want to fill their database with the MAC addresses of phones at 'random' locations where they happen to have acted as access points?
AFAIK only marshmallow allows creating a 5.2GHz hotspot on dual-band phones, but you can't create a hotspot on both bands simultaneously, so a phone by itself with GPS enabled in the middle of nowhere can't be used to "mark" a location, presumably they filter out MAC addresses that move frequently, and are aren't seen "near" to fixed MACs they already know?
Yes, we knew it's what they do, also my router is newer than the most recent visit of a streetcar to my street, so it has been gathered by phone/tablet.
Just login with a google account, you can restrict the key to one or more IP addresses, but that's optional information.
I does accept the two MAC addresses (2.4GHz and 5.2GHz) from my router which only differ by a single bit, but you can't fool it by giving the same MAC address twice, or by giving it one valid and one fictional MAC address. So they do validate that multiple valid MAC addresses are in use within a certain proximity to each other, which avoids people going on fishing expeditions to find every router's location, without being there, thought dual band routers will negate that to a certain degree with a little guessing, also the API key is limited to a certain number of queries per day.
I tried giving two MAC addresses one with a high the other with a low signal level, flipping the signal levels didn't alter the location they returned. I haven't tried with three MAC addresses.