#1337 F21 privacy issue, pinging fedora servers every 300seconds (Workstation only?)
Closed None Opened 4 years ago by bitlord.

Fedora 21 Worksatation image "has" new feature in "gnome" which helps with "Captive portal" services (sorry for lack of knowledge on my side about this), this feature is implemented in NetworkManager, and when package 'NetworkManager-config-connectivity-fedora' is installed (by default on 'Workstation' image) it "pings" fedora servers every '300seconds' which I think is a privacy issue for users, it is not documented, it is hard to find for regular users, and it is hard to disable it.

I understand that this is useful for some people, but most people will never use it, and every feature that ping some outside server/service should be disable by default, or optional during install, so that users know when there is some service which talks to the outside world without user asking for it to do that (doing it in the background).

repoquery says only 'gnome-shell' directly depends on it, but I didn't looked if any other spin install it manually? (I used 'repoquery --whatrequires NetworkManager-config-connectivity-fedora')


This is not a privacy issue. In fact, it's not an issue at all.

Captive portal detection works by downloading a text file from Fedora's server and checking the contents. If the file contents are not what we expect, we mark the connection as "portal". This has few results:

1) If networkmanager manages to find the login dialog for the captive portal, it presents it to you so you can authenticate

2) It reports "portal" instead of "connected" to apps, which means browsers won't allow you to surf to random websites and your email client will not download email until you authenticate with the portal, which prevents the captive portal from poisoning your DNS cache and prevents apps from sending data to the portal server itself (as it hijacks all connections) which may or may not be malicious.

This is a very positive thing to have. It increases your security and provides a good user experience.

The portal detection does not leak any private information, and is a non-issue just like package managers (PackageKit, dnf) automatically refresh the repo metadata cache when checking for updates.

As such I request FESCo will close this ticket as invalid.

Elad, first off: I agree. The benefits of the captive portal functionality significantly outweighs the potential downsides. That being said, I think you missed the actual privacy concern when replying here. The concern is not on the client side, but the server side. Essentially, we now have a heartbeat being sent from all (non-firewalled) Fedora systems to a Fedora webserver. This means that the admins of this webserver have records of the public IP address of all (non-firewalled) Fedora Workstation clients.

Now, it should be noted that this is not tremendously different from Fedora <= 20, as the default homepage for all installations is start.fedoraproject.org, which therefore would also be capturing these IP addresses. The major difference here is that while a homepage can be changed, there is effectively no way to disable this feature for people who strongly desire not to have their address logged (for example, it may be forbidden for users operating within certain organizations, such as governmental).

I'd say that the best resolution here would be to remove the strict dependency from the gnome-shell package and just make sure that captive portal support is available as part of the standard install set. For those users that are privacy-sensitive, we can provide a release note and/or wiki page instructing users to remove the captive portal package(s).

Would this be a reasonable resolution all around?

Replying to [comment:1 elad]:

This is not a privacy issue. In fact, it's not an issue at all.

Why do you want to reveal you location every 300seconds? (IP address means something too?)

About DNS issues, most services (at least those who care) today use SSL, and certificates, so fixing issues with this is unneeded, it will fail, if someone can get valid certificate for malicious purpose and pretend to be someone else, no one can help you then. (more layers, make system more complex, and when it fails it makes it more fun?)

Do you know how many users use this feature? I understand that it can be useful, that is probably why it is implemented in gnome, but I still think it shouldn't be enabled by default silently, at least tell users "Here is the list of services which will be running in the background and ping servers/services, do you want that?"

About package management, I think that is more documented, and people probably understand that there is no automatic updates/notifications without checking remote locations, and that happens in the background.

Replying to [comment:3 bitlord]:

Replying to [comment:1 elad]:

This is not a privacy issue. In fact, it's not an issue at all.

Why do you want to reveal you location every 300seconds? (IP address means something too?)

About DNS issues, most services (at least those who care) today use SSL, and certificates, so fixing issues with this is unneeded, it will fail, if someone can get valid certificate for malicious purpose and pretend to be someone else, no one can help you then. (more layers, make system more complex, and when it fails it makes it more fun?)

The problem with cache-poisoning isn't necessarily security related. It's more of "while I'm captive, all DNS entries are returning the same IP, and it doesn't always clear fast enough to be useful once I get through the portal". It's usability, not security.

Do you know how many users use this feature? I understand that it can be useful, that is probably why it is implemented in gnome, but I still think it shouldn't be enabled by default silently, at least tell users "Here is the list of services which will be running in the background and ping servers/services, do you want that?"

History has shown that giving users too much information that they don't understand will hurt their experience significantly. If you went to the bank and, before you were allowed to start a checking account you were required to read a long document detailing every possible investment that the bank might make with your money, do you think you'd bank there?

I would also note that Apple's iOS and Microsoft's Windows both also behave the same way. (Checking against a known site under their control in order to determine connectivity). This is not unexpected from a user perspective.

As for how many users will use this feature, people who use Fedora and don't at least occasionally visit a net cafe, airport, hotel or other public WiFI location would tend to be the exception, not the rule.

The largest group that is likely not to need this are the stationary desktops inside a corporate network. And in that case, it's almost guaranteed that they will be behind a NAT, which would lead to very limited information (the server logs can only come up with "one or more users behind this NAT connected". That really doesn't tell anyone anything at all of use.)

About package management, I think that is more documented, and people probably understand that there is no automatic updates/notifications without checking remote locations, and that happens in the background.

This is somewhat different, as the mirror network fairly effectively spreads the information around so that no one has the complete picture. (There's some question about the mirrorlist page itself, but since many users of Fedora turn this off or run their own local mirrors, it's fuzzier.)

Replying to [comment:3 bitlord]:

Replying to [comment:1 elad]:

This is not a privacy issue. In fact, it's not an issue at all.

Why do you want to reveal you location every 300seconds? (IP address means something too?)

If I understand the question and security concern here, I am more surprised about the 300 seconds rule. I would expect NM to check the connection once, once you connect to a new network (should it be limited to WiFi even?) and not after that. I understand most captive portals have a time-out, but if I see the interest when you first login, then the user knows he/she is behind a captive portal and thus knows how to deal with it.

I also expect NM to not check for captive portal on network that are known not to have one (ie: do not ping Fedora every 300seconds when at home).

Pingou: It checks every 5 minutes because it's connectivity check, not just portal check. That way if your DSL connection goes down, you'll know that automatically and apps won't needlessly try to connect, and your browser will tell you you are offline.

sgallagh: We do have a firewall by default, and most people have NAT these days anyway. We don't block non-root ports, but I don't think this has anything to do with this feature - if I want I can detect Fedora computers on my network even without them having NetworkManager connectivity check - they download the metalink when checking for package updates, they connect to servers which are publicly listed as Fedora mirrors. As such adding connectivity detection is really not a privacy issue.

The strict dep was added so people who have Rawhide / F21 installed would get this on updates, which is something gnome-shell maintainers wanted. You can remove the configuration file or modify it even when the package is installed, fwiw. See this thread for info about that - https://lists.fedoraproject.org/pipermail/desktop/2014-July/010051.html

Bitlord: SSL has nothing to do with this. Cache poisoning is still an issue - users are most likely to click "ignore and continue" on invalid certificate errors. IP addresses are not uniquely identifying and fetching this file every 5 minutes does not "reveal your location" to anyone. There is no privacy issue here.

--

I should also say that this was not done "in secret" as the reporter of this bug tried to imply in the description, in the inflammatory message they sent to the users mailing list, and on IRC - it was discussed upstream and downstream for a while and was done in 100% transparent way.

I have no problem with removing the dep from gnome-shell (but you'd have to ask someone who actually maintains that package if that's okay) and adding that package to comps - but this feature is NOT going to be disabled in Workstation as there is no real reason for disabling it, there is no real privacy/security concern.

Replying to [comment:6 elad]:

sgallagh: We do have a firewall by default, and most people have NAT these days anyway. We don't block non-root ports, but I don't think this has anything to do with this feature - if I want I can detect Fedora computers on my network even without them having NetworkManager connectivity check - they download the metalink when checking for package updates, they connect to servers which are publicly listed as Fedora mirrors. As such adding connectivity detection is really not a privacy issue.

You misunderstood me (or I was unclear). I'm not talking about a machine firewall, I was talking about a perimeter firewall. In other words, regardless of the state of the machine, if the site considers some information sensitive, it will protect it at the outgoing router. There's very little concern about this information inside the corporate network.

The strict dep was added so people who have Rawhide / F21 installed would get this on updates, which is something gnome-shell maintainers wanted. You can remove the configuration file or modify it even when the package is installed, fwiw. See this thread for info about that - https://lists.fedoraproject.org/pipermail/desktop/2014-July/010051.html

I can understand that, but there is a better place for it: the fedora-release-workstation package. By defining the set of things necessary to be considered "Fedora Workstation" as deps on that package, you will ensure that people get the new features they need if they install Workstation. (And if they decide to continue forward with the classic roll-your-own Fedora, they don't end up with unexpected changes).

Bitlord: SSL has nothing to do with this. Cache poisoning is still an issue - users are most likely to click "ignore and continue" on invalid certificate errors. IP addresses are not uniquely identifying and fetching this file every 5 minutes does not "reveal your location" to anyone. There is no privacy issue here.

--

I should also say that this was not done "in secret" as the reporter of this bug tried to imply in the description, in the inflammatory message they sent to the users mailing list, and on IRC - it was discussed upstream and downstream for a while and was done in 100% transparent way.

I have no problem with removing the dep from gnome-shell (but you'd have to ask someone who actually maintains that package if that's okay) and adding that package to comps - but this feature is NOT going to be disabled in Workstation as there is no real reason for disabling it, there is no real privacy/security concern.

Adding it to comps should be done anyway, for future compatibility. I think making it a strict dep on the fedora-release-workstation package instead of gnome-shell also makes sense.

Replying to [comment:3 bitlord]:

Replying to [comment:1 elad]:

This is not a privacy issue. In fact, it's not an issue at all.

Why do you want to reveal you location every 300seconds? (IP address means something too?)

Help me understand this concern. While I understand that IP addresses can be sensitive information, in order to have meaning, they need to have some correlation with other information. No cookie or other tracking technology is used, and you can verify that. Knowing ''your'' IP address every 300 seconds would be very concerning, but knowing that there is a Fedora system running Network Manager at that address seems considerably less so. There are millions of those, and as noted, they're already doing other network-related tasks automatically (like checking for updates).

I agree that there are some circumstances where having these things turned off is useful, and I think moving the dep to fedora-release-workstation makes sense. (And, while too late for F21, it might make sense to have some checkboxes in the Privacy screen which disables this check, automatic refreshes of software updates, and anything else we can.)

  • AGREED: Ask Workstation to rethink how to pull the package in with the goal of easily enabling people to opt out (+5, 0, -0) (sgallagh, 17:47:38)

I would also expect NM to check for connectivity and captive portal only on network configuration change. Every 300 seconds is just an arbitrary number. I think the user will notice earlier that there is something wrong if DNS and anything else is not working for almost 5 minutes.

Anyone noticed the leet number of ticket, by the way?

Just to report that on gnome bugzilla there is a discussion about this too [[BR]]

[https://bugzilla.gnome.org/show_bug.cgi?id=737362 Bug report on gnome bugzilla]

OK, little update how it works now.
Now two packages depend on NetworkManager-config-connectivity-fedora

{{{
fedora-release-workstation
gnome-shell
}}}

And if you decide not to use this feature, you can find how to disable it by editing the config file NetworkManager-config-connectivity-fedora provides '/etc/NetworkManager/conf.d/20-connectivity-fedora.conf' which is documented in NetworkManager.conf(5) "CONNECTIVITY SECTION"

And when you do that, then package update arrives and fixes all of your problems:

{{{
1 warning: /etc/NetworkManager/conf.d/20-connectivity-fedora.conf saved as /etc/NetworkManager/conf.d/20-connectivity-fedora.conf.rpmsave
}}}

Now instead of your modified conf file, you get default again.

Latest package installed

{{{
NetworkManager-config-connectivity-fedora-0.9.10.0-7.git20140704.fc21.x86_64
}}}

Replying to [comment:17 bitlord]:

OK, little update how it works now.
Now two packages depend on NetworkManager-config-connectivity-fedora

{{{
fedora-release-workstation
gnome-shell
}}}

Yes. The dependency was added to fedora-release-workstation so that it could be removed from gnome-shell and NetworkManager-config-connectivity would still be installed on Workstation installs. The removal from gnome-shell hasn't happened yet, but it likely should.

Replying to [comment:17 bitlord]:

And if you decide not to use this feature, you can find how to disable it by editing the config file NetworkManager-config-connectivity-fedora provides '/etc/NetworkManager/conf.d/20-connectivity-fedora.conf' which is documented in NetworkManager.conf(5) "CONNECTIVITY SECTION"

And when you do that, then package update arrives and fixes all of your problems:

{{{
1 warning: /etc/NetworkManager/conf.d/20-connectivity-fedora.conf saved as /etc/NetworkManager/conf.d/20-connectivity-fedora.conf.rpmsave
}}}

Now instead of your modified conf file, you get default again.

Please file this in bugzilla -- it's clearly just a packaging oversight; that file is marked as %config but should be %config(noreplace).

The replace/noreplace issue was filed and resolved in
https://bugzilla.redhat.com/show_bug.cgi?id=1153901

However, gnome-shell requiring the config connectivity package has not been resolved. It is being tracked in
https://bugzilla.redhat.com/show_bug.cgi?id=1205963

Login to comment on this ticket.

Metadata