Re: [Captive-portals] Arguments against (any) Capport "API"

[David Bird <dbird@google.com>]

On Thu, Apr 6, 2017 at 8:05 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

David Bird <dbird@google.com> wrote:
    > I agree, but chances are VERY high that _something_ will trigger the Os
    > capport detection to give the user a captive portal notification.  If
    > not, then the walled garden is so large that the UE (nor the user)

Only if the user hasn't got another network connection.

There may be many possible (wifi) networks available, and being able to ask
each what they provide without leaking any other http traffic or DNS requests
seems like a good thing to me.

a) You are already leaking information (DHCP, etc) as you need IP connectivity before you do anything (unlike Hotspot 2.0 where you are in fact querying networks prior to association). In the case of Open WiFi, you also already had user intent to join the network. If you are talking about auto-login scenarios and leaking information, I'd argue that has nothing to do with "captive portals" and more to do with "public access" ... and auto-login into public access is pretty much always a bad idea (unless further security is being provided).

b) You will happily leak all this information when there IS NOT a captive portal... How did the portal increase your exposure? The portal, in some respects, is doing you a favor.

 

I haven't found the point in the thread where the arguments against were
clearly stated. Feel free to unicast me a pointer to the right part of
the archives.

a) There really is no incentive for any venue/operator to deploy the API (if there is an incentive, it isn't to the benefit of the user, see below)

b) If 'discovery' (e.g. knowing what is in walled garden, etc) is through an API, you will have hotspots that keep Capport device 'captive' when the network might not really enforce it. I think you just gave the operator WAY too much control over the Capport compliant device. Not to mention, it would be embarrassing that you will have hotspots that keep "Capport compliance" devices captive, where legacy devices are not. 

c) There is highly likely that you will have broken implementation (e.g. an API and a DHCP server support Capport, but without any real NAS) - this could be intentional or completely by mistake. You can imagine it would be pretty easy to mistakenly configure a DHCP server with a "Captive Portal URL", pointing it to some hotspot provider company, and presto - you have a Capport device only hotspot (that doesn't actually work). 

d) There will be such huge problems in deployment that UEs will just ignore this Capport API, still rely on Legacy discovery, and nothing has changed (in fact, it only got more complicated and broken).