Hello I’ve created the lyrcfier snap (https://dashboard.snapcraft.io/snaps/lyricfier). It requires a connection to mpris dbus with Spotify. Actually I’m running (and asking users to run):
auto-connecting lyricfier to spotify is interesting because we’ve not quite had this request before.
Because interfaces form a contract between the providing snap (the slot) and the consuming snap (the plug), the provider generally needs to make some sort of a promise that it won’t break consumers. In the typical case like, for example, mir or network-manager, they provide sockets or DBus APIs via their slot declaration and as part of the review process for snaps that provide the slots, there is a discussion and agreement that the publishers won’t intentionally break clients.
The mpris interface is interesting because:
a) it has historically been meant for the slotting application to integrate with the desktop environment so that, for example, play/pause, previous, next, etc widgets in the (unconfined) DE can drive the application
b) the mpris DBus API is stable and shouldn’t break so long as the providing snap continues to provide the slot
c) snaps are allowed to slot the mpris interface without triggering a manual review (so long as the mpris name matches the snap name)
‘b’ actually was the justification for implementing the mpris snapd interface to support snaps connecting to the slot (and why snap connect works for you now). While ‘b’ is also a point in favor of auto-connection, ‘c’ is the problem. The spotify publisher has not said that they plan to provide the mpris interface to other snaps or to not break them. Granting an auto-connection would be premature until spotify agrees they plan to support consumers of the slot (ie, agreeing to not remove the slot or to change its API, etc).
-1 to auto-connect at this time. If someone wants to reach out to spotify and they agree to support per-snap (or global) auto-connections to its mpris slot, then I would vote +1.
Thanks for the long explanation. There is any other alternative to get the current song from Spotify?
I can understand the argument against auto-connect request for this case but I can’t hide a very frustrating developer experience creating the snap. I’ve spend literally long hours trying to get the package right hitting different strange problems and I don’t think that my app is doing anything too complicated or dangerous.
Anyway thanks again! And I will research more options.
@emilio - please note that I am just one vote. Other reviewers will weigh in. Even if they agree with my assessment, the door is still open for someone to approach spotify (perhaps @advocacy?) and go from there.
Lastly, you might want to see the section ‘Manual connection mitigations’ in Process for aliases, auto-connections and tracks for ideas on how to improve your snap. Alerting the user at runtime that the interface is not connected is useful even with auto-connection since it provides a better UX if the user uses snap disconnect.
What you’re saying here makes sense, @jdstrand. However, I can’t quite reason how this logic applies only to autoconnection and not to the mpris plug in general. If we’re concerned about a given snap not continuing to provide a slot, why allow connection to it at all? Doesn’t the mere use of a slot imply that the user is hoping that slot sticks around? In this case it feels a bit odd to say that we’re cool with your users connecting to a slot that may disappear, but we’re not cool automatically connecting it because it may disappear. How are these cases significantly different?
Maybe I can answer my own question. If I run sudo snap connect <snap>:<interface> <snap-that-doesn't-have-interface>:<interface> I get an error. If I try to install a snap with an interface that automatically connects, and the slot has disappeared, what exactly happens? Will the install fail? Or will the interface just not be connected? If the former, then I agree, -1 to the autoconnection without spotify saying that it will stick around. If the latter, I’d like to hear your response to what I said above.
In my opinion, if the install fails then this is a bug and should be fixed and should have no bearing on whether we would agree to allow this or not. I tend to agree with @kyrofa that I don’t see much of a distinction between a snap ceasing to provide an interface and choosing to auto-connect it or not - mpris is a dbus interface with a known API and if a snap is able to slot a this interface in the first place without any guarantee that it actually provides this interface then I don’t see why would would try and worry about that for declaring auto-connect for a snap which wishes to plug it.
If we do care about this, then perhaps the onus should be on the store to try and ensure any snap which slots such an interface actually does provide it… otherwise I don’t see there is much point worrying about it.
As such, +1 from me to auto-connect lyricfier:mpris to spotify:spotify-mpris
It should not fail install (there is simply no candidate to connect and therefore auto-connect).
In terms of the original question, this all comes down to the fact that interfaces are contracts between the slot side and the plug side. In the normal case, to be a slot means to provide something to any snap that may plug it. We have several mechanisms and patterns to inform our processes and snap declarations.
For privileged slot services that should typically manually connect (eg, network-manager), we a) as part of process request that the provider’s publisher make a statement that they will not break consumers and b) issue a snap declaration allowing connection.
For unprivileged slot services that should typically auto-connect (eg, mir), we a) as part of process request that the provider’s publisher make a statement that they will not break consumers and b) issue a snap declaration allowing connection and auto-connection.
mpris falls outside of these patterns because while we don’t allow auto-connection, we will allow connection provided the snap uses the defaults for the mpris interface, which grants use of org.mpris.MediaPlayer2.<snap name> without manual review. Why did we implement it this way? Because binding to the well-known DBus name is a ‘providing’ action (it is just a specialized form of the ‘dbus’ interface really) and the mpris DBus is meant to be used by other applications. It is a slot by any reasonable definition and there didn’t seem to be any reason to deny snaps access to this standard API. We also knew that we wanted users to be able to connect controllers to snaps providing the mpris interface without needing the store to be involved (keep in mind, users who can snap connect are admin users and can modify the system in arbitrary ways).
The key point in my mind is that connection vs auto-connection for mpris is the only mechanism we have to express “you can connect it, but no promises” vs “we’ll let you auto-connect because the publisher says that you can trust it will work”. If we simply grant the auto-connection without talking to spotify, we as reviewers are making the promise that plugging snaps are good to trust it, but we aren’t in a position to make that promise. Conversely, as reviewers we’re saying to spotify that all plugging snaps are fine to connect, when we have no idea if that is true or not (perhaps they don’t want to expose the API to everything by default).
This particular request is for a particular lyricfier snap (as opposed to all snaps) to auto-connect to spotify, but as reviewers we can’t promise to lyricfier that spotify won’t break them and we can’t promise spotify that lyricfier won’t abuse the privilege of auto-connection.
I maintain my -1 to auto-connect until such time that spotify publishers comment that this intend for the mpris interface to be stable for snaps to use. IME, they are free to make the choice on a snap-by-snap basis or for all snaps.
do you have security concerns as well? it seems your main concern is about possible breakage from the spotify side. I notice that this snap purpose is to work with spotify ATM, afaict from just reading its description it will not really perform any function without it.
I don’t have security concerns per se with mpris in general since the application should be using common libraries for these APIs that would hopefully be addressed by stage-packages and rebuilds, but see below.
My concern is subtle. The mpris interface exposes a slot (since it is a DBus service) and there is a contract between slot providers and plugs consumers, but as far as we know, spotify is only using the mpris interface so that the desktop shell can drive it and not for other consumers to use it (this is in contrast to say, the docker interface where the slot provider is very much intentionally providing the docker service to consumers and the snap publisher of docker must request use of the interface to provide this service). spotify has not requested or otherwise stated that they want 3rd party snaps to use this interface, so there is no contract between them and consumers: spotify is completely within their right to remove the interface, breaking all consumers. If we grant auto-connection to lyricfier, we are in effect signing that contract that spotify won’t break lyricfier, but we are not in a position to make that claim (this is in contrast to implicit interfaces where snapd is specifically exposing the services for use by snaps and as reviewers we understand the snapd implementation and its intent and can sign that contract).
Getting back to the security concern, because we are not spotify, as reviewers I feel we cannot just declare that it is ok for everything to just connect to its mpris interface, for abuse or otherwise. We don’t know the implementation details of spotify and even if we did, we cannot presume to know what the publisher wants (there is an argument that since they haven’t asked for global auto-connect or otherwise, we actually should assume they do not want it).
Put simply, spotify has not requested that its mpris interface be globally (or in this case, snap-specifically) auto-connected so granting auto-connection on their behalf seems inappropriate.
(This is a rather interesting request in general and the rationale applied here will also apply similarly to the dbus interface (where we have not yet had a similar request, but could))
@emilio - please understand this is a somewhat abstract discussion. If it is decided that auto-connection should not be granted, our advocacy team (or similar) can reach out to spotify and see what they have to say for your or all snaps.
In general the main concerns about auto-connections are:
Security, if there is a security concern we want the user voice involved in making the connection
Stability, this applies more to providers though, in general if a provider wants to offer a slot for general auto-connection we expect some commitment to stability on their part. I don’t think there’s a clear cut argument like this for the consuming side because there’s a lot of reasons software might break and in general in the absence of security concerns we should try not to stop snaps to offer the same kind of experience as an unconfined snap.
There is an administrative cost, and in general for slots sported by application snaps is much cleaner/clearer to manage the connection from the slot side, instead of proliferating plug-side one-offs.
But there are some arguments being made here that sounds a bit too strong to me, in the sense that manual connection is possible and in general we don’t make promises to defend accesses to snap slots from the unconfined world. If a snap has a mpris slot it might get connected to by other things that can.
I think there is though some security concern here, in the sense that private information is acquirable over the connection, that’s kind of the point afaiu.
So because of this and the administrative cost considerations, I think manual connection is still the best trade-off.
.