Hello,
Opera would like to have an auto-connect rule to the removable-media interface for opera, opera-beta and opera-developer packages. Users have complained that they can’t access files on USB disks and this auto-connect rule should solve their problem.
A test package is already updated to opera-developer’s edge channel (69.0.3625.0).
Thank you in advance!
Auto-connection is not typically granted for removable-media (Auto-connecting the removable-media interface for keepassxc, Auto-connection of removable-media for polarr?, Request: auto-connection of removable-media for chromium, Firefox - removable-media interface auto connect request) since users can enable this easily themselves.
-1 from me for auto-connect of removable-media for opera.
Looking at past requests, they were denied for legitimate reasons, but the replacement functionality isn’t there. I would say +1 from me, unless we can provide a trivial way for users to enable this on all platforms (i.e. not Gnome Software dependent or command line).
Define “easily”. Joe user who installed a browser because they saw a shiny button in GNOME Software now has an application which for an unfathomable reason (to them) can’t do a basic thing (load a document off a USB stick, of photo off an SD card) that they’ve been able to do forever in all other browsers. There’s no prompt, no guide, nothing which helps the user understand why they get the error, nor anything which points them to a place where they can fix the problem. Likely they will just think the browser is broken.
Even putting the snap connect line in the store page doesn’t help. People don’t read store pages, they click the button, install the app and expect it work - which is a reasonable expectation.
Please, can we figure out a better way forward for users than just rejecting reasonable requests for auto-connection in the hope that there might be some magical UI in the future to guide a user. Right now there isn’t, and it’s a super frustrating gap in the platform functionality.
@popey - please see the (updated) auto-connection request considerations and the section under it on manual connection mitigations. Snap publishers are in a position to do reasonable UX to guide the user on how to connect interfaces. I agree that snapd could make this easier for publishers and users, but we shouldn’t wait for “magic”-- if you have identified this as a “frustrating gap” (which I believe you are right to call it that), please raise this via snapd’s stakeholder process so the work can be prioritized accordingly (I suggest this conversation happen outside of the forum between you, @mvo, @pedronis and @Wimpress).
As store reviewers, we are in the difficult position of trying to provide both a curated store and a good publisher experience, but our voting process necessarily must make compromises at times. In this case, we have voted consistently in favor of maintaining the user’s voice (see aforementioned URL) for removable-media, even among similar requests for other browsers. I don’t see opera’s request as different from those. Considering that opera can choose to perform the items in the aforementioned page until such time that an even better experience is available, -1 for auto-connecting removable-media.
I strongly object to “(eg, consider a relatively common use case of a USB key with encryption keys on it; all snaps with removable-media auto-connected would have access to these keys).” in the auto-connection request considerations.
I’d like to see data to support the assertion that USB keys commonly contain encryption keys. I think there’s a certain class of user who does this. That’s not nearly as widespread as the guide suggests. Anecdotally I have around 50 USB keys around my house and none of them have or have ever contained encryption keys. I’d argue the vast majority of users use USB keys to contain data, photos, videos and documents.
I will at your request raise this outside the forum though.
This is meant as but one example as a hint to a reviewer that USB keys may have sensitive content on them (an albeit incomplete one) and not a justification for why removable-media is manually connected.
The reason why it is currently manually connected is because the access is by its definition optional for a functioning snap because the data may or not be there and when the interface was initially created, we felt that the user’s voice was paramount wrt connection because snapd cannot know what is on the removable-media (encryption keys example, sure, but USB sticks are used to move around NDA materials, used with air-gapped systems, might contain sensitive pictures or other content, etc).
It seems what is really being asked here is a reconsideration for why removable-media is manually connected, which is fine to discuss and I’ll respond to the other thread.
FYI, I rewrote the removable-media section to make the current situation clearer. Discussions are still ongoing wrt the larger point.
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, opera is a major browser from an official publisher. Granting auto-connection. This is now live (for opera, opera-beta and opera-developer).
Thank you very much for the help! It’s indeed working now. Also thanks for the link to the processes.