Experimental flag for hiding ~/snap

Also, it’s worth noting that not every application will respect XDG_* variables, and will place configuration data in what is pointed to by $HOME in their runtime space. If this change will make $HOME point to $HOME/Snap for the snap then they’ll be placing their configuration in the folder that you’ve explicitly said is not for that!

1 Like

they do not work on Ubuntu Core where home is never auto-connected, they will not work in enterprise env’s where an admin decided that (certain) snaps should not have access to the users general data and disconnects the home plug explicitly … in such cases $SNAP_USER_DATA is still needed for the snaps to function properly …

And how is $SNAP_USER_DATA or $SNAP_USER_COMMON improved by this change? You’re simply rearranging deckchairs.

i’m not talking in support of that move here, just pointing out a flaw in the argument :slight_smile:

a badly articulated argument is just as valid as a cited research thesis. ;-p

1 Like

My reading is that the move from ~/snap to ~/.snap would happen for all snaps on the system. It’s the environment changes that would be limited to core22+ snaps.

That makes sense, since the environment changes are very likely to break existing snaps. For example, imagine I have a program that writes its configuration to $HOME/.foorc and I’ve created a core20 based snap out of it. With the current environment, it will write that config to $SNAP_USER_DATA/.foorc. If we leave $HOME unchanged for snaps, the program will start getting AppArmor errors when trying to access its config file.

There’s no core22 snaps in existence right now, so making the environment change contingent on the base snap won’t break any existing published snaps.

What are the flaws of :

⋅ a file named hidden

⋅ at the root of folder /home/$USER

⋅ which contains names of folder to hide, one name by line

?

Nothing else to change, just check if this file exists when installing snapd and append snap to it ? Or create it if not already.

Hmm so traditionally XDG_* variables live under $HOME - and with the current situation where $HOME == $SNAP_USER_DATA this is still respected.

However with this new approach, since $HOME is ~/Snap/<snap_name> then the XDG_* variables are now under $SNAP_USER_DATA instead (ie ~/.snap/data/<snap_name>) which seems extremely confusing to me. How does a user / developer know which location to expect their snap will use when storing data? Why is “user-facing data” seen any different than non-user facing data? This is breaking a pretty well-established convention.

Also I agree this doesn’t solve the majority of user complaints which are that the ~/snap directory exists in the first place - we are trading that problem for a similar one (ie. now ~/Snap exists too) as @mardy suggests above.

3 Likes

Adding to what Alex said, I think the part of the proposal to add a ~/Snap directory will be deeply unpopular: it’d feel like a bait-and-switch when combined with moving the existing ~/snap directory.

One of the main complaints about the existing directory hierarchy is that people expect to have control over the non-hidden files in their home directory. But if they exercise that control over the contents of the ~/snap directory and move files/directories around, things break. The ~/Snap directory would have the same restrictions. The imposed structure might be simpler (i.e. no subdirectories with revision numbers), but it is still constrained.

I suspect much of the complaints come from desktop users, and in most of those cases they’d want to read and write documents in standard directories like ~/Documents or in other locations custom to the user. This seems much better handled by the document portal or home interface rather than the addition of a ~/Snap directory.

2 Likes

As a desktop user I already hide the ~/snap folder which I don’t need to see permanently.

Hello all,

Just to add some color to the conversation, as it looks like there’s some confusion about what we’re trying to do and why.

There are two different points at play around this discussion. One of them is about the fact people are unhappy that there is a directory inside $HOME that is related to snaps at all. We’re not trying to address this argument, because the point of this directory is to offer the snap a safe and isolated space that is still convenient for the user to see. Note that this is exactly the same reason why we have Pictures, Downloads, etc, inside the home directory. So hiding the directory from view goes against its very purpose, which is to be visible.

There’s a second argument about it which is related to the fact the shape of that directory today is unpolished, and that’s true. Back when we created the system there was too much in our minds, and we simply copied an internal pattern that we’ve used in a few different places, which is a correct pattern, but it’s not a proper user interface. We’re trying to address that, not bait-and-switch, and not take blind criticism at face value either, as that will continue to exist regardless of what we do.

We’re not yet completely sure that the approach we’re going for is the right one, though, which is why instead of making the change visible we’ll first have a feature flag that enables experimenting with the concept privately. Once that’s available, we’d encourage experimenting with it and providing feedback to the team. We certainly don’t want to get that one wrong again.

1 Like

I do think the proposed layout of ~/Snap is better than the existing ~/snap directory, but if I’ve got 50 snaps installed it’s still going to feel a bit unwieldy. If many of those directories are empty (or appear empty), then it’s not going to feel like something the user owns. And that is one of the main complaints about the existing ~/snap directory.

Maybe one solution would be to make creation of the directory opt-in? If I’ve got 50 snaps installed, but the only subdirectories under ~/Snap are for the music app and photo manager then the directory will be much more manageable in a graphical file manager. It’d also mean that don’t need this facility (e.g. a game or a simple command line utility) don’t impose visible complexity on the user.

If the we’re only showing these directories to the user when they have a purpose, then they are more likely to accept it.

