Curious URL matching

destruct
destruct
Community Member
in 1Password in the Browser

Hi.

First off I want to say that overall I am a very satisfied user. In the vast majority of cases 1Password does exactly what I need. Good work!

Having said that, I'm seeing (in my opinion) suboptimal behavior and would like some clarification if possible.

I have a domain under which there are separate credentials for some sites vs others. There are enough sites under these that I don't want to have to add a URL for each one. In this case I have 2 1Password logins as follows.

Login1:
URL: https://abc.def.blah.com/

Login2:
URL: https://blah.com/
URL: https://ghi.blah.com/
URL: https://jkl.blah.com/

When I go to https://foo.ghi.blah.com/ it offers both Login1 and Login2 as options (and in that order), despite Login1 matching nothing but the base domain (which is an exact match for a URL in Login2).

Having read through some other threads about URL matching it seems like hashes for both the full name and the base domain are stored, which I get. So my questions are:

  1. Wouldn't exact-match of the base domain to a URL in Login2 (https://blah.com/) carry more weight than just a base match with Login1?
  2. Understanding that you can't do regex or partial matching due to the hash, would it be possible to have behavior like so:
  • For exact match, choose that login, done.
  • For no exact match but some login(s) with a matching base domain, decrypt those and do deeper matching
  1. If #2 is not possible, how about storing hashes of each level (or a configurable number of levels) of subdomain? So for https://foo.ghi.blah.com/ it would store hashes of the full name, and ghi.blah.com, and blah.com.
  2. if #3 is not possible, how about an "exact match only" on a per-login basis? Then I could at least tell it that Login1 should only be considered on an exact hostname match.

At the very least I would prefer to have some weighting, such that Login2 is offered at the top of the list (and hitting Enter selects it) instead of what appears to be alphabetical ordering currently. Login2 is clearly a better match than Login1 in the example above.

Thanks,

Clay

Comments

  • jxpx777
    jxpx777
    1Password Alumni

    Hi, Clay.

    First off I want to say that overall I am a very satisfied user. In the vast majority of cases 1Password does exactly what I need. Good work!

    Thanks so much for the kind words. They really do mean the world to us.

    I'm seeing (in my opinion) suboptimal behavior and would like some clarification if possible.

    As you know, this topic has been brought up before and right now, we don't have any plans to adjust this behavior. Your post is very well considered, though, so I think my reply needs to be as well. :blush:

    despite Login1 matching nothing but the base domain (which is an exact match for a URL in Login2).

    This isn't quite right. You have a Login with a URL whose full hostname is a substring of the page you're viewing. This isn't an exact match.

    Wouldn't exact-match of the base domain to a URL in Login2 (https://blah.com/) carry more weight than just a base match with Login1?

    I will need to review the code, but I think this is one point where if it doesn't behave this way, it probably should. If the hash of the hostname matches the full hostname hash of the item's URL, then we should indeed pick that one. But, pursuant to the "exact match" comment above, it would have to be an exact match and not merely a substring. Even www.blah.com is different from blah.com.

    For exact match, choose that login, done.

    As long as we're clear on what exact match means, then this is the current default behavior. If you have exactly one Login with a URL whose complete hostname matches the complete hostname of the page you're viewing, then it should choose that one. If you have more than one with such exact matching, then it should offer those to you first and then offer others behind the "Show N more Logins" menu item.

    For no exact match but some login(s) with a matching base domain, decrypt those and do deeper matching

    I think somewhere in one of my many posts on this topic, I have conceded that something similar to what you describe with decrypting and then doing additional matching or filtering would indeed be possible, but it comes at the cost of adding additional complexity to a feature that is already so confusing to so many people. Perhaps it would make it less confusing, but I'm not so sure about that, and deciding to take an additional step on this would require a lot of consideration about the possible trade-offs and what we might not be seeing. For instance, how does this survive a user with hundreds of Logins for the same root domain? How about if those Logins each have several URLs?

    If #2 is not possible, how about storing hashes of each level (or a configurable number of levels) of subdomain? So for https://foo.ghi.blah.com/ it would store hashes of the full name, and ghi.blah.com, and blah.com.

    I don't see us ever doing this. If we did, it would be all or nothing. Adding additional configuration for this kind of thing only adds complexity to the app for every user for a need that affects a small number of our users overall.

    if #3 is not possible, how about an "exact match only" on a per-login basis? Then I could at least tell it that Login1 should only be considered on an exact hostname match.

    This is closer to possible, but an additional checkbox for this use case is still very unlikely to happen. As soon as we would add this checkbox, we invite user confusion over its purpose and whether or not it applies to their particular use of the app.

    While I appreciate that this need affects your particular use of 1Password, I hope that it's not controversial to say that with millions of 1Password users out there, this is not a dominant use case. Making changes to this behavior would have consequences for every user for the benefit of a relatively small number of users that need this specialized functionality. We are very fond of saying that no decision is permanent around here. But given the teams' focus on 1Password 7 right now and all the rest of the irons we have in the fire, this isn't likely to get any significant attention from the people it would need to make it a salutary change (UX design, devs from all of our platform apps, etc) for the foreseeable future.

    Thanks again for your very thoughtful post, and I'm sorry I don't have a more favorable answer for you right now. Do let us know if we can help with anything else or if you have additional questions or concerns. We're always here to listen to your ideas and feedback.

    --
    Jamie Phelps
    Code Wrangler @ AgileBits
    Fort Worth, Texas

  • destruct
    destruct
    Community Member

    Thank you for the very detailed response. While my engineer-brain could keep this discussion going, I completely understand your point about probably fairly unique use cases compared to the majority. It is only a minor gripe for me, and if this is the worst thing I can find to complain about then it must be a pretty solid product. :) Thanks again, and I'll keep an eye on release notes in case someone decides to take pity on me in the future!

  • littlebobbytables
    littlebobbytables
    1Password Alumni

    One of the toughest aspects is balance. Ensuring any change doesn't invite confusion while at the same time making 1Password better. I've seen how an option can generate confusion and how often it gets enabled. I've seen how a single word can generate a ton of support requests which we didn't anticipate so it isn't the case that we always get it right - far from it. That means we may not be right here either but I do know that we need to do all we can to ensure 1Password is accessible and friendly which sometimes means saying no to certain power features that smaller groups of people might find useful. Hopefully we tread the line carefully and find ways to make it more useful without sacrificing ease.

This discussion has been closed.