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

[Vincent van Dam <VvanDam@sandvine.com>]

On the larger subject, as a browser person, the real reason for

sandboxing is - I believe - privacy.  One basic security assumption

for the web is that it is easy to cause a user to visit a site.  A

captive portal isn't special in that regard, so I don't credit claims

that sandboxing is a security measure.

Yes, that (all the privacy and security  risks) is true with public access, generally. (Why are captive portal networks extra suspicious?) Browsers themselves might behave differently on a 'capport compliant' device in that they would rely on the os detection. But, the browser could (and can today) simply ask the user 'want to connect to this captive portal?' .. let the user decide. It is pretty safe if https and a URL the user is comfortable with.

I agree with asking the user. Both capport and UE are making a decision to either display or not display in a sandboxed browser. They take this decision on behalf of the user and I think this evolved like this. Doing one step back, imo it makes more sense to (once the icmp is received) display a dialog and ask how the user wants to continue to the capport (if UE permits). UE can optimise this user flow by either choosing a default behaviour they see fit and have the user configure this behaviour somewhere, or just remember what the user had chosen. If the UE would send an extra http-header indicating the capport is visited in the sandboxed browser, the capport can inform the user if they think it would be better to fulfil the journey in a regular browser (and explain how to do that). Either way, the user will be in control, rather than either capport or UE.

Gr.,

Vincent van Dam