Lock Timeout behavior
From what I can see running 1P v4 on Windows 7, the auto-lock timeout is based on xx minutes of inactivity on the entire PC, not inactivity with the 1Password app. This is different than how the 1Password auto-lock works on iOS. I think auto-lock should work the same on all platforms, and I think the iOS method is preferable.
I saw a discussion in the Beta thread about this. It appears that the original behavior in the beta version was changed in the released version. But I agree with what svondutch said in that earlier thread:
I understand what you're trying to achieve, but when the user does not interact with the main app, then it should lock itself after the specified interval (because that is what the customer expects it to do).
Can someone from AgileBits comment on the change? And what are the prospects for changing it back (or giving users an option in the Preferences to decide how they want it to work) ?
Unlike RichardPayne, I work in an environment that is not strictly locked down. So there are many times when I leave my desk without locking my workstation. I would prefer that 1P lock itself if I got distracted by some other task and forgot to lock it myself. My environment has many distractions, and it is inevitable that one working there gets interrupted quite often.
Thanks, Scott
Comments
-
To my knowledge, @Rabbit32, the activity timer is based on 1Password activity. In fact, there's a request to change that on the list of requested features. (See also this thread from February.)
I'll ask Development whether a change slipped past me unnoticed.
0 -
According to Development, the auto-lock timer is affected by the Universal Unlock option on the Browsers tab of 1Password preferences.
If that option is enabled, the helper monitors all activity and resets the auto-lock timer with each keystroke or mouse click.
If the Universal Unlock option is disabled, the helper doesn't unlock the main program, so the auto-lock timer is reset only on interaction with the main 1Password program.
0 -
Hmm, that doesn't match what I'm seeing. I'm running 1Password 4.0.0.499 with Auto-Lock set to 15 minutes. [I'm on Windows 7 SP1 Ultimate 64-bit.]
I unchecked Universal Unlock and ran two tests, each time leaving 1Password minimized and untouched for over 20 minutes. When I then clicked the taskbar icon, it came right up with the vault unlocked.
0 -
@DBrown
As a semi-related aside, I have to say that, while I understand and partially agree with your attitude to having large numbers of options, I think having multiple unrelated features tied to a single option is even worse, as is having implementation specific side effects (which is what this seems to be).
The ability for the app and helper to sync lock states is not really related to auto-lock triggering on 1Password activity or system activity.0 -
@Rabbit32, we believe that's fixed in 4.0.1.BETA-500, now available. Could you let us know how it works for you?
Thanks!
0 -
@RichardPayne, the response that I'm getting is that opinions on design will always differ, and this is just how it's designed...at least for now.
As always, we sincerely appreciate hearing your thoughts on the user experience, and I'm sorry I don't have a more satisfying answer for you.
0 -
Normally I don't use beta software. Can I install it and still keep my official release in place? After trying out this fix using the beta, I would resume using the current release.
If I can only have one version installed at a time, will my vault be changed in any way by installing and using the beta version?
Thanks, Scott
0 -
Can I install it and still keep my official release in place?
No. If you install OPW4 beta then it will replace OPW4 stable.
will my vault be changed in any way by installing and using the beta version?
No.
0 -
@RichardPayne, the response that I'm getting is that opinions on design will always differ, and this is just how it's designed...at least for now.
Only up to a point. There are in fact right and wrong decisions when it comes to design and having unrelated side effects to settings is definitely a bad one. Still, in this case it's not the end of the world in the grand scheme of things.
0 -
Hi @RichardPayne,
There are in fact right and wrong decisions when it comes to design and having unrelated side effects to settings is definitely a bad one.
You can have right decisions and still have side effects. In this case, it has to do with the way the locking and unlocking system works in two separate processes, they're connected. It's difficult to sync between them without having no effects on other settings and this also makes it difficult to provide proper settings that makes sense to everybody.
We'll take another look and see if we can find a better approach to this from the settings point of view. We'd love to hear your thoughts on this as well.
0 -
I'll be honest, I'm struggling to understand why. If you want to synchronise the lock timeouts then all you have to do, rather than monitoring system activity, is monitor activity in the app and the helper separately and then, just before an auto-lock is executed, query the last activity date/time from the other process. If it is inside the timeout then update your last activity time to the one receive from the other process and wait.
0 -
From my understanding, it wasn't that simple and we made the harder choice because it was more feasible to maintain. If it was that simple, we would've love to keep it consistent with the Mac platform.
0
