Subject: Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas
From: Michael Richardson <[email-masked]>
To: Tommy Pauly <tpauly=[email-masked]>
Cc: David Bird <[email-masked]>, Erik Kline <[email-masked]>, captive-portals <[email-masked]>
Date: Thu, 02 Jul 2020 14:55:31 -0400
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>

Not really a CAPPORT protocol problem... but...

Tommy Pauly <tpauly=[email-masked]> wrote:
    > One point I wanted to clarify: the iOS and macOS betas support for
    > CAPPORT discovery and APIs still goes through the standard and existing
    > UI flow for captive portals. The times in which the captive portal UI
    > is shown is limited, for example to times when the user is in WiFi
    > settings.

Is there a simple way for the user to get back to the portal page from the
notification bar?  Can the user choose to keep it open longer?

I noticed on the Thalys train that if you closed the portal page that it
tended to kick you off the network.  That is definitely an anti-pattern!!!
I don't know how we will cope with it, while at the same time, making it
clear that it's a bad design.

Worse was that the portal page had a nice tiled map with the current
location... AND THE TILES WERE NOT LOCAL.  So as more and more people learnt
to keep the page open... the network got significantly slower.

    > Thus, while adoption should indeed be easy and only require
    > adding a small bit of infrastructure in order to provide a flow that
    > doesn’t require redirects, the set of circumstances in which a network
    > can display content to the user is not increased.

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