[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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





On 5 April 2017 at 22:30, Michael Richardson <[email protected]> wrote:

David Bird <[email protected]> wrote:
    > -- We tend to ignore what the venue/Hotspot operator wants.. They WANT
    > you at the captive portal... Hence, why they went out of their way to
    > have a CAPTIVE portal. We could define an alternative method for the
    > portal, but why? Do Hotspot operators WANT more interfaces, with
    > unknown user experiences, that limit their options? There is a reason
    > why in WISPr the browser method was called the "Universal Access
    > Method"... because, well, it's universal. (Moreover, Hotspot operators
    > are largely marketing companies -- they are very used to designing Web
    > user experiences, that is their business).

That's only one view.

Some operators need a record of who used their network for legal reasons.
It's not all about advertising either; at Midway Airport, it was about
having me pay after my free sample wore off.  At my hotel, it was about
keeping the network from being overrun by riff-raff.

In one case that was brought to our (Android's) attention, there was a Wi-Fi provider in a refugee camp who was using the captive portal feature in their equipment to show a camp information page (where to go for medical services, which phone numbers to call for XYZ, etc).

Such a use case would argue against bypassing the page via some kind of auto-sign-in, but might highlight the need for an "information about this network" URL.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature