cross-posted from: https://slrpnk.net/post/30993218
Copious access points are deployed by naïve admins who are oblivious to the fact that not everyone runs the latest gear. The shitty practice of pushing wi-fi in an arbitrarily exclusive way needs pushback. The first step is exposure. We need to enumerate the various ways demographics of people are being excluded and collect a DB on it.
The wi-fi protocol is the first point of failure. E.g. 802.11b vs 802.11a/g/n… All new hardware is backwards compatible with older protocols. When an 802.11b device cannot see a signal, it’s because some asshat proactively disabled 802.11b.
Most exclusivity occurs with shitty captive portals. There are countless ways to fuckup a website to make it exclusive. E.g.
- to impose SSL, which inherently imposes recent certs and CAs that exclude old devices. It’s essentially rock stupid when the captive portal is nothing more than a button that says “I accept the ToS”.
- to impose JavaScript, which encapsulates a whole industry of poorly trained people who have no concept of stability of standards and interoperability.
- to impose SMS confirmation, which makes the ignorant assumption that every single user has a mobile phone, that they carry it with them, and that they are willing to share their number willy nilly.
🌱environmental impact🚮
The brain dead practice of deploying public Internet access using needlessly exclusive tech is a form of forced obsolscence. It’s one of the factors that pushes people to throw away working devices in order to overcome these ecocidal Internet access deployments.
🔧the fix💾
An app that records SSIDs, their location, and all the detectable exclusivity characteristics. It should also take human input with notes to record exclusivity that is not auto-detectable. Ideally the local DB would sync with a central DB. It should also be possible to extract a GPX file for a given region which could then be imported into OSMand or Organic Maps.
Badly implemented captive portals are an issue, yes. But enforcing certain security standards on public wifi so that random people can not see everything you are doing online is good.
And I would advise against going online with a device so old and unmaintained that it has issues with its SSL root certificate.
But enforcing certain security standards on public wifi so that random people can not see everything you are doing online is good.
There is a blind “for security reasons” excuse the industry likes to use to force people to chronically upgrade their hardware… to boost sales. I try to stay immune to that bait.
The access point needs to protect itself – full stop. An access point that oversteps their authority and becomes a nanny that dictates security practices on others without knowing their security posture and threat model to protect people from themselves can bounce. We don’t want their “help”.
In any case, the DB I am proposing is factual. Whether a fact in the DB is “good” or “bad” is for the users of the DB to decide. And either way, it’s useful.
And I would advise against going online with a device so old and unmaintained that it has issues with its SSL root certificate.
Can you give more details? If the certs have not expired, the device is able and willing to make a connection. If the certs fail due to age, the app makes the user aware of the problem (and in the case of OSMand it refuses to use the connection regardless of the user’s wishes). So what’s the issue?
Note the context is with captive portals. If someone thinks it’s a good idea to force a captive portal on a public LAN to get a simple “I agree” signal, why might that be sensible? AFAICT, it’s down to a clumbsy admin who did not think through the consequences of SSL on a captive portal. The captive portal is not in itself a useful resource for the user. It’s just an obsticle with the sole purpose of getting a signal that someone agrees to the text of a policy that is public anyway. Once the obsticle is out of the way, it’s the independent job of every resource to implement appropriate security for the task at hand, which in come cases may not involve SSL at all (e.g. accessing an onion server). But when the captive portal blocks someone due to (what I regard as clumbsyness), the apps the user would use are blocked regardless of how well they are secured.
(edit) Some captive portals collect personal info, where you must submit an email or phone number. SSL is probably unavoidable in those cases, but ideally the app would collect that info as well. We would want the DB to indicate that sharing personal data is a precondition to access.
If someone is offering a public wifi, there is a reasonable expectation that other people sitting in the same cafe for example can’t listen in on what you are doing on your device. As older wifi encyption standards are easily compromised, this requires enforcing a semi-recent wifi-standard. You can of course make your own judgement in your own home, but in a public space it is different.
As for SSL certificates… this isn’t only a captive portal issue. If your device has such outdated root certificates that you run into issues already at the captive portal, you will have also issues with each and every website that uses https. Root certificates are only cycled out of use for good reasons, such as them becoming compromised, so by using an super old root certificate on your device you are wide open to MITM attacks on supposedly secure connections.
