Support autofill for applications on Mac

jdfrench
jdfrench
Community Member
in Mac

The 1Password plugin for iOS is great (in those few apps that support it). Why not bring something similar to Mac? Thanks to the less-sandboxed nature of OS X, it wouldn't even require applications to build in support (though it would probably require "access for assistive devices"), and could automatically select the right password based on the focused application (just as the browser plugins do it based on the current webpage).

1Password Version: Not Provided
Extension Version: Not Provided
OS Version: Not Provided
Sync Type: Not Provided
Referrer: forum-search:In-app autofill on Mac

Comments

  • rickfillion
    rickfillion

    Hi @jdfrench,

    Thanks for writing in. Unfortunately it's a little more complicated than that. There's a couple different problems at play here.

    1. 1Password itself has to be able to do this while sandboxed, since we sell it on the Mac App Store as well.
    2. Detecting which app is focused is easy. But translating which an app to its URL is trickier. So you need some kind of hint from the app about what URL we should look for. This is passed to us by the calling application on iOS.
    3. We'd rather be able to do it without using Access for Assistive Devices, cause that comes with its own issues. But then we need to find a way to return the data in a secure manner. This would require some code running in the other app. Then we hit problems with mutual authentication across processes, and making sure that no one is listening in on the communication.

    It's something that would be very cool, and every now and again one of us comes up with a prototype that's one step closer... but so far we're not there yet.

    Cheers.

    Rick

  • dgivone
    dgivone
    Community Member

    +1 for this feature. Everyone uses a combination of desktop and web apps so having this feature creates parity between the two experiences.

    I think this can be accomplished uses three different means:

    1) A plugin approach that the application explicitly supports (similar to iOS). Maintains the sandbox approach.

    2) A non-plugin approach that maybe uses a local web server to serve passwords to the application directly. 1Password could even maintain a white/black list of apps for an extra layer of security. The application would have to send some domain information that would have to be verified by the web server.

    3) Access for Assistive Devices approach, which would only be available for direct download. You could create a separate daemon that is downloaded separate that can act as a translation layer for the sandbox. I really think this is the best approach and in a way it was the purpose of the Assistive Devices API, ie. for apps to communicate with each other. With the assistive devices approach you could scan the UI hierarchy to try and find the username/password. Since 1Password is such a popular app, they may let you in the AppStore with the feature. I think you can modify the text/password box directly when using assistive device so it may still be as secure as typing, provided the app is using the secure input API for the text field.

    You mentioned translating an app to its URL is tricky, but you have a lot of information to go by:
    1) The bundle ID - the bundle id is in reverse dns form, so you could reverse it back
    2) The application name - The name alone can provide the mapping between app and password

    I think 1Password could also have a field associated with each entry that can associate an entry to an application. This would be a one time setup and similar to creating an account. 1Password could slurp up any information about the app using the Info.plist. It could also just give the user a dropdown of all the apps on the machine (not sure if that is possible with sandboxing).

    Another similar feature which is kind of like a lightweight version of the above feature would be to detect the current running application when the 1Password menu item it opened. The menu item could search using the application's name and bundle id and have it pre-populate the search results so when the user wants a password there is already a good guess.

    I think this would be a great feature addition to 1Password and really hope you guys add it.

  • AGAlumB
    AGAlumB
    1Password Alumni

    1) A plugin approach that the application explicitly supports (similar to iOS). Maintains the sandbox approach.

    @dgivone: It isn't something that's possible yet, but perhaps someday in the future. ;)

    2) A non-plugin approach that maybe uses a local web server to serve passwords to the application directly. 1Password could even maintain a white/black list of apps for an extra layer of security. The application would have to send some domain information that would have to be verified by the web server.

    This is sort of how the browser extensions work now. But while 1Password can validate our extensions (since we make both), to make it work with other apps we'd need to vet them and validate their signature. That's really not feasible. On iOS, Apple approves and signs all apps available in the App Store, so there's a chain of trust there that our iOS extension can take advantage of.

    3) Access for Assistive Devices approach, which would only be available for direct download. You could create a separate daemon that is downloaded separate that can act as a translation layer for the sandbox. I really think this is the best approach and in a way it was the purpose of the Assistive Devices API, ie. for apps to communicate with each other. With the assistive devices approach you could scan the UI hierarchy to try and find the username/password. Since 1Password is such a popular app, they may let you in the AppStore with the feature. I think you can modify the text/password box directly when using assistive device so it may still be as secure as typing, provided the app is using the secure input API for the text field.

    It's an interesting idea

    You mentioned translating an app to its URL is tricky, but you have a lot of information to go by:
    1) The bundle ID - the bundle id is in reverse dns form, so you could reverse it back
    2) The application name - The name alone can provide the mapping between app and password

    As we've seen in the past, this is very spoofable, and therefore exploitable. Things have improved a bit at the OS security level, but it's a problem without a good solution given the legacy baggage. When Apple changes the way OS X works at such a fundamental level to improve security, it means some growing pains for both developers and users on the platform.

    I think 1Password could also have a field associated with each entry that can associate an entry to an application. This would be a one time setup and similar to creating an account. 1Password could slurp up any information about the app using the Info.plist. It could also just give the user a dropdown of all the apps on the machine (not sure if that is possible with sandboxing).
    Another similar feature which is kind of like a lightweight version of the above feature would be to detect the current running application when the 1Password menu item it opened. The menu item could search using the application's name and bundle id and have it pre-populate the search results so when the user wants a password there is already a good guess.
    I think this would be a great feature addition to 1Password and really hope you guys add it.

    If we can get a way to securely interact with 3rd party apps on OS X (the way we can on iOS), that would be great, and it could enable a lot of convenience for all of us without compromising security. Thanks for bringing this up! :)

  • dgivone
    dgivone
    Community Member

    The bundle id and name are spoofable, but not if the application is signed. You can do a sign check to verify whether or not the system trusts the application therefore allowing you to safely read the bundle information. If the app is signed correctly, the system inherently trusts the application.

    Also, the last idea of just using the app name and bundle to prepopulate a search for the 1Password quick view would be a big step forward and it could already be done securely. Interacting this way is probably what the users are already do when prompted for a password from 3rd party apps. For instance, when I open the app store and want to purchase an app, the app store prompts me for a username and password. I then use cmd+option+\ and type "Apple" to find my password for the app store. I think prepopulating the quick view would be useful.

    Thanks for all the hard work. I'm a big 1Password fan.

  • ag_kevin
    ag_kevin

    Hi @dgivone ,

    That is one of the avenues we are looking at. We really want to be able to provide this feature, but we will make sure it is secure before we can consider it. We'll take your info under advisement, but we believe there is still one "gotcha" that prevents it from working, but we do continue to investigate it.

    Thanks so much for taking the time to write in with that information!

    Cheers,
    Kevin

This discussion has been closed.