I could probably explain myself another way, but first I will say that "make before break" obviously makes a ton of technical sense, hence why most vendors do it. And, I'm speaking generally, I'm sure different vendors are doing slightly different things. But, I think the 'arms race' is proof that it has some consequences that either operators find annoying, or reports we are hearing are just 'fake news' :)
Another way to view it... Consider the ideal user experience: User: Wanting Wi-Fi, and already knows about years of reports about how un-safe public WiFi is. UE: Hey, btw, there is public access WiFi available User: Click, yay! (Just like the IETF network!) [Everything works] WISP: Wow, that is a ton of valuable data, but we lack control Now consider the ideal user experience from the WISP perspective: User: Wanting Wi-Fi, and already knows about years of reports about how un-safe public WiFi is. UE: Hey, btw, there is public access WiFi available User: Click, yay! (Just like the IETF network!, oh, wait, there is a portal) [Some apps fail (though UE could then pin to LTE), others may work in walled garden (if the UE allows them)] WISP: Nice... still getting a ton of valuable data, and we have some user contact, consent, branding, and service selling opportunists! User: A bit annoyed (but not enough to complain harshly to the venue) by the up-selling (and contemplates where the world has gone to when WiFi isn't free), but is enjoying some of the walled garden resources offered by the WISP for free. User: Wow, that portal was super easy to use because I was already logged into my social network (or maybe IETF website :) anyway What actually happens today (made extra dramatic for effect :) User: Wanting Wi-Fi, and already knows about years of reports about how un-safe public WiFi is. UE: Hey, btw, there is public access WiFi available User: Click, yay! (Just like the IETF network!, oh, wait, there is a portal) WISP: Dang, we aren't getting the data (or analytics on traffic) we once got (or still get with no portal / garden) WISP: Dang, the user isn't able to access our free walled garden resources because the UE thinks they can't WISP: Knows their portal is broken in some UEs (the marketing firm web developers don't really understand limitations of walled gardens), gives instructions on best way to invoke portal "reliably" User: This portal is completely un-usable with UE, laptop is ok. I get they are being cute with a social login, but it isn't working that well. I don't remember any of my passwords. User: They told me I could access information and certain Apps for free, but I don't see how. This is pointless. User: Complains to venue Venue: Complains to WISP who adds capport detection URLs to the walled garden The arms race is a WISP trying to fix this user / UE / venue "public access" expectation gap, by tweaking things to get the desired result (for good intentions, or perhaps questionable). This can be viewed as the UE as having different 'policies' for captive portal public access networks vs. public access networks without portals. One policy includes assuming all network connections will work (because the UE did a DNS check plus some additional, rather statistically insignificant URL tests), and puts the default route on the network without further ado. The other, captive portal, policy (assigned even though the network demonstrates general Internet connectivity via DNS tests, and maybe some of the test URLs, the UE still wasn't convinced), disallows any network use until the user performs actions in a broken browser of the UEs choosing (and doing). I think there are some user options to be had in there somewhere... On Fri, Apr 7, 2017 at 12:01 PM, David Bird <db...@google.com> wrote: > I am not claiming to have all the answers, or that this is an easy (or a > single) problem to solve. And I reserve the right to be completely wrong :) > > Absolutely, as a mobile subscriber with unlimited data who (more or less) > trusts my mobile provider, it is also my preference that devices behave as > they do today (except when I do interact with 'legitimate' portals, they > are often broken or extra annoying because of the browser selection, I > sometimes turn off WiFi). I think there are other use-cases and other users > have different priorities, trust in network providers, and data plans. > > What I think you are illustrating is that it is technically VERY > challenging to implement "make before break" for an entire network for all > connections in environments that only provide limited access to a limited > number of connections (and that it is particularly hard to do this in > 'hostile' public access networks where there are commercial incentives for > trickery). There are very different cost, benefit, and trust considerations > for users. Hopefully, new protocols like QUIC and Capport can make that > hand-off smoother, robust, and secure while also allowing users access to > resources in public access environments (with or without captive portal and > walled garden). > > When I talk about 'public access', I include all Open SSIDs with and > without portal, and even some wired environments. As a venue/provider, > those are my option when offering public access: a) Wide Open SSID, no > portal, few customer complains (and those all get directed to vendors, UE , > AP, or ISP), maybe legal issues, probably have squatters hogging bandwidth, > b) Open SSID with captive portal, more complaints (which is an ongoing > issue that can't as easily dumped onto vendors), but also making money and > have branding and analytics to offset the costs of providing public access, > fewer problems with squatters, c) do a combination of things, including > wired. I talk about 'public access industry' in terms of NASDAQ and private > companies that represent an ecosystem where commercial marketing often > centers on making it *Easy* and *Secure* to get public access around the > world... > > When I talk about the difference in behavior UEs have for 'public access' > and 'captive portal', I think some pockets of engineers, who have > responsibility for the security of their specific users, understand this > difference in that you want to protect the user just as much on Open WiFi > networks irrespective of the existence of a captive portal (i.e. any public > access). I think some UE engineers also feel uncomfortable about supporting > Open WiFi at all (and therefore give users warnings), but users demand it > -- why? because of public access and ease-of-use. Today most people > consider an Open SSID to indicate 'public access'. That SSID may or may not > have a portal, full or partial Internet access, or all sorts of > man-in-the-middle "applications". Figuring out what trickery is happening > in public access networks will always be a moving target... > > What I believe is that public access network providers who use captive > portal feel completely *justified* in doing anything they could otherwise > do when users connect to an Open SSID (without captive portal) public > access networks. After all, the user trusts the UE, and the UE trusts the > user intent to join the Open SSID public access network after it warned the > user about the risks. If UE vendors want to change that behavior, I think > it is as easy as enforcing the same policy for Open SSID w/o portal as with > portal (i.e. a common policy for all public access). There would no longer > be incentive to trick UE captive portal detection, because the public > access network is being treated the same by the UE regardless. However, > this will shift user complaints about public access non-usability, even for > Open SSID networks with no portal, to the vendors instead of the network > operator. There is a delicate balance there between what users want, what > they *should* want, what they are willing to give up, and what services > networks are trying to provide. Venues get all those usability complaints > today, and the solutions they come up with are not often elegant. > > As I said, not an easy, or single, problem... And one we can't completely > solve (or even try to) in this WG. However, there are things we can do to > improve capport nonetheless. > > > On Fri, Apr 7, 2017 at 9:11 AM, Erik Kline <e...@google.com> wrote: > >> I fundamentally do not understand what it is you're trying to say here. >> I apologize for being thick. >> >> The mobile devices with which I am most familiar do "make before break" >> even for unsecured SSIDs without a captive portal. They do a few probes of >> various types and to various destinations (vis. Mariko's research and >> presentation) on /every/ network before deciding whether to switch general >> traffic over to it. >> >> (Note that a few apps that style themselves as networking sophisticates >> may try to fling a few packets on a newly attached network before the OS >> has done its validation, but those are the very rare exception. And we see >> the occasional bug report when they get themselves confused because they >> haven't waited for the system's detection to do its thing or haven't >> trusted the detection result. =) >> >> I don't understand how these mobile devices should be doing something >> different. Failing to do what they currently do and going back to "break >> before make" will not sit well with users. I personally do not see a >> solution down that road, but perhaps I misunderstand or others see >> something I don't yet. >> >> On 8 April 2017 at 00:03, David Bird <db...@google.com> wrote: >> >>> A root cause of the so-called 'arms race' around captive portal >>> detection that I'm trying to highlight is that it will always continue for >>> as long as UEs treat captive portal networks specifically different than >>> they do public access networks generally, you will have incentive to >>> exploit that difference in behavior in the public access industry. >>> >>> On Fri, Apr 7, 2017 at 6:52 AM, David Bird <db...@google.com> wrote: >>> >>>> On Fri, Apr 7, 2017 at 6:36 AM, Erik Kline <e...@google.com> wrote: >>>> >>>>> 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. >>>>> >>>>> >>>> But, it DOES happen when you connect to Open SSID without captive >>>> portal (or when the venue evaded your detection). Maybe the captive portal >>>> networks wants to offer these services in their walled garden... and it is >>>> likely the user would be happy about that (provided they selected the >>>> network on purpose). >>>> >>>> If you had ICMP giving you real-time feedback, you could more >>>> accurately (and quickly) detect what connections will work and which will >>>> not on the network. QUIC will help in maintaining session continuity as >>>> connections are pinned to different interfaces. >>>> >>>> >>>> >>>>> 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. >>>>> >>>> >>>> Cookie isolation on secure websites doesn't really help the user any... >>>> >>>> >>> >> >
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
