🆕 Disable Firefox network captive portal #735

New Issue

2019-01-23T14:43:18Z

TNTBOMBOM commented

2019-01-23 14:43:18 +00:00

(Migrated from github.com)

Add here enhancement to FF privacy by disabling network captive protal:

Why?Read here:

https://forums.whonix.org/t/universal-firefox-attack-through-http-manipulation-and-wont-fix/6726

Add [here](https://www.privacytools.io/#about_config) enhancement to FF privacy by disabling network captive protal: Why?Read here: https://forums.whonix.org/t/universal-firefox-attack-through-http-manipulation-and-wont-fix/6726

👍 1

Atavic commented

2019-01-23 18:39:51 +00:00

(Migrated from github.com)

Same principles apply to network.connectivity-service prefs in FF 65, see:
https://github.com/intika/Librefox/issues/102

Same principles apply to *network.connectivity-service* prefs in FF 65, see: https://github.com/intika/Librefox/issues/102

beerisgood commented

2019-01-23 20:21:02 +00:00

(Migrated from github.com)

@Atavic or as you write here: https://github.com/ghacksuserjs/ghacks-user.js/issues/610#issuecomment-451689075

👍 1

blacklight447 commented

2019-08-28 12:38:32 +00:00

(Migrated from github.com)

@thorin-oakenpants what are your thoughts on this one?

Thorin-Oakenpants commented

2019-08-28 13:31:33 +00:00

(Migrated from github.com)

Here's some info. My understanding from memory is that it would block users from using some wifi: e.g hotels, public wifi, etc. Forget the tor ticket: that's just their threat model: sending success data to Mozilla is not an issue TBH.

Honestly, I'm not sure if this "leaks" anything without user interaction: e.g. do you need to go to the landing page for anything to happen, or if FF "detects" them auto-magically? It's certainly something I would not put on the website, but leave for a user.js.

ghacks-user.js

/* 0390: disable Captive Portal detection
 * [1] https://en.wikipedia.org/wiki/Captive_portal
 * [2] https://wiki.mozilla.org/Necko/CaptivePortal
 * [3] https://trac.torproject.org/projects/tor/ticket/21790 ***/
user_pref("captivedetect.canonicalURL", "");
user_pref("network.captive-portal-service.enabled", false); // [FF52+]

Here's some info. My understanding from memory is that it would block users from using some wifi: e.g hotels, public wifi, etc. Forget the tor ticket: that's just their threat model: sending success data to Mozilla is not an issue TBH. Honestly, I'm not sure if this "leaks" anything without user interaction: e.g. do you need to go to the landing page for anything to happen, or if FF "detects" them auto-magically? It's certainly something I **would not** put on the website, but leave for a user.js. ghacks-user.js ```js /* 0390: disable Captive Portal detection * [1] https://en.wikipedia.org/wiki/Captive_portal * [2] https://wiki.mozilla.org/Necko/CaptivePortal * [3] https://trac.torproject.org/projects/tor/ticket/21790 ***/ user_pref("captivedetect.canonicalURL", ""); user_pref("network.captive-portal-service.enabled", false); // [FF52+] ```

👍 2

blacklight447 commented

2019-08-28 15:59:22 +00:00

(Migrated from github.com)

I see, the privacy impact is not fully understood, and can have some quite frustrating effects when people disable it without knowing what it is. i vote to not include it and close the issue.

👍 2

Mikaela commented

2019-08-28 16:06:40 +00:00

(Migrated from github.com)

Agreed

TNTBOMBOM commented

2019-08-28 16:07:02 +00:00

(Migrated from github.com)

Honestly, I'm not sure if this "leaks" anything without user interaction

The problem is its over HTTP without TLS encryption thus manipulating connection is possible from ISP or attack over wifi...etc

So opening the user to be attacked through his browser is recommended against to be considered privacy saving.

> Honestly, I'm not sure if this "leaks" anything without user interaction The problem is its over HTTP without TLS encryption thus manipulating connection is possible from ISP or attack over wifi...etc So opening the user to be attacked through his browser is recommended against to be considered privacy saving.

Mikaela commented

2019-08-28 16:14:13 +00:00

(Migrated from github.com)

The problem is its over HTTP without TLS encryption thus manipulating connection is possible from ISP or attack over wifi...etc

Isn't that the whole point of captive portal checking as that is exactly what the captive portal will do?

If we do this, I think we should start recommending Captive Browser or something similar, but I still don't see much point.-

> The problem is its over HTTP without TLS encryption thus manipulating connection is possible from ISP or attack over wifi...etc Isn't that the whole point of captive portal checking as that is exactly what the captive portal will do? If we do this, I think we should start recommending Captive Browser or something similar, but I still don't see much point.-

Thorin-Oakenpants commented

2019-08-28 16:21:20 +00:00

(Migrated from github.com)

blacklight447-ptio said

I see, the privacy impact is not fully understood...

Yeah, sorry.. I can't keep up with everything, and some areas are not my forte :)

TNTBOMBOM said

The problem is its over HTTP without TLS encryption....

That's not a browser problem, that's a protocol problem.

--

Yeah, look: it's not a privacy issue AFAIC, it's a security one. Here's someone reliable: https://www.eff.org/deeplinks/2017/08/how-captive-portals-interfere-wireless-security-and-privacy (PS: I haven't even read it yet: but will do, tomorrow if sober)

