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.

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 portalThis 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.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.