https://bugs.kde.org/show_bug.cgi?id=459039
Bug ID: 459039
Summary: Gripe with Kwallet Password Management
Product: kwalletmanager
Version: 22.08.1
Platform: Archlinux Packages
OS: Linux
Status: REPORTED
Keywords: needs_verification, usability
Severity: normal
Priority: NOR
Component: general
Assignee: va...@kde.org
Reporter: nekone...@protonmail.ch
Target Milestone: ---
SUMMARY
This isn't necessarily a bug with Kwallet but rather a usability gripe with it
about how it's designed as a whole.
Comparing Kwallet to the likes of KeePassXC, Kwallet's password management is
less structured to maintained in the UI and has far fewer features than
KeePassXC. Some will say: "then don't use Kwallet," but there's a few problems
with this that I'm going to get into but my primary response to this is that I
don't *mind* Kwallet as a concept but I find it greatly lacking and even
frustrating in a few different ways.
One of these reasons is because of the aforementioned lack of features compared
to KeePassXC: as it stands, KeePassXC is superior to Kwallet almost in every
conceivable way. So much so, that I honestly think KDE should actually
integrate KeePassXC better into Plasma and SystemSettings officially *instead*
of Kwallet because of both how much better it manages data (from the user-end)
and its other great features like: password generation, 2FA/OTP, and browser
integration. As a user, I interact far more with KeePassXC as a password
manager than with Kwallet and this brings us to my next point...
In my experience, Kwallet does a better job at requesting for authentication
for desktop applications than KeePassXC; kwalletd5 is just better than the
KeePassXC secrets integration and matches the system theme better; however,
Kwallet has an irritating user flaw: if a user opts to save a credential but
enters it incorrectly (to my recollection or something to that effect), fixing
this becomes an unnecessarily frustrating task to fix. An example would be like
using git@github SSH and then being stuck having to enter the key manually
forever because Kwallet won't prompt for this anymore.
Another usability example would be when a matrix client asks to save encryption
key data to Kwallet but Kwallet's only export options are XML and "encrypted;"
which on its own isn't "bad," but when KeePassXC is so much more
feature-complete than Kwallet, makes transferring this data either impossible
or non-user friendly enough to seem that way thereby barring user-choice and
unintentionally creating a "lock-in" if they discover KeePassXC later because
Kwallet is the KDE community default.
That said, I think it would be better for the Plasma ecosystem as a whole to
adopt a fork of KeePassXC to integrate with kwalletd5 to get the best of
authentication requests, user data management, and user security in regards to
supporting secure password generation, and 2FA/OTP.
Another option is to evolve Kwallet far beyond what it is in both UX/UI and
usability but... honestly, that would be far more work than just implementing a
rebranded KeePassXC fork because it functions and already feels like it belongs
in a Plasma desktop; Kwallet seems almost ancient by comparison, in my opinion.
OBSERVED RESULT
Kwallet, despite being an official KDE password manager, falls short in how
effective it should be.
EXPECTED RESULT
Kwallet should either officially integrate with a fork of a superior Qt
offering or substantially adapt to achieving equal parity in design and
functionality.
SOFTWARE/OS VERSIONS
Linux: Arch Linux x86_64
KDE Plasma Version: 5.25.5
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
ADDITIONAL INFORMATION
N/A
--
You are receiving this mail because:
You are watching all bug changes.
