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

[Michael Biebl]

[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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-utopia-maintainers/attachments/20170409/b3744101/attachment.sig>