Add a way to store/fill in user names

[palant]

The details are still to be determined. However, it's clearly important to store the user name in addition to the password. It should be filled in automatically as well. Password name cannot be used as user name (at least not in all cases) - some websites require frequent password changes, so password name needs to change. UI-wise it will probably boil down to an optional "User name (if different from password name)" field.

To be determined:

• Should the user name be editable?
• Do we want the user to select the form field (= field name) or should we try to guess?

Usually, the user name field should be the one preceding the password field - is this a safe assumption?

[kzar]

• The user name should be editable, that is something the user needs to be able to control. I've definitely needed to do that before when changing my username / email for a website.
• We should try to guess the right field name. Like you say it will nearly always just be the preceding field and the user will expect this to be done for them.

[palant]

These questions aren't as obvious as they seem ;)

The user name should be editable, that is something the user needs to be able to control.

Currently, if you want to change the password name you have to create a new password. This is more intuitive than allowing to edit the password name as that operation modifies the generated password. That's the reason why Easy Passwords currently doesn't have a concept of editable password metadata. And the question here still is, do we need to complicate the UI by adding editable metadata or is changing the username retroactively uncommon enough that recreating the password entry would be acceptable.

the user will expect this to be done for them.

We are already "guessing" password fields and some users considered that not intuitive which is why we now have a mixed approach (only guess if the currently focused field isn't a password field). Same will be the case for usernames, some users might prefer selecting the username field explicitly rather than deal with unexpected implicit behavior.

One possible flow would be right-clicking a form field and selecting "Remember for this password" from the context menu. The advantage here: we can associate form data with a password without (much) additional UI, and we don't have to limit it to user names. Challenge: how does one choose the right password, in particular during registration when the password doesn't exist yet? Additional complication: can it happen that people will associate sensitive data with their passwords? Should we encrypt stored form data? And even if we don't, can we show it in the "All passwords" list in a way that people can restore this data manually?

[kzar]

the question here still is, do we need to complicate the UI by adding editable metadata

Good question. Well looking through my vault I can see this metadata:

• Flag for passwords / secure notes that indicates whether the master password needs to be re-entered before they can be viewed or used.
• Flag for passwords / secure notes indicating whether it's a favourite or not.
• Two further flags for passwords which indicate if a password can be auto-filled or auto-logged in.
• User name.
• Folder (for grouping related notes or passwords together).

Personally I don't find any of these useful apart from the user name. Being able to add tags to entries might be nice but with a decent text search feature this isn't very important.

So perhaps you're right and we can completely avoid adding editable metadata, putting the user name into the password's salt instead.

I guess in the future we could even add a wizard that helps the user change the user name / name for an entry. It could explain that the password must change too, saving the old password as a legacy one until the user is finished. That would be fine for me, since changing the user name is a pretty unusual thing to do and changing the password on a site at the same time as changing the user name wouldn't be hard.

[palant]

Let's try it with the following design:

• We have additional metadata on the passwords, it is optional however. Additional metadata is encrypted in the data storage.
• There should be one more icon next to the password saying "Form fields and notes" in the tooltip. It's probably best to place it on the right side of the password name in the listing so it's clearly different from the password retrieval icons but one still wouldn't click on the delete icon by mistake.
• By default, this icon should be partially transparent. It should only be black if any data exists there. Existing form fields/notes should also be indicated by the password tooltip.
• The view should show the site and password name as text. If no form fields are stored yet these should be followed by the text "You can remember additional form fields by right-clicking them after filling in the password." Otherwise it should show the stored form fields (field name, delete icon on the right, text field). It should be possible to edit or delete values, field names cannot be edited.
• At the bottom there should be a label "Notes:" followed by a multi-line text area - for arbitrary text. There should be two buttons: "Save" and "Cancel."
• When the user right-clicks a form field with a value (non-empty text field, checked checkbox or radio button) we should check the following:
  • Did we fill in a password in this form? If so, add a context menu item to offer associating this field name/value with the password. This will only work if master password is still remembered, we might need to show a message saying that the user needs to enter their master password first.
  • Does the form have a password? Offer generating a password for this field value. This would be an interactive flow, password name preset with the field value. The user might have to enter master password first. Caveat: in Chrome we cannot open the bubble UI programmatically, do we open a new tab instead?
• When filling in passwords, we try to fill in stored fields as well - locating them by name in the same form.
• All passwords page needs to indicate when a password has stored form fields/notes. This data is encrypted so there should be an additional button to show the form fields or notes, similar to actual passwords.

[kzar]

Sounds really good to me, some thoughts:

• I really like the idea of being able to store arbitrary form fields. That would be pretty handy for some websites that ask other questions. (There are a few sites I use that ask for things like date of birth or another secret when logging in. LastPass never gets these right.)
• I think the interaction for storing form fields sounds a little confusing, but perhaps just because it's so different from what I'm used to. What about offering to save form fields when the form is submitted too? That might be more intuitive (and less work for the user) but I guess we would also need to keep track of the user's preferences to avoid nagging them constantly.
• Perhaps we should treat the user name field as a somewhat special case? I think it could make Easy Passwords much easier to use since basically every password will have some kind of user name / email associated with it.
  • How about including a user name field when creating a new password? I would find that really useful. (Much quicker than creating a password, filling it out, entering user name, right clicking on the field and pressing to save.)
  • How about always displaying an input for the user name on the fields page? If given a value we we could have it match the common field names like username, email, user etc. (We could only suggest for email if the value contains an @. We could also stop suggesting the value for field names which have other values saved.)
  • I'm guessing the user name wouldn't be included in printed backups if it's stored with the other encrypted secrets? That would be kind of a shame, it would be nice to have the user name in the printed backup.
• I don't necessarily need a note per password, only one per domain. I guess you're right that the interface might make more sense having them per-password though, and that would be fine for me too. (I suppose it especially makes things simpler when dealing with alias domains.)
• I would like the ability to also save notes that aren't tied to a password or domain. Perhaps we could just have a special dummy password called "General secure notes" or something for the notes to be attached to? We could then just have a little magic in the all passwords page to display those nicely.

[palant]

What about offering to save form fields when the form is submitted too?

Trouble is, typically the first form submitted on a website is going to be very different from the usual one (registration vs. login). Also, Mozilla seems to have had some trouble with password change forms (see https://bugzilla.mozilla.org/show_bug.cgi?id=1243722 for example).

How about including a user name field when creating a new password?

That was the idea with the second flow above - rather than creating a password first and associate the user name with it then, fill in user name on the registration form, right-click it and go into the password creation flow from the context menu - with the user name already being preset. But we need a field name from somewhere (and I'm concerned about websites that use different field names in registration and login forms).

If given a value we we could have it match the common field names like username, email, user etc.

I'm afraid that this will not be sufficient, there are lots of possible variations here. Looking at what Firefox is doing, they search backwards from the password field assuming that the first text/email/url field will be the user name. But they also have to maintain chrome://passwordmgr/content/recipes.json for the "special" cases (granted, this is a rather short list).

I'm guessing the user name wouldn't be included in printed backups if it's stored with the other encrypted secrets?

As indicated above, this would be optional - the user would have to request form fields to be displayed explicitly. Similar functionality is planned for passwords in #11.

I would like the ability to also save notes that aren't tied to a password or domain.

LastPass stores these notes on the dummy "sn" host name. With the spec here, you could do that manually - open a special page like "New Tab", go into passwords, edit site name into "sn" and add a password. In future we might add UI to get there easier, but that's definitely unnecessary in the first step.

[kzar]

you could do that manually - open a special page like "New Tab", go into passwords, edit site name into "sn"...

Yea, fair enough. That sounds fine to me for now, I just don't want to lose any data when I migrate. Any opinion on the dummy host name we'll use for these? Simply notes? (We'll need to make a choice for the LastPass migration script.)

Trouble is, typically the first form submitted on a website is going to be very different from the usual one (registration vs. login).

Good point, I didn't consider registration forms. I guess when the user is recording a new password they might have already registered on the site, but we don't know either way. Tricky. Also this makes me think, what's to stop the user using our form context menu for the user name field during registration? I guess then we'd have exactly the same problems.

Personally I still think we should treat the user name as a special case, prompting for it when recording a new password. It's true the approach of guessing which field to fill won't be perfect, but neither are the alternatives. With the context menu interaction you've suggested for recording form fields manually the user will have the power to do something when the magic doesn't work, but the rest of the time something sensible will happen.

(If we don't treat the user name field as a special case we will also have trouble migrating people's data from LastPass. Since LastPass doesn't store the field name for the user name field we won't know where to put it otherwise. Sure we could throw them all in field called "user" or something, but then form filling would completely break, hardly a nice first experience for someone trying Easy Passwords. I have just over 200 passwords saved, fixing the form fields for every one would be a lot of work and probably more than we could expect from the average migrating user...)

[palant]

Any opinion on the dummy host name we'll use for these? Simply notes? (We'll need to make a choice for the LastPass migration script.)

No, I wouldn't go with anything like that, in order to avoid conflicts with real hosts. It should definitely be some reserved domain name. It seems that notes.invalid would be a good choice.

Ok, here is the alternative design:

• Password creation forms have an additional field, below "Password name." The label says: "User name (only if different from password name)."
• User names are stored in clear text. Consequently, they show up immediately on the All Passwords page (in parentheses behind the password name).
• User name will be indicated in the password tooltip in the list if it is set.
• Editing user names is possible via an "Edit password data" icon placed right from the password name in the list. This icon will be grey (half-transparent) if no data exists.
• The view showing up if this icon is clicked will display site and password names, as non-editable text. This will be followed up by the user name, an editable text field. Optional: additional form fields and notes, not subject of this issue however. This view should have "Save" and "Cancel" buttons.
• When the password is being filled in, Easy Password should attempt filling in the user name as well. The value should be taken from the user name field or (if it is empty) from the password name. The user name field is the first text/email/url field before the first filled in password field of the form. I guess that we shouldn't fill in if the field already has a value.

Advantage here is that filling in user names is usually covered without requiring any additional actions, in particular nothing as obscure as context menus. Also, since user names can be considered non-confidential it simplifies dealing with them a lot.

[kzar]

Sounds good to me 👍.

[kzar]

I just started having a play to see if I could implement the UI for this:

I couldn't help but wonder what advantage having the password name / user name distinction gives us. Perhaps we could improve the labelling but at the moment having the two fields seems a little confusing. Since we're going to try filling out the password name for user name anyway, why not call the field user name and be done with it? (If the user attempts to save a password with no user name we could always display a message explaining they can enter any string they like.)

[palant]

I couldn't help but wonder what advantage having the password name / user name distinction gives us.

The reason is mainly sites that require you to change your password regularly - there you would generate a new password by choosing a different password name but keeping the user name the same.

It might indeed be better to have a "User name" field here, with a small link below it: "I want a password name that is not the user name" (tooltip: "This is useful if you need to generate a new password for the same user name, different password name will result in a different password"). Clicking this link will hide it and show the second field as you have it in the screenshot above. This approach also makes the placeholder of the password name field unnecessary.

It should also be a good idea to display both password name and user name in the passwords list rather than moving this information into the tooltip as proposed above. It should really be "password name (user name)" if a user name is set. Note that user names which are identical to the password name should not be saved in the first place.

[kzar]

Ah, I didn't consider the case of the user needing to generate a new password for a site.

I like your idea for the password creation form, keeping things simple for the majority of the time whilst still allowing power users to tweak the password name if they want.

[palant]

The alternative would be relabeling the current password name as "user name" and merely introducing an optional (numeric?) "revision" field - both would go into the password calculation. This would more obviously serve the purpose of regenerating passwords. Modifying the user name will not be possible then, one can view this both as an advantage and disadvantage.

[kzar]

Great idea, that would make this all much simpler to use, let's do that. (I think it would be quite a nice feature too, being able to regenerate an old revision again should it be required. Much easier than thinking "hmm what did I put for the password name 2 months ago?".)

Also if we start the revision field as an empty string instead of zero then we don't even have to implement it right away, since the seed for the first revision will be the same either way. (In the mean time if one of us really needs to generate a new password for a website I guess we can just change the password length!)

[palant]

Well, one more design that will hopefully make things more obvious:

• The current "Password name" field is relabeled as "User name."
• When adding a generated password, there should be a small text link "I need a new password for the same username" below the "User name" field. When clicked, it will hide itself and show an additional "Revision" input field (<input type="number" min="1" />, default value 1, maybe we can make it accept non-numbers somehow despite numbers being the suggested format).
• The requirement for the user name being unique has to be relaxed into user name and revision combination being unique - typically, two password revisions are required to exist in parallel when a password is updated. This means that the key in the data storage will only be the user name for revision 1 (default), for other revisions it should be "username\0revision".
• Password generation should be based on the storage key, so existing generated passwords won't change (revision is 1 for those) but passwords for a different revision will be different.
• If the revision number isn't 1, it should be displayed in parentheses after the password name in the passwords list (italics maybe?), same on the All Passwords page.

This approach works without any editable metadata - changing user name or revision requires creating a new password.