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

Erik Kline <ek@google.com> Fri, 07 April 2017 13:36 UTC

Return-Path: <ek@google.com>
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 CBAA0126DED for <captive-portals@ietfa.amsl.com>; Fri, 7 Apr 2017 06:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 DGfqDF56SMvU for <captive-portals@ietfa.amsl.com>; Fri, 7 Apr 2017 06:36:40 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 078A1126C3D for <captive-portals@ietf.org>; Fri, 7 Apr 2017 06:36:37 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id v76so34526397ywg.0 for <captive-portals@ietf.org>; Fri, 07 Apr 2017 06:36:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SvQ8XiJxGgIsS5ZNg2HnHYHhKEdbnQGuw+PQuaCqLLI=; b=VFnjjLPKPGNm+2Pirw1r/27U9zLl4E/5lcfm0wP8lUjiedSXG7u3y9ZqjnRkSAj9g2 mqxf/77Mz3iMcMB6KbSiOBQ3lD1PolDL4QyOguc9W6olMOBxnnkJVfaLMKmJEVI0J0s4 0Cf4UOCJecmoSy8kB3oJklqPRvtZZLobrCy1KBSuunbnMfHbUPFuLo7r+sAD2SzORRzr mynWT+f/UHpKRaV0Fhxs8NjJJTr/XT7/SWiE6odJebGydOpooeIefSbbHW6zct+vQmqo b9OlmrkmEi4slqrORlxrg3zkiCPWeio5geg/zNS1fDVj+yVOfpqXs0hdI1K758oVy+EO HznA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SvQ8XiJxGgIsS5ZNg2HnHYHhKEdbnQGuw+PQuaCqLLI=; b=B72qEhJnXIXZFq1skCelZM8r1MOQz7QMwQwzw6KXoJpeiL5tYnGXYzx2JVH3u0dgBa Jxk7f0teXXlePA2pD7+rZeU+UB4U2jd0bk/Dts6MJ/obxxXP0tktA9Qmf5NOUTvjPSj3 d2IhipT0UOpYybX14pHNe6O2oXoEus5pdz9LwC3B4z39oR7T7XatbGvzKi2WbWIMTcFd mtj9joXUCIgBH38qvCAIaZlJ3KYJpQH1D4lSIL9oow6KVJiNs+Swm4JUZAETpFKZ2vxk h5Y12J1xDhaXO9fsvY378TISnccYqW1rOkJWhcvx3rLf17vWrCGea00nB2epSZpyC6g5 8hUQ==
X-Gm-Message-State: AFeK/H1u4XZJBO7ktp4tUjWx/2LMJqTSa/vzcklktKHyNqVYm1y+C8Sa3/sJhvK40ehyvSMO8w1yao4Sofy1DO3h
X-Received: by 10.129.62.25 with SMTP id l25mr26594573ywa.0.1491572195892; Fri, 07 Apr 2017 06:36:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.220.12 with HTTP; Fri, 7 Apr 2017 06:36:15 -0700 (PDT)
In-Reply-To: <CADo9JyVfmhir8YtOR2mzzaaPL_9mBKgFmht6-SA50SfPmh9z6w@mail.gmail.com>
References: <CADo9JyU2wiEBB4L7ADSybt9se7jCN764JSEoHuGTcuiU_jDscQ@mail.gmail.com> <CAAedzxqR5bWTP_gou+hC5cgQ99tV275nX_ijm7iUok4-h+3wMQ@mail.gmail.com> <CADo9JyVfmhir8YtOR2mzzaaPL_9mBKgFmht6-SA50SfPmh9z6w@mail.gmail.com>
From: Erik Kline <ek@google.com>
Date: Fri, 07 Apr 2017 22:36:15 +0900
Message-ID: <CAAedzxrck9+TBpEp-x8_tG-oxxKh4MQ4-x+iuGNGd6JsG=poQQ@mail.gmail.com>
To: David Bird <dbird@google.com>
Cc: captive-portals@ietf.org
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="f403045f30eeedbe9e054c93b6b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/HZ6ji60SBG4x4fVNbMV6KsDfurw>
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
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, 07 Apr 2017 13:36:42 -0000

>
> I think the client should, ideally do:
>
> -  Use the network for all connections (why ask permission when
> forgiveness is cheap).
>

Not gonna happen.  Mobile clients do a ton of work to enable "make before
break".  There is no such thing as forgiveness from users who can't get
Facebook updates, Twitter notifications, nor email while their device is
held hostage because it switched to Wi-Fi and tore down mobile before
checking for a captive portal.

This may also address your question elsewhere about browsers and
"sandboxing".  I suspect the sandboxing to which you're referring is about
cookie isolation (primarily), but there's a kind of "network sanboxing"
that is applied as well to ensure the browser uses a self-consistent
networking configuration.