It’s clear that the current password saving and updating experience is no longer the best that it can be. This is partly as a result of the forced changes to support Firefox WebExtensions a couple of years ago and partly because we’ve not had any spare time to keep up with technical developments in the same way that commercial password managers were able to.
I want to dedicate some time to improving this situation soon and am therefore sharing my proposed approach so that you can offer feedback about whether it will solve challenges you currently have, or potentially introduce new challenges that I will need to take into consideration before starting work on the project.
The idea
When the user opens the Kee popup, assuming they have at least one available password source, two states are possible (ignoring a few edge cases that have no significant effect on password saving):
a) There are known entries for this website
b) There are no known entries for this website
Creating
If the user wants to save a new entry, they click the + button (from either state a or b):
Clicking the generate icon will open the password generator (not shown). Generated passwords will be copied to the clipboard and displayed (masked) in the associated password field. This partially complete entry will be remembered when the popup is closed and re-opened so that the user can complete a website sign-up process without losing the password even in those rare cases where the website prevents Kee from recording the sign-up submission.
Although not shown in the image above, there will be some kind of interface to add fields.
If they have recently submitted a sign-in form or used the password generator the last time the popup was open, some details may already be pre-filled:
We’re tight on space and don’t want to overcomplicate the interface so there is no way to edit a field name, type, nor any of the advanced metadata such as HTML name and id.
Web page favicons can be displayed in the top left of the editing view. When or if this can be implemented is unknown. For the foreseeable future, editing a favicon will remain an advanced feature to be achieved using Kee Vault or KeePass.
The primary button will be “Next” unless the user has requested to always skip the “Where” step (below), in which case it will be “Create”.
Where to save
While acknowledging that we sometimes want detailed control over where our new entries are saved, many users put every entry in a single group in a single password database so we will allow them to skip that configuration step when it is safe to do so.
Since groups are uniquely identifiable across every kdbx database, we can re-use the existing mechanism that remembers what the most recently used group is.
We will change the meaning of the “remember the group you most recently saved to” setting to “automatically save all new entries to the group you most recently saved to”. We will always store the unique ID of the most recently used group (effectively forcing the old optional behaviour to always be true). The group browse/search panel shown above will pre-select the most-recently used group if it is available.
Kee will therefore only need to present the “Where to save?” section when one or more of the facts below are true. Where it makes sense, we’ll present an information message that explains why the previous request to always save in the same place has been ignored for this entry.
1) The “automatically save all new entries to the group you most recently saved to” setting is disabled (or it is enabled but we don’t yet know what the most recent group was)
Users can set this from the “Where to save?” section and set/unset it from the Options tab.
2) More than one database is open
In future we could add an option for remembering a preferred password source for saving. Until that happens, we will assume that users who have multiple sources open will want the detailed control of selecting which database and group each entry is saved into.
NB: The “Always save new entries here” checkbox shown in the mock-up above won’t actually be shown when there is more than one password source until this hypothetical “preferred password source” feature is developed.
3) The recorded group can not be found
This may be because it has been deleted or hidden from Kee. Or it could simply be that the required database is not open.
4) An entry for this domain already exists
I expect that a desire to organise entries into different groups and databases is strongly correlated with Kee users who store more than one account for a particular website. It’s not a perfect assumption but combined with our later plans to improve multi-page sign-ins, I think it’s a reasonable enough compromise regardless.
Updating
If instead the user wants to update an existing entry from state (a), they can expand the matched entry and click the edit button:
If they have recently submitted a sign-in form or used the password generator the last time the popup was open, some details may already be pre-filled.
Changing entry URLs
Some advanced options to control the modifications to URLs for an existing entry will be removed.
When a user is updating an existing entry…
If the URL of that entry is not an exact match, we’ll automatically update the URL if we are confident that the domain matches; the existing URL will be deleted (available via the entry history of course).
Otherwise, we will display a warning message explaining that the new URL will be added to the entry; the current URL will be retained in the entry and the primary URL of the entry will be changed to the new URL.
Expand to see more technical details
// primary url to compare against entry being edited
compareUrl = formWasSubmitted ? Url of frame containing the form : Url in address bar
// An Exact match, regardless of the existing entry's configuration
if url of edited entry matches compareUrl exactly
then No change
// A Domain match, regardless of the existing entry's configuration
else if url of edited entry matches compareUrl domain
then Automatic URL change
else if a form submission was not detected and the url of edited entry matches the domain of >=1 frames within the tab
then No change
else
then Display the warning message at the top of the popup
Warning message
This entry is for a different site.
Continuing with this update will enable you to fill these credentials into this site too.
Make sure this is not an attempt to trick you into revealing your password!
[x] I understand; there is a legitimate reason for these credentials to be shared with the current website from now on.
Explanatory notes
If no form submission has been detected and the following is true:
url of edited entry matches compareUrl, the compareUrl domain or the domain of >=1 frame
Then the user may be attempting to update the entry to sign in to a frame on a different domain. Perhaps the website has recently outsourced or brought in-house it’s authentication service? This is highly unlikely, partly because authentication via iframes is now rare and well known to be less secure than other techniques. For any rare intranet or ancient sites that move to or from this authentication approach, the user will need to manually change the URL in Kee Vault or KeePass if the automatic action taken (or not) by Kee is incorrect.
Note that if Kee is able to detect the form submission the user can opt to add the new URL to the entry regardless of whether the old URL is present elsewhere in the tab or not.
Continuing
Whether creating or updating, there is always a possibility that an entry can be in an edited state when the Kee popup closes; this is both by design (for example, when generating a password for a new sign-in) and unavoidable (for example, when the web browser or operating system forces the popup to close due to events beyond our control).
Wherever possible, we will save the edited information when this happens so that it can be retrieved the next time the user opens the Kee popup on the same browser tab:
If it has been less than 2 minutes since the popup was closed or changes were made (TBC) we will automatically show the entry. The user can of course press “Cancel” if they intend to discard the changes.
Further thought may be required to best handle situations where the user edits an entry in the popup and then submits a sign-in form before explicitly discarding or saving their previous changes. At least initially, I’ll ignore all sign-in submissions within the 2 minute automatic continuation period or if the user explicitly asks to “Show entry”. Hence, a user will be able to force the use of the submitted form data only by waiting for more than 2 minutes, selecting the “dismiss” option and clicking the + button to start adding a new entry again. This should ensure that a tab can intuitively be re-used for another sign-in and save operation at a later time.
Additionally, to reduce memory usage, we’ll automatically discard this temporary edit information after approximately 24 hours.
Third party authentication
First question is, do you have any idea what this section is going to be about?
I’m unsure whether the concept is all that clear and/or whether there is a better way to label this new type of entry.
Essentially, on some websites I want to be able to record a sort of reminder of which third party authentication option I chose when creating an account. In the first instance, this should be which provider needs to be selected, ultimately though, I’d like to be able to associate the website with a particular entry for that 3rd party provider.
Perhaps one day there could even be some automatic selection of the correct provider and a fully automatic sign-in process, although this is likely to require a lot of work for every specific provider we would want to support so I don’t think it will happen in the foreseeable future. Until then, I at least want to be able to easily see the information required to successfully sign-in to the website without creating yet another account from a different provider.
Timeline
Kee version 3.3
Redesign the popup to make space for, and technically support, saving passwords from there rather than embedded within the page. We will continue to use the current save/update password dialog at this stage.
This will not be released to the stable channel but is available right now for Beta testers so please take a look - the overall visual style is more-or-less finished in my opinion so feedback is welcome before I implement the same approach for all the new features mentioned in this topic.
Kee version 3.4
Replace the existing save/update tabbed interface with newly styled interface that achieves similar results to the current system.
Allow invocation of the Save feature even when Kee has not detected a password that can be saved. At this point we can also add support for entries that serve as a simple reminder that a third party authentication service was used for the current website (e.g. Google, Facebook, corporate SSO).
This will be released to beta testers once there are no significant regressions compared to Kee 3.2. Depending upon how difficult some of the implementation steps are, this may or may not include all of the features described in the topic. This may be released to all Kee users if beta testing is successful.
Kee version 3.5
Continue implementation of remaining features and iron out any issues that arise during the version 3.3 and 3.4 beta testing periods.
After beta testing this version, I expect it to be released to all users.
Kee version 3.6+
Possible further enhancements might include recording a special state for the first time an entry is filled. This could allow us to defer storing form field identification data when it is likely that the user has recorded the submission of a sign-up form rather than a sign-in form.
The bigger picture
There are three core interaction points to consider when ensuring that Kee can most effectively enable users to store credentials for later re-use. How can a user…
- Be made aware that there is an opportunity to save a password
- Instruct Kee to save the password
- Receive confirmation that it was saved
Given that I have recently rolled out improvements to (1) in Kee version 3.1, I don’t intend to focus on that at the moment, although ongoing experiments in that area could continue independently of this project. The proposed improvements outlined above address (2) and (3).
It is essential that these password saving improvements work in harmony with other visual improvements to the extension, as you can see in the version 3.3 beta. Although important, saving a password is a very rare event in comparison to the number of times that it will be accessed overall so it’s critical that changes to this feature don’t compromise the ease with which the extension can be used to find and fill passwords into the correct sign-in forms. Have I missed anything that might cause a problem in this regard?
You might also be interested in the future changes to multi-page sign-in support that depend upon the re-design being discussed in this topic.
I’m sure that this kind of features are useful to some if not for most people. I just wanted to give my perspective on the matter as well.