To fight back against chronic forced smartphone upgrades, we need a tool to track public access points that impose new phones
To fight back against chronic forced smartphone upgrades, we need a tool to track public access points that impose new phones
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.
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.