Right now if you use Status to access a dapp like Cent which needs login information, you get offered autofill from password managers on most devices. However, Status still identifies as Status to the password manager, even if context is changed to the dapp, which means the password manager will offer the password for Status (if any) and not for the dapp itself.
This is a UX breaker and hugely impractical, especially since login cookies seem to be lost after every Status restart, and Status itself crashes with Java exceptions every time the phone falls asleep long enough to dump the cache of the app. This means that roughly every 5 minutes, a Status user (on Android at least) needs to full re-login into Status, then navigate to the dapp, wait for it to load (why no PWA manifest and offline cache for assets?), then log in there. That’s two times a user has to manually enter a password, unless the main one is in the password manager which slightly reduces friction there.
I propose the following 10x UX improvements, apart from fingerprint logins which are already planned:
- remember dapp cookies indefinitely (as long as they’re set to be remembered rather than the custom duration imposed by Status) per user account in Status. Encrypt cookies with private key and wipe on logout. Decrypt and auto-apply on logging in again with same identity. This makes it possible for two identities to use two accounts of the same dapp on the same device without constantly having to log in and out of everything.
- expose dapp URL to the password manager, not the app name (Status). See how normal browsers do it.