Kdenlive removable-media

Please add removable-media to the connections for kdenlive snap

1 Like

There are many KDE applications without permission for external disks, I had filed an upstream bug, but it has remained unresolved.

https://bugs.kde.org/show_bug.cgi?id=406413

I’m going over these now.

Can store admins say if I need to request these are added separately or can I give a list here?

It’s unclear to me precisely what this means so I’ll answer in a way that I hope addresses your question. :slight_smile:

You are free to plugs removable-media in any snaps you wish. Plugging the interface does not trigger a manual review and there are no snap declarations needed to use the interface.

For auto-connecting, we don’t grant auto-connect for removable-media since the access is almost always optional and we want to preserve the user’s voice so forum requests are needed where you feel the functionality is required.

If you have just a few that you want to auto-connect, the I suggest filing different topics for each. If you have a lot and several have identical, specific requirements, then we can try out having you create forum topics for each group of applications. Please be sure to read through both “auto-connection request considerations” and “Manual connection mitigations” in Process for aliases, auto-connections and tracks before doing all the legwork with the forum requests. If you have questions about those sections, feel free to ask them here and we can discuss before you submit more forum requests.

@jriddell ping - this request is waiting on your response to @jdstrand comment above, thanks.

I’m quite confused at this, we make desktop software and people expect to be able to open and save their files from their home directory and from removeable media. Not being able to is quite a feature regression compared to every other way to install and run the apps.

1 Like

The home interface is auto-connected.

removable-media is manually connected for the reasons outlined in the aforementioned doc: Process for aliases, auto-connections and tracks. As mentioned, for applications whose core functionality is dealing with removable-media, we can issue snap declarations for auto-connections. For other cases, users are free to connect the interfaces themselves and have access to removable-media, and the aforementioned doc has strategies for publishers to use today to guide users, with plans for the improving the system going forward.

I believe we should allow removable media auto connection for some types of applications and/or publishers, like this case here. Having to manually do this (if and after the user realizes it does not work) is a major impediment to a smooth user experience.

FYI, as discussed elsewhere, Process for aliases, auto-connections and tracks was not as clear as it should be to describe the current situation. I’ve hopefully addressed that just now.

We don’t yet have a definition of “some types of applications” so we ask publishers for the reasoning to auto-connect and weigh that against the criteria and thought processes in Process for aliases, auto-connections and tracks. Once there is a class of applications, we would update the criteria (like we did for joystick).

As for the smooth user experience, there are things today that publishers can do to provide a smoother experience (again, as listed in the aforementioned topic) and there is future work for snapd to improve the developer experience in this regard.

Do note there are also discussions related to removable-media here: Opera requests auto-connect to removable-media

@jdstrand

I agree that removable-media gives an application access to sensitive data, and that user choice is important here. However, I disagree that removable-media gives access to more, or more sensitive data than home does. With the danger of throwing oil on the fire; I always assumed removable-media was not auto-connected to prevent cryptolockers from encrypting backups and to prevent the spread of viruses using USB sticks, because I cannot understand why removable media would be more sensitive than a user’s home directory.

I do not think I have ever had a situation where a removable drive contained data that is more sensitive than my home directory. This might be the case in some enterprise environments or for very specific power users. However, in that case, the person or the admins can easily disconnect removable-media. The opposite is much less the case: a regular user who just wants to read a PDF on their USB stick using Okular will just think something is broken.

As an example, Ubuntu is used a lot in my research group, and we often get papers from conferences on USB sticks. These people know very little about what a snap is, and they have no idea why they can’t open a PDF on a USB stick in Okular.

Why the workarounds are less than ideal

Let’s look at the workarounds.

  • use a newer, safer API. Eg, instead of using cups-control, the application could use the Printing portal. If an application needs access to a file from a disconnected interface/etc, use a file dialog that supports portals

In this case, the app should use the xdg desktop portal file chooser. This is a good solution when it works. This “almost works” for a very long time now, but it still doesn’t. Until this works on every supported desktop distro by default, it can’t solve the removable-media problem.

  • have the snap check if the interface is connected via snapctl is-connected <iface> and instruct the user to use the snap connect CLI command or connect via the snap-store/gnome-software GUI.

First of all, instructing users on how to grant the permissions without using the CLI is very hard. Since snaps are cross-distro, we can’t assume gnome-software is installed. Snapd could make this easier by having some “permission-request” command which pops up a GUI where users can grant permissions. Smartphones have something like this and the desktop portal tries to replicate this.

Second of all, when should the app request the user to grant access? In the ideal scenario, the access is requested only when the action is taken. Again, the desktop-portal does this well and in many cases this works without having to write snap-specific code in the application. However, it doesn’t work on every supported distro.

  • So the first option is to modify application code to check whether the user wants to access removable media, and then prompt the user to run a command. I do not think it is acceptable to force developers to write snap-specific code.
  • Or you create a wrapper, which checks if removable-media is connected when the app starts, and requests access if it’s not. As a result, the permission request comes without any context. Will the application work without this permission? Why does it need this permission? I suspect that if many applications do this, users will learn to just grant the application permission without consideration because they noticed some applications don’t work correctly if you don’t grant them that permission.
  • fallback gracefully. Eg, if password-manager-service is disconnected, fallback to storing passwords locally

Not really an option for removable-media. When a user wants to open video files on removable media, and Kdenlive can’t access them, Kdenlive is broken for them.

So as a result, none of the workarounds actually give a good user experience, and we have the risk of teaching users to just grant every app whatever it requests. (The Windows Vista effect, basically)

Solutions

The best solution is to make sure the file access desktop portal works perfectly, and works everywhere. From what I’ve seen, it would be possible for the KDE snap launch script to make sure KDE/qt apps use the XDG-desktop-portal to open files. This is already the case for Flatpaks afaik. However, this means the xdg-desktop-portal support must work on every desktop distro supported by snapd. This is not the case at the moment, so we need an intermediary solution.

I personally think every desktop application should have access to removable media until the xdg-desktop file portal works correctly everywhere. There are far more people who use external devices as if it was their home directory than people who store data on external devices which is more sensitive than what’s in their home directory. Just treat removable-media like the pulseaudio interface. Stop auto-connecting it once there is a good alternative.

However, people have been asking this for years, and your views will probably not change, so I have a counter-offer: At the very least any application whose primary purpose it is to display or modify files specified by the user should get access to removable media. This includes

  • Document editors and anything like Libre/Only/WPS/MS-Office.
  • Video and Photo editing software
  • PDF readers, ebook readers, markdown viewers, …

Do note, however, that even this proposal still “breaks” the use-case of people who use external media as if it was their home directory.

1 Like

Home auto-connecting is a different topic that has been discussed elsewhere. It only auto-connects on classic distro for transitional reasons and is a different use case than removable-media since home is expected to always be present when removable-media, by definition, is not. People are discussing if removable-media should be treated as transitional and other options, but the fact that home, gsettings, unity7, desktop-legacy and x11 all auto-connect but give away too much isn’t justification that another interface should too.

For the record, this was an exceedingly painful behind the scenes transition to provide a regression-free experience. That isn’t saying it can’t be done, but I would advocate strongly for putting those engineering resources into improving the current situation.

After several discussions between snapd architects, security, advocacy and other reviewers, we’ve updated our removable-media criteria in our processes.

Applying the new criteria to this request, kdenlive is a well-knwon, mature video editor. The snap’s publisher is a long time developer within KDE and known to the snapcraft community. Granting auto-connection. This is now live.