I’m just a regular user. I like all of Canonical’s projects: FUSA, auto-detecting missing codecs, the tool for installing drivers, Upstart, Unity (which I still use), Mir, and now Snaps. I do see room for improvement. I just wrote that FAQ based on what I read hear in the forums.
I agree with you that things should be made clearer to the user. I’m thinking that the right approach is:
Each app should only be listed once. If an app has multiple sources then the source used by default should be something set by distro policy, which could be changed by the user. There should be a button to choose another option. When the user clicks “Install” there should be a popup window telling the user what the app will have access to, that the app may require additional permissions while using it, how to change permissions, and which source will be used. It should be familiar since Android also has a window open to inform users of what the app will have access to.
Canonical has a PR problem. There’s an ongoing grassroots campaign to completely delegitimize the company and its projects. The Canonical response is to say nothing unless asked directly, and then instead of responding at the fundamental level, they respond on a technical level. This is similar to what happens in politics, where the Left talks about helping the oppressed and justice and how the Right is evil while the Right talks about details of policy. This campaign is hurting popular support and turning the undecided against you and killing any momentum your projects manage to gain. You need to dull its teeth by removing the legitimate excuses that are being used as the basis of the attacks. Did you notice how after open-sourcing Launchpad the haters didn’t stop hating, but they were no longer able to use Launchpad as the excuse and had to change their vector of attack? The claim against you is that Snap is making the user’s computer not be the user’s computer anymore, but on a substantial level transfers control of the system to Canonical and the developers of applications at the user’s expense, and that Canonical is the Microsoft of Linux, that Ubuntu is the Windows of Linux, and that you are trying to take control of the entire Linux ecosystem through a monolithic store. The way to neutralize this argument is to make the entire infrastructure open-source, make the choice of repository and login service configurable, and allow users to disable auto-updates on a per-app or system-wide basis. Once you do that there will be nothing substantial to criticize you about, so the conversation will have to move on to your comfort zone which is technical merit and then you have the opportunity to gain mindshare and widespread adoption.
So for deb-based packages you want us to pop-up a window that says “this package has full access to your system as root, can erase your entire hard drive, and upload all your data to wherever it wants to”? Or are you saying that only Snap packages should be forthcoming about the access that it has over your system?
Something like that, yes. Be honest with the user, and let the user know that if he wants greater security he can choose a different install option. No need to push, just inform.
Edit: You can also let the user know about the updates policy and the different disk-space requirements of the different install option, perhaps behind a “learn more” link. Be honest about all the options.
Did it happen ? It happened a snap embedded a currency-miner. And snap can be proprietary closed source packages, so where is safety here ? Who reviews what ? Who trusts who ? And since most snap for being usable will be connected to home and removable-media interfaces, they may not harm my system with root privileges, but may ( ¿ question marks here ? ) totally harm my personal data and leak them anywhere… I don’t care my system broke. I care my personal data to stay where I expect them to stay, in an expected state and storage.
It’s like all of a sudden we’re no longer safe using legacy packages - whilst for years we all had the feeling to be in a more « secure » context thanks to distro-curated APT/.deb repositories than, say, in other famous OS.
Back to app-store. I don’t think so much info are necessary. Just show the existing choices, where and when ever there is choice. Here’s an app. You can install it as [ snap | .deb | flatpak ]. It’s enough to trigger curiosity user’s side, who’s now able to search about one or the other package if s⋅he cares.
Snap are safer seems obvious for you. As a stupid user, first things I see about snap are the annoyances. Suddenly Firefox can’t save nor read a file from my desktop or my documents folder. Gimp won’t save my edited photos on an usb-thumb or external HDD. None of my snaps will access my personal folder because it sits on a different partition.
…and this is just because as a stupid user, how could I guess :
⋅ I installed a snap - since the app-store did not clearly tell me,
⋅ I should have set some wise and useful permissions - since opening the app itself does not offer me any hint either.
Seriously. Can’t you see the «user experience » challenge here ? And we could also talk about personal config’ files loss vs. restore-mechanism as other examples of good ideas badly shown. Once again it’s not at all a critic of snap in themselves, it’s mainly a critic of « how they are shown » to the users. Or precisely, how they are not enough explicitly shown, explained and taught to the users.
Besides these basic awkward ways regarding UX in managing snaps, add some ever-moving « trends » and « fanboyism » around brands and communities and mine is bigger than yours, no wonder why snap adoption is not so happy-shiny.
If you only have distro repositories in your /etc/apt/sources.list and /etc/apt/sources.list.d, then the traditional packaging system is fairly secure: the PGP signature checks ensure that the packages come the archive, and the project’s policies mean that any packages going into the archive undergo some level of checking by an Ubuntu developer.
If you’ve added any PPAs or other external repositories to the list, all bets are off. While you still have the PGP checks to ensure you are receiving the packages the PPA author provided, you are now giving the PPA author the same trust as the Ubuntu developers. And this doesn’t just extend to the application you installed from the PPA. If the PPA adds a package with the same name but higher version number as something found in the main Ubuntu archive, then your next apt upgrade call will happily replace the Ubuntu package.
Having a snap ship with a cryptocurrency miner is bad, but it is worth keeping things in perspective. It was only stealing CPU cycles on computers it was installed on. That’s the least an equivalent attack via a PPA or external repository could do.
The Steam.deb accidently erased user data because they forgot to set -e in a bash script and used an unset environment variable. The Chrome .deb broke apt by using incorrect syntax, and set a root cronjob which repeated the mistake if it was manually corrected. So, yes, there’s a history of .debs breaking the system and erasing user data.
This isn’t nearly comprehensive enough to be accurate. It’s simplistic which leads people to use the misleading shorthand “Snaps are proprietary”. It’s just wrong.
There’s more to snaps than just “the client” and “the server”. There’s snapcraft, snapd, the graphical snap store snap, apparmor, kernel patches, the build system (launchpad), the storefront (snapcraft.io/store), and finally the webserver that hosts the snaps. The vast majority of that code is open source. The tiny bit which hosts the snap files isn’t currently open source. Just like github isn’t, where many people get their software from.
A big beef I have with Snap is that when compared to GitHub, there’s always GitLab or BitBucket or other alternative. Snap has no such alternative option.
Furthermore, Snap’s assertions system is a major problem. This means that the server side isn’t just closed-source, but you actually can’t implement an open-source store without the user recompiling and installing a forked snapd on their system. We don’t have Canonical’s signing certificates, which ensure that the Snap server remains proprietary and that any open-source 3rd-party effort is pointless.
That’s why it is important that this discussion does not descend into anecdotes. Everybody’s individual experiences are important (and this thread seems to be a good place to share them), but a robust engineering solution has to be driven by all the data.
I think this is also a great path forward, but this will require additional community outreach which neither GNOME nor Canonical seem to be doing at the moment. Some outreach that needs to be done:
There is no current work to add support for camera and audio portals into electron.
There is no current work to add support for any portals in Java Swing.
Many applications need to be ported to these new api’s and many snaps need upstream inclusion, updates to the latest and greatest desktop helpers/extensions etc.
Asking app developers to support the portal api’s directly is not the right way forward, in my opinion. This needs to be supported by the toolkits, and we need people familiar with these technologies to write that support.
I am 100% convinced that Canonical cannot do this outreach on their own. Fixing app distribution on Linux desktop requires so much work that the only way we can achieve this is by collaboration. Adding portal support is a great step in the right direction. Glaring issues like snapd’s lack of internationalization in snap metadata can be easily fixed by using existing standards like AppStream. I understand the security issues of AppStream, but not using it means “app metadata” is one more issue that Canonical need to fix on their own. You simply can’t expect Canonical to have enough developer resources available to solve all these issues at once.
So in my opinion, it is vital for the future of snaps that you increase collaboration with the wider desktop Linux ecosystem. I’m not entirely sure how to do that. However, responding to criticism with “people who don’t like Canonical will never like snaps” seems counter-productive. Sure, the proprietary nature of the snap store will hardly be an issue for the wider ecosystem of app publishers, but it is a big issue for the other people who are trying to fix Linux desktop app distribution. You need good relations with them because you simply can’t fix all these issues on your own. It doesn’t matter that these people will never use snaps. What matters is that these people see Canonical as a good open-source citizen worthy of collaborating with.
Sidenote: portal support for snaps on 18.04 is still wonky; I have a snap that consistently crashes when it tries to use the files portal on 18.04. Where should I report issues like that?
None of those alternatives are open source releases of GitHub’s server code, however. If a third-party wants to write their own snap store neither we the community, nor they Canonical will stand in their way.
In fact, I remember someone from Canonical published a proof of concept open source snap store a few years ago, but nobody was interested enough to pick it up and actually run an alternative store.
The problem with this and any Snap Store is, once again, assertions. All Snaps are signed with a Canonical private key on the Store Server side. Thus, the user must install a forked snapd on their system with different public keys to use a different server.
The only thing the hardcoded assertions key currently enforces is that each snapd instance is only connected to a single snap store. A different distribution like Manjaro could very well ship a modified snapd to their users which points at their own store. Manjaro chose to use the snap store hosted by Canonical because they like the advantages that gives them. This is no different from how Linux Mint used to point apt on their devices to the Ubuntu repo’s in the beginning and switched to their own repo’s after a while. Manjaro will be able to switch to their own snap store if that makes sense to them. Note that this is exactly what the Ubuntu Touch project did. They are using “click”, the precursor to snap, and they created their own store and Canonical helped them with the transition from the Canonical store to their own store.
So I strongly disagree that “any open-source 3rd-party effort is pointless”. Snapd is a great package manager and any distribution can take advantage of that, just like they already do with apt.
However, in this context, there are two limitations in snapd that apt doesn’t have:
There is no user-accessible config to change the snap store. This is something that would be trivial to add to snapd if people are interested in running other stores, though this feature would need a lot of design work to make sure that the user experience of switching to a different store is good. For example: what happens with the already installed snaps? Given that on some devices, the kernel itself is also a snap, this is an important issue to solve before making it possible for users to change this.
Each device can only use a single store at one time.
The second point was a conscious design choice by the snapd developers with two main motivations:
The first motivation is that having only one store per device solves a lot of the user experience issues that ppa’s have. Note that this is not “everyone using snap should use the Canonical store”. What they actually want is “every device using snap should only use a single store”, regardless of who runs that store. Canonical’s experience with ppa’s showed them the disadvantages of having each device connect to multiple separate “stores”. Flatpak is currently experiencing the same issues; hence their push to get as much apps as possible into Flathub, instead of each publisher hosting their own Flatpak repo like they did in the beginning.
The second motivation is that having only one store makes a lot of stuff easier to implement. The snapd developers have not implemented this functionality to make their jobs a lot easier. Though on this forum some snapd developers have showed that they are open to the idea of someone else adding this functionality to snapd. They will simply not add it themselves.
[ bad faith ON ]
As if actual things regarding snap were already well enough designed to ensure a good UX.
[ bad faith OFF ]
Improvements are real, and are really still needed today, on what snap offer. One thing after the other. There is a cruel lack of fancy, easy, eye candy, full featured snap manager aiming at average desktop users.
The possibility of other snap-stores are interesting ( I can totally see why the team behind a distro would want that ) and their relative limitations ( one store per device ) are totally understandable.
But details matter. UX is not a detail, especially when targeting desktop-users. Strange how the « big lines » or « global concepts » of snap sound very well thought, but their [ realization / what happens in front of average users’ eyes ] are not so glorious.
Now if people gets confused with snap-store, maybe it’s also very easy to fix : just mention on the store front page something like « here you will only find the finest app’s in all shiny glory snap package ».
Maybe it’s already like that, i don’t know, snap-store is not installed by default on Ubuntu Budgie.
Self-explain. Teach. Trigger curiosity. Never hide !
If people tell “you” they are confused, it’s very probably because “you” forgot to show or tell them something - a thing that was obvious for “you” but not at all for them. It’s a language/communication/design/layout issue. Maybe the ability to install both snap-store ( for only snap ) and (gnome-)software ( for only apt/.deb official repositories ) ? One should not exclude the other.
If not addressed, those « language » issues end up perceived as intended attempts to « impose » something.
