That seems like a pretty big assumption. From what i understand there already exists deployment of wifi hot spots to track people (both for advertising purposes and for spying purposes) to the extent that phone providers started radomizing MAC addresses.

I am saying that using deauth packets to prevent wifi from operating does not seem to be outright illegal and there are valid reasons to be able to do it. Considering basically every high end AP has the ability to target rogue APs and the FCC takes a dim view on people selling jammers, it seems like the context of the application of this determines whether you are jamming or not and not the use of deauth packets by itself.

I mean if you define the party as hostile then yeah but that also all applies to a non-public network controlled by a hostile party but [Citation Needed] that this is something that people are likely to encounter in the wild. If were at all common it would be pretty noticeable because you'd notice any certificate shenanigans and it wouldn't take that long for a technical person to come along and notice any port scanning. That's before considering that OS's typically have a more aggressive firewall posture on public networks to begin with not making them particularly juicy targets.

>Brave browser does not implement this URL after a cursory examination.

Brave has to be a snowflake but it's just a restyling of the same settings page: brave://settings/security

>Google has also unquestionably had a caustic and corrosive impact upon privacy in a myriad of realms. They can and do receive subpoenas constantly, and the only way out of their databases is wiping all of their closed-source components from your devices.

Security != Privacy and those are frequently completely at odds. It's hard to argue that public wifi is anything but a privacy nightmare but from a purely technical security perspective, I must just shrug at public wifi now.

Isn't it odd that you can't read electromagnetic signals penetrating your walls without your consent?

Wrong. Remember Dmitry Bogatov's case. Yes it was a Tor exit, not an open WiFi, but it doesn't matter. Even worse, there is now a law here in Russia that prohibits running WiFi access points that don't take technical or organizational measures to identify (e.g. get passport or phone number of) the person who is connecting.

Making your phone use max power to emit information is nothing like the wifi radiation you get from your neighbors.

What gives you, company xyz, the right to essentially DoS an AP just because they share the SSID? Just because you call something CorpWiFi, doesn't really make it legal to DoS someone else's SSID that is also called CorpWiFi. There does not seem to be any kind of legal framework that would allow you do so, but inversely, you are essentially then not only committing multiple types of crimes, but you are also violating free speech.

I get the reason, but the solution really needs to be something else, even if that something else is some sort of change to the WIFI spec and inclusion of some kind of authentication or security layer.

And that is, of course, where people come to reasonable disagreement; it simply doesn't feel creepy to a lot of folk. I assume the difference in feel is whether one interprets "capturing unsecured wifi packets via wardriving" as akin to peeping-Tomming into every neighbor's house or akin to sailing along a coastline full of lighthouses broadcasting their beacons and writing down the strobe patterns.

That's a misnomer. It doesn't actually make it hidden, only transmit beacons with a blank ssid. That's why even if your network is hidden, it will show a "hidden network" option for you to manually enter the SSID[1]. Moreover, client devices that have hidden networks saved will send out probe packets with network names it has saved[2], so it can determine whether the hidden network is actually around. This is actually worse for privacy, especially if your network name is vaguely unique, because you're broadcasting this high entropy information everywhere you go.

[1] https://www.digitalcitizen.life/wp-content/uploads/2020/10/h...

[2] https://www.acrylicwifi.com/en/blog/hidden-wifi-network-secu...

consent isn't needed, given that broadcasting your SSID in the open clearly fails the "expectation of privacy" test.

Also from a practical angle, what exactly are you trying to prevent? That there's a wifi router at your house?

To play devil's advocate, some APs support rogue triangulation. Ours plot any rogues on a building map so we know exactly where they are. When combined with a proper wireless survey, you could ensure that they don't deauth anything beyond the building perimeter. Not that I recommend that, since at the very least someone should be able to tether their phone if they want. But also because it puts additional overhead on your APs, which are usually already taxed in high-usage areas.

Probably but you'd have to check the captive portal's TOS

When working for an ISP it came up quite a few times that customers had extensive questions about security because they were genuinely worried about their ex-spouse spying on them. Even if they were all just "paranoid" in their specific cases (I wouldn't know), I think it's a fair concern. If all it takes is some googling and a bit of money to rent cloud GPU's, well, scorned lovers have done way more expensive and less effective things to cause damage or violate privacy.

Literally every single public wifi network, which is a significant percentage of all internet traffic (including basically everyone working from a wework for example), is vulnerable to eavesdropping/mitm

I'm not saying you're wrong, or that they're right. However, it seems to me that there has to be a middle ground between draconian signed blobs (which I'm not convinced will solve much for long, either) and the silliness that is the current state of things. Deauths have been used in so many wifi cracking schemes over the years and the fact we still don't seem to care about them (or treat them as harmful interference and blame the device) is getting silly.