After a regression happens because of an unexpected upgrade of a snap application the round is lost - as far as snap platform user experience goes. The idea is for the user to be able to schedule updates when and how it is convenient to him. The user knows best how to balance the risk of getting hacked because he didn’t update versus having his system going down because a snap got updated. Even Intel botched the firmware updates after the Meltdown vulnerabilities despite knowing about them for >6 months before shipping the updates. You can’t reasonably expect new software to not have bugs (even bugs as features when a workflow/usability change may negatively impact the system the snap application is part of).
Letting users schedule updates for when and how it’s convenient for them, if they so choose, is exactly what snapd enables, today.
Unless I missed some changelog snap does not allow me to not schedule updates and only perform them manually. I can configure apt updates to never happen unless I allow them through the Software & Updates app. But I cannot do that for snaps. My home computer is not like a server, it doesn’t stay on 24/7. I open my laptop to do work, and when I 'm done I update. I don’t want to have my computer auto update while I 'm working and I don’t want to lose the simplicity of updating when I say so versus becoming an oracle and imagining when I can have my computer on but not work on it so it can update. I also don’t want my snaps to update without me seeing the changelog - and relevant warnings - in my terminal so I can troubleshoot them before I need to use an application that misbehaves. Keep it simple please- allow home users the ability to tie snap upgrades to the options available in Software & Updates app (and therefore disable upgrades when they see it).
2 Likes
@Iolaum you can currently set snapd to only refresh snaps once per month as per the docs I linked above. However I know that’s not quite what you’re looking for…I wonder if snapd can get closer to what you’re looking for without using a global off switch though:
@niemeyer Maybe snapd could support an option that, when selected, means that snapd doesn’t automatically refresh for a month after the last manual refresh. That way @Iolaum can refresh only when they turn off their computer, as long as they do that once per month?
@Iolaum if you read what @niemeyer (the snapd lead) has said earlier in this thread (quite close to the start but also throughout), they’re not producing an off switch because they don’t want users to be stuck on outdated and insecure software. By not producing the off switch, they’re forcing themselves to grow features (like maybe the one I suggested above) which mean that users should never need an off switch. It’s not being kept ‘simple’, as you see it, because they want updated systems that are usable, which means somewhat complex (but very useful) policy.
Why can’t you work and update simultaneously though, not enough bandwidth?
As far as I know, snap updates don’t have changelogs anyway, @niemeyer is this an option that devs should be able to give? Perhaps someone could choose to configure snapd so that after snap refresh is run, before refreshing, all the changelogs come up for confirmation? Or, snapd could require that users refresh when refresh is run but provide the changelogs somewhere for access. Also how do you define ‘misbehaves’ @Iolaum?
@Ads20000 Yes, it would definitely be reasonable to have an option to say “skip refresh windows if the last manual update was within N days/hours/etc”.
1 Like
Until this feature is implemented, I flat out cannot use Snap packages.
I recognize the desire to protect users—but the end result is that I cannot use snaps at all, or any of the other potential benefits they offer.
I’m toying with the possibility of just installing everything in -devmode, but that of course has it’s own, major security implications.
2 Likes
@Ads20000 Misbehaves means that it does not behave as the user expects it too. This can be a bug (incorrect implementation), a new feature that changes the user experience (UI or UX changes), or something else. Let me state an example:
Say that I have installed the skypeforlinux app through a snap (isntead of a deb from microsoft ppa as I 've currently done) in my parents laptop. And then let’s suppose that in a new version microsoft updates the UI as usually happens with this apps. As far as my parents are concerned this can be more of a bug than a feature. Right now I have set Ubuntu Mate to notify of updates that are available that they accept at their convenience. Therefor if after that something goes wrong (either because of a bug or because of a UI change) they can be ready for it (and hopefully figure out the UI change on their own). On the other hand, apps/snaps that update in the background without the user knowing when may surprise the user at inconvenient times.
On top of it it’s interesting that the snap enterprise proxy application allows (as claimed here, haven’t verified it) to defer snap updates, but the user on a laptop/desktop can’t. If it’s reasonable to allow the user to keep using an older kernel on his machine (e.g. by disabling updates) why is it unreasonable to give him the option to do that with snaps as well ? I am not saying that a user should do that, and if I met such a user I 'd try my best to help him solve the technical debt that made him make such a decision.
Snaps really need to have a way to plug into the centralized way an Operating System has for managing updates (e.g. the Software and Updates application in Ubuntu and derivatives). Snaps are a good technology, and I 'd rather have skype as a snap instead of a normal installed deb in my system, but not at the expense of losing, as a user, the unified workflow I have for controlling how my system updates.
I think I heard a while ago that a notification feature is on the roadmap, just be patient 
What stops you to set up such a proxy on a desktop/laptop ? It is just a question of installing and configuring software after all (there is no magic in running a proxy locally on a desktop/laptop and point your proxy settings to localhost, many people do that all the time)…
One of the bigger goals of snaps is to actually take away the need for having to control this. If you look at server snaps (any snap that starts a system service) they already do fully automatic rollbacks if the service fails to start after an upgade. The builtin rollback and selftest features in snaps aim for exactly that … not having to care for updates anymore and having a system that always works, no matter if something gets updated or not.
The target here is to take away a burden so that your parents will not even have to care if an update happens or not but will always have their applications fully functional without being bothered with maintenance work or reading cryptic messages in changelogs.
1 Like
One of the bigger goals of snaps is to actually take away the need for having to control this.
This will never happen. Software always had and will always have bugs. Look for example the bugs Intel’s firmware updates had after the Metldown/Spectre vulneerabilities were announced. This is why people who professionally administer systems said in this thread that auto updates are a no go.
BWhat stops you to set up such a proxy on a desktop/laptop ?
I 'm not keen on installing a proprietary solution in order to use snaps properly. Moreover it adds complexity in managing the system. Lastly, as has been suggested here, one way to kill snap upddates is to block/redirect api.snapcraft.io. If I just wanted something for myself I could settle for that. But It’s a duct tape solution and I don’t like it. Moreover this feels like DRM on video games when they were shipped in CDs (legitimate users couldn’t make back ups of their CDs [to cover for scratches/damage] but cracks and images were available for people who didn’t buy them). People who want to go around auto updates can do so, but non-technical users don’t have a way of controlling their updates according to their needs. Moreover this approach prevents Ubuntu desktop distributions from integrating snap updates in the Software and Updates app that handles updates for the rest of the system. Why do we need two different update mechanisms in Ubuntu? This (not allowing snap updates to be fully controlled by the user - that includes never update -) is wrong and I hope Ubuntu developers will realize that allowing users to control updates does not harm the quality of snaps.
2 Likes
If you’re using snapd you’re already using the proprietary snap store.
Because they’re for two different package managers. Snappy has reverts which means that updating without prompt in the background is safer because you can revert the update if it breaks something (which they’re less likely to do because snaps don’t use shared dependencies in the same way that Debs do) - albeit by Terminal which admittedly most users won’t know how to do.
I think this is a good move, however, I’m not aware of ChromiumOS updates having an off switch?
Also perhaps Ubuntu could have settings to control snappy in Software & Updates. Please mark yourself as affected by this bug that I just filed! 
1 Like
I think the malware found on the snap store is actually a reason to keep the status quo on this issue. Snappy, Flatpak, AppImage, random binaries, external Apt repositories are all weak on this because there’s no distribution maintainers checking every app’s source code (with few exceptions) for malware and understanding software inside-out. However snappy is stronger than the others firstly because everyone is locked into Canonical’s snap store, there’s no possibility of someone installing a rogue Flatpak remote that Flatpak can’t take down (though someone could sideload a rogue snap with snap install foo.snap --dangerous) and Canonical can implement checks on all uploaded snaps but also can remove snaps from the store and secondly (more relevantly to this topic) forced updates has the potential to ensure that malware is removed from everyone’s computer via dummy packages that ensure that malicious changes are reverted etc. If updates weren’t forced, someone could turn them off because they don’t want unhelpful changes to their software etc but they may never hear about a particular malicious app and they could thus be stuck with it. I suppose it could be made so that updates are only forced for malicious apps or some notification is given for those updates which grabs people’s attention so it’s not easily dismissed (but I’m sure some would still dismiss it) - maybe the title bar being ‘Your computer is infected’ or something…
Forced updates are also a risk though because someone could push a malicious update to a benign app and it would be installed to everyone’s computer that has the snap.
The malware found in the snap stop show that as far as software distribution goes the snap stop is nothing special compared to other solutions. Malware has been found, for example, in the android playstore, it will also find it’s way in the snap store, especially as it gets more popular. This means that disabling automatic updates is as important in snap store as it is in all other methods of software distribution.
As a reminder. Disabling automatic updates is not about not keeping a user’s system updated. It is about using a custom update process that fits the user’s requirement. If somebody wants to stop updating he can already do that by blocking access to the snapcraft servers.
Yes, and if you can specify exactly what control you need and why then the snapd team are happy to develop features to help with that use case (short, for now, of implementing a global off switch).
I suggested a use case earlier that seemed to be overlooked/ignored. Given Shuttleworth’s recent interest in security, it might be worth considering.
I feel like there’s been more time spent explaining why a kill switch to snap updates won’t be implemented on this forum than it would have taken to implement by a large margin. The use cases keep building, the explanations for why it won’t be done stopped making sense a long time ago. Seems like this has gone on long enough for developers to clearly say we won’t ever do it and close this thread or just do it so this conversation can stop. There’s plenty of good reason have it and not very good ones to not.
5 Likes
Am 48. First computer at age 12. I have stuff I wrote since about age 17 stored away safely and if you knew how infrequently I have backed up over these years, perhaps, you would consider me insane. Still, I have lost very little due to security issues, mistakes and malicious binaries.
I am responsible for all IT for my employer, thankfully less than 20 machines including their servers.
Snap has all other signs of great maturity, and I really do like it - it could become the best distribution platform ever, but only truly mature software will land on some systems I manage that I view as in any way critical.
Truly mature software will let you risk not updating for as long as you see fit to take such a risk without making you block domains at whatever level you choose to block such.
Assuming the immaturity of your user? Sorry, looks pretty immature to me - bury the kill switch in a .conf file in /etc, /snap or where-ever you like and ‘Gumby’ will naturally always be updated. If Gumby determines reason (no matter how foolish insane) to block the updates then he will find a way regardless what you think of him.
Have a nice day.
2 Likes
That’s an interesting perspective. As a counterpoint to this specific line
of thinking, disabling refresh would also mean that the fixed snap
wouldn’t be automatically pushed out to affected users.
@jdstrand A user who wants to control his update process is also able to check for updates and inform himself of that scenario (new security updates). Also security updates can cause harm as well if they are not vetted, a good example are Intel’s Spectre firmware updates that bricked some devices and had to be rolled back.
On top of that, Canonical’s proprietary solution for managing snaps for enterpise customers, who will be the biggest consumers of snaps because of IoT, already allows them to stay outdated (given what has been said here about version pinning, have not read the docs myself).
2 Likes
This is what Niemeyer (the snapd lead) often refers back to and, I must admit, this does seem to be outdated because of the existence of the Snap Enterprise Proxy. Is really to be expected that non-enterprise users use this proxy? It doesn’t seem very easy to set up but maybe that’s the point, in reality, it’s still hard to ‘simply disabl[e] updates altogether’ for the reasons given above.
I’m also guessing this still applies.
As far as I understand it, snapcraft is not a democracy. We should keep satisfying what Niemeyer requested above and providing use cases and suggesting forms of mitigation (I think the snap refresh timer was introduced as an outcome of this topic? Plus Niemeyer said it would be ‘reasonable to have an option to say “skip refresh windows if the last manual update was within N days/hours/etc”’ so this is a change which effectively has design approval which is an outcome of this topic. Probably also the Snap Enterprise Proxy bore the thoughts of this topic in mind), but the developers have no obligation to satisfy our demand just because we make the demand. If you absolutely can’t stand the status quo, I suppose the only answer is to manually work out a way to block refreshes (maybe by using the Snap Enterprise Proxy) or by using a different universal packaging system like Flatpak. Alternatively…if anyone reading this understands Go, it may be possible to code a snapd soft fork which implements certain changes which many users want but the snapd team disagrees with, now you could say ‘but we shouldn’t have to resort to a fork!’ but if you can’t do the other things I’ve suggested as action in this post then we do have to because we fundamentally disagree with the snapd team, we have no other option. Forking is part of open-source, after all, perfect for when you have design disagreements that can’t be resolved any other way. @G.S.1 listed the changes that should be made in this repo, also see the other pinned snap repositories on their GitHub.
Specific use cases need to be given as objections, as requested by the snapd team, rather than generally raging against the status quo, you can Like (+1) previous posts to achieve that. I really hope this topic is kept open so that more use cases and proposed solutions (short of an off switch) can be suggested by the community, I think closing this topic permanently would be a big downside for the snap project, enabling criticism to be made in-house is bold and can result in positive changes. E.g. @robsoles you kinda gave a use-case but you didn’t state why forced refreshes are a problem for you, can you state that more clearly? Why do you need software that ‘will let you risk not updating for as long as you see fit’? Saying merely that ’ it should because I say so and the software should #RespectTheUser 
’ doesn’t challenge the status quo because the snapd team clearly aren’t responsive to such a statement because they’ll just disagree (and you can just Like previous comments that have said the same thing rather than write a new one). Give specific reasons why you can’t update software on systems and suggest action short of an off switch - e.g. do you need the refresh timer to be extended? Would it be OK if the timer allowed one refresh every five years? Or is there software that you need to keep completely static with not even security updates for longer than five years? Why?
This is a good example, going back to Niemeyer’s original post on this topic, though,
@niemeyer were health checks implemented? Would they always catch cases like the one given above? If not, is it reasonable to accept that the user’s system is bricked because snapd or the snap developer didn’t do health checks etc properly? Can snapd really expect developers to implement lots of automated testing when they don’t have to do so for any other packaging format? Should users be forced to suffer when developers/snapd get that wrong? I guess you would argue that the alternative is that users are left on vulnerable software because they won’t update their software, but what’s the actual risk of them being attacked because of their decision?
Is this a common experience? Maybe it would be acceptable for snapd to allow users to be vulnerable to attack because they want to be? They don’t mind the risk of having all their data (that which is accessible to a particular app) stolen?
Going back to Niemeyer’s original post again:
Maybe the key part of this is ‘some of the problems’, maybe some users want those problems but appreciate the other solutions that snapd has produced? Do we really need to fork to get this situation that some users want? 
2 Likes