Autofill... domain matching choices?!? O. M. G.

steve28

Holy crap. It's here! Mostly!

It would be awesome if you had ONE more choice:

• domain only: match as long as domain.com matched
• host: the full host needs to match (i.e., sub.domain.com)
• full URL: the full host, port, and path

---

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Browser:_ Not Provided

DenalB

Great idea, @steve28 !

+1 vote from me 👍

ag_Gabriele

Hi steve28, glad you noticed the changes :) I’m one of the designers behind this feature and it’s part of a bigger set of changes to coming to Autofill.

Currently we only support the “default” behavior (loose matching), strict matching by host (whole host including subdomains must match exactly) and “never” which causes the item to never show as a suggestion on the specified URL.

We’re working on an overhaul to the algorithm used for Autofill suggestions which might help address your other concerns. We’ve made it so that the suggestions now take into account the path, the subdomain, the port and scheme in order to boost the most fitting suggestions.

This update to the algorithm is still a work in progress and disabled by default. It can be enabled in the betas, under Autofill settings in the extension and under advanced settings in the desktop app. Enabling in on both will give you consistent suggestions across the extension and the desktop app as a nice bonus :)

Please be warned that these features are experimental and not ready for prime time. There’s no risk to testing them out but you’ll probably run into bugs like duplicated suggestions or suggestions for items you’ve archived or recently deleted. We’re ironing those out.

As long as you don’t depend on these features for your daily work, or just want to give them a 15-minute try, feel free to give them a shot and report on your thoughts :)

Tertius3

@ag_Gabriele I'm using them in the beta plugin, and I notice one annoying thing has vanished: a favorited but not exactly matching entry was shown above a perfectly matching (including subdomain) but non-favorited entry. Now the perfectly matching entry is the first offered choice. This is the way it should be.

roustem

This is the way it should be.

Huh, I just came here to complain that the new matching algorithm completely broke my workflows for Google and Amazon where I have close to 200+ logins combined. I now see logins that I would use maybe once a year showing at the top of the list.

I used to manually mark a few items as favourites and they always showed on top.

Tertius3

To elaborate what I find good:
I have a favorited entry for www.somedomain.de. I have another non-favorited entry for hostname.home.somedomain.de.
I request hostname.home.somedomain.de with my browser, and previously, I was offered both entries with the favorited one on top for login. That was clearly wrong, since the second one was a better match. Now, with the different matching algorithm I was offered the second entry first, and that's what I wanted in the first place.
However, I also set the second entry to "only fill on this exact domain" in the website details of the 1password login entry. Dunno which setting actually made the change - the configuration in the item or the global plugin configuration setting.

ag_Gabriele

Both changes probably helped in different ways. Setting something to “only fill on this exact domain” won’t affect how it ranks in suggestions, just whether it displays or not. Although adding this as an extra signal to the ranking algorithm is something that might be worth considering.

DenalB

Hey @ag_Gabriele !

and “never” which causes the item to never show as a suggestion on the specified URL

Sounds good. But I don't have a setting for "never". I'm using 1Password for Windows 8.9.11 (80911014).

It can be enabled in the betas, under Autofill settings in the extension and under advanced settings in the desktop app.

I have this setting in 1Password for Firefox beta 2.6.1, but not in 1Password for Windows 8.9.11 (80911014).

Maybe this setting appears in the next beta build for Windows. 😉

There’s no risk to testing them out but you’ll probably run into bugs like duplicated suggestions or suggestions for items you’ve archived or recently deleted.

That's what I recognized already, and that's why I disabled the setting in the browser extension after trying for a day. 😊
https://1password.community/discussion/135868/setting-improved-autofill-suggestions-what-does-it-mean

ag_Gabriele

@DenalB apologies, “never”’s actually only found in the nightly for now. If you’re on windows, you also won’t see the new setting under “advanced” because that’s part of the Universal Autofill feature found on the macOS version only. It’s not currently available on windows because we don’t have the ability to support Universal Autofill there. By using the browser extension, you should get most of the mileage out of this feature.

Hope you get to try the setting again in the next beta, and let us know how it feels. Those known issues should most likely be fixed then.

