Modernized design and Seamless workflow

[nitrogl]

I added the following features and improvements:

• Modernized design: icons and popup window that provides user-friendly feedback
• Seamless workflow: fingerprint starts automatically (no button required to be pushed manually)
  • First 5 attempts are automatic, then a button "Try again" appears and restarts the fingerprint scan
  • If the fingerprint device is "busy", it waits for it

I tested it on Firefox 153.0.4 (64-bit) - and https://webauthn.io/ and GitHub itself (if that matters)

[Karloss1234]

I like the modern look.

With respect to its position, my thoughts are that this is a high-status dialog box, which is as important as a conventional password request. As password requests are presented as large popups in the middle of the window, I think this passkey popup should be the same, just like Windows Hello:

What was already there achieved this and really just needed a modern look and to go straight to fingerprint press:

--centred/prominent in the current Firefox window/tab, like a password dialog box
--visible without requiring the user to look at the toolbar (some users won't have the extension icon visible)
--it needs a Cancel button, just like a password popup

I have also found a potential bug. On www.webauthn.io, registration succeeds, however when I click on the extension icon in the browser extension bar, it still shows the "Verify it's you, touch the fingerprint reader..." dialog. It is only after doing a follow-up authentication that the extension menu reappears.

Regarding the fingerprint retry handling: I like the effort to make fingerprint failures more resilient, but I have a concern about putting the retry logic at this level. This effectively hides some of the weaknesses of the current fprintd-verify approach rather than addressing/removing those weaknesses.

My concern is that we eventually want WebAuthnLinux to move toward communicating with the fingerprint service through D-Bus directly. If retry/error handling is built around fprintd-verify now, we risk making this workaround part of the architecture and then having to remove/rework it when the D-Bus implementation is introduced.

Many elements of the extension are still experimental/undeveloped, and the use of fprintd-verify is one of those elements. I think users should be able to see the experimental elements, especially as this is a security extension. Keeping the current retry behaviour raw/minimal/honest until we have the underlying D-Bus fingerprint-service interface sorted out seems like the best way forward.

[nitrogl]

Thanks for your constructive feedback.

I agree that it is still a little clunky and needs a cancel button and a persistent popup/window. But please consider that passkeys (e.g. YubiKey ones) are presented natively in Firefox with a popup coming from the web address (close to the HTTPS shield). Not as centred popups. I'm not familiar with how it can be developed within an extension.

About the bugs. I agree, and it disappears within 5/10 seconds on my side to come back as it's supposed to. This is worth looking into when I have time. Also, if Firefox loses focus, it disappears, but it doesn't reappear automatically - one needs to click on the icon. I haven't tried without having the icon in the toolbar.
(I have an additional on-screen display service that alerts me whenever the fingerprint is in Scan mode; so those visual artefacts have less impact on my system. But I understand and agree that those should be better addressed at the extension level.)

In my system, I have to configure retries in PAM configuration. I'm not sure whether it's calling fprintd to natively do it, or it's PAM itself which owns the retry logic. For the time being, I'd keep the logic as it is now until a better solution can be integrated.

[Karloss1234]

One thing that may be worth clarifying for the project is that the WebAuthnLinux native host currently bypasses PAM entirely. webauthnlinux_host.py directly calls:

['/usr/bin/fprintd-verify', '-f', 'any']

My concern with this approach is that a lot of fingerprint hardware can't use standard Linux fprintd. There are experimental fprintd implementations which are required (including open-fprintd). I would I like avoid these limited experimental implementations by eventually moving to communicating directly with the fprintd D-Bus service. It would give the native host direct access to the fingerprint service (skipping fprintd and PAM) rather than building more handling around the many implementations of fprintd-verify. The dbus-service will give a response to every fingerprint press (like Windows Hello does or a password failure). Currently my open-fprntd only provides me a response after many failed finger presses. Your PAM code also only seemed to provide a response after many finger press attempts.

Your PAM retry handling seems like a good logical interim solution, or a permanent solution if it is decided to stick with frintd-verfiy; I just wanted to make the distinction clear as part of the longer-term architectural considerations.

[nitrogl]

Thanks for the clarification.

One correction first: I don't have any PAM retry code in this PR. My retry configuration comes from the standard PAM configuration on my system:

auth            sufficient      pam_fprintd.so max-tries=10 timeout=30

in /etc/pam.d/<whatever>, with the appropriate values depending on the hardware.

If you were referring to my fingerprint-osd project, it does not use PAM either. It actually uses D-Bus directly. It subscribes to fprintd's D-Bus signals, for example:

dbus_interface="net.reactivated.Fprint.Device",
signal_name="VerifyStart",

at lines 99-100 of src/fp-bridge.py.

I agree with you that moving WebAuthnLinux towards direct D-Bus communication is the better long-term solution. I'm actually quite keen to contribute to that, and I think the code from fp-bridge.py would be an obvious starting point.

But I think this should be considered separately from this PR. The purpose of my changes here was to improve the current workflow, not to redesign the fingerprint backend. The retry handling in the JavaScript was deliberately a small, short-term solution to make the existing implementation less frustrating to use.

I also don't think we gain much by keeping the current UX deliberately "raw" while waiting for a future D-Bus implementation. I found it great that the current implementation is already functional, and great that I can manage my keys - despite, yes, it blocks native passkey methods from being used - and these changes make it considerably more usable without preventing us from replacing the underlying fingerprint communication later.

For me, the distinction reads simple: D-Bus is the right direction for the fingerprint architecture, as you mentioned, but it shouldn't need to block improvements to the user experience of the existing implementation.

The changes have also made a very noticeable practical difference for me. I can now register and authenticate fingerprint passkeys with GitHub, Google and Amazon with significantly less friction than before.

Again, I'm happy to work on the D-Bus side as a follow-up, since I already have working Python code for communicating with fprintd that could be adapted. But doing the integration properly and testing it across the relevant hardware and fprintd implementations is a considerably larger change than this PR.

I would therefore prefer to keep this PR focused on the UX improvements and leave the D-Bus implementation as the next step.