Please auto-connect removable-media to the following snaps:
Published by me:
Note: I’m part of Snapcrafters, but these are published on my own account. The source of these snaps is in the snapcrafters GitHub organization.
PhotoScape is a photo editor and viewer. This app is very mature, has existed for decades on Windows and runs on Linux using Wine. The number of users of the snap has decreased a lot because the snap was not working for a long time, but I recently rebuilt it using much more robust tooling and it’s now at 7,931 weekly active devices and slowly climbing. Viewing and editing photos on removable media is common for artists. https://snapcraft.io/photoscape
Arduino is a mature and well-known IDE. It opens source code files from removable media. Storing these on removable media is common in lab environments https://snapcraft.io/arduino
S4A is another IDE which also opens source code files from removable media. It is mature in the sense that it has not been updated since 2016, but the current functionality works well without any issues. Not a well-known app, just less than 1000 installs. This app is specifically targeted to children, to help them learn about robots. https://snapcraft.io/s4a
Published by the upstream developer with me as a maintainer:
Krita is the full-featured digital art studio. It is common for graphical designers to store images on removable media. Very mature and very well known. https://snapcraft.io/krita
Foliate is an e-book reader which displays books on removable media. Well known. I wouldn’t call it mature but it has existed for a few years now, works well, and the developer is constantly improving it. https://snapcraft.io/foliate
All applications, apart from PhotoScape, are open source.
As per the updated requirements for auto-connect of removable-media all of these applications fit within the viewers / editors category. For the first 3, whilst the publisher is not the upstream for any of these, they are a member of snapcrafters. For the last two, ideally this request should come directly from the publisher themselves but since the requester is a listed collaborator for these snaps, again this meets the requirements.
As such, +1 from me for auto-connect of removable-media for photoscape, arduino, s4a, krita and foliate.
+1 for auto-connecting removable-media for photoscape, krita and foliate since they meet the requirements for ‘media editors’ and the publisher criteria is met.
IME, arduino and s4a do not meet the newly defined requirements since ‘source code’ does not constitute sound, photo, or video files. @alexmurray - can you provide more detail on your vote for these?
@galgalesh - removable-media is a potentially sensitive interface as documented in our processes. Can you provide more details on why we should override the user’s voice on install for arduino and s4a instead of the snaps using one of the manual connection mitigations? (The justification of lab environments could be used for any number of applications).
@jdstrand Quick question: both Arduino and s4a already have access to raw-usb for different reasons, so technically, they can already access removable media if they want to do so for nefarious purposes. Does this factor into the decision at all?
I did not register the absence of “source code” in the requirements.
The reason why I ask for the auto-connection is because the Arduino IDE and S4A are often used as an introduction into computer science and electronics. I think that for this audience, the current user experience of manually granting an application access to removable-media not acceptable. Mainly because it is not discoverable what goes wrong and how a user can fix the issue when they try to access removable media.
I do not believe it is common for S4A and Arduino to access or change files on removable media, so you can argue that the privacy issues are more important than the occasional bad user experience. This access might be common in some lab environments, but in that case the computers will be managed by an IT admin who hopefully knows how to grant this access.
That’s an interesting point and could be considered by @reviewers. This is part of the problem with transitional interfaces: they allow too much. Personally, on principle I think we should be considering the interfaces on their own terms since that allows us to be consistent across the ecosystem. That doesn’t mean there can’t be exceptions.
Well, but your snap is able to use ‘snapctl is-connected’ and advise the user which while it may not be a perfect UX, it doesn’t necessarily mean it has to be bad UX.
Anyway, we have a voting process and other @reviewers will vote (ie, it isn’t ‘up to me’, though I will occasionally remind people of current processes). I’d like to hear what others say about this, since there are extenuating factors like raw-usb and that these are teaching tools (perhaps @pedronis wants to weigh in on educational software wrt removable-media auto-connection).
@jdstrand, I don’t see much semantic difference between viewing / editing source code to viewing / editing images / media etc and so to me the distinction seems unnecessarily arbitrary - hence my +1 vote.
@alexmurray - when we discussed expanding the criteria for removable-media, we did make a distinction for ‘media files’ since, in part, common use cases are such that media files are expected to live on external media (we intentionally did not cover other file types). That doesn’t mean that we can’t expand the list, but ‘seems unnecessarily arbitrary’ doesn’t meet the review criteria and IMO that rationale does not outweigh the user’s voice (from our agreed to review processes: “by definition data that is not always present (as is the case with removable-media) is optional access for typical snaps. All snaps with this interface connected have unrestricted access to all data from any plugged media. Considering that removable-media may contain sensitive documents, sensitive pictures/media, encryption keys, etc and that snapd has no insight on the nature of the data, the user’s voice with regard to connection is preserved”).
IME, source code files are not something that in the general case are expected to live on external media, and as such, I’m opposed to adjusting our processes to include them. @pedronis, as architect, can you weigh in on whether or not we should add ‘source code files’ to be listed alongside ‘media files’?
For the specific case of arduino and s4a, perhaps we can make an exception, but if we do, IMO, the justification should be that typical uses cases for these snaps is that the source code will live on removable-media for an important class of users for these snaps (ie, students in the classroom). In talking through this, I’m now voting +1 to auto-connect for arduino and s4a specifically.
Since these snaps have been characterized as “an introduction into computer science and electronics”, I put forth the idea that perhaps we can generalize a use case for our processes to include “educational software” (perhaps with “used in teaching environments”) with the justification that a common use case for the software is the classroom where students are expected to save their files on removable media. @pedronis - can you comment on this proposed general case?
the categorization relates to media being often large and often coming/being from external media. It’s not related to the types as such, but common usage patterns around them.
@jdstrand@pedronis - thanks for the clarification - on reflection I agree that we should evaluate requests from an end-user use-case perspective, rather than the more shallow approach I took above (re file-types etc). I agree that perhaps adding an additional use-case around educational software would make sense to me.
@jdstrand 9 days have passed since the last reply. Do we have enough votes for Foliate, Krita and PhotoScape? (Foliate has a popular open issue about this)
Any update on whether education software should be added to the categories?
+2 votes for, 0 votes against auto-connect of removable-media for photoscape , arduino , s4a , krita and foliate. This is now live for photoscape , arduino, s4a, krita, and foliate however I notice now that s4a currently does not plug removable-media (I have however updated the snap declaration to allow this so that future uploads of the snap which do plug removable-media should get auto-connected on install).
