In principle, yes. But FWIW, here’s a good example of doing it poorly:

https://sopuli.xyz/post/45724372

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.

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, @[email protected] 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 [email protected].

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

No it’s not. You have overestimated the value of your wi-fi radio to Google by far. The value of tracking what, a dozen or so opt-out SSIDs per country or so is far more negligable than whatever penalty they would pay. Your SSID squawks aren’t worth that much.

The SSID harvesting is not for you. It’s for all of Google and Apple’s users who travel within range of your wi-fi radios. If you are squaking an SSID without opt-out flags, you’re helping Google and Apple regardless of whatever else you do.

Not to use what? Wi-fi? Of course, if you have no need for an access point, not having one is the best case.

Did you follow the link? It’s Google’s own policy.

I’m not seeing a good case here for not putting Google in a position of violating their own legally binding terms.

I should also mention if you boycott Apple (thus Apple’s maps), the SSID must end with _optout. If you want to boycott both Apple and Google, Google’s optout tag must be at the end of the SSID and Apple’s optout tag can only be followed by Google’s optout tag. So something like foo_optout_nomap. At least that’s my understanding.

(edit) FWiW, I’ll cite the source for Google if anyone is interested. AFAIK, Apple’s opt-out flag is just a rumor.

PSA: one way to boycott #GoogleMaps is to append your SSID with _nomap. This opts out of Google using your access point for navigation.

Used PC charities and shops tolerate a certain age limit of hardware. My local charity tried (and failed) to sell PCs with linux installations. So they will only accept used hardware that can run a relatively non-ancient version of Windows. They said generally they do not want anything older than 5 years (but somewhat contradicted themselves by saying if it has a Win7 or later sticker on it, it’s young enough to accept). Anyway, 2013 hardware is on the chopping block because the FOSS platforms that do not demand high-performance hardwrae are unpopular. Most people are naive about the spychips and used PC shops are oblivious to their usefulness.

It’s sad that the spy chips were discovered over a decade ago, and now 13 years after AMD began making them we still don’t have info as basic as which chips have it.

I personally want to know which 2013 hardware to grab before it gets melted down as scrap metal.

I am not sure why you are getting downvoted for this post.

That’s the problem with Lemmy – it was designed to support silent downvotes. Some admins realize it’s a bad idea and have the wisdom to disable downvotes instance-wide until the Lemmy design improves.

My guess in this case: among AMD subscribers must be some loyal fans who “chase the shiny” and to avoid their own cognitive dissonance they would want to suppress anything negative about AMD’s later chips in an /emporer wears no clothes/ fashion. But w/silent votes, we can only guess.

Arm has trustzone, so you can’t simply nix x86 chips and be done with it. We would need to do the same research for arm chips.

This means we could create a demand for old phones by separating those without spychips from the rest. Although it’s a bit sketchy when considering all phones have a dodgy gsm stack designed for remote compromise, IIUC. Maybe Osmocom neutralizes it - not sure.

Oh I didn’t think of that. It’s native French speakers who use “mail” for “email” (when speaking english).