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

Comments

  • ag_anaag_ana

    Team Member

    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.

  • bigfrigginbigfriggin Junior Member

    That was my understanding too. However, let's say I have one secret with exact website entries and another with similar websites, but far from the exact site I'm looking at in my browser. It will still show me both under "Suggestions" when using the browser. Can you fill me in on the minutia of the rules behind what "Suggestions" shows me so I can better use 1Password?

  • brentybrenty

    Team Member
    edited July 29

    @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! :)

  • bigfrigginbigfriggin Junior Member

    Thanks @brenty I wasn't specifically asking about code, but thanks for the vote of confidence!

    I was hoping for info on more granular control -- currently it seems like 1Password is suggesting items based on more than just the domain.tld. Here are 2 screenshots that show what I mean. Descriptions follow each:

    In the above screenshot, taken from this very page, we see that the domain.tld in the browser is discussions.agilebits.com. The 1Password plugin is showing an item intended only for support.agilewebsolutions.com. Plus, there are all these non-login items like identities and credit cards, when none of these field of fields appear on the page.

    In this screenshot, we see that that *.domain.tld is help.liftengine.com yet a bunch of items are being suggested. I'd be expecting that the only suggestions to show up here would be the ones with green arrows. These are the only items in my Vault that actually have help.liftengine.com in the website field of the 1Password record. All the others show different subdomains on our main domain.tld, (which may be ignored by design since you specifically said domain.tld not *.domain.tld, above) but some of my items' website entries _only_ have IP addresses.

    Didn't there used to be a "strict" option for suggestions? I've got over 2k login items in this Vault and I really need to be able to enforce an exact suggestion match on *.domain.tld, not just domain.tld, and right now I can’t do that. Plus I'm confused about including the suggestions that only have IP-address based URLs.

    Any suggestions?

  • BenBen AWS Team

    Team Member

    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

  • bigfrigginbigfriggin Junior Member

    The item you've highlighted does have liftengine.com in a website field on it...

    Hi @Ben you're right - I did see that one of the entries had liftengine.com in it way down the list there, so I now get why that one showed up. But why did it show up above the entries that actually had the exact match of help.liftengine.com in them? Is it because it's marked as a favorite in 1P?

    What about the first screenshot with discussions.agilebits.com vs. support.agilewebsolutions.com?

    It would be great if we could account for this without hurting folks who need it to work the way it currently does.

    With regards to the subdomain matching, I too have AD and RADIUS logins that work across hosts on the root domain, i.e. mail.liftengine.com, info.liftengine.com, etc. but I also have some in legitimately different subdomains like fry.esx.liftengine.com where the esx.liftengine.com part signifies a logical hierarchical split from the root domain.

    I know some organizations like to "abuse" hierarchical DNS to make things easier to understand (i.e. www.domain.com vs. staging.www.domain.com vs. qa.www.domain.com) but for organizations like mine that have historically sync'd-up our naming conventions hierarchically with our policy scope & security boundaries, the current way 1P does matching is too inclusive.

    Essentially, if the Suggestions mapping had an option to pull only items based on the full hierarchical domain name host.[subdomain.domain.tld] instead of just host.[domain.tld] and host.subdomain.[domain.tld], many existing use-cases would be well-served.

  • bigfrigginbigfriggin Junior Member
    edited July 30

    Thanks for the info @Ben I do see that the liftengine.com one is in there now. My bad.

    With regards to your example with rit.edu - you're absolutely right, HOST1.rit.edu and HOST2.rit.edu should have the same login credentials because rit.edu is the root domain. Showing these 1P logins in Suggestions at the same time makes perfect sense.

    But my organization aligns our policy & security boundaries with our naming conventions according to DNS's long-standing hierarchical formats. For me, HOST1.esx.domain.com and HOST1.domain.com are two very different hosts (both named HOST1) in two different domains (esx.domain.com vs. domain.com).

    @brenty above gave the paypal.com vs. paypa1.com example for why the suggestion matching is done - it would be quite undesirable and dangerous from a security perspective to suggest a login item for an unrelated URL. We unequivocally agree on this point.

    I'm arguing that for me and any other "old timers" that follow strict DNS naming & usage conventions, showing logins for both esx.domain.com and domain.com side-by-side in Suggestions is just as bad as showing paypal.com and paypa1.com at the same time.

    It would be a really bad thing if I accidentally sent my domain.com credentials to a server in the esx.domain.com management domain, and vice versa.

    Does that help with my ask?

  • bigfrigginbigfriggin Junior Member
    edited July 30

    And to be clear, I do understand both use cases, which is why I was hoping there was a toggle I could hit.

    I get that modern naming conventions have moved towards DNS-as-description (i.e. www.domain.com vs. qa.www.domain.com vs. staging.www.domain.com), but there are still a lot of shops out there properly following RFCs and defining their security & policy boundaries around DNS's original hierarchical namespace.

  • brentybrenty

    Team Member

    @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. :)

  • bigfrigginbigfriggin Junior Member

    @brenty I remember that feature change between 1Pv3 and 1Pv4, in fact it was the driver behind my first post here! I’m not claiming to know the perfect answer here. I just know that I’m either (a) finding myself needing to be very careful when choosing from suggestions or (b) spending time finding the appropriate suggestion that’s buried in the list.

    Both have the terrible effect of taking me out of my flow. I can’t ⌘\ nearly as much as I’d like to!

    My personal vote would be a per-item toggle that says something like “don’t include this login in Suggestions unless perfect FQDN match”. Maybe not even make the option visible without a master toggle in Advanced settings, I dunno.

  • bigfrigginbigfriggin Junior Member

    And yes, being able to treat a specific domain more strictly would also be very useful!

  • 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.

  • bigfrigginbigfriggin Junior Member

    Thanks @littlebobbytables @brenty @Ben and @ag_ana , I appreciate your candor on this. In the meantime I’ve decided to segment the entries I’m worried about into a different Vault that I only activate when necessary. That, and cleaning up the multiple duplicates I have accumulated in the least 10 years.

    One last question: referring back to my very first screenshot in this thread, what's the expected logic around the website being discussions.agilebits.com but the 1Password login item having support.agilewebsolutions.com as the only websites item?

  • 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.

  • brentybrenty

    Team Member

    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:

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Emoji
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file