In principle, yes. But FWIW, here’s a good example of doing it poorly:
daveyOsborn
joined 11 months ago
Saw this in the article:
This is the biggest drawback of hidden SSIDs. When a network is hidden, your phone or laptop has to constantly shout, "Are you there, [Hidden Home Network]?" everywhere you go.
There is a paper that describes how an iOS device listens to everyone else’s phones as they broadcast all the SSIDs they connect to (regardless of where the two phones intersect). It gave the impression that phones also reveal non-hidden SSIDs when looking to connect, as it’s uncommon for people to have hidden SSIDs.
It’s a handle that is broadcasted from your wi-fi router, if you have one. It enables your phone or laptop to distinguish your network from your neighbors.
I lost the link but the research was done by: Douglas J. Leith, School of Computer Science & Statistics, Trinity College Dublin, Ireland, 25th March, 2021 in a paper titled “Mobile Handset Privacy: Measuring The Data iOS and Android Send to Apple And Google”.
Every Android device owner is a Google spy. Every iOS device owner is an Apple spy. They don’t know it, generally. Android and iOS devices ~~constantly~~¹ harvest the radio data of their surroundings and they send the data home to their respective mothership. This is hard-wired into the platforms and has nothing todo with accounts. An arbitrary person randomly walks/drives by your house with their iPhone or android powered on, and it collects your SSID, MAC, GPS position, etc and sends it to Google or Apple, unwittingly, because people are oblivious as to what’s going on.
¹ The phone user may need to have location services enabled for the phoning-home to occur.. not sure if turning on location services enables the data sharing in both directions or just one. Guess I need to re-read the research.
32
153M+ US & Canada drivers licenses leaked on the dark web (Update: source of the leak revealed)
(krebsonsecurity.com)
I’m glad that opting out is available, but there is no practical, technical enforcement.
What sort of technologically-enforced mechanism might you envision that does not rely on legal enforcement?
Lately I practice the only tech-enforced option I know of: wholly pull the plug on wi-fi. Indeed, this means I only have ethernet in my house and wifi radios are disabled. It also means for my smartphone to reach the cloud, I am reverse tethering over USB. Try getting a crowd of people to do that. I will praise you if you can get 10 people to do that.
There is such a thing as bluetooth routers. So a middle ground would be to pull the plug on wi-fi and use bluetooth instead. Though it’s a compromise because we cannot¹ be certain that Google does not also harvest bluetooth. But at least the limited range would mean fewer cases where the signal reaches the street. Of course you would have to be okay with the slower speed.
If Google violates their own policy, it’s legally actionable. So if you are going to run wi-fi you can do your part in helping grow the legal liability that Google has signed up for. I see no good excuse for not appending _nomap to the end of your SSID. It’s just pure lazyness not to.
¹ well strictly speaking, we might know from the location data whether Google uses bluetooth. But if it’s not part of the location data it would not be an absolute indicator that it’s not collected.
It has nothing to do with your phone. If you have wi-fi at home and the wireless signal reaches the road, then it’s relevant.
They are microprocessors embedded within the microprocessor. Intel’s IME enables remote access (by intel’s own admission). If you are not a corporation who manages a fleet of machines, the backdoor can only be used against you. AMD’s variant called the PSP is similar but closed-source. We don’t really have a complete picture of the extent of the compromise with AMD because of the opacity of it (as AMD proactively denied a request for source code). What we don’t know /can/ hurt us, as we already got stung by a defective driver for the AMD’s PSP.
Even if the spychips were to be hypothetically designed to be aligned with the interests of non-corporate individual consumers, there is no such thing as bug-free software. They have added complexity that works against us and brings vulnerabilities. And we also cannot dispense of the deliberate design whereby some remote actor decides for the user what software is or is not “authorised” to execute. I alone should decide what is authorised on my PC.
So the fix is to use an AMD processor made before ~2014 (roughly speaking), or a pre-2009 intel. AMD chips were behind intel in terms of performance, but probably not 5 years behind. So I figure 2013 AMDs are the most interesting. But we only have a fuzzy idea of which AMD chips are spychip-free.
Well, @passenger@sopuli.xyz mentioned that it’s on the google page. But then when I chose some of the brands under “Find specific steps for your access point”, it’s a bit useless because manufacturers web admins have no sense of discipline or self-control. They cannot resist the urge to rearrange their website which broke Google’s links. But further below on Google’s page are some general instructions. I would try to follow those. And if you get stuck, maybe try posting a support request in !homenetworking@selfhosted.forum.
(update) I just had a closer look at the general instructions to do a quick sanity check. Google’s instructions for linux are bad at the 2nd step. That is, running ifconfig as a linux user can be tricky.. might need to run /sbin/ifconfig instead. And even if it runs, it does not give the gateway anyway.
If you’re on linux, run ip route instead, which will say something like default via 192.168.1.1. Whatever IP address is the default gateway, that is what you need for the next step. Note I am only talking about linux. Google’s instructions are probably fine for other platforms.
What I would expect to happen is when an AOS or iOS device falls in your range in the future, it will not report the AP to the mothership. But the motherships will still remember the history and perhaps be able to continue exploiting it. To have more certainty, I would change the MAC address on the AP if it lets you, and perhaps also change the prefix of the SSID for good measure. If your AP gives no means for changing the MAC, you could investigate replacing the firmware with openwrt -- but probably not worth the effort just to change the MAC.
When I setup an AP, I chose the same SSID as a neighbor but then added the suffix for fun.. to confuse things. Then they changed their SSID (perhaps in fear that something dodgy was going on).
Apple seems to say hiding your SSID will not protect you:
“This opt-out doesn't work for hidden networks because they make their network name available only to known devices, so other devices can't detect "_nomap."”
So IIUC, if you hide your SSID and an Apple spy (read: normal iOS user) connects to it, their device will ignore the _nomap token and report your AP to the mothership. And note as well that a hidden SSID only makes your AP invisible in the absence of traffic. iOS devices can probably see and process traffic that happens to be in motion when they are in range.
Glad to hear Apple has aligned with Google on that.
view more: next ›
Indeed it is the most obnoxiously hostile act somewhere between bullying and license to kill bounty. I would like to know how the system works because certainly the US is not the only player.
Is it really a case where Trump can willy nilly list whoever he wants, and all allies are obligated to obey without question? Is there no mechanism by which Italy or the UN can say “hold on, we are not going to accept Trump tagging his political adversaries as terrorists and then lick boots unconditionally”? Anti-terror policy is losing legitimacy with every abuse of it, including Trump’s assassination of drug dealers under the abusive claim of “narco-terrorism”.