Open whitebyte opened 4 years ago
Another valid reason to split: when a Notebook is operating in a safe place, there is no need to lock the database when the session is locked (and is even annoying, e.g. on idle auto-lock), but when taking the Notebook away to a possibly unsecure location (i.e. closing the lid), the database should be locked.
I would also vote for this. Here's the current setting:
Actually, there is no need to have an option for "lid is closed" as the user can also control that per OS setting (lock or hibernate OS when lid is closed).
If you still want both parts of the existing option, I would split them up and let the user decide. Otherwise, I suggest to just omit the "lid is closed" part.
I also vote for this feature: "Closing the lid" could also mean suspending the computer. I loved the "Lock workspace when the computer is about to be suspended" feature from KeePass, it is the only option that I miss using KeePassXC.
Hello,
I also would very much like that this setting is split.
Most users will standby and then carry their laptop around or leave them unattended, which exposes the laptop to more risks than when working on them. At the other hand, I constantly lock my screen for security/privacy reasons (and this is a general digi-sec recommendation) even when I only leave for a minute. In this situation, locking (all) keepass databases does not make a lot of sense (the option can still be there but separated from the "lock when lid closed").
Triggering the keepassXC database lock by standby does not seem to be easy to implement accross platforms/distributions (https://github.com/keepassxreboot/keepassxc/issues/2753) and the "lock after inactivity" timeout has issues (https://github.com/keepassxreboot/keepassxc/issues/2014) and is not feasible to be used to replace "lock when standby" (e.g. if you standby just before your ~8h work shift, your databases stay open overnight/WE/etc)
As "lock when lid closed" is already implemented as one trigger out of the 2 for this setting, I hope this is quite straightforward to implement? I think that would be great!
came here for this, looking forward to 2.8 thank you!
Not sure whether this is the same issue, but probably at least very similar: I find it very inconvenient that the DB is locked as soon as the screen begins fading out. Like, the option to turn off the screen after, say, 5 minutes does not turn the monitor instantly black after 5 minutes but instead slowly darkens it within a couple of seconds.
Expected behaviour:
- The screen time-out of 5 minutes is reached.
- The screen slowly begins to fade out.
- After a couple seconds, the screen is completely black.
- KeePassXC locks the database.
Actual behaviour:
- The screen time-out of 5 minutes is reached.
- KeePassXC locks the database.
- The screen slowly begins to fade out.
- After a couple seconds, the screen is completely black.
This behaviour is annoying because the screen fade-out can be interrupted by wiggling the mouse, but for the KeePassXC database it's already too late. It's basically locked immediately after 5 minutes without prior notice.
– @realpixelcode in https://github.com/keepassxreboot/keepassxc/issues/8563#issuecomment-2335150944
Take that up with the implementors of the screen fade. They send out the notice that everything was turned off when the fade starts.
– @droidmonkey in https://github.com/keepassxreboot/keepassxc/issues/8563#issuecomment-2335152509
Maybe KeePassXC could wait for something like 30 seconds before actually locking the DB?
That wouldn't do anything besides delay the locking? No signal is sent out for a canceled screen lock / screen off.
Summary
This is a proposal to split the "Lock databases when session is locked or lid is closed" checkbox into two, one for session lock and another for lid closed. There is valid use case when locking a DB on lid close is undesirable: a laptop with an external monitor. After a lid is closed, a session will continue uninterrupted -> no reason to lock.