Re: [Captive-portals] Arguments against (any) Capport "API"

[Erik Kline <ek@google.com>]

I think we can't get away from nodes doing both new style (7710 + yet-to-be-published stuff) and legacy detection.  In an increasingly HTTPS-ified world I would expect we'll end up with devices doing something like:

    [1]

    if (7710 available) {

        do 7710 + yet-to-be-published interaction;

        if (successful HTTPS Internet query) return;

    }

    [2]    # possibly in parallel with [1]

    do sacrificial cleartext HTTP request

    if (rewriting detected) {

        do legacy interaction;

        if (success HTTPS Internet query) return;

    }

    [3]

    last ditch effort here

I think it's what the majority of client OS vendors do with (first) [3] and (then) [2] that will determine, in a sort of game theoretic sense, how successful [1] will be.

If a majority of client OSes implement [3] as "never make this network the default, but some apps can use it via a multiple Provisioning Domain API (to support connecting to printer hotspots, and the like), or new TAPS API, while leaving (if available) mobile up", then captive portal vendors will at least be incentivized to stop faking out the queries that constitute [2].

If there proves to be some industry support for [1], and ongoing measurements show some meaningful adoption trends, then OS vendors can look at taking action with respect to networks that still only support [2].  This could include things like de-prioritization in ESSID auto-join algorithms.

We'll obviously need to provide value to as many reasonable parties as possible through whatever [1] ultimately becomes but that value can grow over time as functionality is added to address an increasing number of use cases.  This is definitely going to take some time.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature