Pass keys can be accidentally deleted pretty easily (edit, click the ‘delete’, save). There’s seemingly no way to get them back.
You can re-import them from a backup which is nice for someone like me who’d bother to make automated encrypted backups, but if you’re not doing that then if you enter the edit dialog, click the ‘remove passkey’ button, then save, you’ve locked yourself out of that account. So every time you edit you’ve got to be real careful to preserve the key if you have no backups.
I have a cat, people have kids. Errant clicks happen. If this behaves similarly on a phone it’s even more likely this happens.
Or, why not allow for full record history? 1password does this well: any edit is preserved, and you can restore old versions at any point. The only way you can truly lose access is if you delete the whole record and let it sit in the ‘recently deleted’ bin for 30 days. (assume votes go towards this idea instead of one where only passkeys are restorable)
@DenBesten Hm, “passkeys” are not like any other field in an entry… I’m not sure if “History for all fields like Password History” should naturally include passkeys (semantically). - And would a history for attachments also fall under “all fields”?
I guess I would be either for this separate feature request to stay as it is - or maybe “History for all fields like Password History” could be expanded to something like “History for all item contents (including passkeys, attachments, URIs …)”?! (as nothig would disappear from that request, but only additional things would be added for “history”-function, I think that change could be justified?)
(Also @grb what do you think how this should be handled?
PS: In that feature request, KeePass(XC) was mentioned… KeePass(XC) has something like a “whole item history”… I think even a small change like ticking or unticking a checkbox - like our “Master password reprompt” - would also be recorded in KeePass(XC)s history as “change”… - I personally would favour KeePass(XC)'s behaviour here, as it makes it not only possible to have a “history” for everything of an item, but also to keep track with EVERY (voluntary and inadvertent) change on any item…
Though that would be a “centralized change history” then - while Bitwarden currently has only a history function for separate fields…)
How do you view them as different? I view them as “the same” because In a JSON export, passkeys, uris and (the link for an) attachment are all very much peer fields, just like notes, usernames, passwords, and custom fields.
Incidentally, Attachments are not actually part of the vault. They are stored external to it, with the vault containing a link to its storage location (URL). In that respect, they are “not like any other field”, but other than that, all fields are in the vault entry.
In almost every other field I can input something, and change it as I like… Not so with a passkey field.
Technically, you’re probably right. I thought more about the general user’s perspective - and here I think it is even unimportant whether something really is a field or not, the important things is whether (voluntary or involuntary) changed or deleted data can be restored.
A passkey can be changed – it just needs to be initiated at the “website” so the keys are kept in sync. Plus, it can be deleted from within the vault.
Regarding Attachments, the big question and the thing I do not know (as I do not use them) is that if I re-upload an attachment, will the URL change and then if it is still referenced in “history” would the contents remain at the URL target?
I thought more about the general user’s perspective - and here I think it is even unimportant whether something really is a field or not, the important things is whether (voluntary or involuntary) changed or deleted data can be restored.