Prioritize a password entry for a particular website

[hyperupcall]

General information

• Browser + version: Any
• Information about the host app:
  • How did you install it?: prebuilt binary
  • version ($ browserpass-linux64 --version): Browserpass host app version: 3.0.10
• Information about the browser extension:
  • How did you install it?: chrome webstore
  • Browserpass extension version as reported by your browser: 3.7.2

Feature Request

To mark a particular entry from a site as "priority" if there are multiple issues

Current Beavior

If multiple accounts are associated with a site (e.g. github.com is a subdirectory in the password store), then, autofilling the login form (with Ctrl+Shift+f) will sometimes result in an unintended password to be filled in.

Proposed Feature

A method to mark a particular account as "priority". So, if there are multiple accounts, that account with priority will be used to autofill the login form.

[maximbaz]

Hello, this is already possible as the entries are also prioritized by usage, so if you manually select the correct entry once on the particular website, next time Ctrl+Shift+F would select that entry as well. Would that address your scenario?

[hyperupcall]

I see - thank you. I think though, it still seems that I would have to do this on every computer and browser that browserpass is installed on? To fix this, I'm thinking state can be set in the .browserpass.json to ensure this is a one-and-done experience, unless there is an alternative remedy.

[maximbaz]

A very simple approach could be renaming the files, as in absence of any usage data, browserpass would sort them alphabetically... It's actually what I personally do, now that you mention it 😅 I name the primary entry github.com.gpg, and all the additional ones I put in a folder, like github.com/secondary-account.gpg. Just keep in mind that as you login on a particular domain at least once, then in this browser the sorting would no longer be alphabetical, but would take usage counts into account - this is done, among other reasons, to make it easy to login with Ctrl+Shift+F on websites which first ask for a username, and on the next page as for password.

[erayd]

@maximbaz I'm open to this feature if there's a good way to do it (and it is something I would use), but have concerns about excessive complexity. If it happens, it needs to be predictable and easy for the user to reason about.

@hyperupcall Can you describe how you envisage such a thing being implemented? My biggest concern is sorting when there are multiple stores (and thus multiple .browserpass.json files).

The single-store case is easy (e.g. via an array of paths, where any path present in the array is prioritised according to array order, and then anything that isn't follows after according to our existing logic). But that approach doesn't translate to multi-store, and is thus unsuitable.

[hyperupcall]

For sure, I wouldn't want needless complexity either

I wasn't thinking arrays, but objects. Specifically, with members representing the paths, and each value, a number, representing the priosity. For example:

With store A:

// store-a/.browserpass.json
{
  "priorities": {
    "google.com/account-cool.gpg": 1
    "google.com/account-notcool.gpg": 2,
    "github.com.gpg": 2
  }
}

And store B:

// store-a/.browserpass.json
{
  "priorities": {
    "github.com.gpg": 1
  }
}

And assuming that all the files, exist, then;

For google.com, account-cool shows up first, then account-notcool, then the order of accounts resulting from the sorting we already have implemented
For github.com, Store B's shows up first, then Store A's, then the order of accounts resulting from the sorting we already have implemented.

As for the predictability and intuitiveness, one option is to document this, but not bake it into the UI; that way, since the user has to the file themselves, they won't be confused. Another option is to indicate in the UI that it has a priority that superscedes all others, like adding its number priroty somewhere.

and re: the file + directory thing @maximbaz mentioned is a good idea, I didn't think of that - but like you said, once one is chosen, it doesn't really work 😅

[erayd]

I think I'd be OK with that. @maximbaz, what do you reckon?

[maximbaz]

I'm fine with the proposed file layout, just wanted to clarify that we are still talking about initial priorities, the sorting that activates in the absence of any usage data, just before we sort by file names - is that also your understanding, or do you want these new priorities to superseed all other logic?

Let's take a specific example, imagine I have five entries for google.com:

cool.gpg
notcool.gpg
old.gpg
verynotcool.gpg
veryold.gpg

I have priorities defined for a subset:

{
    "priorities": {
        "google.com/cool": 1,
        "google.com/old": 2,
        "google.com/notcool": 3,
    }
}

In the fresh installation, they are sorted by priority and then by name: cool, old, notcool, verynotcool, veryold. Imagine then we logged in with cool one time, with notcool 10 times, and with verynotcool twice. Furthermore, imagine that I used verynotcool last, for example because google uses multi-stage logins, and on the "username" page I selected verynotcool via popup, pressed Next, and now I'm on the second stage, where google is asking for password.

Is this the expected sorting in popup?

1. verynotcool - because it was the latest that was used, to be able to Ctrl+Shift+F through the multi-stage logins (Ctrl+Shift+F always selects the first entry).
2. notcool - because it was used most
3. cool - because it was used less
4. old - because it was not used at all, but has a priority defined
5. veryold - because it was not used and has no priority defined

[erayd]

I'm fine with the proposed file layout, just wanted to clarify that we are still talking about initial priorities, the sorting that activates in the absence of any usage data, just before we sort by file names - is that also your understanding, or do you want these new priorities to superseed all other logic?

IMO, this logic should supercede - it's basically saying, "let me manually determine priority for these items". So, anything with a priority number gets sorted by that number, at the top of the list. Then everything else comes after those entries, sorted by our existing priority rules.

If this feature were to only provide sorting info in the absence of usage history (i.e. how your example works), I think that would make for a confusing UX. Doing it that way seems like a bad idea to me.

[erayd]

It could also be reasonable to allow negative priority numbers, and put anything with a negative priority at the bottom of the list, after all other entries. I would use the heck out of that... I have a whole lot of client accounts in my store that I never want Browserpass promoting up the list, and this feature would provide a handy mechanism for me to enforce that.

[maximbaz]

I know my usage of password store is much simpler than yours, but have you considered simply moving the old clients to a separate password store, that could be excluded from Browserpass? Or removing the usage count for them, so that they would naturally flow to the bottom, as if unused?

Could you also give an example of how you are thinking to use this feature, with positive priorities? I thought perhaps you'd keep the current clients in the priority list, maybe even all with priority 1, so that old clients not in the list would go to the bottom, but with completely superceeding the logic, you'd miss the convenience of multi-stage logins with Ctrl+Shift+F... Or even worse, you will risk leaking credentials on websites with multi-stage logins (like google), because on websites without priority defined in browserpass.json, Ctrl+Shift+F will select the password for the last used entry, and on websites with priority list, Ctrl+Shift+F will fill out the high-prio-entry's password, rather than the just selected one for username...

[erayd]

...have you considered simply moving the old clients to a separate password store, that could be excluded from Browserpass?

I already have them in a separate store. I don't want to exclude them though, because I do use those entries, albeit rarely. I just don't want them ever getting promoted.

Or removing the usage count for them, so that they would naturally flow to the bottom, as if unused?

This isn't a solution, because (a) we don't provide a usage-count-editor, and (b) they aren't unused; I'd keep having to do this. If I could simply define them as lowest-priority (or even better, demote an entire pattern, similarly to how we handle ignore), that would simplify things somewhat for me.

Could you also give an example of how you are thinking to use this feature, with positive priorities?

Something I do a ton of is logging into Google, and there are multiple accounts I do this with. I always want one specific account to be the top one, but because that account often isn't the most-recently-used one, every time I log into Google I have to check which one is actually at the top right now before using it, thus rendering CTRL+SHIFT+F useless for me on that particular domain.

...on websites without priority defined in browserpass.json, Ctrl+Shift+F will select the password for the last used entry, and on websites with priority list, Ctrl+Shift+F will fill out the high-prio-entry's password, rather than the just selected one for username...

This is a really good point. I had not thought of it until you brought it up, but I share your concern.

Perhaps tweaking it so that most-recently-used remains highest priority for the tab it was invoked on would be a suitable solution? That way there is no risk of accidentally leaking the wrong password, but it can happily coexist with the priority feature.

[maximbaz]

Perhaps tweaking it so that most-recently-used remains highest priority for the tab it was invoked on would be a suitable solution? That way there is no risk of accidentally leaking the wrong password, but it can happily coexist with the priority feature.

I like this idea a lot, and I can't believe we didn't think about it earlier - it makes so much sense! The most-recently-used one should definitely be the highest priority only on the current tab, and maybe even only until this particular tab doesn't change domain. This way, your most used Google account would already be always the first, without any priority feature, and yet Ctrl+Shift+F would be consistently predictable. This also sounds simpler to implement, perhaps we should extract this idea out of this discussion?

---

Setting that aside, I can see your other scenario for demoting priorities, you are right that removing them altogether is not a solution. However let me try to spell out one more idea, it will help me better understand this case, please tell me where my thoughts go the wrong way 🙂

I imagine you have a customer A, and you use their login a lot, so the usage count grows, and these credentials naturally bubble up. Then the work is done, and customer goes into maintenance mode - you still need to login ocassionally, but very rarely, and instead you are actively working with customer B and their login. The annoyance to solve is that login for customer B will be below customer A for quite a while, until the usage counter finally overtakes, if ever. And if that's the case, and my assumption is correct that your wish is to make customer B be on top, I can see two ways you could achieve this (both not implemented today):

1. Go edit browserpass.json and put negative priority for that particular website (or pattern, as you say, which is maybe even more advanced), thus disabling the frequency sorting for this domain altogether.
2. Alternatively, next time you visit the website where customer A is annoyingly still on top, you use Add button to clear history for one item #260 to reset usage count for the customer A entry - you can still use this entry, but from now on it will never be on top, because customer's B usage count is already >0, and it grows faster, because you use it more frequently anyway.

[erayd]

The most-recently-used one should definitely be the highest priority only on the current tab...

This, I disagree with, for two reasons:

1. We have a large existing user base which is familiar with the current behavior (most-recent at top, regardless of which tab or window). CTRL+SHIFT+F, by default, means "use whatever I last used here". If we violate a well-established default behaviour like this (especially in a way that can silently change, due to changing login counts), it'll cause confusion.
2. It's fairly common for me to start using a new credential, and to use it repeatedly within a short period of time - I'm using it the most comonly now, even though it may not be the most-used overall. So having it at the top of the list due to most-recent is the desired behaviour, regardless of which tab I may be using.

However, allowing most-recent to override any manual priority on the current tab once invoked there (and as you say, possibly just until the domain changes) IMO makes a lot of sense, for the security reasons you mentioned earlier.

...perhaps we should extract this idea out of this discussion?

I think it belongs here, to be honest. I'm not seeing a good use-case for it independently of a manual-priority feature, unless there is a separate scenario that you think would benefit from it?

I imagine you have a customer A, and you use their login a lot, so the usage count grows, and these credentials naturally bubble up. Then the work is done, and customer goes into maintenance mode - you still need to login ocassionally, but very rarely, and instead you are actively working with customer B and their login.

This is the case for some logins (particularly with project-based work), but with others they start out rarely used and remain remain that way. The latter tends to happen for systems where I am engaged on an ongoing basis for something that isn't a one-off project. An example might be a network appliance for which the only reason I need to log in is configuration changes or patching.

1. Go edit browserpass.json and put negative priority for that particular website (or pattern, as you say, which is maybe even more advanced), thus disabling the frequency sorting for this domain altogether.

This would definitely be my preferred way of demoting stuff. Explicitly chucking them overboard with an anchor attached is predictable, easy, and will get a lot of clutter out of the way. Note that we are referring to entries here, not websites / domains.

2. Alternatively, next time you visit the website where customer A is annoyingly still on top, you use Add button to clear history for one item #260 to reset usage count for the customer A entry - you can still use this entry, but from now on it will never be on top, because customer's B usage count is already >0, and it grows faster, because you use it more frequently anyway.

This method is unsuitable, because it relies on the assumption that customer B's usage is more frequent, when that is not necessarily the case.

[hyperupcall]

Ah, yeah my understanding is different too - I'm was also saying that these new priorities should superscede all logic. And likewise for me, moving the entries to a separate password store isn't a solution for the same reason. But like you mentioned, there is a security concern for multi-login scenarios (thanks for pointing that out), so I suppose a more recent login should be above all else due to security.

This idea:

The most-recently-used one should definitely be the highest priority only on the current tab...

I really like. To be honest, the current behavior was originally confusing for me because I assumed everything was ordered alphabetically. But it appears this behavior is different than what existing users expect. And since I don't remember my recently used logins, whenever a new entry appeared at the top of the list, it seemed random - although now I'm learning it's the most recently used. But I definitely understand my confusion is not a reason to change current behavior, even if it could be possible that a majority of users were confused as well.

Maybe the security problem could also be solved with a timer. By default, the timer is 0, which which means the most recently used password of an entry will always float to the top of the list. But if it's say, 30, then it will only float to the top for 30 seconds, enough to fill out all the forms for the multi-stage login scenaio.

Or Maybe there can be an option for "per-tab", and "global" for saving the most recently used password for a particular. Or an option for disabling recently used passwords all together.

Or maybe there can be an "X" by the the most recently used, so right after I login, I can click the "X" so I get the behavior I want.

I'm suggestions options because for me, it's not intuitive that there can't be a situation in which a thing with prority 1 isn't always at the absolute top of the list. I get the security concern, but at the same time, I want Ctrl+Shift+F, to fill out the password with the highest priority - I can't remember which password I most recently used an hour or so ago, I'm just asking for the most frequent.

The demoting stuff is natural, especially for negative priority numbers, but I have no preferences. Once I can't do Ctrl+Shift+F, I have to check the whole list, and I don't have enough alternative accounts for any particular website for it to be hard to find the account i'm looking for.

[maximbaz]

I do think Ctrl+Shift+F behavior deserves to be reconsidered regardless of the priority idea, but we can keep the discussion here.

I think my main argument would be that in my experience it's hard to remember what login I used last, but it's easy and natural to remember what login I typically use. I believe it's what @hyperupcall refers to as well, in the second to last paragraph above. With the proposed behavior to Ctrl+Shift+F we can make it work like this out of the box, for everyone, on all websites, if you let Browserpass learn your usage pattern for a bit, and leave priority feature for more advanced use-cases, or if you want the proper sorting on a fresh installation. And when I say "typically", I mean the entry I use most frequently now, not necessarily throughout my entire life - so being able to reset frequency counter is an essential part of my entire thought process.

I am not so much afraid to change behavior when we introduce good improvements, we have tools for this, like bumping major version and showing a changelog notification.

And in this particular case, I feel like most people won't even notice that the behavior changed, except (hopefully) they'll find that it's now more intuitive than it used to be, and they can trust Ctrl+Shift+F to pick the right thing in more situations. I'm not claiming that the scenarios below are covering everything, but they probably represent the most usual ones:

1. If you use one entry most frequently, it will remain the first one regardless of this proposal.
2. If you mostly use one entry, but occasionally use another one, then right now you don't trust Ctrl+Shift+F, as you can't remember what you used last time, and so you have to open popup - with the change, you'd be pleasantly surprised that the entry you typically want is always on top now, so you can start using Ctrl+Shift+F.
3. If you use several entries equally often, then you don't use Ctrl+Shift+F anyway, and this change won't really impact you.
4. If you used to use one entry and now switched to typically use another one, a button to reset the counter on the old entry, to forget that it used to be your typical entry, could be an easy and intuitive way for folks to demote it.

And as an additional bonus, with this proposal, the behavior of Ctrl+Shift+F would be both identical and safe to use with whatever of the currently mentioned ideas for the priority feature we have, we won't have to remember that Ctrl+Shift+F behaves differently on websites with and without priority defined, and we can just focus on figuring out what we want out of the priority feature.

What do you guys think? 🙂

---

As for the priority feature itself, given that you both express preference for superseding or replacing the frequency algorithm on the domain that has priority defined, I buy your arguments, and therefore I am more than happy for us to explore this way. So let me ask, which one should it be, supersede frequency data, or completely ignore it, if for a given domain we have both? Could you perhaps update my example with your expected behavior, or maybe even expand it, to cover for all desired features, like negative priority, to make sure we all agree on the desired outcome?

[hyperupcall]

I think my main argument would be that in my experience it's hard to remember what login I used last, but it's easy and natural to remember what login I typically use. I believe it's what @hyperupcall refers to as well, in the second to last paragraph above.

Yup 👍

What do you guys think? slightly_smiling_face

I like this! For me it works in more cases out of the box, and the reset frequency makes it flexible enough in case users switche the account that they use the most.

So let me ask, which one should it be, supersede frequency data, or completely ignore it, if for a given domain we have both?

Since now the entries are listed by frequency rather than recency, I think a better strategy might be to store the frequency data in the .browserpass.json file, and just not do the priority feature. I originally proposed the priority feature due to inherent issues with recenty ordering of the entries, but now since those are fixed, the only issue remaning is cross-browser and cross-computer syncing of the frequency data. I think having a priority feature would also be redundant, since the most frequently used entries are naturally the highest priority. So I guess your example wouldn't really be applicable in this case - I'd only sort by frequency.