That's what I've already mentioned with the URL in my bug report. But that metered-thing is broken by design.
First of all, NetworkManager is highly unreliable and intransparent, one of the worst inventions of the Linux of the last 10 Years. Second: What if the machine does not use NetworkManager? Some people are so upset about that damned NetworkManager, that they just throw it out. Third: How does Network guess, whether a connection is metered? Technically, there's no reliable way to do this. You can just check and set it on a „per connection basis”. That's extremely error prone bullshit. I've been to so many locations where I had been guest and got a „free” connection, but beeing asked to keep the volume low. Fourth: Is that my machine or yours? Would you be so kind to leave the final decision about what the machine does and doesn't to the owner? Or do you want to compete with Microsoft? Fifth: That argument is nonsense. Because apt – which is much more important in terms of security – does allow to configure whether to update/upgrade or not, you can easily choose to do it manually only. How can the same Company, Ubuntu, have two completely different methods and then claim „would be easy to abuse and have serious security consequences.” ? Sixth: I'm in the IT security business for over 30 years and have been information security officer in several large companies. What precisely makes you think that I need someone as a guardian? Don't you think people like me could be responsible for their own machine? Seventh: In terms of security: Depending where you are, it's sometimes advisable, even necessary, to reduce traffic to an absolute minimum, beyond matters of connection metering. Sometimes it is necessary to just open a VPN tunnel. Or not even send any DNS queries. Eight: It does not make sense if every single program performs it's own upgrade policy based on the personal opinion of the software author. It must be possible to have a central process of upgrading, like I have here, which does all in one routine (apt, git, docker, file sync,...), which is called when appropriate. Ninth: Keep in mind that if snap cannot be configured to avoid any network traffic and to keep it's mouth shut, it could itself be considered a violation of security requirements and complete be forbidden on machines for travelling in particular countries. Tenth: Your argument does not make sense, since snap cannot (unlike apt) be limited to refresh only in case of security reasons. It will refresh in any case of a new package, even if it does not have any security implication. Eleventh: Don't argument with security reasons, if you don't have a threat model and a security model. Shouting „security” is not a rhetoric trick to justify poor design decisions. Blindly downloading in any network is not security. Twelfth: What are the security consequences? Why would I need a new version of e.g. a video cutting program in the mid of a flight if I don't even use it? Thirteenth: Even if there are security problems with a package: That does not imply to immediately replace it. Many security issues do not apply to all users, and in bad cases it would be sufficent to issue a warning or to block the snap package until the user want's to update. Fourteenth: I'm using Linux, Debian, and Ubuntu from their very beginning. Was compiling the first usable versions of the Linux kernel. In all that time it was always possible and easy to configure a machine in a way, that it does not communicate over the network without the user/admin wanting it to do so. Why do you break this property of Linux? Why do you think that this good practise of the last 30 or so years should be abandond by decision of snapd authors? Fifteenth: If you argue that it could have security implications, why don't you consider the case that it could be snapd itself, which is vulnerable, and opens that vulnerability by automatically communicating over the network? Didn't we recently have a bug in dpkg/apt with package integrity checking? Isn't this arrogant to believe, that others have security issues that need to be fixed immediately, but snapd is so good and clean and safe that it can run just anywhere? Sixteenth: What, if it is not allow by law of the local country or organization, and not just metering? Seventeenth: Once a notebook has a password for a WLAN network or has learned to use an open WLAN network with its SSID, and the notebook does not have a physical WLAN switch, you just cannot login fast enough to change settings and prevent downloads. It just does not work the way intendet by the snapd authors. Eighteenth: You have no chance to control. Neither snap list or snap search bothers to tell the size of an installed or available snap. If that „metering detection” of NetworkManager – which I didn't even find a comprehensible description of how it works for – fails, and that damned snapd downloads a new version of libreoffice (occupying 1.7GByte on my hard disk at the moment), this can cause hundreds or even thousands of dollars of costs, e.g. on airplay, mobile roaming, satellite phones, or particular hotels on remote islands. Nineteenth: The metering game is based on assumptions that not always hold true, e.g. that the notebook is directly connected to the metered network. This is not always true. E.g. I often have used a local airgapped network with a partable switch, some devices, DHCP server, file server, acting a routers, and then be connected to a mobile connection through an OpenWRT switch with a USB mobile stick. From the notebook's view, this is just a regular network. How should it know it's metered? Twentieth: My current machines (18.04, 19.10) do not even have that metered setting in the NetworkManager GUI. Or in a summary: That's poor design, broken in several aspects. When travelling, I do need a notebook that just does no communication at all without my consent. For the last 30 years I had this (even if it is difficult to keep control over your own machine once you have NetworkManager and systemd). snapd does not comply with this, and in combination with NetworkManager acts in a very unpredictable and unreasonable way. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1859185 Title: No (obvious) way to turn autorefresh off To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1859185/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
