Automatic Biometrics Prompt on Open Popup

Feature name:

  • Automatic Biometrics Prompt on Open Popup

Feature Description

  • When Unlock with biometrics is enabled, clicking extension will trigger biometrics prompt automatically as default behavior.
  • A checkbox option should exist to disable this behavior and require original behavior of clicking Unlock with biometrics on lock screen.
  • Avoid triggering biometrics prompt after clicking Lock Now.
  • I originally commented on this at: Automatically Select Biometrics for Unlocking when available - #3 by cho-m

Clients / Repos Affected:

  • Web

Timeline to completion (estimate):

ETA: Q1/2021

I tried out a quick implementation, which can be seen in below GitHub comparison pages:

Some things that may need to be discussed:

  • decide if better to swap default behavior and checkbox option
  • not too sure if there is a better way to detect initial lock screen. currently using the window.previousPopupUrl, which is modified after every NavigationEnd inside app.component.ts.
  • possibly tweaking timing. currently set to 100ms matching the element focus event.

I also came for something similar.

The current unlock-and-fill procedure is just too slow and awkward, which you have to press the extension → unlock with biometrics → put your finger on the scanner. As I much prefer autofilling with the keyboard shortcut or using the experimental autofill on page load, I think the default action should be prompting you to unlock on any autofill action, whether it’s filling on page load, keyboard shortcut, or pressing on the extension.

Doesn’t seems like something hard to implement. If the team agrees, could start working on the code.

@cho-m I think that would be great! @cscharf @Hinton this would be nifty!

@allenhu1029 - I think this may fall in line with password re-prompt for some items, so users can decide if they want to use biometrics before filling in an item. @Hinton what do you think?

Is this a variant of the idea from feature requests:

I had previously tried running a modified version of the old WIP PR for those features, but I wasn’t able to programmatically call openPopup due to security restrictions.

You can always create a new GitHub Contribution topic with full details of what you want to do and get it reviewed by someone on Bitwarden team.

1 Like

@cho-m Ahh yes this was what I was actually looking for, thanks for linking it.
I’ll look into that PR and see if I could create a working version.

@tgreer @cho-m I think this feature sounds great, one thing that pops to mind is that we would want to gracefully handle the desktop application not running. Opening the browser extension and getting a “start the desktop application” popup that needs to be immediately closed adds another prompt blocking the way. (Although it might be nice to inform the user we attempted to login using biometrics in a less intrusive way.

1 Like

When I have a chance, I’ll take a look into this.

Based on a quick glance, I believe most of the messages are created inside NativeMessagingBackground.connect, so state data needs to be passed from LockComponent.ngOnInit to there.

I need to look further into whether storageService can be used for temporary data like this, or if some extra method parameters are needed.

May also take a look into using this.platformUtilsService.showToast for just displaying warning/error messages for this scenario.

1 Like

Going from my memory I suspect adding another argument to platformUtilsService.authenticateBiometric would be preferred. It should provide a direct way to interact with the NativeMessagingBackground service. And might avoid the browser extension ending up in a weird state due to the popup closing unexpectedly.

Using toasts for warnings seems reasonable :+1:

I’m picking up where @cho-m left off and trying to get this feature across the finish line, but could use some guidance. I’m totally new to the Bitwarden codebase and learning as I go, any help is appreciated :slightly_smiling_face:

This is where I’m stuck. I understand that the biometric flow starts in LockComponent.ngOnInit, and somehow we have to get a parameter (i.e. waitForDesktop) from there to NativeMessagingBackground.connect. If waitForDesktop is true, we show the dialog telling the user to start the desktop app, otherwise we just show a toast.

But I don’t understand how to pass such a parameter through the BrowserCryptoService, which I think is required for this to work. Could you point me in the right direction?

I haven’t looked at the code in a while, but it would seem reasonable to add an argument userInitiated: boolean = false to platformUtilsService.authenticateBiometric, which can get passed along to the biometricCallback. Which can then be handled in browser/main.background.ts at master · bitwarden/browser · GitHub to let the background service know it shouldn’t generate dialogs.

1 Like

Thanks. Unfortunately life got in the way of following up on this. Is it really so bad if the browser extension prompts immediately to start the desktop application? I understand it might be a bit “startling” for the user, but it actually might save a few clicks and seems like the right UX.

The technical challenge with a more graceful fallback is that the unlock request has to traverse the BrowserCryptoService, which doesn’t (and probably shouldn’t) have any concept of user interaction. Whereas PIN and password auth handle UX (dialogs, toast) in the Lock UI itself, Biometric auth delegates all UX to the platform services.

If I’m reading the call stack correctly: (browser)LockComponent.unlockBiometric calls (angular)LockComponent.unlockBiometric calls await this.cryptoService.getKey('biometric'). I think this is what initiates the auth flow via platform services.

I hope this get implemented soon, not clicking on the unlock with touch id each time saves me a lot of time each day.

Any updates regarding this @danep or @tgreer ?

@Samplex I think this one was all @danep’s work.

@danep - I think you were on the right path, but @Hinton would need to confirm. Let us know if you have questions :+1:

@danep UX wise a non blocking toast seems more friendly than a blocking dialog. But feel free to implement it using the existing UX for now and we can look into improving it at a later time.

The interfaces changed fairly recently which muddles things, and I agree that cryptoService shouldn’t necessarily have knowledge of if the user imitated it or not.

1 Like

Thanks for the encouragement, I’ll try to take another look at this in the next few days and move it forward one way or another.


Thank you @Hinton @danep and @tgreer

Would be great to test it and give some feedback.


@danep When is this feature in the Mac Appstore version of bitwarden?

@Samplex this feature is at the beginning of implementation. We’ll need to review and test before this moves into a release, which is done roughly every 5-6 weeks.

1 Like