[Captive-portals] captive portal browser capabilities

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 18 January 2019 17:11 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4862130EAC for <captive-portals@ietfa.amsl.com>; Fri, 18 Jan 2019 09:11:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBEfvuKE7ZSk for <captive-portals@ietfa.amsl.com>; Fri, 18 Jan 2019 09:11:35 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE8DC130E8A for <captive-portals@ietf.org>; Fri, 18 Jan 2019 09:11:34 -0800 (PST)
Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 95A053808A for <captive-portals@ietf.org>; Fri, 18 Jan 2019 12:10:52 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 11A80262D; Fri, 18 Jan 2019 12:11:32 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 10254B8C for <captive-portals@ietf.org>; Fri, 18 Jan 2019 12:11:32 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: captive-portals <captive-portals@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Fri, 18 Jan 2019 12:11:32 -0500
Message-ID: <26273.1547831492@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/_EoSY9NGV54IdzjdunzWw4tlxE4>
Subject: [Captive-portals] captive portal browser capabilities
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Jan 2019 17:11:38 -0000

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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-