I understand the logic behind this, but I feel it’s quite misleading. Accessing local music is literally the purpose of the app, and the Music folder starts out unpopulated by default; the only users who add anything to it are users who use local music players.
Yes, we could prompt the user to find their music folder on first launch to make the portal system to remember it, but this would worsen the UX by adding a hurdle for non-technical users to succeed at jumping over before they can use the app. Such a thing would also feel pretty stupid IMO:
App: “Where’s the music folder?” [shows a dialog window with “Music” already visible in it] User: “Uhh it’s right there. Wow this app is dumb.”
IMO whitelisted access to standard XDG dirs shouldn’t be considered a security problem.
Another issue is that the app is called out as having microphone access, which sounds scary. This is not something I specifically added, but rather it hitches a ride on the pulseaudio permission which is required for playing audio — another core function of a music player! So as I see it, there is no way to remove this warning without destroying the app’s core functionality. Needless to say, this feels unfair.
Same with Network permissions since you can’t very well listen to online radio with network access, right? I mean, sure, in the abstract, connecting to the internet could allow a malicious app to do nefarious things — but this is a verified FOSS app by one of the oldest mainstream FOSS organizations in the world that literally has the term “online radio” in its summary to alert users about what kind of network content it’ll be accessing. Does none of that count for anything in the safety classifier? That also feels unfair and misleading.
Overall I’m not sure what we’re going for here. The permissions model seems designed to scare non-technical users away from every app that’s not a toy.
In general, I agree that the labels are overreaching but some of it is more nuanced.
There is no such thing as microphone access that’s the website mislabeling the PulseAudio socket.
The permission isn’t completely safe either as it allows full audio input, output playback, ALSA devices, pulseaudio modules access but there is no such thing as “Audio portal” yet. So it’s “safeness” is up for debate.
I can tell Elisa in this case is safe with the added context that it comes from a trusted vendor and is verified etc. but the website is making an objective judgement here.
Same with Network permissions since you can’t very well listen to online radio with network access, right?
The same goes for this too. Without the added context these permissions cannot be considered fully safe. I can say Firefox on Flathub should absolutely not be marked unsafe for using “Network” but I can’t extrapolate this “trust” to every app on Flathub.
If we start marking it safe for one or two we have to do it for every app, then there is a high chance a scam/malicious app pops up that uses the seemingly benign and “essential” network permission (marked safe with “green”) for some evil activities. Then that puts the website in a weird position as it it didn’t warn the user about it before installing.
The issue with the labels was discussed before in the matrix rooms. Two suggestions popped up were
Remove the red/yellow/green safe/unsafe labels and make it more like Google Play Store which just lists the permissions and doesn’t “judge” them
Allow reviewers/admins to override it for “trusted” apps manually. Apart from scaling issues, this needs a bunch of work because we need to expose these manual “overrides” so that downstreams like GNOME Software and KDE Discover etc. can choose to use them.
Remove the red/yellow/green safe/unsafe labels and make it more like Google Play Store which just lists the permissions and doesn’t “judge” them
I just noticed that this is what Discover does right now too. The current UI and wording of the safety ratings on the website are mostly 1:1 and kept in sync with what GNOME software does.
I can sympathize with the position you’re in on the subjects of audio and network access, but the problem is that there’s no actionable way for the developer to turn them green. That means the decision to mark them with a lower level of safety amounts to a decision to mark entire classes of apps as inherently less safe than other apps, which simply doesn’t feel right. It cheapens the concept of safety, and people will start to ignore it.
Presenting a flat list of permissions seems like a good plan IMO, yeah. And indeed, we do that in Discover to avoid having to wade into this thorny issue. We have some thoughts about doing it anyway, but rather than separating the “safety level” from the “community trustworthiness level” as Flathub currently does it, we’d combine them into one. You can see some of our thoughts at Assign apps a safety rating using an at-a-glance "safety scorecard" (#16) · Issues · Plasma / Discover · GitLab. The basic idea there would be that broad permissions aren’t ipso facto a problem unless the app has some combination of other compromising traits, such as not being sandboxed, being proprietary, or being unverified.
but the problem is that there’s no actionable way for the developer to turn them green. That means the decision to mark them with a lower level of safety amounts to a decision to mark entire classes of apps as inherently less safe than other apps, which simply doesn’t feel right. It cheapens the concept of safety, and people will start to ignore it.
Yea, I agree and it is not just these two but a bunch of other permissions don’t have a “portal” alternative as well.
This is probably better discussed in a GitHub issue on flathub-infra/website. Last time people were divided about both options and the discussion dissipated before something came out of it.
