On 8 Mar 2016, at 8:11 PM, Martin Thomson <[email protected]> wrote:
> On 8 March 2016 at 18:45, Mark Nottingham <[email protected]> wrote:
>> I've seen CPs that ask for Facebook username and password, but NOT over HTTPS, and not to a Facebook domain (IIRC); it's more of a user education / security UX problem than anything.
> That's perhaps an extreme - and horrific - example of what I thought
> you intended here.
> Loading a real browser allows a CP to close the loop with tracking
> bugs. That is less offensive, though to what degree might depend on
> where you sit.
> There are probably plenty of potentially relevant reasons too. For
> example, a network operator might simply want to authorize one set of
> users (their paying customers) over others. A sandbox in that context
> represents a hurdle for their users, who can't rely on cookies or
> other preexisting state. The sandbox then has security drawbacks in
> that it encourages users to pick less secure passwords.
One aspect that's potentially different is that current CP detection implementations (going to add a term for that :) can be automatically triggered; if the OS recognises a SSID ("ATTWifi", anyone?), it'll pop up a window.
Without sandboxing, that means the network gets tracking data without any user intent in a very common case. An attacker can also spoof a common SSID to gather such data.
Of course, OSs could stop automatically joining Wifi networks, but that would make for a lot of unhappy users...
Mark Nottingham https://www.mnot.net/
Captive-portals mailing list