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

Re: [Captive-portals] captive portal browser capabilities



Erik Kline <[email protected]> wrote:
    >> I will not be surprised if there is nothing that satisfies my needs
    >> and is still capable of dealing with portals.

    > Can you clarify what "dealing with" means here for you?

    > Automatically interacting with a portal? (e.g. clicking agreement
    > checkboxes, filling in email addresses or facebook details, ...)

That would be be awesome, but until we are widely successful, it isn't going
to happen, so it's really, as you guessed:

    > Detecting the presence of a portal and then "calling a human for
    > help"?  (vis. your Chrome X11 forwarding idea)

Calling human for help.
The connectivity is not for long durations of time.

The initial purpose of this box is to bring IPv6 uplink into a wired testing
environment, and act as the "ISP" link for other devices.
[Some of which will be captive portals under test... :-)]

But, you didn't comment on my real query:

> So it occurs to me that maybe a document that establishes a reasonable
> subset of capabilities would be a good thing to have.  Then at least, both
> portal makers and captive portal browser providers could have something to
> work towards.

> Maybe this is really W3C work?



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



Attachment: signature.asc
Description: PGP signature