iOS 12 Autofill Technical Details

craig_francis

Following on from:
https://discussions.agilebits.com/discussion/comment/462382/#Comment_462382

From a technical point of view, can you explain exactly what account details 1Password exports to iOS... which Safari uses to list the accounts that 1Password stores.

I'm mostly interested in the domain; e.g. is it the Full or Top Level Domain? and what happens if a login has more than one domain?

For example, if I have a Login with the details:

Username: craig
Website 1: https://a.example.com
Website 2: https://b.c.example.com

What is exported?

I'm hoping to get Ricky from Apple to look at this, as the domain I use for developing websites currently has 52 logins associated with it, and iOS does a very poor job at showing the most relevant one for the specific sub-domain (e.g. I would hope it would focus on the exact matches first, but that won't be possible if 1Password only exports the Top Level Domain).

---

1Password Version: iOS 7.2.2
Extension Version: Not Provided
OS Version: iOS 12.1 (16B92)
Sync Type: Not Provided

AGAlumB

@craig_francis: It's really simple: 1Password gives iOS a list of TLDs and their corresponding username and password -- just those three pieces of information. I think it's best not to think of it in terms of a Login item in 1Password, as it's not the same thing; iOS 12 Password Autofill is meant to be much more general-purpose, not tied to how one specific app organizes and presents information. Does that make sense? :)

P.S: Ricky is a good guy, but I'm not sure how much luck you'll have selling that. 52 logins really sounds like an edge case. ;)

craig_francis

I’m hoping one of your programmers can confirm if it is the TLD (Top Level Domain), or the FQDN (Fully Qualified Domain Name).

I was talking to Ricky at the Passwords conference in Stockholm on the 19/20th Nov, and he wanted to know exactly what you were exporting, because he agreed that there was a problem (even for people who might only have a couple of logins for a domain).

AGAlumB

I’m hoping one of your programmers can confirm if it is the TLD (Top Level Domain), or the FQDN (Fully Qualified Domain Name).

@craig_francis: I said TLD. But I realize that technically I misspoke. It's really neither TLD nor FQDN. It's the "naked domain" -- e.g. apple.com -- since that's what the feature uses: it doesn't do "Open and Fill", for example, so the full URI is not useful.

I was talking to Ricky at the Passwords conference in Stockholm on the 19/20th Nov, and he wanted to know exactly what you were exporting, because he agreed that there was a problem (even for people who might only have a couple of logins for a domain).

I'm not seeing that. It looks like it won't display more than 4 or 5 inline. Any more than that (or, if it's just more convenient for your use case, since 1Password can display more details -- iOS 12 Password Autofill UI does not contain much information), you'll need to tap "Passwords"/key icon to bring up a full list of matches (or "1Password..." at the bottom). There's potentially more we'd like to do with 1Password's UI there when you open it though. :)

craig_francis

Thanks @brenty,

I just wanted to check if it was the TLD (apple.com) or the FQDN (www.apple.com).

As you're exporting the former, then iOS has no chance of being able to do anything clever with the filtering (i.e. selecting the best match by default).

Is there a reason you decided to only do the TLD?

As in, when someone had a login for "www.twitter.com", didn't iOS offer it as an option when they were "mobile.twitter.com"?

I don't think the full URL is relevant or needed here, but maybe that might be useful in future.

With that information I can raise a bug report with Apple, cc in Ricky, and see if we can get the iOS API updated so that you can provide the FQDN as well... then iOS can do any post-processing necessary, and still have the extra information to make better choices.

AGAlumB

I just wanted to check if it was the TLD (apple.com) or the FQDN (www.apple.com). As you're exporting the former, then iOS has no chance of being able to do anything clever with the filtering (i.e. selecting the best match by default). Is there a reason you decided to only do the TLD?

We didn't. Top Level Domain is ".com" in your example, etc. I think you misunderstood my earlier reply. We're giving iOS the "naked domain", e.g. "apple.com", since that's what is supported. Perhaps something more granular will be supported in the future, but it's impossible to say at this point.

As in, when someone had a login for "www.twitter.com", didn't iOS offer it as an option when they were "mobile.twitter.com"? I don't think the full URL is relevant or needed here, but maybe that might be useful in future.

It really depends on what the feature is meant to do. Given that it only supports filling a username and password at a matching domain, this does seem sufficient -- though I can certainly understand your desire for more complex possibilities; they're just not available at this time.

With that information I can raise a bug report with Apple, cc in Ricky, and see if we can get the iOS API updated so that you can provide the FQDN as well... then iOS can do any post-processing necessary, and still have the extra information to make better choices.

I'm not sure I agree that there's any bug. It seems to be working exactly as designed, even if it doesn't fit your particular wishes. But certainly there's nothing wrong with enhancement requests. Cheers! :)

craig_francis

When you say more complex possibilities are not available at this time...

I'm just wondering, if 1Password did export a login for the domain "www.twitter.com" (not stripping it back to "twitter.com"), what would happen if the user tried filling logging in on "mobile.twitter.com"?

I'm trying to work out if iOS needs to change (as in, do the same kind of work you are doing, but for all password managers and it's own keychain)... or if it does already do this, then you're stripping useful information for no reason, meaning that iOS has no chance of being able to list the logins based on the best match first.

Also, sorry, I should have double checked what TLD meant, it's been a few years.

ag_andrew

Hi @craig_francis,

