[Pkg-utopia-maintainers] Bug#859934: enable captive portal checking by default

[Michael Stapelberg]

Source: network-manager
Version: 1.6.2-3
Severity: wishlist

Filing this issue to get the discussion started.

I recently noticed that NetworkManager as distributed by Debian does
not do captive portal checks by default. I.e., when using an Airport
WiFi (or similar), users are left in the dark about how to connect to
the internet. Given that more and more websites go https-only, users
will just be presented with a hard-to-understand error message about
security issues.

I think having NetworkManager detect captive portals is a clear
improvement in user experience.

In technical terms:

• You can check what NetworkManager thinks of your connectivity using
  e.g. “nmcli networking connectivity”, which will result in either
  “full” or “portal”.

• In Debian, regardless of the network type, I always see “full”,
  because we don’t specify the connectivity.uri setting.

• Fedora ships the following configuration fragment to enable
  connectivity checking:
  https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/20-connectivity-fedora.conf

• Not all frontends make use of the connectivity status. E.g.,
  nm-applet does not seem to do anything, whereas I’m told that GNOME
  shell will make use of the status.

Aside from the technicalities of enabling the feature, there are a
couple of open questions to answer:

1. Does enabling connectivity checking pose a privacy issue? No user
   data is transmitted in the connectivity checks, but merely making
   such a request implies that the user is running a Debian(-based)
   operating system with NetworkManager.

2. I’m assuming the ideal URL to configure as connectivity.uri is a
   Debian-specific URI (as opposed to re-using Fedora’s), and that URI
   would likely point to a vhost configured on Debian’s static
   mirroring infrastructure. Extrapolating from network-manager’s
   71874 popcon votes and a default connectivity check interval of 300
   seconds, we’d place an additional load of at least 239
   requests/second on our infrastructure. Are we equipped to handle
   this load now and in the future? Note that we could easily disable
   the feature by removing the DNS record of a single-purpose vhost
   for this feature (e.g. nm-connectivity-check.debian.org).

I’d be happy to talk to DSA to get point ② clarified, but I’m not
quite sure who can help with clarifying point ①. Any thoughts?

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel, mipsel, arm64

Kernel: Linux 4.9.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)