How would you address this?

By default the Wayland compositor should not allow any app to take screenshots without being asked for a permission through xdg portals before.

For this case I assume two things (I could be wrong here though):
1) As a KDE Plasma core component Spectacle is allowed to to take screenshots with permanent permission by default.
2) Spectacle's --nonotify option is a very niche feature that is only used by few people who know what they are doing (for example using it in scripts).

I would suggest to eliminate this feature from Spectacle.

The feature could be put it into a separate app which is not allowed to take screenshots by default. The separate app would have to ask the user first to give permission for taking screenshots in the background.

In the past we had Spectacle going through the screenshot portal but the UX was awful:
1. Launch Spectacle
2. Click one of the "Take a screenshot" buttons
3. Get prompted by the portal to allow this, and also to select what kind of screenshot you want all over again

It was terrible, especially for the case of launching spectacle to via a global shortcut to take a screenshot quickly. The UX was simply unacceptable for an app whose only purpose is to take screenshots. It's for that reason that Spectacle currently uses a private protocol to talk to KWin.

Now, I would like it to eventually be ported back to use the portalized screenshot system, but only once we can ensure an adequate UX that doesn't prompt the user to confirm doing what they just explicitly said they want to do. As a result no actual security wold be gained by this as Spectacle would either be whitelisted by the system, or allowed once by the user with that permission being remembered over time.

Now, I do get your point that the existence of the command-line interface for spectacle means that any app with access to run shell commands can secretly take screenshots without the user's permission. That's true, and it's a theoretical security risk.

However the interface is also useful for users automating their own workflows. We can't prevent the users from doing something useful simply because it *could* be abused. This would be like nailing someone's windows shut to protect against the threat of someone nefarious climing into an open window. That's not real security.

As such I'm quite dubious about this suggestion. If your threat model involves untrustworthy local software having shell access, you have already lost the battle.

But I'll let Noah the maintainer decide what to do from here.

While you might be notified, it would still possible to take a screenshot without your consent and do something with it using the --background option or DBus API. This also applies to GUI mode if you have the "Save to default folder" option checked in the settings dialog. I'm not sure if it's possible for a background process to send synthesized keystrokes to the compositor to do a global shortcut.

The fundamental issue in the situation you described is that you can start a program capable of doing nearly anything in the background using other programs without getting consent from the user. You could also start a program that copies documents to some place on the internet or deletes nearly everything in the Home folder without your permission. I don't think this is an issue that can or should be addressed by removing the --nonotify option.

I get your point that an app which already has shell access could do worse things than taking screenshots without consent from the user. Especially since we don't have a standard sandboxing mechanism for apps in Linux by default at the moment. However I would have preferred that Spectacle at a minimum would inform the user by a notification indicator when a screenshot is taken in the background.

Wayland / Portals seem to be designed to slowly transform Linux desktops in the direction of separating applications from one another step by step. Maybe we'll get there some day.

I can understand your decision to close this request for the moment. Thank you both for your detailed answers.

To be clear, if there was infrastructure for a more comprehensive solution that spectacle could adopt, I would not oppose that. I just oppose removing this option for the reasons already given.

I appreciate your understanding.

FWIW the sandboxing and portals systems seem designed to support a use case where we can't necessarily trust our own apps, more akin to the Google Play store on Android. However from my perspective this is ceding most of the field before battle has even been joined. If we can't prevent the user from installing actively malicious software on their system, I think we've already lost. Android shows us what this world looks like: 99% of the free apps on the Google Play store are garbage that's at best only mildly user-hostile and at worse is using every dark pattern in the book to try to harm you. Even the strongest sandbox is no protection at all for local software that can trick the user into giving it permission to do whatever it wants.

This approach passes the buck by saying, "well, I told you there was a risk, you you clicked on the Accept button anyway!" But it should be obvious that this is not an effective system for truly protecting the user. We have decades of experience to show us that regular people will click on anything, won't read dialogs, don't understand digital risks, etc. Putting the responsibility on them is wrong.

Personally I think what we should be striving for us to keep actively bad software out of our apps stores and software repos in the first place, and therefore off the devices of casual users who are least able to manage the risks of malicious apps.

But this is a much larger topic. :)