1Password is not unlocking properly with universal unlock after sleeping

MikeT

This discussion was created from comments split from: Can i preview attached photos inside 1Password?.

bkh

"If you already have Universal unlock turned on, then you would only have to do this once per the 1Password program's process."

I have to do the double-unlock every time the computer wakes from sleep --- it sleeps after 1 hour idle. I have 1Password configured to lock on screen saver (20 minutes) and on computer lock. I have Universal unlock set. I suppose the 1Password main app dies when the computer sleeps, even though I remain logged in. I just tested this: did a double unlock, then Start Menu > Sleep, then wake the computer, still logged in with the browser window open, unlock via the plugin, and the main app is locked despite the padlock symbol becoming unlocked in the taskbar. Forcing the user to double unlock is crude. And it isn't once per log-in, it's once per unsleep.

"We simply can't sync the lock status from the extension/helper to the program process when it is not running."

Then launch it so it can receive the lock status. Or don't, but have it query for lock status when it starts at some later time.

I was kind of hinting at this in my mention of a watchdog process. The eager sync strategy is that a missing main app (or helper for that matter) is launched by the watchdog at the moment the browser plugin is unlocked by the user so that the main app can receive the unlock event. The lazy sync strategy is that, at the time the app is launched (such as via clicking the padlock in the taskbar) it pokes the browser extension / helper if it exists, which then turns around and syncs down the lock status. The eager strategy is better because it preserves the unlocked state in this scenario: main app exit, unlock in browser, kill browser, start main app.

MikeT

Hi @bkh,

I've split your post from the other thread, so we can focus more on that specific problem as it is off topic in the other thread.

I have to do the double-unlock every time the computer wakes from sleep --- it sleeps after 1 hour idle. I have 1Password configured to lock on screen saver (20 minutes) and on computer lock. I have Universal unlock set. I suppose the 1Password main app dies when the computer sleeps, even though I remain logged in.

That's definitely not right. The process would still be running as long as the main program is open, it doesn't matter if it was locked by the screensaver or sleep. The key thing is for the helper process to see the program process.

I just tried this with 1Password 4.0.1.503 on Windows 8.1, no problem there. Unlocking the extension after waking up does unlock the main program that was opened.

Can you tell me your setup here and I'll try to reproduce it with your settings.

Then launch it so it can receive the lock status. Or don't, but have it query for lock status when it starts at some later time.

Launching it means opening the main program, the program process isn't decoupled in a way that it can be launched without the app. It is also a security thing, we do not want to leave a process without a visible UI running after we send an encrypted data packet with your data to it.

Also, users do not want us to open the main 1Password program every time they unlock the extensions.

I was kind of hinting at this in my mention of a watchdog process. The eager sync strategy is that a missing main app (or helper for that matter) is launched by the watchdog at the moment the browser plugin is unlocked by the user so that the main app can receive the unlock event. The lazy sync strategy is that, at the time the app is launched (such as via clicking the padlock in the taskbar) it pokes the browser extension / helper if it exists, which then turns around and syncs down the lock status. The eager strategy is better because it preserves the unlocked state in this scenario: main app exit, unlock in browser, kill browser, start main app.

My understanding from the engineering team is that the process model and the APIs we use on Windows doesn't allow us to do this. Believe me, our engineering team spent a lot of time trying this and the type of resources we use does not permit us to have this. The most feasible way we can maintain universal unlock is how it works now.

This certainly isn't impossible but it is difficult for us to handle that type of setup. We do revisit this every once in a while to figure out if there are newer ways to handle this.

RichardPayne

@MikeT‌

My understanding from the engineering team is that the process model and the APIs we use on Windows doesn't allow us to do this. Believe me, our engineering team spent a lot of time trying this and the type of resources we use does not permit us to have this. The most feasible way we can maintain universal unlock is how it works now.

The understanding I had from @svondutch was that this was simply an arbitrary choice to use "push master password to other process" instead of "pull master key from other process".

Thack

@MikeT‌ - it's when you've got 'Show 1Password icon in the notification area' checked.

If you minimise 1P when that box is checked, it actually appears to close 1P (i.e. the "glow" disappears from the icon on the taskbar). Then the situation described by @bkh occurs.

In summary, it's like this:

Show in notification area checked
1/ Minimise the main window
2/ Sleep the computer
3/ Wake the computer
4/ Unlock 1P in the browser
5/ Switch to main window - a second unlock is required

Show in notification area NOT checked
1/ Minimise the main window
2/ Sleep the computer
3/ Wake the computer
4/ Unlock 1P in the browser
5/ Switch to main window - already unlocked

Personally this seems very weird and not like other Windows programs. It's like you aren't allowed to minimise the program when "Show in notification area" is checked - it closes it whether you want that or not.

Or maybe I've misunderstood?

RichardPayne

@Thack‌

You don't need to sleep at all. Just replace sleep/wake with lock/unlock and you get the same effect.

Oddly, if you open up the main app, lock it, minimise it and then unlock the browser then the main app is unlocked too. So it does appear that when "minimised to systray" it not actually closed. I wonder if it is closing when the system is locked while it is minimised?

DBrown

What's the setting of the Universal Unlock option (on the Browsers tab)?

Do you see different results when it's enabled from when it's disabled?

Thack

OK, here is the story with Universal Unlock enabled and disabled, too.

UNIVERSAL UNLOCK CHECKED
Show in notification area checked
1/ Minimise the main window
2/ Sleep the computer
3/ Wake the computer
4/ Unlock 1P in the browser
5/ Switch to main window - a second unlock is required

Show in notification area NOT checked
1/ Minimise the main window
2/ Sleep the computer
3/ Wake the computer
4/ Unlock 1P in the browser
5/ Switch to main window - already unlocked

UNIVERSAL UNLOCK NOT CHECKED
Show in notification area checked
1/ Minimise the main window
2/ Sleep the computer
3/ Wake the computer
4/ Unlock 1P in the browser
5/ Switch to main window - already unlocked

Show in notification area NOT checked
1/ Minimise the main window
2/ Sleep the computer
3/ Wake the computer
4/ Unlock 1P in the browser
5/ Switch to main window - already unlocked

Now this is weird and not what I was expecting. If "Universal Unlock" is NOT checked, then unlocking at the browser unlocks the main application, too. This seems to be the opposite of what it should be doing, doesn't it?

Edit: Sorry - I've just noticed that the label after that checkbox suggests it's the other way round, and that unlocking the main app unlocks (or doesn't) the browser too. Anyway, whatever: the OP was talking about unlocking via the browser first. It seems that when minimised to the system tray, sleeping the computer causes the 1P application to close, hence the need to double-unlock if you unlock at the browser first, as the OP describes.

@RichardPayne‌: would you consider verifying these results on your installation? Thanks.

@bkh: it looks like you can get around your problem for now by UNchecking the "Show in notification area" and taking care to minimise 1P, rather than closing it. Then after waking the computer you should only need to unlock once.

Thack

Oh, this is getting complicated. It turns out that if you have it set as follows:

1/ Show in notification NOT checked
2/ Universal Unlock NOT checked

....and then sleep and wake the computer, the application remains unlocked, but the browser locks and requires unlocking after waking.

This whole behaviour feels very confusing and unintuitive, and I'm pretty sure it's buggy - not what the designers originally intended.

I think this area needs rethinking - the exact behaviour in all four of those checkbox combinations needs defining for:

1/ When the computer sleeps/wakes and is then unlocked at the browser;

2/ When the computer sleeps/wakes and is then unlocked at the application;

3/ Without sleeping/waking, 1P is locked/unlocked at the browser;

4/ Without sleeping/waking, 1P is locked/unlocked at the application.

I count that as 4 * 4 = 16 scenarios that need putting in the left hand column of a table and the required behaviour for each defined in the right hand column.

DBrown

@Thack, @svondutch has promised to look into this and respond. Once he confirms that it's working as intended, and I understand all the permutations, I'll figure out how to make them clear in the user's guide.

Thanks for your help and patience!

RichardPayne

@Thack‌
My earlier testing was on a domain XP system. I've just tested your extended use cases on a non-domain Win7 box with the following results:

UNIVERSAL UNLOCK CHECKED
Show in notification area checked: a second unlock is required
Show in notification area NOT checked: already unlocked

UNIVERSAL UNLOCK NOT CHECKED
Show in notification area checked: a second unlock is required
Show in notification area NOT checked: a second unlock is required

Thack

@DBrown‌: I've got another idea. Are you absolutely sure you need those two features to be optional? I'd be SORELY tempted to make these two decisions yourself, rather than giving the user a choice. If I were doing it, I'd set "minimise to system tray" to off, and set "universal unlock" to on, and then delete those two checkboxes. It would make everyone's life much simpler.

I'm sure we'd cope. :-)

RichardPayne

Universal Unlock I could agree with. I'm not sure why anyone would want that turned off.
However, I'd only support losing the minimise to the tray option if they get rid of the notion of the app not being able to query the browser helper for lock state and master keys when it starts.

Thack

Oh yes, @RichardPayne‌, I agree with you there. I think there's quite some tidying up to be done in this whole area. Mind you, it's always easy for me to say these things - I'm not the one writing the code! :-)

bkh

Thanks to @MikeT for making a proper home for this topic, thanks to @Thack for comprehensive test results, and also to @RichardPayne for useful extended tests.

Now I hope @svondutch sees the merit and feasibility of some improvements to this.

DBrown

I'm not sure at all, @Thack, but (a) I'm fairly low on the list of People Who Decide These Things, and (b) I personally like options, though I'm in a small minority.

bkh

@MikeT said "It is also a security thing, we do not want to leave a process without a visible UI running after we send an encrypted data packet with your data to it."

But wait, that's the usual configuration for me. The main app is alive but running minimized to that little lock icon in the Windows taskbar notification area. It's not exactly without a visible UI, just a very unobtrusive one.

"Launching it means opening the main program, the program process isn't decoupled in a way that it can be launched without the app. Also, users do not want us to open the main 1Password program every time they unlock the extensions."

I was thinking of the fact that a Windows shortcut can be set to "run minimized" when the program launches. You wouldn't have to open up a big window when you unlock from the extension. Just make the main app alive.

svondutch

@Thack @RichardPayne Is this where the bug is?

1. Minimize 1Password
2. Sleep your PC
3. Unlock 1Password in web browser
4. Click on 1Password tray icon

Result: a second unlock is required. Expected result: 1Password should be unlocked because "universal unlock" is turned ON.

RichardPayne

@svondutch‌
From @Thack's testing:

UNIVERSAL UNLOCK CHECKED
Show in notification area checked
5/ Switch to main window - a second unlock is required
Why is a second unlock required when universal unlock is one and the app should only have minimised to the systray (ie should still be running)

UNIVERSAL UNLOCK NOT CHECKED
Show in notification area NOT checked
5/ Switch to main window - already unlocked
Why is a second unlock NOT required when universal unlock is off. Should need to be unlocked independently. Or it didn't autolock correctly.

My testing on my domain linked XP box matched @Thack's.
Testing on my Win7 non-domain box showed the same issue with UU and Minimise to systray checked. I could not replicate the behaviour with UU off on Win7.

svondutch

@RichardPayne I can reproduce problem #1 but I'm having a hard time reproducing problem #2 (in my testing, the app is locked at step #5)

RichardPayne

@svondutch‌

I could reproduce either on one of my machines so the issue is affected by something other than the settings mentioned. For me, the key differences are domain XP vs. non-domain Win7.

You're not supporting XP so ignore that. Do you have a domain linked machine to test on?

svondutch

Do you have a domain linked machine to test on?

@RichardPayne I'm afraid not. Anyway, I did fix that other problem (double-unlock every time the computer wakes from sleep) that @bkh reported here. To be included with 4.0.2.BETA-504.

Thack

@svondutch‌: LOL! It does seem to have got rather complicated! :-)

I've got to take a break now, but later on today I will try to write down what I would expect the behaviour to be, in terms of being logical to the user and technically feasible. I'm quite hoping @RichardPayne‌ will do the same.

RichardPayne

@Thack‌ LOL, I've already explained my expectations to @svondutch‌ a few times now. I suspect he must be getting bored of me! :D

svondutch

@Thack‌ @RichardPayne‌ Please download 4.0.2.BETA-504 and try again. Thanks!

RichardPayne

The update site appears to be broken:

https://app-updates.agilebits.com/check/2/5.1.2600/OP4W/en/503/Y

"Not Found"

DBrown

@RichardPayne: The "new-version check" function in 1Password seems to be working correctly. I'd always recommend that route, because URLs can change.

RichardPayne

I was using the version in the app. I posted the url because that's what the app displayed to me.

Might have been something in the middle. I'll try again later.

DBrown

OK, please let us know, because that's what I did, too.

Thanks!

MikeT

Hi @RichardPayne,

We've done some changes to our app-update site, so that might be the cause. We'll investigate this.

In the meantime, you can find the download link here: https://app-updates.agilebits.com/product_history/OPW4#beta