Subject: [Captive-portals] captive portal browser capabilities

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jan 2019 12:11:32 -0500

I find myself setting up a container that will be deployed as part
of an IoT solution.  It will need to deal with captive portal interfaces
as the purpose of the container is to provide uplink connectivity.

It would be nice if it could be lynx/elinks/etc, but I doubt that
will work well enough.   Running something via ssh-forwarded-X11 would
be acceptable. Ideally the browser is so limited in functionality
that it seldom needs upgrades, and also ideally it's a single (if big) binary
without any LD_PATH dependancies.  And available for armhf :-)

I will not be surprised if there is nothing that satisfies my needs
and is still capable of dealing with portals.

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-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Erik Kline <[email-masked]>
Date: Fri, 18 Jan 2019 11:48:50 -0800

> 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, ...)

or

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

or something else?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 18 Jan 2019 15:32:35 -0500

> checkboxes, filling in email addresses or facebook details, ...)

That would be be awesome, but until we are widely successful, it isn't going

    > 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:

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