Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Tommy Pauly]

Hi Steve,

Glad you’re testing is going well so far.

> On Jul 7, 2020, at 6:03 AM, Steve Haskew  wrote:
> 
> Hi Tommy,
> 
> I have now been doing some testing of our solution with iOS 14 and it has 
> been fairly straightforward in getting it all working at a basic level!
> 
> I have a couple of observations/queries:
> 
> Just to confirm, are you not yet supporting any of the informational elements 
> (venue info URL, seconds remaining etc) since you say the user experience is 
> not changing? Despite setting these values I am not seeing any difference.

That’s expected. The iOS 14 beta doesn’t include any changes to the Wi-Fi 
settings. There are ways to check for the values being parsed in system logs if 
you want to confirm, however. 

> 
> Secondly I have on a few occasions been directed by probe instead of via the 
> API. I am working to replicate this with packet capture etc so that I can 
> determine whether it’s variation in my setup or any kind of bug, but it is 
> also likely just because I am repeatedly logging in and out and jumping on 
> and off the network in question! Do you know what the criteria is (timeout 
> values on the API request, any retries on the API request? etc.) for fallback 
> to probe method?

If you can submit a feedback/bug with system logs attached when you see this 
behavior, we can look into it. There are various error heuristics for when we 
fail to receive a valid API connection. Likely we’re hitting one of those, but 
it would be good to confirm which.

> 
> Thanks for your efforts in getting this implemented!

Thanks for implementing it too!

Best,
Tommy
> 
> Steve
> 
> 
> 
>> On 22 Jun 2020, at 22:30, Tommy Pauly  wrote:
>> 
>> 
>> Hello CAPPORT,
>> 
>> I wanted to highlight an announcement we’ve made for the betas of iOS and 
>> macOS released today:
>> 
>> How to modernize your captive network 
>> 
>> 
>> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis and 
>> draft-ietf-capport-api by default. This doesn’t change the user experience 
>> of logging onto captive networks, but the system will request the DHCP 
>> options and handle the RA option, and will prefer using the Captive Portal 
>> API Server interaction over having a probe that is intercepted.
>> 
>> If you have a portal system that is already implementing the CAPPORT 
>> features, please test out these betas and let us know if you see any issues! 
>> And if you have a captive portal solution, we’d encourage you to start 
>> supporting this soon.
>> 
>> Best,
>> Tommy
>> 
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Steve Haskew]

Hi Tommy,

I have now been doing some testing of our solution with iOS 14 and it has been 
fairly straightforward in getting it all working at a basic level!

I have a couple of observations/queries:

Just to confirm, are you not yet supporting any of the informational elements 
(venue info URL, seconds remaining etc) since you say the user experience is 
not changing? Despite setting these values I am not seeing any difference.

Secondly I have on a few occasions been directed by probe instead of via the 
API. I am working to replicate this with packet capture etc so that I can 
determine whether it’s variation in my setup or any kind of bug, but it is also 
likely just because I am repeatedly logging in and out and jumping on and off 
the network in question! Do you know what the criteria is (timeout values on 
the API request, any retries on the API request? etc.) for fallback to probe 
method?

Thanks for your efforts in getting this implemented!

Steve



> On 22 Jun 2020, at 22:30, Tommy Pauly  wrote:
> 
> 
> Hello CAPPORT,
> 
> I wanted to highlight an announcement we’ve made for the betas of iOS and 
> macOS released today:
> 
> How to modernize your captive network 
> 
> 
> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis and 
> draft-ietf-capport-api by default. This doesn’t change the user experience of 
> logging onto captive networks, but the system will request the DHCP options 
> and handle the RA option, and will prefer using the Captive Portal API Server 
> interaction over having a probe that is intercepted.
> 
> If you have a portal system that is already implementing the CAPPORT 
> features, please test out these betas and let us know if you see any issues! 
> And if you have a captive portal solution, we’d encourage you to start 
> supporting this soon.
> 
> Best,
> Tommy
> 

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[David Bird]

As an individual design decision, I agree... Just that the protocol spec
does not attempt at requiring this...
Also has deployment issues as each enforcement device now needs the
"operator" SSL certificate.

On Fri, Jul 3, 2020 at 1:33 PM Erik Kline  wrote:

> The enforcement device and the API endpoint can be the same device, if you
> like.
>
> On Fri, Jul 3, 2020 at 9:37 AM Steve Haskew  wrote:
> >
> > David,
> >
> > This is a very good observation - and one that we have had to consider
> in our implementation. The source of the captive status needs to be
> reliable and quick enough to achieve the flow described in section 6
> (Example Interaction):
> >
> > "Once the user satisfies the requirements for external network access,
> the client SHOULD query the API server again to verify that it is no longer
> captive.”.
> >
> > For us, the API saying the user is online but the enforcement device
> still blocking them would be a major support headache, but could be caused
> by a number of different scenarios. This sentence was key in making us seek
> a robust solution to that possibility.
> >
> > Thanks,
> >
> > Steve
> >
> >
> > On 3 Jul 2020, at 17:23, David Bird 
> wrote:
> >
> > Thanks Steve, I have no doubt that some operators will implement this
> very well! :-)
> >
> > Indeed, the login flow is the same through the Portal via API (assuming
> you figure out the "unique device identity" question).. and I'm sure you'll
> have the API server fully integrated with your AAA so that all sorts of
> logout events are handled (e.g. NAS restart, idle timeout, etc).
> >
> > In the long-tale of public access, I believe users will experience a
> wide range of networks, with various levels of integration. My concern is
> more that users learn (or even told by venue staff) to disable CAPPORT
> support if they find it often "wrong" (e.g. there is a CAPPORT API but no
> NAS enforcement; API says you are logged in, but NAS is
> dropping/redirecting; etc)...
> >
> > [I personally believe we missed an opportunity to make a more robust
> protocol by directly involving the NAS (for notification of captivity),
> providing a single source of truth...]
> >
> > On Fri, Jul 3, 2020 at 7:13 AM Steve Haskew  wrote:
> >>
> >> Hi David, Tommy, all,
> >>
> >> Just to add the the discussion, from the perspective of a network
> operator! We are just implementing and going to be testing this very soon..
> We don’t see any issues in terms of policy application, because the final
> step to log the user in will be the same with either approach. Actually,
> this provides a really nice route for us to resolve the ever-increasing
> issue of the ugliness of forcing redirects, especially with the decreasing
> use of plain HTTP (and therefore causing SSL warnings). We can only hope
> that other vendors roll this out soon too! I see it as a big step forward..
> >>
> >> However, the challenge for us that is linked revolves around identity.
> MAC Randomisation (also coming in iOS 14)  is great for privacy, but in the
> short term is poor for user experience on any form of guest wifi,
> particularly for longer stays (e.g. hotel, vs cafe). We’ve actually seen a
> deterioration of support for Hotspot2.0/Passpoint, in that installation of
> a profile from within the Captive Network Assistant on iOS no longer works.
> >>
> >> It feels like the dichotomy of privacy vs user experience here has no
> practical solutions - could this be something that the wider WG has
> previously considered, and is it within the remit of the group to look at?
> >>
> >> Thanks,
> >>
> >> Steve Haskew
> >>
> >>
> >> On 3 Jul 2020, at 14:23, David Bird 
> wrote:
> >>
> >> Thanks Tommy,
> >>
> >> Might you have screenshots of the user experience ? I'd be interested
> to see it
> >>
> >> Agreed, adopting the new CAPPORT spec is very easy to setup (just a
> DHCP server config change at the access point, and an API/Portal server on
> the Internet). The complexity for network operators comes when fully
> integrating this new "application" method of captive portaling with
> existing "network" (NAS/redirect) methods. The complexity is in ensuring
> the NAS and API are enforcing the same policies, for all kinds of users
> (roaming, paid, free, etc) ... if the network operator doesn't do this
> well, or at all, then the complexity is shifted to client device support,
> answering questions like "Why does the WiFi at airport X not work only for
> new devices?". For this reason, I believe you will eventually start probing
> for redirects again...
> >>
> >> You may trust the API, but you may also want to verify :)
> >>
> >>
> >> On Thu, Jul 2, 2020 at 7:24 AM Tommy Pauly  wrote:
> >>>
> >>> Hi David,
> >>>
> >>> 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 

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Steve Haskew]

David,

This is a very good observation - and one that we have had to consider in our 
implementation. The source of the captive status needs to be reliable and quick 
enough to achieve the flow described in section 6 (Example Interaction):

"Once the user satisfies the requirements for external network access, the 
client SHOULD query the API server again to verify that it is no longer 
captive.”.

For us, the API saying the user is online but the enforcement device still 
blocking them would be a major support headache, but could be caused by a 
number of different scenarios. This sentence was key in making us seek a robust 
solution to that possibility.

Thanks,

Steve


> On 3 Jul 2020, at 17:23, David Bird  wrote:
> 
> Thanks Steve, I have no doubt that some operators will implement this very 
> well! :-) 
> 
> Indeed, the login flow is the same through the Portal via API (assuming you 
> figure out the "unique device identity" question).. and I'm sure you'll have 
> the API server fully integrated with your AAA so that all sorts of logout 
> events are handled (e.g. NAS restart, idle timeout, etc).
> 
> In the long-tale of public access, I believe users will experience a wide 
> range of networks, with various levels of integration. My concern is more 
> that users learn (or even told by venue staff) to disable CAPPORT support if 
> they find it often "wrong" (e.g. there is a CAPPORT API but no NAS 
> enforcement; API says you are logged in, but NAS is dropping/redirecting; 
> etc)... 
> 
> [I personally believe we missed an opportunity to make a more robust protocol 
> by directly involving the NAS (for notification of captivity), providing a 
> single source of truth...]
> 
> On Fri, Jul 3, 2020 at 7:13 AM Steve Haskew  > wrote:
> Hi David, Tommy, all,
> 
> Just to add the the discussion, from the perspective of a network operator! 
> We are just implementing and going to be testing this very soon. We don’t see 
> any issues in terms of policy application, because the final step to log the 
> user in will be the same with either approach. Actually, this provides a 
> really nice route for us to resolve the ever-increasing issue of the ugliness 
> of forcing redirects, especially with the decreasing use of plain HTTP (and 
> therefore causing SSL warnings). We can only hope that other vendors roll 
> this out soon too! I see it as a big step forward.
> 
> However, the challenge for us that is linked revolves around identity. MAC 
> Randomisation (also coming in iOS 14)  is great for privacy, but in the short 
> term is poor for user experience on any form of guest wifi, particularly for 
> longer stays (e.g. hotel, vs cafe). We’ve actually seen a deterioration of 
> support for Hotspot2.0/Passpoint, in that installation of a profile from 
> within the Captive Network Assistant on iOS no longer works.
> 
> It feels like the dichotomy of privacy vs user experience here has no 
> practical solutions - could this be something that the wider WG has 
> previously considered, and is it within the remit of the group to look at?
> 
> Thanks,
> 
> Steve Haskew
> 
> 
>> On 3 Jul 2020, at 14:23, David Bird > > wrote:
>> 
>> Thanks Tommy,
>> 
>> Might you have screenshots of the user experience ? I'd be interested to see 
>> it
>> 
>> Agreed, adopting the new CAPPORT spec is very easy to setup (just a DHCP 
>> server config change at the access point, and an API/Portal server on the 
>> Internet). The complexity for network operators comes when fully integrating 
>> this new "application" method of captive portaling with existing "network" 
>> (NAS/redirect) methods. The complexity is in ensuring the NAS and API are 
>> enforcing the same policies, for all kinds of users (roaming, paid, free, 
>> etc) ... if the network operator doesn't do this well, or at all, then the 
>> complexity is shifted to client device support, answering questions like 
>> "Why does the WiFi at airport X not work only for new devices?". For this 
>> reason, I believe you will eventually start probing for redirects again... 
>> 
>> You may trust the API, but you may also want to verify :)  
>> 
>> 
>> On Thu, Jul 2, 2020 at 7:24 AM Tommy Pauly > > wrote:
>> Hi David,
>> 
>> 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. 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.
>> 
>> Thanks,
>> Tommy
>> 
>>> On Jul 1, 2020, at 5:27 PM, David Bird >> > wrote:
>>> 

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Peter Yee]

Steve,

 

IEEE 802.11’s Random and Changing MAC Address Study Group is 
looking at the issue of both privacy and operator impacts of MAC address 
randomization. They are in the process of creating a pair of Project 
Authorization Requests that will be used to spin up a new IEEE 802.11 task 
group to consider what modifications are needed in IEEE 802.11 to support 
operator needs while protecting user privacy. The latest version of the privacy 
PAR can be found here 
<https://mentor.ieee.org/802.11/dcn/20/11-20-0854-02-0rcm-par-proposal-for-privacy.docx>
 . The PAR that addresses operational issues can be found here 
<https://mentor.ieee.org/802.11/dcn/20/11-20-0742-01-0rcm-proposed-par-draft.docx>
 . These are not particularly detailed documents – PARs (and their accompanying 
Criteria for Standards Development) are high-level documents that are used to 
justify the need for a new task group and to specify the scope of that task 
group and the specification(s) it will produce. Once approved, the new task 
group will produce either one or more amendments to IEEE 802.11 or it may 
produce one or more Recommended Practices, the latter of which can be thought 
of as similar to Informational RFCs, while the former are like Standards Track 
RFCs.

 

-Peter Yee

 

From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of 
Steve Haskew
Sent: Friday, July 03, 2020 7:13 AM
To: David Bird; Tommy Pauly
Cc: captive-portals
Subject: Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

 

Hi David, Tommy, all,

 

Just to add the the discussion, from the perspective of a network operator! We 
are just implementing and going to be testing this very soon. We don’t see any 
issues in terms of policy application, because the final step to log the user 
in will be the same with either approach. Actually, this provides a really nice 
route for us to resolve the ever-increasing issue of the ugliness of forcing 
redirects, especially with the decreasing use of plain HTTP (and therefore 
causing SSL warnings). We can only hope that other vendors roll this out soon 
too! I see it as a big step forward.

 

However, the challenge for us that is linked revolves around identity. MAC 
Randomisation (also coming in iOS 14)  is great for privacy, but in the short 
term is poor for user experience on any form of guest wifi, particularly for 
longer stays (e.g. hotel, vs cafe). We’ve actually seen a deterioration of 
support for Hotspot2.0/Passpoint, in that installation of a profile from within 
the Captive Network Assistant on iOS no longer works.

 

It feels like the dichotomy of privacy vs user experience here has no practical 
solutions - could this be something that the wider WG has previously 
considered, and is it within the remit of the group to look at?

 

Thanks,

 

Steve Haskew

 





On 3 Jul 2020, at 14:23, David Bird  wrote:

 

Thanks Tommy,

 

Might you have screenshots of the user experience ? I'd be interested to see 
it...

 

Agreed, adopting the new CAPPORT spec is very easy to setup (just a DHCP server 
config change at the access point, and an API/Portal server on the Internet). 
The complexity for network operators comes when fully integrating this new 
"application" method of captive portaling with existing "network" 
(NAS/redirect) methods. The complexity is in ensuring the NAS and API are 
enforcing the same policies, for all kinds of users (roaming, paid, free, etc) 
... if the network operator doesn't do this well, or at all, then the 
complexity is shifted to client device support, answering questions like "Why 
does the WiFi at airport X not work only for new devices?". For this reason, I 
believe you will eventually start probing for redirects again... 

 

You may trust the API, but you may also want to verify :)  

 

 

On Thu, Jul 2, 2020 at 7:24 AM Tommy Pauly  wrote:

Hi David,

 

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

 

Thanks,

Tommy





On Jul 1, 2020, at 5:27 PM, David Bird  wrote:



That's pretty cool! 

 

This will give new opportunities in monetizing WiFi for new iOS and macOS 
devices with only a DHCP server change and an API server!

 

On Wed, Jul 1, 2020 at 4:22 PM Erik Kline  wrote:

+1

Out of curiosity, does the implementation handle the 7710bis options'
urn:ietf:params:capport:unrestricted value?

On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Steve Haskew]

Hi David, Tommy, all,

Just to add the the discussion, from the perspective of a network operator! We 
are just implementing and going to be testing this very soon. We don’t see any 
issues in terms of policy application, because the final step to log the user 
in will be the same with either approach. Actually, this provides a really nice 
route for us to resolve the ever-increasing issue of the ugliness of forcing 
redirects, especially with the decreasing use of plain HTTP (and therefore 
causing SSL warnings). We can only hope that other vendors roll this out soon 
too! I see it as a big step forward.

However, the challenge for us that is linked revolves around identity. MAC 
Randomisation (also coming in iOS 14)  is great for privacy, but in the short 
term is poor for user experience on any form of guest wifi, particularly for 
longer stays (e.g. hotel, vs cafe). We’ve actually seen a deterioration of 
support for Hotspot2.0/Passpoint, in that installation of a profile from within 
the Captive Network Assistant on iOS no longer works.

It feels like the dichotomy of privacy vs user experience here has no practical 
solutions - could this be something that the wider WG has previously 
considered, and is it within the remit of the group to look at?

Thanks,

Steve Haskew


> On 3 Jul 2020, at 14:23, David Bird  wrote:
> 
> Thanks Tommy,
> 
> Might you have screenshots of the user experience ? I'd be interested to see 
> it...
> 
> Agreed, adopting the new CAPPORT spec is very easy to setup (just a DHCP 
> server config change at the access point, and an API/Portal server on the 
> Internet). The complexity for network operators comes when fully integrating 
> this new "application" method of captive portaling with existing "network" 
> (NAS/redirect) methods. The complexity is in ensuring the NAS and API are 
> enforcing the same policies, for all kinds of users (roaming, paid, free, 
> etc) ... if the network operator doesn't do this well, or at all, then the 
> complexity is shifted to client device support, answering questions like "Why 
> does the WiFi at airport X not work only for new devices?". For this reason, 
> I believe you will eventually start probing for redirects again... 
> 
> You may trust the API, but you may also want to verify :)  
> 
> 
> On Thu, Jul 2, 2020 at 7:24 AM Tommy Pauly  > wrote:
> Hi David,
> 
> 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. 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.
> 
> Thanks,
> Tommy
> 
>> On Jul 1, 2020, at 5:27 PM, David Bird > > wrote:
>> 
>> 
>> That's pretty cool! 
>> 
>> This will give new opportunities in monetizing WiFi for new iOS and macOS 
>> devices with only a DHCP server change and an API server!
>> 
>> On Wed, Jul 1, 2020 at 4:22 PM Erik Kline > > wrote:
>> +1
>> 
>> Out of curiosity, does the implementation handle the 7710bis options'
>> urn:ietf:params:capport:unrestricted value?
>> 
>> On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson > > wrote:
>> >
>> > Tommy, this is great!  Thanks for all your work here, it's good to see 
>> > this turn into something concrete.
>> >
>> > On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote:
>> > > Hello CAPPORT,
>> > >
>> > > I wanted to highlight an announcement we’ve made for the betas of iOS
>> > > and macOS released today:
>> > >
>> > > How to modernize your captive network
>> > > > > > >
>> > >
>> > > The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis
>> > > and draft-ietf-capport-api by default. This doesn’t change the user
>> > > experience of logging onto captive networks, but the system will
>> > > request the DHCP options and handle the RA option, and will prefer
>> > > using the Captive Portal API Server interaction over having a probe
>> > > that is intercepted.
>> > >
>> > > If you have a portal system that is already implementing the CAPPORT
>> > > features, please test out these betas and let us know if you see any
>> > > issues! And if you have a captive portal solution, we’d encourage you
>> > > to start supporting this soon.
>> > >
>> > > Best,
>> > > Tommy
>> > > ___
>> > > Captive-portals mailing list
>> > > Captive-portals@ietf.org 
>> > > https://www.ietf.org/mailman/listinfo/captive-portals 
>> > > 

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Tommy Pauly]

> On Jul 2, 2020, at 11:55 AM, Michael Richardson  wrote:
> 
> 
> Not really a CAPPORT protocol problem... but...
> 
> Tommy Pauly  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?

One of the goals of having the portal URL be transmitted in the API is to aid 
ways of getting back to that URL. We don’t have any such way in the beta UI, 
but such an experience is possibility in the future if networks adopt the API.

Thanks,
Tommy

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

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Michael Richardson]

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

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





signature.asc
Description: PGP signature
___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Tommy Pauly]

> On Jul 1, 2020, at 4:22 PM, Erik Kline  wrote:
> 
> +1
> 
> Out of curiosity, does the implementation handle the 7710bis options'
> urn:ietf:params:capport:unrestricted value?

That doesn’t yet stop us from sending out the probe, no. That can be something 
added later, based on how networks adopt it.

Thanks,
Tommy

> 
>> On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson  wrote:
>> 
>> Tommy, this is great!  Thanks for all your work here, it's good to see this 
>> turn into something concrete.
>> 
>>> On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote:
>>> Hello CAPPORT,
>>> 
>>> I wanted to highlight an announcement we’ve made for the betas of iOS
>>> and macOS released today:
>>> 
>>> How to modernize your captive network
>>> 
>>> 
>>> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis
>>> and draft-ietf-capport-api by default. This doesn’t change the user
>>> experience of logging onto captive networks, but the system will
>>> request the DHCP options and handle the RA option, and will prefer
>>> using the Captive Portal API Server interaction over having a probe
>>> that is intercepted.
>>> 
>>> If you have a portal system that is already implementing the CAPPORT
>>> features, please test out these betas and let us know if you see any
>>> issues! And if you have a captive portal solution, we’d encourage you
>>> to start supporting this soon.
>>> 
>>> Best,
>>> Tommy
>>> ___
>>> Captive-portals mailing list
>>> Captive-portals@ietf.org
>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>> 
>> 
>> ___
>> Captive-portals mailing list
>> Captive-portals@ietf.org
>> https://www.ietf.org/mailman/listinfo/captive-portals
> 
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[Martin Thomson]

Tommy, this is great!  Thanks for all your work here, it's good to see this 
turn into something concrete.

On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote:
> Hello CAPPORT,
> 
> I wanted to highlight an announcement we’ve made for the betas of iOS 
> and macOS released today:
> 
> How to modernize your captive network 
> 
> 
> The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis 
> and draft-ietf-capport-api by default. This doesn’t change the user 
> experience of logging onto captive networks, but the system will 
> request the DHCP options and handle the RA option, and will prefer 
> using the Captive Portal API Server interaction over having a probe 
> that is intercepted.
> 
> If you have a portal system that is already implementing the CAPPORT 
> features, please test out these betas and let us know if you see any 
> issues! And if you have a captive portal solution, we’d encourage you 
> to start supporting this soon.
> 
> Best,
> Tommy
> ___
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>

___
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals