[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 =-
- [Captive-portals] captive portal browser capabili… Michael Richardson
- Re: [Captive-portals] captive portal browser capa… Erik Kline
- Re: [Captive-portals] captive portal browser capa… Michael Richardson