Gabriele

DenalB

Hey @ag_Gabriele !

Hope you get to try the setting again in the next beta, and let us know how it feels.

I'll do so. 😉

Those known issues should most likely be fixed then.

I'm looking forward to these fixes.

ag_Gabriele

Lovely! If you have any questions or feedback we're always here to listen.

Cheers,
Gab

robochacho

I'm trialing 1Password over a competitor and you have me as an instant customer if the new autofill features work well.

Question - will we have the ability to set a global default autofill behavior? Editing hundreds of logins sounds miserable or am I overlooking something?

ag_Gabriele

@robochacho happy to hear! Let us know about your experience with these new features.

We haven't looked into allowing you to set a global default, however we'd like to hear more about bulk use-cases and see what we can do to help with that. Can you tell us more about the nature of the logins you'd be editing? I imagine the "only fill on this exact domain" behavior is only useful in certain situations, so would it make more sense to you to have a global default or a way to change specific items in bulk?

Tertius3

@robochacho Websites tend to change their hostname part. Often it is "www.somewebsite.com", but sometimes "www1.somewebsite.com" and more digits 1..9, "login.somewebsite.com", or just "somewebsite.com", or whatever prefix their admins choose. This prefix is changed now and then during the lifetime of the website, invisible to the user, so I feel the default ("fill anywhere") is just right - it ignores any prefix and matches just *.somewebsite.com. Otherwise, 1Password would just stop offering autofill if the prefix is changed behind the scenes, and you are suddenly locked out until you manually find that entry and correct it.

If you really have some website where you must match even the hostname part, you can change the matching. However, that's usually not the vast majority of entries.

DenalB

@ag_Gabriele
Instead of having a setting Never fill on this website in every login entry, it would be much better to decide on specific websites not to show any suggestions, like a blacklist or something. And I know that there is a long-awaited feature request for the extension, already. 😉

ag_Gabriele

@DenalB thanks for the feedback. Just thinking through this, I wonder if those two things would be mutually exclusive in your perception? I.e. are there situations where a hypothetical "don't show suggestions on this website" option would be useful and where the existing "Never fill on this website" wouldn't, or vice versa? For example one scenario I can think of is a website where you don't want some suggestions but not all. Whereas on some other sites (or maybe specific pages?), as you say, you might want to disable suggestions altogether. Curious about your thoughts.

Tertius3

@ag_Gabriele If you have some desktop app login, but no website login, you never want this login show up as suggestion in the browser plugin. But you might enter the manufacturer website as website url, so it is eligible by the browser plugin. If you have an additional login entry for the website (same URL) but with different credentials, you want this login show up in the browser plugin - but still not the app login.

ag_Gabriele

@Tertius3 interesting, thanks. So far, there have been no changes yet to how autofill works with Desktop applications on macOS, so the new rules don't apply there. That's something we're looking at doing in the future. I'll keep track of your feedback so we can get back to it once we start working on that.

Please let me know if there's anything else I can help with, or if you have more feedback.

wagnerone

Our team was one that has been heavily affected by decision to not include this v7 feature in v8.

I was overjoyed to see discussion of this being added to v8, but dismayed when I realized all the many records we set to "don't show in browser" in v7 do not have this flag set in v8.

How do I efficiently find all records that have this value set in v7 and correspondingly set it in v8?

Please do not tell me I have to edit each and every record.

ag_Gabriele

@wagnerone Thanks for bringing this up, that's something we hadn't considered. We can probably find a way to provide backwards compatibility so that you don't have to do that manually. We'll be looking into that.

wagnerone

@ag_Gabriele Thank you! That would be awesome and highly appreciated!

PeterG_1P

Thanks for the suggestion, @wagnerone! 🙌

ag_Gabriele

Hey all, we discussed this internally and it's now on our radar. Unfortunately due to the busy start of the year, this particular backwards-compatibility fix won't be making it into the beta as soon as all the other improvements will. You can potentially expect it later in the year or near the end of the year, but I just want to be clear that we cannot promise any specific timeline. That said, it's something we definitely aim to do.

