https://bugs.kde.org/show_bug.cgi?id=497273
--- Comment #1 from Noah Davis <noaha...@gmail.com> --- Similar to bug 479184, not sure if it should be marked as a duplicate. I'm going to copy/paste some comments from that report that are relevant. (In reply to Nate Graham from comment #3) > 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. (In reply to Noah Davis from comment #4) > [snip] > > 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. [snip] (In reply to Nate Graham from comment #7) > 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. :) -- You are receiving this mail because: You are watching all bug changes.
