Don't use default browser profile for captive portals

Tracked by Jolla

asked 2017-04-06 23:29:36 +0200

schmittlauch gravatar image

updated 2018-01-15 16:32:05 +0200

Currently the captive portal detection of SFOS opens a detected portal in a new tab of the standard browser. This is a bad idea as that may give the portal access to various browser data like cookies and my be used for tracking. Some captive portals have multiple tracking ad networks integrated.

Sophos Security describes an issue which has been fixed in iOS in 2013. It may be wise evaluating whether SFOS is affected by something similar.

Androids captive portal detection opens the portal in a very restricted locked-down browser environment without access to systems cookies and other profile data. Other functions are restricted as well.
This is also not only a privacy issue, as an attacker could set up a WLAN network with a common SSID and try to exploit browser vulnerabilities/ mine bitcoin/ steal login data from password store … in the then automatically loaded captive portal page.

A short term goal for SFOS should be to always use a fresh & separate browser profile for captive portals. Further restrictions may also be worth to be evaluated.

edit retag flag offensive close delete



@rainemak Maybe this issue is for you?

schmittlauch ( 2017-04-06 23:30:52 +0200 )edit

If anyone at Jolla looks into this issue and a special treatment for such captive portals is developed, please also have a look at this thread that got a bit dusty:


ossi1967 ( 2017-04-07 13:06:17 +0200 )edit

Captive portal detection seems to be fairly recent in Firefox; the tracker is still open:
Presumably the SFOS browser will pick this up in future versions of Gecko?

DaveRo ( 2017-04-08 00:56:42 +0200 )edit

Speaking of captive portals, do they work reliably for you? I tried to connect to two this week-end (a McDonalds and an airport), and they never loaded in the default browser. I opened Webcat and they loaded immediately.

Sthocs ( 2017-04-11 12:22:43 +0200 )edit