New 1Password keyboard and filling
Hi everyone,
First of all, thank you for being part of our beta family! Your feedback on design, usability, and functionality is a critical part of our development process. We especially appreciate that you're willing to bear with the occasional bug and having implementation details change under your feet in order to help us test new features as we develop them. Given that we just made a significant change to our filling feature midway through development and testing, you may be wondering why, so I'll do my best to explain some of the thinking that informed this change.
What are we trying to accomplish?
In order to understand why we changed our approach to filling, it's important to first take a look at our overall goal. We want to provide you with a filling solution that offers a balanced blend of convenience and security. As we have stated publicly, we do not believe that any such solution can include using the clipboard and still make a serious claim to security.
Why did we change filling?
With the goal above in mind, we originally set about to create a filling solution that would allow our customers to fill logins without using the clipboard. We evaluated a number of different approaches, but in the end there were only two that offered us the ability to fill text into other apps and browsers. We could either create a custom keyboard or we could implement an accessibility service.
Given that many Android users opt to install third-party keyboards in order to have specific functionality, our preference was to avoid creating a custom keyboard if possible. So we set about developing our filling feature using Android's accessibility service framework. This approach showed a lot of promise initially. In short order, we were able to fill logins into third-party apps and into Chrome with a moderate level of success and we were able to do it without using the clipboard.
At this point we published our first beta including the filling feature, with the intent that we would continue to incrementally improve our ability to detect and fill logins with the help of your feedback. Unfortunately, as we continued to investigate issues that you brought to our attention, we became increasingly aware that some of these issues looked to be insurmountable.
Lollipop-only
We received a lot of feedback about the fact that our filling implementation was Lollipop-only. While this was done in service of our goal of eliminating the need to use the clipboard, it meant that the majority of our current customers couldn't use it, and were thus stuck using the keyboard anyway.
Filling in browsers
Basing our filling implementation on an accessibility service meant that we didn't have direct access to text fields in browser pages. In order to fill logins into text fields within a browser, we had to effectively trick the browser into executing a simple Javascript routine which would then fill the text into the fields. We accomplished this by filling the Javascript into the URL bar for the browser and then having the user tap the enter key on the keyboard.
This approach was somewhat effective in Chrome (which allows some Javascript execution from the URL bar) but was completely ineffective in many popular third-party browsers (which provided different URL bar functions or didn't support Javascript execution at all). This was a technical limitation that prevented us from offering any kind of filling in these browsers. Given that browsers are right up there with keyboards in the realm of personal preferences, we didn't like the proposition of forcing our customers to choose between using the clipboard or giving up their favourite browser.
Filling in apps
The issue with needing Javascript to fill text into login fields doesn't end with browsers either. Many apps use embedded web views to display a web page for logging in, rather than providing a native interface. In this case, just as in the case of browsers, we didn't have direct access to text fields in the web view. Furthermore, there is no URL bar for the embedded web view, so there was no way to execute Javascript. This was an insurmountable limitation that prevented us from being able to fill logins into these apps.
This is a big deal as the group of apps that use web-based logins includes a wide variety of apps that span a number of categories including finance, gaming, and social media among several others. In fact, based on anecdotal evidence from our testing and your feedback, it seems that more apps use web-based login interfaces than native login interfaces. This meant that our customers would again be forced to use the clipboard in order to fill their login information into many of their favourite apps.
System navigation
Whenever the 1Password filling interface was displayed, it would effectively interfere with normal system navigation using the home and overview (recents) buttons. Technical limitations prevented us from detecting taps on those two buttons, which in turn meant that the filling interface wasn't dismissed at the appropriate time. This created a confusing and undesirable user experience.
Room for improvement
In addition to the major issues above, there were a number of minor issues with the previous approach. Taken together, these issues presented a major obstacle to continuing development of our filling feature. We were faced with the prospective of releasing a feature with significant limitations and little prospect of improvement. At this point, the challenges of pursuing a keyboard-based approach began to pale in comparison to the obstacles we had encountered with our accessibility service.
Changing our filling implementation to be based on a custom keyboard brings us much closer to our goal of eliminating the need to fill logins using the clipboard. In theory, this implementation should allow you to fill your logins anywhere on your device. In practice, I'm sure that there are still some bugs to work out. While these bugs may temporarily prevent filling from working in a few specific situations, this keyboard-based approach shouldn't face the kind of technical limitations that the previous approach was subject to.
How does filling work now?
The current implementation of our filling feature uses a custom keyboard that is optionally paired with an accessibility service. In addition to the usual responsibilities of typing text, our custom keyboard is responsible for launching the 1Password filling interface. This is done by tapping or long-pressing (depending on the context) on the 1Password icon to the left of the space bar in our custom keyboard. By itself, the keyboard can allow you to unlock your vault, select a login, and then manually fill that login by selecting the appropriate field and then tapping the appropriate button (either "fill username" or "fill password"). With the accessibility service, the keyboard can go a step further and identify the login fields and fill them automatically for you.
For more details on enabling and using our new filling implementation, please take a look at our super-secret filling document in the user guide.
Onward and upward
This new filling implementation is still very much in beta. There are a number of improvements to both the keyboard and filling that we have planned and there are a few bugs to be fixed. This is where you come in. With your help in squashing the remaining bugs, we are confident that we can provide an entirely clipboard-free filling experience. Please keep the feedback coming!
The 1Password Android Team
Comments
-
What about browser support?
Barring any outstanding bugs, the 1Password keyboard should be able to manually fill logins into web pages in any browser that you choose. For some browsers though, the 1Password keyboard can go a couple steps further by detecting the appropriate login for the web page, suggesting it to you, and then automatically filling that login once you tap on it.
Automatic filling (with login detection)
- Chrome
- Opera
- Javelin
Manual filling (no login detection)
- Firefox
- Dolphin
- Opera Mini
- Next
- Puffin
- UC Browser
As we work on improvements to our filling implementation, we will continue to update this list with changes and additional browsers.
0