Copious access points are deployed by naïve admins who are oblivious to the fact that not everyone runs the latest gear.

They aren't usually naïve. Their goal isn't to support the oldest random gear. Its to provide a specific good experience for the majority of their users, usually on a tight budget, and with low maintenance overhead. Accommodating 802.11b is almost never part of the defined requirements.

When an 802.11b device cannot see a signal, it’s because some asshat proactively disabled 802.11b.

The good reason to disabled 802.11b on your access point is that if a device starts talking in 802.11b, most equipment will have the entire SSID slow down to accommodate it. Most folks aren't keen on having their fast wifi session slow to an 11Mbs crawl. 802.11b also rides exclusively on 2.4GHz, a frequency band that is very full these days with things like bluetooth, cordless landline telephones, and even microwave ovens. It can make for a miserable experience that the only cure for is to NOT use the 2.4GHz band, meaning also no 802.11b.

the fix An app that records SSIDs, their location, and all the detectable exclusivity characteristics.

That sounds like a fantastic way to build a database of known vulnerable users to exploit because of use of security vulnerability riddled older devices/OSes.

They aren’t usually naïve. Their goal isn’t to support the oldest random gear.

In that case, the naïvety is in their goal (as opposed tech naïvety). A public resource should obviously have inclusivety as a goal.

Its to provide a specific good experience for the majority of their users

Marginalising some people because some other ppl have the false perception of better performance is both absurd and elitist.

usually on a tight budget

It’s wrong to put chronic upgraders with new tech in the “tight budget” category. The tight budget category is for those with old devices.

and with low maintenance overhead.

Proactively unticking the 802.11b box requires more maintenance overhead AFAICT. You have to make the effort to configure it with less cabability then you have the overhead of answering complaints and user support questions about why Bob cannot see the SSID.

Accommodating 802.11b is almost never part of the defined requirements.

Bad requirements.

The good reason to disabled 802.11b on your access point is that if a device starts talking in 802.11b, most equipment will have the entire SSID slow down to accommodate it.

That’s not how it works. Different radios get different SSIDs.

802.11b also rides exclusively on 2.4GHz, a frequency band that is very full these days with things like bluetooth, cordless landline telephones, and even microwave ovens.

Please find me a microwave oven that does not function because of 802.11b signals in the area. Of course what you want to say is that the oven causes a problem for the 802.11b user, when in fact an 802.11b user will gladly risk that unlikely interference over getting no service at all. 802.11b has error correction, so there is no legit concern of data corruption. It’s also really grasping at straws to claim all those people on cordless non-GSM phones are having notable intereference issues. Bluetooth is only used in a <10 meter range (usually much less in practice), so also grasping at straws there.

That sounds like a fantastic way to build a database of known vulnerable users to exploit because of use of security vulnerability riddled older devices/OSes.

Citation needed that there is a credible server-side vuln relevant to a public access point.

Suppose a public library announces: we support 802.11b (among other standards) and we have no captive portal. Please describe the vuln and threat agent who would exploit it.

Another question for you: You're asking for an app to be created to catalog these sites that would support 802.11b. Are you proposing a smartphone app?

Proactively unticking the 802.11b box requires more maintenance overhead AFAICT.

I think your "As Far As I Can Tell" is really the key part here. It sounds like you do not have a background in enterprise IT as a number of your points are missing the knowledge that would come with that and lead you to an incorrect conclusion.

A public resource should obviously have inclusivety as a goal.

100% inclusivity isn't realistic. Its just not possible to design as system with infinite requirements. Sure, YOU are asking for only 802.11b, but if the requirement is 100% inclusivity then someone else can next come along and require IR or some other non-standard or deprecated technology.

Marginalising some people because some other ppl have the false perception of better performance is both absurd and elitist.

Its not elitist if the entire solution is slowed to an unusable speed because the impacts of a single 802.11b user has on the entire network. It becomes useless to everyone.

It’s wrong to put chronic upgraders with new tech in the “tight budget” category. The tight budget category is for those with old devices.

I'm not. I'm talking about the IT budgets. There isn't an infinite amount of money for IT.

That’s not how it works. Different radios get different SSIDs.

Okay so now you've just increased the cost of every access point because it has to accommodate a separate radio which didn't before. This goes back to IT budgets. There are much better uses for that money such as installing more access points in other areas for even greater access for more folks.

It’s also really grasping at straws to claim all those people on cordless non-GSM phones are having notable intereference issues. Bluetooth is only used in a <10 meter range (usually much less in practice), so also grasping at straws there.

No, you're not understanding because you're missing an IT background. Problems with service generate support calls. Support calls mean staff have to service this calls. This means you either have to grow your support staff, or burden your engineers with more work preventing them from performing more upgrades or improvements elsewhere. Further, these service calls would be something like "my wifi is horribly slow, or drops all the time", when those are problems of congested spectrum that there's nothing that can be done about that. You can't tell your neighbors to get a better shielded microwave. You can't limit the number of users in a specific area so the spectrum doesn't get overloaded. So you'd have unhappy users, unhappy engineers, and a whole bunch of money spent that doesn't accomplish the goal of getting the most people online with the finite budget available to IT.

Citation needed that there is a credible server-side vuln relevant to a public access point.

I didn't say server side. I meant client side. If you had created this app where it would be known that users with old out-of-date client hardware would be congregating, a malicious actor would have a field day exploiting them.

Another question for you: You’re asking for an app to be created to catalog these sites that would support 802.11b.

Both those with and those without 802.11b.

Are you proposing a smartphone app?

It’s an abstract proposal for an app that runs on a mobile device. A well designed app would run on old and new devices. New devices would have some advantages, like being able to detect 802.11be. So a 2025 device would be able to collect more useful details than a 2018 device.

I think your “As Far As I Can Tell” is really the key part here. It sounds like you do not have a background in enterprise IT as a number of your points are missing the knowledge that would come with that and lead you to an incorrect conclusion.

Most public APs are not enterprise deployments. Some public libraries outsource to Cisco, but a vast majority are SOHO routers sitting under the counter of a cafe or bakery. If the Cisco pros have to do considerably more work, I don’t give a shit about that. The app is collecting facts that matter to users. It makes no difference whatsoever to the collection of the relevant characteristics how much labor the Cisco pros are doing in their deployment.

A public resource should obviously have inclusivety as a goal.

100% inclusivity isn’t realistic. Its just not possible to design as system with infinite requirements. Sure, YOU are asking for only 802.11b, but if the requirement is 100% inclusivity then someone else can next come along and require IR or some other non-standard or deprecated technology.

No one said anything about absolutes. Of course it’s absurd to claim that in the absence of absolutes we should not collect inclusivity and availability data. It’s the opposite of what you imply. It is in fact the absence of absolutes that make this app useful.

Its not elitist if the entire solution is slowed to an unusable speed because the impacts of a single 802.11b user has on the entire network.

Yes it is elitist if you would then exclude that 802.11b user from service. Even if you have some absurd/bullshit idea that everyone in a cafe needs to stream high-definition video with no buffering, it’s still elitist to exclude those who have 802.11b and a decent buffering mechanism in their app for whatever they are doing.

It becomes useless to everyone.

Nonsense.

I’m not. I’m talking about the IT budgets. There isn’t an infinite amount of money for IT.

There is no sensible place in the app to give a shit about the budget of the supplier. The app collects facts. One might hope that high budgets will yield high availability and inclusivity which the data would naturally effectively reflect. But in the end that’s incidental -- not a problem for the app.

Okay so now you’ve just increased the cost of every access point because it has to accommodate a separate radio which didn’t before. This goes back to IT budgets. There are much better uses for that money such as installing more access points in other areas for even greater access for more folks.

Cheap Asus SOHO routers handle this. Again, the app makes transparent the quality of the deployment. Bad quality deployments are rightfully exposed.

No, you’re not understanding because you’re missing an IT background. Problems with service generate support calls. Support calls mean staff have to service this calls. This means you either have to grow your support staff, or burden your engineers with more work preventing them from performing more upgrades or improvements elsewhere. Further, these service calls would be something like “my wifi is horribly slow, or drops all the time”, when those are problems of congested spectrum that there’s nothing that can be done about that. You can’t tell your neighbors to get a better shielded microwave. You can’t limit the number of users in a specific area so the spectrum doesn’t get overloaded. So you’d have unhappy users, unhappy engineers, and a whole bunch of money spent that doesn’t accomplish the goal of getting the most people online with the finite budget available to IT.

If you want to dodge 802.11b deployments because you’re afraid a neighbor will use a leaky microwave oven while you’re trying to access the net, the data generated by the proposed app supports your use case. The same data for finding inclusive APs can be used to find elitist APs.

I didn’t say server side. I meant client side. If you had created this app where it would be known that users with old out-of-date client hardware would be congregating, a malicious actor would have a field day exploiting them.

Stop nannying people. Every user has their own use cases and with that implies a security posture and threat model that is right for that individual. Fuck you for trying to dictate to others what their security posture must be without even knowing their use case.

It’s also naïve to claim “out-of-date client hardware” is inherently too insecure for the task at hand. New software fixes old bugs and brings new bugs. Bugs are exploited by malicious actors. New software is rich in unknown bugs -- the kind of bugs you cannot control for. Old software is rich in known bugs and vulns, the kind that you can control for. This is why wise users do not “chase the shiny” and prefer to deal with the devil they know. It is rightfully the choice of the user in control of their own assets how they want to secure themselves.

You are divorced from the reality of how most of this works, its show up so many times in your perception of a problem and your proposal for a solution for that flawed identification of a problem.

802.11b was introduced in 1999. It was largely supplanted by 802.11g in about 2004. This means the devices you're advocating for support for are likely way over 20 years old. With 20-25 year old tech, you're into the definition of "retrocomputing" by that point. Even if you could get on the internet they are largely useless because the software clients for internet use have not been updated to meet today's web standards. Lets say you're successful and find an 802.11b access point on the internet. I would doubt you'd be able to run a web browser that would let you usefully access many sites.

It’s an abstract proposal for an app that runs on a mobile device.

There are no app stores for any device that only has 802.11b. The very first Android phone and very first iPhone both shipped with the later/faster 802.11g. Your crazy 802.11b requirement will be for device like a HP/Compaq ipaq Windows Mobile 5 device from 2004 like this:

You can't even buy batteries for those anymore. Who in the world are you trying to serve with this insane app idea?

A well designed app would run on old and new devices.

On what planet would you expect a modern app to be written that would run on both iOS 18, Androi16, Windows Mobile 5 from 2004? That's what you're asking for. THAT is your 802.11b devices. Most everything after that used newer 802.11g.

Most public APs are not enterprise deployments. Some public libraries outsource to Cisco, but a vast majority are SOHO routers sitting under the counter of a cafe or bakery. If the Cisco pros have to do considerably more work, I don’t give a shit about that.

I gave you the benefit of the doubt when you said "public APs" to mean municipal or state funded. You're not talking about those though, you're talking about privately owned APs that belong to businesses.

Stop nannying people. Every user has their own use cases and with that implies a security posture and threat model that is right for that individual. Fuck you for trying to dictate to others what their security posture must be without even knowing their use case.

No, Fuck you for trying to dictate that private businesses run insecure setups putting their other customers at risk because you want to run your 25 year old gear that can't effectively use the modern internet anyway because of how old they are.

Old software is rich in known bugs and vulns, the kind that you can control for.

Except you're NOT controlling for them, you're running on gear so out-of-date that they haven't been patched it years. The control is not using old insecure unsupported tech, or wrapping it in modern tech to control for the old, but you're not wrapping it. If you were, you wouldn't be asking for 802.11b.

You're so far out of your depth with your lack of understanding on this idea. I think it comes from a good place, but your ignorance far exceeds your ability to rationally even form the problem question much less propose a solution. You're not hurting anyone with your crazy ideas, so there's no reason to stop you, but I'm done given it any thought.

Have at your app! Good luck!