-
-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable or Provide Our Own Captive Portal Detection #681
Comments
...and while I do use a Firefox sync account, I do take issue with unnecessarily phoning home like this. |
PS : Only this one ? Yes I believe and the word key is : "portal". |
I shouldn't default to disabling the feature. I've seen too many situations where users are confused in portal situations. Guidance, resulting from detection, is more user-friendly.
|
If there were a success.txt file or just a HTTP 204 generator on the waterfox site, this could be kept with a more privacy friendly url. |
For firefox, I just remove the URL and set it to 'false'. If Waterfox is for power users, why not add a checkbox: "Disable Portal detection" |
IMHO Waterfox webpage is behind Cloudflare, that's really privacy unfriendly. |
Please, let's keep this focused – captive portal detection. Cloudflare discussions include:
|
If you use sync, then phoning home will definitely happen. I do consider it unnecessary, but - by looging into sync - you just agreed to Mozilla way of using its services. Reconsider the use of sync, IMHO. |
I have setup my own sync server, getting it to function is another
matter but all the services do run...
…On 1/2/19 1:09 PM, Atavic wrote:
If you use sync, then phoning home will definitely happen. I do
consider it unnecessary, but - by looging into sync - you just agreed
to Mozilla way of using its services. Reconsider the use of sync, IMHO.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#681 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZUOod04sEnbibVmfbiSlTKbW6XWvlEks5u_QPSgaJpZM4U6SCn>.
|
So my previous comment doesn't apply anymore, I agree with your concerns. |
Things like this are why I think librefox, be it in stock firefox or in waterfox, seems like a great idea. |
@mparnelldmp please, what problem do you find with the existing detection routine? |
I don't think having it enabled by default is a good idea, the same goes for any other part of WF that reaches out and touches a remote server, except for maybe the WF updates server (which doesn't apply for distro packages). |
Why not?
Please, let's keep this focused; captive portal detection. |
I reported to Mozilla but, because it uses http, it's trivially easy to use MiTM to hijack these requests by faking the gateway on any given network and then redirect or replace the content with whatever nastiness the attacker desires, because it appears to be an "official" browser function since a little thing drops down and tells you to click here to login to the network... |
Because we know that Mozilla isn't super trustworthy for privacy (in terms of marketing, logging, etc), it would be nice to either disable or replace with our own the captive portal dection system. I'm fairly certain it pings detectportal.firefox.com on every network we connect to.
It reminds me of the generate_204 pages that Chrome/Chromium and Android use. While no data is shared, usually, metadata and IP address info is there, and enough for corellation of users.
The text was updated successfully, but these errors were encountered: