[CCed the full message so Jeremy has all context]
Hi Michael Am 09.04.2017 um 14:04 schrieb Michael Stapelberg: > > 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? 2) is already solved, we have http://network-test.debian.org/nm, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=729783 $ cat /etc/NetworkManager/conf.d/connectivity.conf [connectivity] uri=http://network-test.debian.org/nm Something like this should already work today in Debian. This feature could be considered "phoning-home", so I'm a bit concerned in that regard indeed and do not want to enable it unconditionally and globally for everyone. If this config is shipped in a separate package, which can be installed (and uninstalled) on demand (and which e.g. the gnome-core or gnome meta package could depend on), would be a reasonable compromise I guess. Fedora named this package NetworkManager-config-connectivity-fedora, shipping /usr/lib/NetworkManager/conf.d/20-connectivity-fedora.conf. The package is installed by default in a F25 workstation desktop. Afair, Ubuntu had/has similar plans. Jeremy, can you comment on that? Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
