(In reply to comment #0)
> Since upgrading to Fedora 21 I notice that my computer is attempting to connect
> to gnome.org whenever I connect to a network.

You can disable it in /etc/NetworkManager/conf.d/20-connectivity-fedora.conf

> I would expect to be able to find a way to disable this inside of the Privacy
> panel.

GNOME itself doesn't ship any such files.

> It should maybe be off by default.

No, I don't want people to have to unbreak their systems. Even without captive portal support, it's also used to check for connectivity. If you're connecting to a wifi that doesn't route to the Internet, you don't want all your tabs, email, etc. to start trying to fetch data. It's also better in terms of security for users, avoiding incorrect SSL certificate warnings.

> Meanwhile, since it's on with no apparent way to disable it, do we plan to use
> the data to get an estimate of users?

It points to a Fedora server in Fedora. I don't know the privacy policy for that service in Fedora, but it's unlikely that it's one of the allowed uses.

It seems like there are actually two components at play here.

NM itself is configured (at least on my system) to hit:

  http://fedoraproject.org/static/hotspot.txt

but in response to that check failing, gnome-shell will instruct itself via D-Bus (using an apparently non-configurable url) to hit www.gnome.org.

Either way, we should be able to disable both of these via the privacy panel.

(In reply to comment #2)
> It seems like there are actually two components at play here.
> 
> NM itself is configured (at least on my system) to hit:
> 
>   http://fedoraproject.org/static/hotspot.txt

Yes, as configured in the file above.

> but in response to that check failing, gnome-shell will instruct itself via
> D-Bus (using an apparently non-configurable url) to hit www.gnome.org.

That's what GNOME does when a captive portal is encountered. You'd get a redirect from www.gnome.org to the captive portal, which will send you back to www.gnome.org once the information is entered (at which point the captive portal helper detects that you're done).

> Either way, we should be able to disable both of these via the privacy panel.

You actually get less security if you don't use it. Disabling NM's connectivity checks will disable both functionality.
Still not interested in handing a way for users to get back to the same broken state that was possible without the connectivity checks.

If restrictions are required for some users (never do any network access without a VPN being on for example), this should be implemented at the NM level, not GNOME, and not in a way that breaks user systems.

> No, I don't want people to have to unbreak their systems. Even without captive
> portal support, it's also used to check for connectivity. If you're connecting
> to a wifi that doesn't route to the Internet, you don't want all your tabs,
> email, etc. to start trying to fetch data. It's also better in terms of
> security for users, avoiding incorrect SSL certificate warnings.

"It's not going to work as nicely without this non-essential feature" is the oldest argument in the book, given by people who are not in a situation where they need to be particularly concerned about their personal privacy.

Some people don't have that luxury, and lacking even an option to disable such things seems exceptionally strange to me from a desktop that is currently trying to position itself as being privacy-friendly.

Also: what happens on the day when Fedora's service provider is having connectivity trouble?  Is there some mechanism that I can use to override the failed result of the check in order to force all of my tabs, email, etc. to load?


Consider how easy it would be to use access (or attempted access) to the above URLs in order to tag certain people as GNOME users.  Would be a really great way to track people who are in a relatively small group.  GNOME is < 1% of the market, right?  If we know that some person we are looking for uses GNOME, then we can instantly reduce our search space by two orders of magnitude.

Also consider how great this information would be in case there is an exploit discovered that impacts GNOME, Fedora, etc.  All I have to do is sit in a busy public place and passively wait until I see requests over open wifi for this URL...

GNOME is depending on NetworkManager, so I don't think we can really just wash our hands of this feature by pushing the blame down the stack.  'Normal users' should not have to know about some file in /etc that they need to edit in order to get their privacy back -- they should be able to find all of this in one place, which is the privacy panel.

For a fedora (downstream) specific issue about this, I filed a fesco ticket.
I would also like to have this optional, not sure which component is responsible for controlling it (or who decides to implement end-user easily accessible control over this feature). 

# fedora specific
https://fedorahosted.org/fesco/ticket/1337

(In reply to comment #4)
> > No, I don't want people to have to unbreak their systems. Even without captive
> > portal support, it's also used to check for connectivity. If you're connecting
> > to a wifi that doesn't route to the Internet, you don't want all your tabs,
> > email, etc. to start trying to fetch data. It's also better in terms of
> > security for users, avoiding incorrect SSL certificate warnings.
> 
> "It's not going to work as nicely without this non-essential feature" is the
> oldest argument in the book, given by people who are not in a situation where
> they need to be particularly concerned about their personal privacy.

That's BS. I already explained to you how it solves a real problem with SSL certificates, bombarding users with "this SSL certificate doesn't match" in Evolution for example.

> Some people don't have that luxury, and lacking even an option to disable such
> things seems exceptionally strange to me from a desktop that is currently
> trying to position itself as being privacy-friendly.

As I already mentioned, it's disablable at the system level.

> Also: what happens on the day when Fedora's service provider is having
> connectivity trouble?  Is there some mechanism that I can use to override the
> failed result of the check in order to force all of my tabs, email, etc. to
> load?

You disable the connectivity check in that file.

> Consider how easy it would be to use access (or attempted access) to the above
> URLs in order to tag certain people as GNOME users.  Would be a really great
> way to track people who are in a relatively small group.  GNOME is < 1% of the
> market, right?  If we know that some person we are looking for uses GNOME, then
> we can instantly reduce our search space by two orders of magnitude.

In which case we should switch Fedora and GNOME's URLs to be part of a bigger group. We could ask Mozilla for their connectivity servers and switch both to that.

> Also consider how great this information would be in case there is an exploit
> discovered that impacts GNOME, Fedora, etc.  All I have to do is sit in a busy
> public place and passively wait until I see requests over open wifi for this
> URL...
> 
> GNOME is depending on NetworkManager, so I don't think we can really just wash
> our hands of this feature by pushing the blame down the stack.  'Normal users'
> should not have to know about some file in /etc that they need to edit in order
> to get their privacy back -- they should be able to find all of this in one
> place, which is the privacy panel.

You say "get privacy back" and I say "give away security". Privacy is nothing without security.

Captive portal checks in no way improve security.  There are two situations that a user could find themselves in:

1) behind a simple innocent captive portal

2) under actual attack

In any case, we should never present the user with the ability to accept a bad SSL certificate.

If we are behind a simple innocent portal then SSL will fail, but that's how it was before now... and there's no real risk here -- even if we present the user with a "bad SSL cert" dialog and they click yes, they're going to try to connect to some server that has no idea what they're talking about.

If we are actually under attack, and the attacker is sophisticated enough to MITM SSL (assuming the user would accept a false cert) then they also _easily_ have the ability to spoof the reply to the captive portal check.  Even if we use https for the check, they could forward the check to Fedora's servers and MITM the other connections.  SSL security only protects a single session.

There is really no "captive portals improve security" argument here.

I think the next step here would be for the proponents of this to come up with a patch.

I like Fedora's approach of splitting this config to a separate package so it's relatively easy to disable: just uninstall config-connectivity-fedora.

I've proposed taking the same approach in Ubuntu and Debian (network-manager-config-connectivity is my proposed pkg name).

If most distros do this, couldn't we just use PackageKit to report the status of this feature and turn it on or off?

The problem in debian/ubuntu is that files in /etc are "specials" and the package needs to be purged to have these files removed.

(In reply to Laurent Bigonville from comment #10)
> The problem in debian/ubuntu is that files in /etc are "specials" and the
> package needs to be purged to have these files removed.

The file could very well live in /usr/lib/NetworkManager/conf.d

(In reply to Bastien Nocera from comment #11)
> The file could very well live in /usr/lib/NetworkManager/conf.d

In fact, that's what Debian 'testing' does now with their network-manager-config-connectivity-debian package.

I've had a go at adding an API to NetworkManager that could be used to implement this control panel addition as bug 785117.

If that change is accepted, the privacy control panel could (a) detect if a connectivity check service had been configured, and (b) enable or disable it.

With this change, it wouldn't be necessary to ship the connectivity config as a separate package to satisfy the privacy concerns.  It would also remove the need to bake in the name of the package providing the config, as would happen with a PackageKit solution.

Created attachment 357620 [details] [review]
0001-panels-privacy-add-network-connectivity-checking-tog.patch

Attached is a patch that adds support for toggling connectivity checking in the privacy control panel.  It depends on the NetworkManager changes from bug 785117, which haven't landed yet.

Canonical would like this feature to be included in Ubuntu 17.10 but we'd like to get some review first if possible.

Review of attachment 357620 [details] [review]:

'k, I thought I'd review even though I'm not a gnome-control-center maintainer. Most of my comments are nitpicks, just one is an actual bug. To me it's clear that this is a good candidate for a setting in Privacy so I hope it can be accepted.

This requires API in a new version of NetworkManager - please bump the dependency. And also you get deprecation warnings unless you follow the recommendations outlined in https://developer.gnome.org/libnm/stable/usage.html "How to use libnm" - I recommend you do that too.

::: panels/privacy/cc-privacy-panel.c
@@ +1253,3 @@
+static void
+set_connectivity_check_label (NMClient   *client,
+                              GParamSpec *pspec,

G_GNUC_UNUSED

@@ +1276,3 @@
+static void
+set_connectivity_row_visible (NMClient   *client,
+                              GParamSpec *pspec,

G_GNUC_UNUSED

@@ +1286,3 @@
+static void
+set_connectivity_switch (NMClient   *client,
+                         GParamSpec *pspec,

G_GNUC_UNUSED

@@ +1295,3 @@
+
+static gboolean
+connectivity_switch_state_set (GtkSwitch *sw,

This should be called on_connectivity_switch_state_set, for consistency with on_location_app_state_set.

@@ +1300,3 @@
+{
+  nm_client_connectivity_check_set_enabled (client, state);
+  return TRUE;

You should return FALSE here, so the default signal handler runs. This is the cause of https://bugs.launchpad.net/ubuntu/+source/gnome-control-center/+bug/1715662

Created attachment 360104 [details] [review]
0001-panels-privacy-add-network-connectivity-checking-tog.patch (v2)

Sorry for the delay in updating this.  Attached is an updated version of the patch.  The main changes are:

* Use G_GNUC_UNUSED for unused function arguments.
* Hook set_connectivity_switch callback to the correct property.

Returning TRUE from on_connectivity_switch_state_set was correct: the real bug was that the set_connectivity_switch callback was hooked up to the wrong NMClient property, so the delayed gtk_switch_set_state() call wasn't occurring.

The intention was to implement the behaviour described here:

https://developer.gnome.org/gtk3/stable/GtkSwitch.html#GtkSwitch-state-set

(In reply to James Henstridge from comment #17)
> Returning TRUE from on_connectivity_switch_state_set was correct: the real
> bug was that the set_connectivity_switch callback was hooked up to the wrong
> NMClient property, so the delayed gtk_switch_set_state() call wasn't
> occurring.
> 
> The intention was to implement the behaviour described here:
> 
> https://developer.gnome.org/gtk3/stable/GtkSwitch.html#GtkSwitch-state-set

Alright, thanks, that part sounds good to me then.

Hopefully a maintainer can review the patch soon.

Review of attachment 360104 [details] [review]:

Thanks for the patch, it looks generally good but I have some comments

::: panels/privacy/cc-privacy-panel.c
@@ +28,3 @@
 #include <gio/gdesktopappinfo.h>
 #include <glib/gi18n.h>
+#ifdef BUILD_NETWORK

we need to either bump the required NM version to 1.10 in configure.ac or, since this is a neatly contained feature, just check here with the NM_CHECK_VERSION() macro

@@ +1320,3 @@
+                           self->priv->connectivity_check_row, 0);
+  set_connectivity_row_visible (self->priv->nm_client, NULL,
+                                self->priv->connectivity_check_row);

could be simplified by using g_object_bind_property()

@@ +1330,3 @@
+                           "notify::" NM_CLIENT_CONNECTIVITY_CHECK_ENABLED,
+                           G_CALLBACK (set_connectivity_switch), w, 0);
+  set_connectivity_switch (self->priv->nm_client, NULL, GTK_SWITCH (w));

again, I'd prefer g_object_bind_property()

@@ +1331,3 @@
+                           G_CALLBACK (set_connectivity_switch), w, 0);
+  set_connectivity_switch (self->priv->nm_client, NULL, GTK_SWITCH (w));
+  g_signal_connect_object (w, "state-set",

handling GtkSwitch::state-set is only needed if the API we're toggling was async which isn't the case

Created attachment 360490 [details] [review]
0001-panels-privacy-add-network-connectivity-checking-tog.patch (v3)

I've updated the patch to protect the code using NM_CHECK_VERSION(), and make use of g_object_bind_property().

As far as the use of GtkSwitch::state-set, toggling the property invokes a D-Bus method call that will invoke a polkit access check.  That could lead to the user being prompted for auth depending on the configuration, which is why I thought the async update mode seemed appropriate.  Is that not the case?

Review of attachment 360490 [details] [review]:

Sorry for the delay, I still have some questions, see below

::: panels/privacy/cc-privacy-panel.c
@@ +1269,3 @@
+  g_object_bind_property_full (client, NM_CLIENT_CONNECTIVITY_CHECK_ENABLED,
+                               w, "label",
+                               G_BINDING_SYNC_CREATE,

This should be G_BINDING_SYNC_DEFAULT to update the label when the NM prop changes.

@@ +1308,3 @@
+                          w, "state",
+                          G_BINDING_SYNC_CREATE);
+  g_signal_connect_object (w, "state-set",

This doesn't look like a proper usage of the API. We shouldn't need to connect to the signal here, instead, the g_object_bind_property() above should be done on the "active" GtkSwitch property and it should be G_BINDING_BIDIRECTIONAL. Nothing else should be needed.

The state-set signal exists for cases where the GtkSwitch state drives an explicitly async API that we control directly which isn't the case with this NMClient api which is (to us) a simple boolean property.

You raise a good question though, if we write a value to NMClient:connectivity-check-enabled and the NM daemon rejects the change, what happens? Does the NMClient instance automatically get notified and updates its GObject property back to the daemon's value?