Re: [Captive-portals] WGLC on draft-ietf-capport-rfc7710bis-01

I have two minor comments of my own to add:

The prioritization section (S3) suggests that conflicting sources of URIs be prioritized.  However, this specifically avoids stating any preferred order.  Rather than saying we don't specify it, how about explicitly letting implementations decide?

OLD:
   URI precedence in this situation is not
   specified by this document.
OLD:
   Implementations can select their own precedence order.

The security considerations (S5) includes this text:

   Operating systems should conduct all interactions with the API in a
   sand-boxed environment and with a configuration that minimizes
   tracking risks.

I would suggest that this is a bad idea.  I personally would recommend against it.  It might have been wise in the past when HTTPS rates were lower, but 2020 is not 2014.  Captive portals occasionally do things like access SSO services (Facebook being one) and a sandbox often doesn't have access to the same persistent storage as a genuine browser.  Asking people to enter passwords in a sandbox can have the effect of building insensitivity to phishing attempts; especially when that sandbox could have limited anti-phishing capabilities compared to a full-fat browser.

I realize that this is in tension with the desire to minimize tracking of people across points of physical connectivity.  I think that the best we can do is recognize that tension and let people reach their own conclusions.

On Mon, Mar 2, 2020, at 09:49, Martin Thomson wrote:
> Hi everyone,
> 
> The editors of draft-ietf-capport-rfc7710bis-01 believe it to be ready 
> for publication.
> 
> Please send comments on this before 2020-03-16.
> 
> Comments supporting publication as-is are valued as much as comments 
> highlighting issues.
> 
> Note that Erik is an editor of this document, so he won't be assessing 
> consensus.
> 
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>