[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] CAPPORT meeting at IETF95 in Buenos Aires.



On Wed, Feb 17, 2016 at 4:51 AM, Yoav Nir <[email protected]> wrote:

> On 17 Feb 2016, at 1:53 AM, Mark Nottingham <[email protected]> wrote:
>
>
>> On 17 Feb 2016, at 3:59 AM, David Illsley <[email protected]> wrote:
>>
>> I'm interested in the Sandboxing point in section 4. I understand these to be designed as a pro-user security feature. In general I don't trust random network devices in hotels so I'll use a VPN. That leaves me open to malware attacks from the captive portal [1]. Deciding to put captive portals into a more-restrictive-than-usual sandbox then seems reasonable to me.
>>
>> Can you explain the problems caused by sandboxing (I don't think I've ever experienced them)?
>
> AIUI, some captive portals want access to the users' normal cookies; e.g., to log into Facebook to authenticate the user (yeah, I know...). Also, I understand that some captive portal sandboxes don't allow some browser features like video playback, and some captive portals feel that they need this functionality.

Video playback in the captive portal. Oh dear. Next they'll be saying they need WebRTC.
 

Not to mention the cool feature regular browsers have of remembering your passwords and helpfully filling them out in forms for you so you don’t have to type them out on your itsy bitsy phone keyboard.

 Yeah. That's one I've been bitten by, and I think that capability should be added to the sandboxed browsers.