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)
