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

Re: [Captive-portals] time-based walled gardens



Absolutely, within a 'closed' environment (e.g. where you have control over your walled garden, what Apps are installed or offered to users, etc), you can do all sorts of cool and clever things with custom interfaces, APIs, and auto- or assisted- logins. This is true today for Hotspot operators (within their own garden and App, they can do anything they want, more or less). This is also true for roaming aggregators (they use their own APIs accessed through the walled garden of Hotspots in their network). None of these solutions require IETF or any standards... I think it is a mistake to try and figure out a common API for everyone to use, as it will never fit all use-cases. In my opinion, we can only create sort of 'core' protocols to convey configuration and network feedback and let the industry decide how it applies to their use-cases.


On Mon, Apr 10, 2017 at 7:57 AM, Michael Richardson <[email protected]> wrote:

David Bird <[email protected]> wrote:
    > Agreed. Except, I'd argue that the "API" could be seen as the browser
    > itself - the "universal" API that everyone is familiar with and that
    > offers endless possibilities. Today, browsers offer largely the same

I don't mind if there is a JS client available for download, but I feel that
the API needs to be real.   On my phone, many of the "core" interactions that
occur over HTTP do not use the stock browser:  Facebook (lite), G+, Hangout,
Strava,  Tripit, etc.

Secondly, in a classroom situation, it might be worth having the ICMP
receiver on the child's system do something different.  In particular
it can not open up the child's browser for the override code.
(Because the teacher will be subject to keystroke capture attacks by
the student)

    > As for as API for login, as I previously mentioned, that already
    > exists and widely deployed and used. Replacing WISPr is a GOOD idea,
    > but I question whether there will be motivation to actually deploy it
    > (unless we make a mistake and it is useful for additional commercial
    > trickery in public access).

okay, I don't know WISPr's capabilities.


--
Michael Richardson <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-