How does Suggestions Work?

When I open 1Password from the browser plugin, how does 1Password determine which secret entry to show in "Suggestions" based on the URL in the browser? I'm trying to limit the number of duplicates in my database by putting the URLs of each internal company website in my "Domain Credentials" secret, but other secrets with unrelated URLs keep showing up in "Suggestions".

I remember in older versions of 1Password there was a configuration option for something like "strict URL matching in Suggestions" but I can't find anything similar now.

Basically, I'd like info on how to customize the Suggestions experience when using the browser plugin. Help?


1Password Version: 7.3.1
Extension Version: 4.7.5.90
OS Version: 10.14.6
Sync Type: 1Password Cloud
Referrer: forum-search:how do suggestions work

«1

Comments

  • ag_ana
    ag_ana
    1Password Alumni

    Hi @bigfriggin!

    The main thing that 1Password looks at is the website fields in your 1Password items to know what to suggest to you. If you store the URLs for your entries in a different field ("Domain Credentials" in your case, if I understood correctly), 1Password will not be able to suggest the correct items for the website you are in, and will default to showing you even unrelated items.

  • AGAlumB
    AGAlumB
    1Password Alumni
    edited July 2019

    @bigfriggin: While we're not going to be able to share the code that does the rest as far as intelligently suggesting (non-Login) item based on the actual webpage, it's actually pretty simple, as far as website URLs: 1Password suggests Login matches for the current domain.tld; it will not show Logins which are for a different one. Otherwise a malicious website could trick you into filling credentials for another: your paypal.com Login will not be offered for filling at paypa1.com, as an example. I hope this helps! :)

  • Hi @bigfriggin

    The item you've highlighted does have liftengine.com in a website field on it... it is in website 5. It is nearly cut off in the screenshot, but that's why it is being suggested. Any Login items that have website fields where the "root" domain matches will be suggested, but ones more closely matching should be given higher priority. If you had one login item with a website field containing https://help.liftengine.com/scp/login.php in this case that should be listed as the first match.

    I really need to be able to enforce an exact suggestion match on *.domain.tld, not just domain.tld

    That isn't something that we currently offer, but I'll suggest to the team that we investigate how to improve this type of situation going forward. It would be great if we could account for this without hurting folks who need it to work the way it currently does. For example, I have an account on the rit.edu domain. Those credentials work on all sorts of hosts on that domain (e.g. gibson.rit.edu, start.rit.edu, sis.rit.edu, etc). I wouldn't want to have to save (and thus update) those credentials for every host, when one Login should cover it. Essentially just as many if not more systems are setup just the opposite of what you're asking for.

    Plus, there are all these non-login items like identities and credit cards, when none of these field of fields appear on the page.

    Correct; identities and credit cards are always suggested on every page, but they should be at the bottom of the list.

    Ben

  • AGAlumB
    AGAlumB
    1Password Alumni

    @bigfriggin: While Ben's example was a good one representative of what most users need (albeit not a domain I am familiar with -- apple.com versus appleid.apple.com would be a common example of where nearly everyone would expect the same Login to work on both), trust me: we also understand where you're coming from. We've got dozen of agilebits.com and 1password.com Logins ourselves and know that can get confusing sometimes. ;) We do, however, need to advocate for what will benefit the greatest number of 1Password users, even when it may conflict with our own personal use cases at times. I don't know what the solution is, but it's definitely not a toggle. We had one for a related feature years ago and it hurt a lot more than it helped, so we removed it. But we'll see if there's something else we can do in the future that might do more good than harm. Question: In your case, might it work for you to be able to designate a specific domain be treated more strictly? I can't promise we'll add a feature like that, but maybe it's worth considering. :)

  • littlebobbytables
    littlebobbytables
    1Password Alumni

    Hello @bigfriggin,

    Let's say I have two Login items for Amazon. The Amazon sign-in page is on https://www.amazon.com and one Login item correctly references www.amazon.com while the other only mentions amazon.com. If I access 1Password mini both will appear as they're both matches for the registered domain amazon.com. If though I use the keyboard shortcut ⌘\ it will always pick the www.amazon.com Login item as there is only one exact match.

    Although I haven't done any large scale tests, if you like to use ⌥⌘\ to access 1Password mini (keyboard equivalent to clicking the toolbar button) then the following is what I believe holds true.

    1. Any matches to at least the registered domain and our flagged as favourites. If more than one these will be ordered alphabetically.
    2. Exact matches to the FQDN and are not flagged as favourites. If more than one these will be ordered alphabetically.
    3. Matches to the registered domain and are not flagged as favourites. If more than one these will be ordered alphabetically.

    So potentially three groups depending on the numbers and each group will always appear in that order. If you're seeing something else please say but my current understanding is this is the expected behaviour.

    The trouble with adding extra options either at the global or individual item level is each new option increases the complexity of 1Password and we're painfully aware it already has a steep learning curve. We removed the option you're thinking of in 1Password 6 because all it did was cause confusion and I can't think I've ever interacted with a person that used it to good effect. Even if we claim something is an advanced option we have to weigh up the benefits from the support if it is misunderstood and misused. It's a delicate tightrope that if we get it wrong can make 1Password more difficult for a lot of people but with little gain. None of that helps but I hope you can understand why we sometimes need to be quite careful when adding new configurable settings.

  • littlebobbytables
    littlebobbytables
    1Password Alumni

    Hi @bigfriggin,

    For some very specific cases we have what we call domain equivalency. If you have a Login item saved for https://appleid.apple.com you would like it to appear when you're on https://www.icloud.com because that's another well known domain that Apple owns and uses. With the exception of Japan (I have no idea why I'm afraid) an Amazon account created on any of their domains works perfectly everywhere else. There are a few more but it isn't a large list at all. We have an entry on this list for ourselves as we own both of those domains. Now agilewebsolutions.com is before my time so I'm unsure what details there would make sense to associate with agilebits.com but I assume there must be a reason for its inclusion.

    So the match is intentional even though I cannot provide a clear explanation as to what credentials would be transferable between the two. Sorry I don't have anything more specific for that particular case although I hope the why puts you at some ease.

  • AGAlumB
    AGAlumB
    1Password Alumni

    In 2011 I believe it was that we changed the company name from "Agile Web Solutions" to "AgileBits". Since we own these domains and moved to the newer one, accounts that referenced the old were migrated to the new one. So that's an "equivalent domain" in the most literal sense. Apple is a better example I think because it's one most people are aware of, using the same Apple ID login credentials for iCloud as well. And yeah, unlike those, I had to create a separate amazon.co.jp account. :lol:

  • jgoeders
    jgoeders
    Community Member

    It would be great if the best matching URL were sorted to the top. Right now I have separate credentials for https://xx.sample.com/siteA and https://xx.sample.com/siteB, and have these exact urls listed in the website field for the 1password entry. However the suggestions don't seem to show me the closest matching URL first.

    I understand the need to handle equivalent subdomains and the such, so I know it is going to show me more suggestions than I would like, but it would be great if they could at least be sorted better.

    And yes, I like the idea of marking certain domains as more strict. Not sure if that potential feature could also be applied to my example where it isn't exactly a subdomain.

  • lando__
    lando__
    Community Member
    edited February 2020

    @bigfriggin,
    I have to jump on your bandwagon. The inability to isolate FQDN from basename is at best an annoyance, and at worst a basic feature whose absence is enough to warrant switching platforms entirely.

    At this point I would gladly use some interpreter or ruleset (PCRE?) nested deep in some advanced menu that would allow for this. As it stands, the advanced features specified in the Preferences leave a lot to be desired.

    @1Password, I truly mean this in the most positive way, if you intend to market this as an enterprise solution, FQDN segregation is a critical component. I can't tell you how many companies follow the URL scheme blahblahblah.example.com to access different resources. I'm quite surprised the demand has not yet reached a point where this implementation is not being seriously considered.

  • ag_ana
    ag_ana
    1Password Alumni

    @bigfriggin:

    This forum is the right place :+1: Thank you for the feedback once again! We will certainly keep it in mind as we continue making 1Password even better.

  • smackie
    smackie
    Community Member

    I was searching for a solution to this and stumbled on this thread so let me add a massive "oh god yes" to the request that @bigfriggin is making.

    I have a bunch of devices on a network DMZ in a data center. All of them are x.foo.org which means that the suggestions are horrible for me when I'm trying to log on. As I have multiple logins for a lot of the machines (admin and general user), I have to pay very careful attention to whichever entry I've selected. Even worse, some of the machines are docker engines and have a ton of services, each with their own auth info.

    The ability to define some explicit FQDN base names to 1Password (i.e. "foo.org") that should never be fuzzy matched would be a great addition. That way, I can add my DMZ info for 1Password get the explicit match I need.

    By the way, whilst we're on the topic, the ability to specify that the tcp port should be in the match as well would be excellent. I accept that this is very much a "Pro" user request but the ability to be able to specify per-FQDN domain options ("Default, Match On Exact FQDN, Match on Exact FQDN + Port") would be amazing.

    Cheers

  • schlappette
    schlappette
    Community Member

    I'm a relatively new 1Password customer, and I'm casting another vote for the ability to segregate explicit FQDN in the suggestions. At my large institution, many of our web services are SSO, so I can use my domain credentials. But other services are unavailable to the general school population, so do not utilize SSO, and have their own discrete logins. I don't want 1Password yelling at me for re-using credentials, so I've generated unique, strong passwords for those stand-alone systems.... and then get over a dozen suggestions from the 1Password autofill, simply because the URL is x.school.edu. I would love to see the ability to define explicit URL/FQDN matching in 1Password!

  • ag_ana
    ag_ana
    1Password Alumni

    Thank you to both of you for taking the time to join the discussion :+1: :)

  • mcarifio
    mcarifio
    Community Member

    The original question above was "how are suggestions made" and then a discussion of various improvements. I'd still like to read something that describes how suggestions are made and in what order and how the key/value pairs are used to populate a login form. I'm often confused by the suggestions made and by the values inserted by 1password. Some of that is probably pilot error (i.e. me), so I'd like to fix that first before suggesting more fixes like the one's above.

    Then again I can't resist. In addition to @smackie's excellent suggestion to define a match, it would also be useful for the suggester to indicate how it matched, e.g. "Matched FQDN x.foo.com" and so forth.

  • mcarifio
    mcarifio
    Community Member

    How did the forum software figure out exactly what I look like? Spooky...

  • smackie
    smackie
    Community Member

    Then again I can't resist. In addition to @smackie's excellent suggestion to define a match, it would also be useful for the suggester to indicate how it matched, e.g. "Matched FQDN x.foo.com" and so forth.

    To expand on @mcarifio's point, some indication of matching (for an FQDN with optional matching rules) would be useful.

    And, altho I didn't really expand on it in the original suggestion but it would be helpful to see the explicit TCP port as a peer of the match too. For example, the two service URLs

       https://server.foo.com:3000
       https://server.foo.com:8086
    

    match to wildly different things and there's no point offering one as a suggestion to the other (if the domain is flagged for extra careful matching). I'm always careful to have the proper URL in the login entry for these sort of machines to make sure that things don't get confused.

    And the following

      https://server-a.foo.com:3000
      https://server-a.foo.com:8086
      https://server-b.foo.com:3000
      https://server-b.foo.com:8086
    

    are all different endpoints and shouldn't fuzzy match against each other. In these cases, it'd be helpful to have a setting like

      foo.com = Match on exact FQDN + Port
    

    as a setting. In that case, you'd have to match the URL locator completely to get a suggestion. For other environments, this would work

      foo.com = Match on exact FQDN
    

    and would match the exact machine name but ignore the port. It would be helpful here to sort the matches so that if there is a port match, it shows up at the top.

    Finally, the default is what we have right now

      foo.com = Match on Domain (Default)
    

    Right - that's about as exhaustive as I can make this.

    Cheers!

  • osrl
    osrl
    Community Member

    It's probably related to this topic: I cannot search other website fields.

    I have multiple subdomains like subdomain1.domain.com, subdomain2.domain.com etc. When I search subdomain1 and press enter, 1Password will "open and fill". But It can't find subdomain2. So I can't "open and fill" other websites easily other than the first one.

  • osrl
    osrl
    Community Member

    It's probably related to this topic: I cannot search other website fields.

    I have multiple subdomains like subdomain1.domain.com, subdomain2.domain.com etc. When I search subdomain1 and press enter, 1Password will "open and fill". But It can't find subdomain2. So I can't "open and fill" other websites easily other than the first one.

  • paxmundi
    paxmundi
    Community Member

    @smackie I can only second that and I deeply wish that this feature gets included soon as I am in the same situation as you.
    Matching suggestions only with domain.tld while you have a passcard with the exact FQDN or even URL (with or without port) is ineffective.

This discussion has been closed.