[Feature Proposal] Device verification for GoodWallet access and sensitive actions

[edehvictor]

Business Description

While using GoodWallet, I noticed that once a user is signed in, the wallet can
be opened again without a local security check.

This can be a problem when someone lends out an unlocked phone, shares a device,
or leaves it unattended. Another person may be able to open GoodWallet, view
wallet information, send funds, or export a private key through the normal app
flow.

The transaction review screen asks the user to confirm the transaction, but it
does not confirm that the person pressing the button is the device owner.
Private-key export also uses a warning dialog without a fresh security check.

I would like to explore an optional device-security setting that asks the user to
verify themselves:

• before reopening a locked wallet; and
• immediately before sensitive actions such as sending funds, exporting a private
  key, or approving a WalletConnect signing request.

Depending on the device, verification could use a fingerprint, Face ID, or the
device PIN.

GoodWallet is a PWA, so I do not think we should assume this will behave like
biometric authentication in a native app. The first task should be to confirm
what is practical on Android, iOS, and desktop browsers.

The feature would give users an extra layer of protection against someone using
an unlocked or temporarily borrowed phone. It would not replace wallet recovery,
protect a compromised device, or guarantee that private keys are safe from
malicious browser code.

Detailed Description of Functionality

A signed-in user would open GoodWallet settings and enable Device security.

When enabling it, GoodWallet would check whether the browser and device support
local user verification. If supported, the user would verify with the method
offered by the device. GoodWallet should call this device lock rather than
promising fingerprint or Face ID, because the operating system decides which
method is used.

The user could choose when GoodWallet locks:

• immediately after leaving the app;
• after a short period in the background; or
• manually by selecting Lock now.

When the user returns, GoodWallet would show a simple unlock screen before
displaying balances or other wallet information. If verification is cancelled or
fails, the wallet should remain locked.

Even when the wallet is already open, GoodWallet should request fresh device
verification before:

• signing and broadcasting a transaction;
• revealing or copying a private key; or
• approving a WalletConnect signing request.

This second check is important because an app lock alone does not help if its
background timeout has not been reached. A normal review or warning dialog should
not be treated as proof that the wallet owner approved the action.

Deep links and pending requests should wait behind the lock. The feature should
not only hide the home screen while leaving sensitive actions available
elsewhere.

If device verification is unsupported or the saved credential is no longer
available, GoodWallet should explain the limitation and allow the user to return
to the normal sign-in or wallet-recovery flow.

Technical Implementation

The main question is not whether a lock screen can be displayed. The important
question is whether the saved wallet session can also be protected.

GoodWallet currently saves SIGNER_SESSION in localStorage, and private-key
sessions include masterSeed. The current send and export flows also show that
normal confirmation is used without local user verification:

• Session storage
• Private-key session type
• Transaction confirmation and submission
• Private-key export

If GoodWallet loads that seed before showing the lock screen, the feature would
mostly be a privacy overlay. Someone with access to browser storage could bypass
it. This limitation should be investigated before presenting the feature as a
security control.

The suggested feasibility work is:

1. Test WebAuthn with user verification on installed Android and iOS PWAs and on
   supported desktop browsers.
2. Test whether the WebAuthn PRF extension can provide a device-protected key for
   encrypting the saved signer session.
3. Use Web Crypto encryption so the saved seed cannot be read until the user
   unlocks GoodWallet.
4. Place the lock before GoodWallet restores the signer session.
5. Add a shared verification guard before transaction signing, private-key
   export, and WalletConnect approval, even when the wallet is currently open.
6. Block all signer access while the wallet is locked rather than relying only on
   hidden screens.
7. Record when the app moves into the background and compare the elapsed time
   when it becomes visible again. Background timers should not be trusted because
   mobile browsers may pause them.

A simple PIN fallback needs separate security review. A short PIN stored and
checked only inside the browser can be guessed or bypassed more easily than
device-backed verification. It should not be added only to make the feature
appear to work on more devices.

The proof of concept should answer these questions:

• Does device verification work reliably in an installed GoodWallet PWA?
• Can the same verification guard reliably protect every signing and key-export
  path?
• Can the saved wallet session be encrypted without making recovery unsafe?
• What happens if the user deletes the credential or clears site data?
• Can the wallet still be unlocked when the device is offline?
• Which Android, iOS, desktop, and embedded-browser combinations are unsupported?

If the stronger encrypted-session approach is not reliable enough, the team can
decide whether a clearly labelled privacy lock is still useful or whether users
should instead be directed to operating-system features such as Android Private
Space, Samsung Secure Folder, or iPhone app locking.

Design Reference (When applicable)

No design reference yet.

The main screens would be:

• Device-security setting
• Enable device lock
• Locked wallet
• Confirm a sensitive action
• Verification failed or cancelled
• Unsupported device/browser
• Credential unavailable and recovery

Acceptance Criteria

• A proof of concept is tested on an installed Android PWA, an iOS Home Screen
  app, and supported desktop browsers.
• The team documents what the feature protects and what it does not protect.
• GoodWallet does not display wallet content or restore the signer before a
  successful unlock.
• Sending funds, exporting a private key, and approving a WalletConnect
  signing request require fresh device verification when device security is
  enabled, even if the wallet is already open.
• The feasibility work confirms whether the saved signer session can be
  encrypted using device-backed verification.
• A normal confirmation dialog alone cannot release the signer or private key.
• Deep links and pending requests cannot bypass the lock or the
  sensitive-action verification guard.
• Cancellation or failed verification leaves the wallet locked.
• Credential loss, cleared site data, offline use, and wallet recovery are
  tested and documented.
• The investigation ends with a clear go/no-go recommendation and a smaller
  implementation issue if the feature is approved.

References

• Web Authentication standard
• Checking for a user-verifying platform authenticator
• WebAuthn PRF extension
• OWASP guidance for local storage