That’s certainly an option, with the down side that all those snap authors that don’t realize that they need to opt into it will just have their files hidden under a ~/.local/share directory or similar. So with that in mind, what’s the real strategy? Are we going to be nagging developers to enable the flag so that users can see content that would typically be exposed anyway for normal applications? How do we do that realistically? Or is it worth hiding every application $HOME away from people’s view regardless, because people are offended by the very notion of a directory with application names under it? Note that this is literally $HOME for those applications, not just $XDG_SOMETHING.

but if I’ve got 50 snaps installed it’s still going to feel a bit unwieldy.

Having 50 snaps should not create the directories. Using 50 snaps would.

On the desktop GUI level, aren’t we already at this point? The desktop-launch scripts configure filepickers to show the real Downloads/Pictures/etc, the one they fail at changing is $HOME itself because there isn’t a good technical solution for it that doesn’t cause permissions issues. On the other hand, extensions go one step further and enable XDG portals, which also shows the real $HOME, and the community (and Snaps own documentation) considers that proper and expected behaviour. I can’t imagine many people actually expect or appreciate the behaviour of a snap saving a file in what it claims is $HOME but isn’t, it’s a recipe losing data!

I do think it makes sense for some apps, but IMO, it’s very much balanced towards the majority of apps not needing to make any of the snap folders visible, to the point making it opt in makes sense to me.

On Ubuntu Core where the home interface doesn’t get autoconnected and the portals won’t work, I can understand the need for a user-visible folder for the snaps internal $HOME, but elsewhere, I’d consider it an implementation detail that’s best kept hidden as far as reasonably possible.

1 Like

That’s a fine response for the cases where it applies, but snaps are not limited to applications that make use of XDG portals. If that was the case then indeed there would be no point in having any other isolated home directories for the application at all.

Even the most basic CLI app will have inconsistencies with home. Relative paths based on current working directory means that users often don’t notice the fact the snap has a different internal home to the host; so the illusion is mostly the same as the portals case. But it gets worse when you consider e.g:

snap run example $HOME/data

Bash will substitute $HOME with what the host sees, not what the snap sees.

I personally think it’s asking too much of the users for them to understand the technical justifications. If the packages documentation doesn’t explicitly mention to use ~/Snap, then they shouldn’t even need to know it’s a thing, and we should encourage hiding the technical details as much as possible. The opt in approach makes most sense to me here.

1 Like

My point is that many of the snaps I actively use don’t need this. For example, I actively use the lxd snap and the current data it’s stored in my home directory is a config file:

/home/james/snap/lxd/common/config/config.yml
/home/james/snap/lxd/23037/.config/lxc/config.yml
/home/james/snap/lxd/23001/.config/lxc/config.yml

I suspect they’d be absolutely fine with those files being moved to ~/.snap/data/lxd, and have nothing of interest to place in the new ~/Snap/lxd directory. The majority of the snaps I use are in a similar situation, since the only user data they’re storing is stuff that they’d stash in ~/.config or ~/.local/share if unconfined.

These snaps would just be adding noise under ~/Snap, and making it harder to find the data from snaps that do want to produce user visible documents. If ~/Snap is only populated by directories with a purpose, then it is going to be more useful to the user and the snaps that opt in to using it.

2 Likes

I understand your idea: only have it when it’s relevant. That sounds like the perfect solution indeed. Except, that’s a bit thin as an actual design plan. Hiding everything until people find out that they cannot see the files? Okay… so people enable the flag once someone files a bug that they cannot find normal application files that are supposed to be visible unless they dig inside ~/.config. What’s next? File a bug, and wait for the package maintainer to notice and the app to be updated? Eventually, app gets updated, then how would that work? Do we move files around under the application to expose them? What do we do with the paths that were previously set in the application configuration? How do we tell the user that application files are moving around? What if the application hides it again?

Again, I can definitely feel empathy for the idea of only displaying things when they need to be displayed. But we need something a bit more clear in terms of plan.

TLDR, I like to put some of my thoughts and probably unrelated preferences here while skimming the thread…

  • In my expectations user’s snap data should be under ~/.local/snap, following the existing file hierarchy traditions
  • I don’t really like applications that believe creating a non-hidden directory for their own purpose in my home folder is a good idea, a ls ~ command should only show the standard user directories and items that I created on my own, nothing more.
  • If there’s a need to create such a folder for accessibility or other reasons, it should be an opted-in option and the path should be customizable by the users.
  • Perhaps making an extension of some sort in the file manager application that presents the data without actually making the directory structures would be preferable
  • Perhaps a FUSE filesystem specifically used to present such information on an arbitrary directory would be preferable, without making the actual directory structures.

My 2 cents.

2 Likes

Most people commonly have visible folders in their home directories that applications make use of all the time. Hopefully we can agree on that? Okay, so with that aside, when we attempt to isolate applications from one another, the reasons why such folders are relevant are still there. What we’re trying to do is to have a middle ground where we bridge a world where applications were commonly reading and writing on such visible space, with a world where applications are isolated from one another. Eventually we’ll have better ways to handle this situation, and we’re working on that as well, but that’s a separate topic. Right now we’re trying to find that middle ground so we can improve security and privacy while having these use cases into account still.

1 Like