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.

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:
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).
Only if this is a purely manual process. Captive portals are trivial to auto-detect.
Only if there is a p/w. This would be a minority of cases.
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.
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.
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.
Only if you do it wrong.
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.
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.