Please keep in touch if you have further questions, or if you have further feedback about this or other parts of the feature. All of it will help us improve our priorities and timelines.

Cheers,
Gabriele

wagnerone

Is there guidance on how to find all records with the old flag set so we can change them ourselves?

I'd hate to edit each record manually, but if it's going to be that long, I may have to for the sanity of our team's sake!

If there is no way to find all these records in order to edit them manually, I guess the only option is to wait.

Thanks!
Mike

ag_Gabriele

@wagnerone let me look into this and come back to you.

1Passworder1

While we are on this topic, would it be possible to have some visual indicator on the entry to highlight which type of autofill behavior it has saved?

For example, right now the entire host part is highlighted blue; no matter whether I have "anywhere on this website", or "exact domain" selected.

Maybe you can make it so that -

• only the domain part (e.g. overdrive.com) becomes blue for "anywhere on this website"
• entire host part (spl.auth.overdrive.com) becomes blue for "exact domain"

Or if you have any better ideas on how to indicate it to the users "at a glance".

EDIT - btw, the autofill-behavior help page linked below the options is throwing 404.

ag_Gabriele

@1Passworder1 hey, thanks for the feedback! That's something we've been working on and you should see it in one of the upcoming betas. It will look something like this:

We're always open to hearing your feedback!

Cheers,
Gab

ag_Gabriele

@wagnerone we looked into whether the 1Password CLI could help with your setup but currently we don't support the sort of advanced editing that would be required to control those specific options. I'm afraid there's no quick workaround in this case, but as I said we've added this to our list of work to do and we will get around to it in the future. I can't promise a timeline unfortunately, we'll be very busy with other priorities until late in the year.

If you have any extra information about your workflow (without revealing anything personally identifiable please), it would be useful to know why you were using that option. Specifically, I'm curious to know more about why you prefer to set the display option rather than remove the problematic URLs from the item. I realize those are not equivalent and I imagine the reason lies somewhere in there, but curious to hear the full story either way :)

Cheers,
Gabriele

wagnerone

Thanks for the update, @ag_Gabriele

We rotate passwords on a regular basis for many app stacks we manage and just got into the habit years ago of making new records every time we do this so we can keep all the old records intact as a set with whatever historical references the records accumulated throughout their lifetime. We want the records to exist in perpetuity, but we don't want them polluting our teams form filling options.

Ever since we switched to v8 all our developer, devops teams, etc. where we used to have a single entry pop up to fill a form, we now have like 20 records show up for every site we log into countless times a week to work on things because that v7 attribute is not honored. It's enough to drive a person mad.

It was suggested we use different vaults, hide them, etc., but that is as disruptive a change as having to deal with this in the short term. We're a busy team, we already maintain too many vaults as it is, and it would be a paradigm shift to deal with.

ag_Gabriele

@wagnerone interesting, thanks for explaining. I wonder if the “archive” feature found in 1Password 8 would help your use case. Archived items remain perfectly intact for an indefinite time, but they never get suggested in the browser. Anyone in the team can access them at any point via the app.

Secondarily (although I know you mentioned you prefer not to edit existing items), 1Password 8 has a password history feature that lets you keep track of all the password a specific item’s ever had. You can see them by using the drop-down next to the password field. I imagine the workflow your team has is already fairly set, but I wanted to mention this possibility.

I’m curious if any of these approaches would work for you.

Cheers,
Gabriele

DenalB

@ag_Gabriele

Just thinking through this, I wonder if those two things would be mutually exclusive in your perception? I.e. are there situations where a hypothetical "don't show suggestions on this website" option would be useful and where the existing "Never fill on this website" wouldn't, or vice versa?

Sorry, I missed that comment ... 🤔

Yes, there are situations where I would love to have an option for Don't show suggestions on this website. On my banking website, I don't want to use autofill. Normally it looks like this:

But the suggested credential is the password only for the app version. So, I'm not able to use it either here on the website.

When switching the autofill behavior to Never fill on this website in this entry, the credential is not suggested. But the suggestion popup is still available.

That's where the possibility to disable suggestions on the website makes sense. And for such an option, a long awaited feature request should exist already. 😉