blacklight447-ptio said > I see, the privacy impact is not fully understood... Yeah, sorry.. I can't keep up with everything, and some areas are not my forte :) TNTBOMBOM said > The problem is its over HTTP without TLS encryption.... That's not a browser problem, that's a protocol problem. -- Yeah, look: it's not a privacy issue AFAIC, it's a security one. Here's someone reliable: https://www.eff.org/deeplinks/2017/08/how-captive-portals-interfere-wireless-security-and-privacy (PS: I haven't even read it yet: but will do, tomorrow if sober)

👍 1

Mikaela commented

2019-08-28 16:45:51 +00:00

(Migrated from github.com)

And with that link, we find ourselves at https://openwireless.org/ and maybe https://github.com/privacytoolsIO/privacytools.io/issues/1184.

👍 1 😆 1

TNTBOMBOM commented

2019-08-28 17:00:55 +00:00

(Migrated from github.com)

Isn't that the whole point of captive portal checking as that is exactly what the captive portal will do?

Usability vs Privacy, When recommending to be disabled is to reduce the attack possibility behind it.

Users of TBB always having it disabled, no one crying to see it enabled.

> Isn't that the whole point of captive portal checking as that is exactly what the captive portal will do? Usability vs Privacy, When recommending to be disabled is to reduce the attack possibility behind it. Users of TBB always having it disabled, no one crying to see it enabled.

Thorin-Oakenpants commented

2019-08-28 17:18:47 +00:00

(Migrated from github.com)

@TNTBOMBOM

Firefox is not Tor Browser (TB: they dropped the word Bundle ages ago). TB users probably have a different threat model (certainly the design principles are a lot different to Mozilla's: FF needs to work out of the box but TB can afford to sacrifice some things if they have to). And FF users are free to go get TB and use it. FF is not TB, and vice versa.

no one crying to see it enabled

Maybe someone did cry about it. Anyway, TB's user base is fairly small, and TB users deal with and expect breakage - it's inevitable. I actually wouldn't imagine many TB users would use this feature anyway. We can trade anecdotal evidence and BS all day long, if you want.

Usability vs ~~Privacy~~ Security

Here's how I see it. If you don't go connecting to captive portals, then you're fine. If you do, then you probably wanted to in the first place, so why break things for end users who do want it.

@TNTBOMBOM Firefox is not Tor Browser (TB: they dropped the word `Bundle` ages ago). TB users probably have a different threat model (certainly the design principles are a lot different to Mozilla's: FF needs to work out of the box but TB can afford to sacrifice some things if they have to). And FF users are free to go get TB and use it. FF is not TB, and vice versa. > no one crying to see it enabled Maybe someone did cry about it. Anyway, TB's user base is fairly small, and TB users deal with and expect breakage - it's inevitable. I actually wouldn't imagine many TB users would use this feature anyway. We can trade anecdotal evidence and BS all day long, if you want. > Usability vs ~~Privacy~~ Security Here's how I see it. If you don't go connecting to captive portals, then you're fine. If you do, then you probably wanted to in the first place, so why break things for end users who do want it.

Thorin-Oakenpants commented

2019-08-28 17:21:05 +00:00

(Migrated from github.com)

PS: thanks @Mikaela and @blacklight447-ptio : I updated the ghacks-user.js here

PS: thanks @Mikaela and @blacklight447-ptio : I updated the ghacks-user.js [here](https://github.com/ghacksuserjs/ghacks-user.js/commit/a0f3da208fc529244581822cfcd80a15e29a272d)

👍 1 🎉 1

TNTBOMBOM commented

2019-08-30 15:12:07 +00:00

(Migrated from github.com)

Here's how I see it. If you don't go connecting to captive portals, then you're fine. If you do, then you probably wanted to in the first place, so why break things for end users who do want it.

Why end user would disable something he know that hes going to use it?
Lets take an e.g WebGL , isnt websites using this feature will stop working if the user disabled it? Thus its mentioned to be disabled because it poses threat model.

Keeping things so it wont break the browser is nonsense because in the end it depends on the end user usage anyway.

> Here's how I see it. If you don't go connecting to captive portals, then you're fine. If you do, then you probably wanted to in the first place, so why break things for end users who do want it. Why end user would disable something he know that hes going to use it? Lets take an e.g WebGL , isnt websites using this feature will stop working if the user disabled it? Thus its mentioned to be disabled because it poses threat model. Keeping things so it wont break the browser is nonsense because in the end it depends on the end user usage anyway.

Thorin-Oakenpants commented

2019-08-30 17:09:57 +00:00

(Migrated from github.com)

@TNTBOMBOM

There's a balance to be had. Throwing absolutely lots of prefs at people who find their way to the PTIO is not a really a good idea. Long lists turn people off, and it gets technical (and most people aren't super technical), which means things need to get explained, which makes it even longer. And some people just blindly apply changes without reading.

There's even talk of removing the section, which I personally don;t think should happen: tidy it up, make it super easy and short: and treat it as an appetizer to what else users can do.

A pref such as captive portal is not a super important pref. Those who connect to captive portals and continue by accepting terms etc probably need to (airports, hotels). Those who don't it makes no difference.

No-one said anything about not informing people - there's a link to more prefs. It's just not worthy of adding to a small select list that caters to a lesser technical crowd.

Keeping things so it wont break the browser is nonsense because in the end it depends on the end user usage anyway.

And vice versa, listing it to be changed (and blindly adhered to by tens of thousands of people causing many to curse you for wasting their time and wrecking their plans when out), is nonsense as well. Like you said, it should be a choice. And listing it on the site is not a choice: since people just apply it: you have to cater for the lowest common denominator.

Just drop it dude

@TNTBOMBOM There's a balance to be had. Throwing absolutely lots of prefs at people who find their way to the PTIO is not a really a good idea. Long lists turn people off, and it gets technical (and most people aren't super technical), which means things need to get explained, which makes it even longer. And some people just blindly apply changes without reading. There's even talk of removing the section, which I personally don;t think should happen: tidy it up, make it super easy and short: and treat it as an appetizer to what else users can do. A pref such as captive portal is not a super important pref. Those who connect to captive portals and continue by accepting terms etc probably need to (airports, hotels). Those who don't it makes no difference. No-one said anything about not informing people - there's a link to more prefs. It's just not worthy of adding to a small select list that caters to a lesser technical crowd. > Keeping things so it wont break the browser is nonsense because in the end it depends on the end user usage anyway. And vice versa, listing it to be changed (and blindly adhered to by tens of thousands of people causing many to curse you for wasting their time and wrecking their plans when out), is nonsense as well. Like you said, it should be a choice. And listing it on the site is not a choice: since people just apply it: you have to cater for the lowest common denominator. Just drop it dude

👍 1

TNTBOMBOM commented

2019-08-31 19:43:39 +00:00

(Migrated from github.com)

And vice versa, listing it to be changed (and blindly adhered to by tens of thousands of people causing many to curse you for wasting their time and wrecking their plans when out), is nonsense as well.

you were talking good until you fall into "Number of Users Dilemma" which needs some analyses.

The simple question to be asked is how many users having this criteria:

Using FireFox
Saw pirvacytools section config FF
Agreed and wanted to apply that, but Blindly without reading the explanation of it
Assume as well hes noob so he wont know which functionality he will disabled
And he done all of that while going to airport or hotel
He forgot what he disables from FF settings in a way he cant revert back what he disabled (noob)
He cant/couldnt reinstall FF to start from fresh one in order to solve his issue
....

If that user existed from 1/zillion im willing to accept his curses. Because if he was honest he should curse himself not anybody else (if hes this type of bad mothing person).

> And vice versa, listing it to be changed (and blindly adhered to by tens of thousands of people causing many to curse you for wasting their time and wrecking their plans when out), is nonsense as well. you were talking good until you fall into "Number of Users Dilemma" which needs some analyses. The simple question to be asked is how many users having this criteria: - Using FireFox - Saw pirvacytools section config FF - Agreed and wanted to apply that, but Blindly without reading the explanation of it - Assume as well hes noob so he wont know which functionality he will disabled - And he done all of that while going to airport or hotel - He forgot what he disables from FF settings in a way he cant revert back what he disabled (noob) - He cant/couldnt reinstall FF to start from fresh one in order to solve his issue .... If that user existed from 1/zillion im willing to accept his curses. Because if he was honest he should curse himself not anybody else (if hes this type of bad mothing person).

This repo is archived. You cannot comment on issues.