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.
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
