Some cafes have the shitty practice of imposing a captive portal for Internet access. Sometimes they demand personal information, and sometimes the captive portal discriminates against people with older phones.
Currently these cafes have the field “Internet access: customers”. That’s misleading and unjustly described. Some of them should be tagged with “Internet access: only for customers with new phones”. It’s not really fair to say it’s for all customers when they use exclusive technology.
“new phones” seems pretty unspecified and also likely be outdated in some years. If there was a field like that, I guess it should be more specific.
Have you tried asking in some osm community?
Yeah, it would not be trivial to establish a thorough criteria that covers all variables which mappers would then pay attention to. It would be more sensible to simply have a flag that says “dysfunctional for old phones” and if any device cannot connect due to being too old, it should be sufficient to set the flag.
There are countless ways incompetent IT folks can fuck up Internet service for the general public. It would be unsurmountable to catalog all such foolish/elitist implementations. But some of the info can be automated. A mapper who is at a location could run a tool that does a wifi scan. The mapper could select the relevant SSID for the establishment, and some basic info could be captured just from that: WEP/WPA/open… and if open then presence of a captive portal could be auto detected.
If such an tool were made to improve maps, it could also double as enriching a DB for navigation use (for those who navigate offline and/or refuse Google location tracking).
Have you tried asking in some osm community?
No. Thanks for reminding me. I was planning to crosspost there.
Maybe mark it a compose of 2G/3G/LTE/NR, such as LTE only/3G+LTE/LTE+NR.
But there is another issue: the cell tower is belong to different MNO, so for some MNO you get 3G+LTE but for another MNO you get LTE.I think OP is talking about WiFi with entry barriers in this case
Ok. Mark it as Open/OWE/WPA/WPA2/WPA3/802.1X. The main reason prevent old phone connect is WPA version. The newer WPA version require newer hardware and software.
Check the OP. it’s about login portals.
Indeed GSM is irrelevant because GSM towers cannot relate to any particular business. GSM standards are much less of a problem. When the country decides to abandon LTE, all non-5G phone owners are fucked nationwide.
It’s a Wi-Fi problem. Captive portals are the biggest problem, and the most obnoxious problem because it’s an artificially created problem as a consequence of incompetence. I only had captive portals in mind when writing the OP, but there are also situations where someone configures an AP to not use 802.11b (for example) and then old hardware does not even see the SSID. My laptop cannot connect at some public libraries for this reason. Then WPA versions /could/ be an issue, I think, but I have not encountered that.
That sounds a bit too micromappy for me, but you should open a discussion on the Wiki anyways.
When you are offline in an unfamiliar region, the most important information at your disposal is where you can reliably get online.
You seem to want to oppose bloat. Internet access is what makes a lean map feasible. It enables you to supplement whatever info is needed. But of course if you are offline, and the map fails to effectively bring you to reliable Internet acess, then everything needs to be in the map because the map is all you have.
So your stance makes no sense. A lean map requires rich reliable info about Internet access in the very least.
You seem to want to oppose bloat.
No, far from it. I am all in favor of making the map as detailed as possible.
What I mean is that this tag is extremely niche, requires local survey, takes some effort to survey, is not very specific, and probably not useful for most people, even with old phones.
It requires quite a bit of technical knowledge to even know what a captive portal is, it also requires going inside the establishment, asking for a Wi-Fi password, connecting to it, figuring out if this captive portal can be used with an “older phone” (this is the unspecific bit), and adding that info to openstreetmap.
All this while we still don’t have
opening_hoursfor the majority of amenities, and I’d guess the vast majority of POIs worldwide are not mapped at all.This means it is highly unlikely to be used almost anywhere, and this means in turn that no data consumer will properly support it.
What I would propose instead of changing the
internet_accesskey itself, is to define a new key likeinternet_access:captive_portal, with defined values ofyes: a captive portal is there but doesn’t require personal info, e.g. one that shows you adsphone_number: requires just a phone number which you can confirm is yours, is a legal requirement in many countriesid: requires some form of ID but no phone number, sometimes can be a legal replacement for the phone numberno: no captive portal
This just adds new info instead of changing the already-understood
internet_accesskey, it’s way more specific than “customers with new phones” (since it is easy to check), and allows you to figure out if you can connect or not in most cases. You can approximate whether you can use wifi with an old phone by checking forinternet_access:captive_portal = no, you can see if you need a sim card by checking thatinternet_access:captive_portal != phone_number, etc.But TBH even this is completely impractical and will be useless for the stated purpose. Just trying a few different cafes until you find one where the internet works for you is a much better strategy than trusting a stranger to correctly fill in some obscure key.
This doesn’t mean that I’m against adding something like this; after all, I have mapped all trees in my local park, including
species, and regularly map cairns while I’m out hiking. But you have to understand that even if you push this through and it appears on the wiki, this is mostly just for fun.What I mean is that this tag is extremely niche, requires local survey, takes some effort to survey, is not very specific, and probably not useful for most people, even with old phones.
Most people probably don’t have old phones. But almost everyone who does would benefit. Only those who never need to connect on the go would not benefit. Those with new phones would also benefit if the information has good granularity, which I will explain below.
Mention of old phones was a human-to-human abstraction. Vulnerable groups of people are being marginalised. The DB would not use the term “old” or “new”.
What most importantly needs to be captured at the simplest level is:
- Internet access: null (unknown)
- Internet access: none (verified)
- Internet access: discriminatory
- Internet access: non-discriminatory
The discriminatory connection can be regarded as such for many different reasons, some deliberate (captive portal w/SMS verify), many incidental (captive portal coded by a JavaScript fanatic with no sense of standards or interoperability).
It requires quite a bit of technical knowledge to even know what a captive portal is,
Only if this is a purely manual process. Captive portals are trivial to auto-detect.
it also requires going inside the establishment, asking for a Wi-Fi password,
Only if there is a p/w. This would be a minority of cases.
figuring out if this captive portal can be used with an “older phone” (this is the unspecific bit),
Non-trivial indeed for anyone with a newer phone. An app could work out what tech is being pushed. But it may be impossible for an app to determine what tech is relevant to passing the captive portal. So accurate granular data would likely rely on manual intervention.
All this while we still don’t have
opening_hoursfor the majority of amenities, and I’d guess the vast majority of POIs worldwide are not mapped at all.This is really irrelevant. Volunteers contribute what they want. And rightfully so. Opening hours could be made less labor intensive with an AI app that encodes the hours based on a photo. But in any case, having some type of missing info is no justification for preventing people from adding other missing info.
What I would propose instead of changing the
internet_accesskey itself, is to define a new key likeinternet_access:captive_portal, with defined values ofyes: a captive portal is there but doesn’t require personal info, e.g. one that shows you adsphone_number: requires just a phone number which you can confirm is yours, is a legal requirement in many countriesid: requires some form of ID but no phone number, sometimes can be a legal replacement for the phone numberno: no captive portal
This just adds new info instead of changing the already-understood
internet_accesskey,I’m not sure why I would be fussy about whether it uses one attribute or another. DB experts would likely and rightfully want to ensure the info is not redundant or having potential for contradiction.
Captive portals come in countless forms: userid+pw, Tel#, GSM-only # for SMS verification, email, ToS agreement, and any combination of those. What’s important is some captive portals are non-discriminatory (no info required and also does not push JavaScript frills that breaks things).
If an AP is 802.11b w/out captive portal, that is a trivial case where it’s safe enough to yield a “non-discriminatory” tag.
But TBH even this is completely impractical and will be useless for the stated purpose.
Only if you do it wrong.
Just trying a few different cafes until you find one where the internet works for you is a much better strategy than trusting a stranger to correctly fill in some obscure key.
Try to step outside of yourself and your own privileged lifestyle and envision yourself in the shoes of marginalised travelers. You land in a foreign city on a cheap day trip. You have ~8-10 hours to experience the city before getting back on the bus or train. You might know you can go to McDonalds to get connected reliably, but you’re failing to exploit effeciently using precious time in a city that has more to offer than you can experience.
You might decide you want local pancakes, not McDonalds pancakes. There are ~10 places marked as having pancakes. Seven have “Internet”, and are scattered around a 7km area. If you go from one to the other on foot, you can easily blow ~20% of your day on a hunt, and still come up empty-handed. If just one pancake shop has “non-discriminatory Internet”, you can make that your 1st attempt and have a good chance at getting a no-bullshit connection while also getting pancakes.
But you have to understand that even if you push this through and it appears on the wiki, this is mostly just for fun.
Helping marginalised people function is more than “just for fun”. Blocking it amounts to being part of the list of problems that force people to upgrade phones and add to the world’s e-waste.
I think you’re misunderstanding me. What I’m saying is literally “go for it”, and proposing what I think is the best way of doing it.
You’re free to just start adding
internet_access:captive_portaltags with whatever values you want to cafes you’ve surveyed, as long as you don’t breakinternet_accesstags it’s fine. OSM tags are folksonomy, after all. I think if you care about it this is the least you can do.Getting it on the wiki would be more difficult - it would require a detailed proposal and an RFC. That’s good in a way, it would force you to think about different values this key might have, and how consumers might handle it. You should probably also do this, so if others also want to do the same you can agree on which keys and values to use.
The most difficult part is going to be getting any data consumers to handle the key in any way. Unless you go ahead and make good-quality patches for a lot of apps (and have the energy to push them through), the best you can realistically hope for is for the key to show up in some obscure menu of “other tags”, likely not even searchable. This is the main reason why it’s going to be pretty much useless for the near future.
Believe me, I’ve been on a few cheap trips like that when I was younger. Back then very few cafes even had public WiFi, and despite
internet_accesskey being already defined, the easiest way to find a cafe with internet was to just walk about - almost none of it was mapped. You can expect the same to be true for your proposal for a long, long time - at least a decade or so, even if it gets accepted.
Captive portals have existed for ages, I dont know of any that check phone age, can you share an example?
Captive portals could check the age of the phone by looking at the user agent string in the HTTP headers. I’m not sure how often that happens, but at several cafes my AOS 5 device would detect a captive portal and then simply render a giant red padlock that covers the screen.
Certainly a majority of the DoS I experience is simply a broken captive portal. The browser renders fewer objects than intended by the web devs, who recklessly assume all browsers are bleeding edge latest that can handle whatever coding frills they deploy. E.g. the screen might say something like “click ‘agree’ to gain access”, but then there is no button, tickbox, or object labeled ‘agree’. A bus or train captive portal will render a nice looking travel-related landscape image, and nothing else. No text. No buttons. Just an image. People with fancy phones would of course get some kind of object they can interact with. One supplier presents an agreement tickbox, but tapping on the box does not cause the box to tick.
I’m not sure what the red padlocks are about. Maybe the devs know they created a discriminatory shitshow, and they choose the dress up the dysfunctionality by detecting browser age and throw up a red padlock instead of trying.
