Don't use default browser profile for captive portals

Tracked by Jolla (In progress)

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

schmittlauch
4334 ●60 ●75 ●71

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.

Comments

@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:

https://together.jolla.com/question/145060/20251-browser-opens-coninuosly-new-tabs/

Thx,

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

Captive portal detection seems to be fairly recent in Firefox; the tracker is still open:
https://wiki.mozilla.org/QA/Captive_Portals
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

answered 2019-05-27 18:43:08 +0200

DaveRo

3404 ●63 ●102 ●108

updated 2019-05-28 12:27:34 +0200

Not really an answer. but I see that captive portal detection was implemented in Firefox 42 (desktop): https://bugzilla.mozilla.org/show_bug.cgi?id=1048131

Gecko has been updated from 38 to 45 in SFOS 3.0.3 I see that network.captive-portal-service.enabled is set to false (in about:config)

I can set it to true, but I don't have a hotspot handy to try it. Anybody?

Added:

I tried connecting to BT Openzone, a public but non-free wifi hotspot scheme here in the UK. The Jolla browser automatically diverted me to the https subscribe page. So it appears to work in some circumstances. Can other people try it?

What I did: In the browser I entered about:config, OKed the warning, searched for 'captive', and toggled network.captive-portal-service.enabled to 'on'.

(I had also, previously, changed the homepage (in settings, apps, browser) to http://example.com but I don't think that's relevant or necessary.)

You'll see in the prefs that it's using Mozilla's 'success' text file server. Jolla could provide their own if necessary - or you could use your own webserver.

edit flag offensive delete publish link

Comments

I toggled 'network.captive-portal-service.enabled' to 'on'. Doesn't change anything when connecting to the free Wifi of my local railway server. But after changing the homepage to example.com when opening the browser suddenly the Login page was loaded. But please tell me, whats the point with 'www.example.com'? Is it safer or unsafer?

dirksche ( 2019-05-28 15:43:04 +0200 )edit

It's just a random http (not https) site. I did it originally as an experiment to see whether not having a secure page helped.

Are you saying that captive portal detection doesn't work if you still have https://jolla.com as a homepage?

DaveRo ( 2019-05-28 16:10:07 +0200 )edit

I used to have an empty page. No homepage set. And with this settings captive portal detection did not work.

dirksche ( 2019-05-28 16:20:54 +0200 )edit

If there's no homepage, and no previous tab to show, then presumably the browser won't make an http request and it won't redirect.

I don't know enough about how captive portal detection (CPD) might work (if it does work) in the Sailfish Browser. The spec (link in https://wiki.mozilla.org/QA/Captive_Portals) describes how it works in Firefox but some of that will not apply to gecko with a different UI.

It could be that what I saw is entirely due to having an http homepage and that getting redirected.

From the spec, CPD should operate when the browser is initially loaded or the network state changes (e.g. go online).

DaveRo ( 2019-05-28 17:15:55 +0200 )edit

You might be right. I will try tomorrow with an homepage like startpage.com

dirksche ( 2019-05-28 18:18:41 +0200 )edit

Don't use default browser profile for captive portals

Comments

1 Answer

Comments

Question tools

Stats

Related questions

Don't use default browser profile for captive portals

Comments

1 Answer

Comments

Question tools

Public thread

Stats

Related questions