We do our best to provide autofill with broadest match we can. So if your item is https://www.twitter.com for example, we give the AutoFill system just "twitter.com". In my tests, iOS will happily use our "twitter.com" url and successfully bring up that item on "mobile.twitter.com".

Let us know if you run into any situations you think should return a result that aren't, and we'll take a look and see if we can't improve things for you.

craig_francis

Hi @ag_andrew,

I'm trying to do the opposite, while not breaking the feature you describe.

Can you say what iOS does if you did provide the full domain?

I ask because iOS might do this lose matching already (and if not, I could ask them to make some changes).

For example... if you were to provide the full domain, iOS could already be handling the "www.twitter.com" vs "mobile.twitter.com" situation... and, by having access to the full domain, iOS could also select the best login if many are available under a single domain.

In my case I'm a website developer, with 52 logins under a single domain, each login is linked to it's own sub-domain; where it's currently impossible to use when they all have the same Name and Domain being shown on the list.

Craig

AGAlumB

I don't disagree with you, but that isn't how it works. iOS does not care about a "best" login; it lists all for the domain, regardless of subdomain. You can test this yourself by disabling 1Password and creating some logins to use with iCloud Keychain. For example, logins for both "www.twitter.com" and "mobile.twitter.com" will be offered to you at any twitter.com page. I can see how it might be useful to some extent to have a subdomain listed in the UI, but it can also be confusing for other users since the subdomain is irrelevant for filling.

craig_francis

So iOS does do the right thing, in that it finds all accounts for the domain (where an account associated with "www.twitter.com" will still be available on "mobile.twitter.com")?

But you decide to strip the sub-domain, because it might be confusing?

That means iOS never has access to the sub-domain information, and cannot filter for the best match when someone does have multiple logins for a domain.

Are you sure this is the right approach? as the cases you are thinking of, the user will only have 1 login, so the account selection list isn't necessary, they just tap on the big blue "Use XXX" button.

AGAlumB

@craig_francis: iOS ignores the subdomain. Try it.

craig_francis

@brenty

I've not done a big test, but it looks like iOS keychain does record the full domain, suggests the best match (as "for this website"), and provides the alternative logins as well.

AGAlumB

That's iOS 12 Password Autofill, not 1Password. Similarly, when you use iOS 12 Password Autofill for login credentials from 1Password, the UI is also iOS 12 Password Autofill. I get what you're saying, but at the end of the day we don't have any control over the presentation when you're using iOS 12 Password Autofill. We'll continue to iterate on 1Password's own UI though. Cheers! :)

craig_francis

It’s the exporting of login details for iOS Password Autofill that I’m taking about.

At the moment you are exporting a list of logins for iOS, this includes the username and the domain, but you are removing the sub-domain (as you call it, you are only exporting the “naked domain”).

I don’t think you should be removing the sub-domain.

iOS needs the sub-domain to do better matching, and it also handles the Twitter problem for you.

Currently 1Password is broken to me on my development websites (which will be the same for any website developer who works on multiple websites under a dev domain).

ag_kevin

Hi @craig_francis ,

Password is currently exporting the naked domain. We are looking into expanding that to export the full domain, but it's not available yet.

Cheers,
Kevin

ref: apple-2665

craig_francis

Great, thanks @ag_kevin

Would I be able to help beta test that?

At the moment I'm having to copy/paste login details, as the current implementation is causing so many problems... where I do also use normal websites as well, so I can test those, and check that this change won't introduce any issues.

ag_kevin

Hi @craig_francis ,

Here is how to join the beta: https://discussions.agilebits.com/discussion/58717/joining-the-1password-for-ios-beta#latest

Note that we do not yet have a timeline when this will be in beta, but you will see it in the release notes when it is available.

Cheers,
Kevin

craig_francis

Thanks, email sent.

AGKyle

Thanks @craig_francis

You should have gotten the details necessary to sign up for the beta. If not please let me know.

craig_francis

Yep, a quick and easy set of instructions, now on 7.2.5 :-)

Ben

Excellent. :)

Ben

AGAlumB

@craig_francis: Also keep in mind that you probably don't have to copy and paste, especially with websites, even if you're not using iOS 12 Password Autofill. You can still use the 1Password iOS extension from the Share [ ↑ ] menu, and 1Password's UI there is designed to provide more information at a glance too. Cheers! :)

craig_francis

@brenty ... kind of, but unfortunately copy/paste is easier for my situation.

For the websites I'm not building, then the iOS Password Autofill feature works well (because I only have 1 login per domain).

For the websites I am building, I have to think about end users more than myself, so I try to auto fill the username/email field based on their previous login, and I auto focus the most appropriate field (typically the password field).

So when the page loads, the iOS keyboard immediately appears... for the users, that's good, because the iOS Password Autofill feature works; but for me, where all my websites are developed under a single domain, the wrong login appears... so I'll either have to press the key icon to see the iOS list of many logins (which is useless, as 1Password only exports the "naked domain") and then scroll all the way to the bottom of a fairly long list... or I'll have to dismiss the keyboard, open the share menu, select 1Password, then have the fun of working with this list (which has got better recently, as the best matches are now towards the top, but it could still do with a dividing gap/line, as some websites I develop do have different logins depending on their access level, and that requires a bit more time to scan and identify).

AGAlumB

That makes sense. Thanks for elaborating! :) :+1: