Hi designers,

on my quest to make the lock screen secure I stumbled over inhibitions. Any application can inhibit the lock screen from activating. That's quite useful as we don't want the lock screen to come up while watching a video. On the other hand it also introduces a security issue: a user might expect the screen to lock, but it never will and he cannot figure out why.

I want to make the inhibitions accessible to the user. What I have in mind is a plasmoid in the systray which gets to active state (shown in the list) whenever the lock screen gets inhibited. When you click on it you see the inhibitions. We know the "Application name" and a "reason". That's something like "VLC"/"Playing video". Listing the inhibitions is one thing, it should also allow to disable an inhibition or to enable an inhibition again. Maybe even add an easy way to inhibit directly from there.

What I would like from you are mockups for this idea. And of course also your opinion on it

Isn't this functionality partly in place in the power settings plasmoid? I believe VLC at least shows up there stating that the machine will not enter standby.

veqz wrote:Isn't this functionality partly in place in the power settings plasmoid? I believe VLC at least shows up there stating that the machine will not enter standby.

Yes, but only for power management inhibitions, not for lock screen inhibitions.

Although power management inhibition and lock screen inhibition are technically distinct, I'd assume that from a user's perspective, they are closely related (both prevent the computer form doing things automatically while they run), which is why it makes sense to unify their presentation, especially since presumably it's in most cases the same applications that inhibit both power management and screen locking.

The presentation of power management inhibition works quite well and should work just as well for lock screen inhibition, except that the battery Plasmoid would not be the right place to show it.

My suggestion would therefore be to create a general "inhibition" Plasmoid (we should look for a better name) which lists applications that currently inhibit power management and/or screen locking, in the way that the Battery Plasmoid currently lists power management inhibiting applications. It should only be activated if automatic screen locking is active, of course.

colomar wrote:My suggestion would therefore be to create a general "inhibition" Plasmoid (we should look for a better name) which lists applications that currently inhibit power management and/or screen locking

That's a good idea! It also solves the technical problem that powermanagement inhibits the lock screen as soon as power management is inhibited. That's technically not correct, but whatever (just because I have my download running and don't want to have the system suspend, doesn't mean it shouldn't lock the screen). With a common list it could also list what inhibits the screen locker through power management.

That entire thing is a bit of a sad story. Theres a gazillion of interfaces to inhibit power management.

The standard freedesktop Inhibition interface which most 3rd party applications use, only supports all or nothing, meaning during a download in your browser the screen will stay on. While it's great that the lock screen doesn't kick in while a video is being played in your browser, it's quite unfortunate that a download also prevents this. KDE's own interface can distinguish between "just keep my computer running" (for music or downloads) or "keep everything on".

Also, I didn't find a way to tamper into logind inhibitions. I can ask it for current inhibitors but it doesn't have a change signal which I currently use to track and list inhibitions. However, I think the logind stuff is only relevant for suspend, so the system delays a request (eg. until the screen is locked or your IM accounts are disconnected), whereas the automatisms you could override there are handled by PowerDevil anyway.

Nonetheless this is something I've been thinking of ever since I started showing inhibitions in the battery monitor - a way to prevent specific applications from blocking powermanagement. I could imagine a list of applications that currently hold (or did so in the past) an inhibition where you can temporarily clear (until the app asks again) or permanently prevent an inhibition.

In fact, I locally played around with a patch to allow activities to prevent PM inhibitions, so you can have a "watch a movie before going to bed" activity where nothing will prevent the computer from turning off after 30 minutes.

Preventing inhibition would be the logical next step, yes.
However, even without being able to prevent the inhibition, it's still useful for transparency's sake to show what inhibits what.

so you can have a "watch a movie before going to bed" activity where nothing will prevent the computer from turning off after 30 minutes.

Hummwhat?
Either you
a) finish the movie, STR and go to bed
b) booooring! go to bed or fall asleep in front of the screen - movie runs out, some time after, the system suspends
c) watch Tv (ie. the movie never ends) *in* bed and want to STR in 30 minutes (for you're not longer withstanding the political talkshow running)

Only in case of (c) it should be necessary to break STR and you probably won't think "oh, I'm now gonna watch boring tv until I can no longer keep up so I change my activity" but at some point "uaaahhhhh - idiots, kaiwannasleep compiplease sleepsoonaswell" - you need a way to break inhibition for the Tv (since maybe there's more from a file download?) and just STR in ½h.

The biggest issue I see on the entire topic is btw. that the typical inhibitors will be fullscreen windows - there's no persestent UI to indicate the state nor some to toggle it...

luebking wrote:Hummwhat?
Either you
a) finish the movie, STR and go to bed
b) booooring! go to bed or fall asleep in front of the screen - movie runs out, some time after, the system suspends
c) watch Tv (ie. the movie never ends) *in* bed and want to STR in 30 minutes (for you're not longer withstanding the political talkshow running)

Only in case of (c) it should be necessary to break STR and you probably won't think "oh, I'm now gonna watch boring tv until I can no longer keep up so I change my activity" but at some point "uaaahhhhh - idiots, kaiwannasleep compiplease sleepsoonaswell" - you need a way to break inhibition for the Tv (since maybe there's more from a file download?) and just STR in ½h.

Good points, but let's discuss those further when we're at that point and keep the discussion on informing about inhibition for now.

The biggest issue I see on the entire topic is btw. that the typical inhibitors will be fullscreen windows - there's no persestent UI to indicate the state nor some to toggle it...

True, there's not much we can do about full-screen applications. Then again, I don't see those as the big issue, as I don't think many users will want their screen to be locked while watching a movie full-screen, anyway. What I'd worry about more are non-fullscreen applications which still inhibit screen locking. Do we know of any such applications, or is this actually a non-issue because really only fullscreen applications inhibit screen locking anyway?

Things that are gonna inhibit screen locking / str are typically video players (download managers really should inhibit str, but that's another matter), because it is *the* case where you sit in front of the system without actually interacting with it.

They come in both flavors, fullscreen and windowed.

An epic trap may be if the video player sits in that (lots of swearing here) systray and doesn't actually play anything, yet still inhibits screen locking.
The question is whether this can be sufficiently indicated by yet another icon in that (more swearing) systray.

Finally, that brings me to ask whether "might expect the screen to lock" is any good security approach at all. It's rather insecure by design. (You leave, 5 minutes later the screen will usually lock and Dr. Evil will of course *never* try to access it during *that* time)

- If you want the system to lock on STR, inhibitors can safely be ignored. If its ok to STR, locking is ok as well.
- If you leave the system in an untrusted environment, you better lock it explicitly (button, usb key, blutooth) *before* leaving it.
- If you *forgot* to lock it in an untrusted environment, the timer *may* bail you out, but how reasonable is it then that you did not forget to check whether it's maybe inhibited?
=> would that "plasmoid" not have to be a fullscreen warn signal across your desktop?