Feature request: limit matching to subdomain [not possible]

SystemSystem

Team Member
edited August 8 in iOS Beta
This discussion was created from comments split from: 1Password AutoFill in iOS 12.

Comments

  • Great feature but they is room for improvement.
    First, it only works with the default keyboard. I have Google Keyboard, and the plugin doesn't show up.
    Second, when we have several possibles choices, it only displays the URL and username... but not the title!

    See:

    How can I select the right one in this configuration?

  • brentybrenty

    Team Member
    edited August 2018

    @celogeek: It's my understanding that only usernames and passwords are supported by Apple's autofill APIs, but I'd love to either be wrong or see that change in the future. "Titles" and other 1Password-specific fields not being used by something meant for general use makes some sense though, even if for our particular use case it would be nice. :)

    Regarding the keyboard, perhaps that's something Google could add support for in the future. But not having anything to do with 3rd party keyboards, I'm not sure that's even an option for them.

  • @brenty it wouldn't be a problem if 1password handle properly subdomains!

    I have a.domain, b.domain, c.domain with different passwords per sub domain. But 1password show them all instead of the sub domain I'm on it.

  • brentybrenty

    Team Member

    it wouldn't be a problem if 1password handle properly subdomains!

    @celogeek: What do you mean? I'm not having any trouble filling logins on any matching URL.

    I have a.domain, b.domain, c.domain with different passwords per sub domain. But 1password show them all instead of the sub domain I'm on it.

    Yep. That's intentional. Those are all the same domain, which will only have a single owner. Should 1Password not fill your appleid.apple.com at itunes.apple.com and store.apple.com? Were that the case, a lot more people would be going to iforgot.apple.com due to the confusion.

  • steve28steve28 Junior Member
    edited August 2018

    Yep. That's intentional. Those are all the same domain, which will only have a single owner. Should 1Password not fill your appleid.apple.com at itunes.apple.com and store.apple.com? Were that the case, a lot more people would be going to iforgot.apple.com due to the confusion.

    @brenty, the problem is the there are a lot of cases (me included) where someone works for an organization with many different systems. They ALL end in the same domain: company.com. However, they have to have different passwords, but same username, for these different systems. This has been discussed here several times, and the same argument for both ways is always given.

    Does the iOS integration allow 1p to choose the order in which the logins are displayed? If so, perhaps a compromise is the "longest match" could always be the first option?

  • brentybrenty

    Team Member

    @brenty, the problem is the there are a lot of cases (me included) where someone works for an organization with many different systems. They ALL end in the same domain: company.com. However, they have to have different passwords, but same username, for these different systems. This has been discussed here several times, and the same argument for both ways is always given.

    @steve28: Oh totally. We're in that camp too. ;) But it isn't the majority use case, and I think it would be shortsighted for us to make 1Password cater only to our situation. Most people are not_IT professionals with that kind of setup, and would find it confusing, frustrating, and downright infuriating if 1Password _didn't offer them logins matching the current domain. Fortunately I think technical folks like us are more than capable of understanding this and selecting the correct login. :)

    Does the iOS integration allow 1p to choose the order in which the logins are displayed? If so, perhaps a compromise is the "longest match" could always be the first option?

    It may be something we can do in the future. But we haven't even in our own extension so far because on most iOS devices it isn't feasible to show the context for a choice like this. To a user, it just looks like the items are in some nonsensical order, even if they're logically organized by best match. I would like to see us try to do something like this in a future redesign, but we really don't have as much to play with when it comes to the presentation of iOS 12 autofill. But if we can do it in a way that reads well to the user in the future that would be great.

  • @brenty what about if in the login you had an option (which was off by default) that allowed the selected login to not use sub domains in matching? Or is that a crazy idea

  • celogeekcelogeek
    edited August 2018

    Lots of people work in a company. Those companies has most of the time several services on different sub domains.
    And those people are not for most of them IT tech.
    So they just deal with the current implementation or choose another software that do the job as expected.

    I mean they is a really simple way to deal with this situation.
    First we try to lookup the best match. If the current sub domain has no match we try the domain above. If not we continue up to the main domain.
    This way it works in every situation for anyone !

    Ex: my.sub.domain.com
    Check: my.sub.domain.com
    Check if fail *.sub.domain.com
    Check if fail *.domain.com

  • btarolibtaroli
    edited August 2018

    I’ve seen outside examples of this too. 1&1 for example. I have logins stored for different services, such as admin, webmail, etc. but I have to select among different entries because of the domain matching. I even keep getting reminded that their webmail supports OTP, when actually it doesn’t. Their admin pages do, though.

    So this sort of most-specific matching would be a nice enhancement.

  • brentybrenty

    Team Member

    Thanks for the feedback, folks! I guess I don't quite understand why this would only be an issue now, since this is how 1Password has worked from the beginning. And indeed, as I mentioned above, the request being discussed here applies to our own use here at 1Password too. The trouble is that's simply not the case for most users, who do need to use their logins across a domain regardless of the subdomain (which, most people won't even know what that is). It's something we'll continue to evaluate, but it's important that we're not changing things for a small number of users at the expense of 1Password being usable by everyone else. :blush:

  • MrRooniMrRooni

    Team Member

    Hi folks. As Brenty mentioned, thank you for all your feedback. The issue we're running into here is that iOS is matching top-level domains. This means that it's treating a.example.com the same as b.example.com and so on. This is not something 1Password has any control over, we just give the system a collection of usernames and associated domains. From there on out it's up to iOS to display them.

    Regardless of our level control, however, I believe this behavior is correct. There are certainly cases where you might have different usernames and passwords for various subdomains, but in this cases you can tap on the 1Password… button to bring up our user interface and see them disambiguated.

  • evanmooreevanmoore
    edited August 2018

    I have a password story to share:
    In my company, we had situation where our users could use their own personal Active Directory credentials finally to sign into their website, but when they needed to access an external resource within their website they had to login 1 more time to get to this resource using their personal AD account. We called this double login problem. This double login was huge problem for our users, because no one wanted to log in one more time. I didn't see what the big deal was, because now everyone had their own personal credential, but to everyone else it was the end of the world and this was not the solution folks wanted ultimately. Although the solution was to fix the double login issue, which we eventually did a year later (AD claim was null), a work around for the time being was to give these users back their general login that didn't prompt them for credentials again and again. However, this work around would cause another problem, which was people entering their credentials wrong and locking the account thus locking everyone out. Oy vey!

    The point of this story... You're never going to hear the end of this request, because we can easily ignore all the QuickType suggestions presented to us and instead open 1Password itself by pressing "1Password..." but folks won't understand this until they investigate. They will look at this like it's a bug, but it's not bug it's by design. The folks participating in this beta are usually technical people, which is why we are noticing this issue and we understand you clearly are aware of this API limitation. I just ask if we can have a toggle to disable QuickType suggestions since Apple does not support custom titles within QuickTime suggestion menu at this time.

    Keep up the great work all!

  • brentybrenty

    Team Member

    Definitely something to consider. Ultimately the only thing we have control over is 1Password. But we'll continue to improve that, and all of us beta testing Apple's stuff can offer them feedback on their stuff too. Thanks for your thoughtful comments and kind words! :)

  • Hi @brenty, your example about apple.com / developer.apple.com / itunes.apple.com seems wrong because all apple.com properties redirect to idmsa.apple.com when logging in. I think all major ID providers (Microsoft, Yahoo, Apple, etc.) now do the same, with probably the notable exception of Amazon (where the problem is actually even worse than just subdomain matching, because many amazon.tld also accept the same password).

    I'm a new 1password user, and It looks like you already have some kind of hardcoded list of special sites, as you offer completions for icloud.com for passwords saved as apple.com (I haven't checked if you also offer amazon.de passwords for amazon.com, that was a major annoyance with my previous password manager).

    Since I'm badly hit by the bug reported here (wrong subdomain matching for many company websites), would you be open to evaluate the following change:

    • By default, limit matching to subdomain
    • Internally hardcode a list of notable exceptions that required subdomain matching like Amazon (where you might also want to hardcode many amazon.tlds as well for your non-US users that regularly switch between amazon.com and amazon.mytld)

    I would be surprised if there were more than 10 exceptions (sites that require subdomain matching) in Alexa top 500.

    This would solve the problems that I also have where on iOS it requires multiple clicks to find out which is the correct password in the common case where a company runs many different services on different subdomain.

    Did you ever evaluate such a change?

  • brentybrenty

    Team Member

    @giovannibajo: This is the sign in page for the appleid.apple.com example:

    https://appleid.apple.com/#!&page=signin

    You may be right about the others, but appleid.apple.com will by far get the most use among Apple users, so I do think it's relevant. Anyway, if you've got a better example, let me know. Anyway, it's just an example. Amazon is a good one, and nothing to sneeze at. I think you get my point. :) This isn't a bug. It's working as intended, for the reasons discussed above. And, ultimately, it's not something we have control over anyway, as iOS Password Autofill is an OS feature, not a 1Password feature. I'm glad it works this way though since that helps the vast majority of users, even if it means I sometimes have to take a second to select the correct *.agilebits.com or *.1password.com login credentials. :)

  • The page you linked contains a form that is an iframe to imdsa.apple.com. To the best of my understanding, all logins to AppleIDs now go through idmsa.apple.com, and most of them through redirects. So again, limiting to idmsa.apple.com should work (though I'm not sure what is your policy wrt iframes).

    But again: even if it wasn't true (like Amazon), my proposal above is to consider this an exception, and only complete subdomains for a handful of websites where the single sign-on system doesn't redirect to a central login server. Even if they are as popular as Apple and Amazon, it should be a very short list of exceptions. In fact, you already have an exception for Amazon, as you correctly suggest logins for amazon.* (I guess with a closed list of TLDs).

  • brentybrenty

    Team Member

    @giovannibajo: I should have mentioned that myself, so I'm glad you brought it up. Think of it this way: if matching/filling worked the way that you're suggesting, it would silently fail when trying to fill into an iframe from idmsa.apple.com with the page being from appleid.apple.com. I think we can agree that would be an awful user experience for pretty much anyone. :)

    I get your point about making exceptions for specific domains (to have subdomains treated as different sites), but not only does that not scale well, it's not a decision for us to make. That's already being done by Mozilla, and we use it in 1Password:

    https://publicsuffix.org/

    We already see a lot of confusion from users (and, frankly, for us, trying to understand the issue they're having) in cases where governments have explicitly requested to have domains added to the list to be treated the way you're suggesting. A recent example was someone who couldn't figure out why their something.gov.uk login wasn't offered at somethingelse.gov.uk. Another was some Australian municipality which I forget. The answer, of course, is that this is how the governments want these to be handled -- as separate websites. Companies do this too. Just look at the list. You can certainly request that your own domain(s) be added too. But I don't think it makes sense for us to start making decisions about public suffixes unilaterally, even if we could (which is not the case with iOS Password Autofill anyway), as that would cause much more trouble for users compared to just needing to select the correct login credentials when you have too many.

    Also, what you're talking about with the Amazon example is completely different from matching all logins for the same domain -- e.g. *.apple.com. In our own software, we use equivalent domains for different domains which are, well...well-known to be equivalent: apple.com and icloud.com; amazon.com and amazon.uk -- they are literally the same company using the same accounts, just offering different services to the user. Treating subdomains as domains is very different, has repercussions for all users, and there's a standard process in place for cases where that needs to be done. We'd make the same call if it were up to us, but in this context it's very much outside the scope of 1Password.

Leave a Comment

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