1P 8's uncontrollable auto-fill just gave away my private data

BobW

My wife made some family travel plans and shared the travel company's trip with me. I clicked the link in their email message, which took me to the site and requested I log in. I hit cmd-\ to bring up 1P, which filled and submitted the form. Unfortunately, while I thought I already had an account, I actually did not -- but there is an account in one of my work vaults. Since there was only one cred in the database, 1P found it, filled it in, and automatically submitted it. And, the travel company share was a one-click affair, meaning as soon as I was logged in, all the details of my family trip were linked to the work account and shared with lots of people in my company. This includes things like scheduling details, personal details about everyone in my family, and how much I paid.

As has already been pointed out, auto-submit is absolutely a security risk, for two reasons:

1. Machine error (i.e., 1P misidentifies what fields it should fill) causes 1P to fill in information the user did not want filled or even to submit the wrong form entirely. People have posted in these forums plenty of examples of this.

2. Human error leads 1P to fill in the wrong credential, triggering whatever consequences are linked to that. This post is about one example of this.

Both cases are high-probability, which is why both have been discussed on these forums. It's actually very similar to removing the anti-phishing feature where 1P will only auto-fill if the domain matches.

I get that some people like the feature. And I'll admit that, when it does the right thing, with the right data, it's a wonderful experience. The problem is, there are just too many variables at play for you guys to ensure it does the right thing, with the right data, with an acceptible level of reliability. And in some cases, it's not even possible. This rightfully led you guys to kill the feature years ago, and you even blogged about the fundamental problems at the time. You say you've fixed all that now, and yet, people keep pointing out the very same problems and you keep fixing bugs related to it. Clearly, the fundamental problems are still present. The only way I can think that happens is that the people who made the decision are gone and the new people have egos telling them they can do it better.

Please give us back the ability to turn off this feature. If some people have narrow enough use-cases that it works well enough for them to keep it enabled, great. (Though, you should warn them as they turn it on that it carries risks.) But don't make everyone for whom it does not and cannot work that well suffer bad UX and potentially embarrassing or costly consequences when things inevitably go wrong. This is terrible for your users and a fairly big liability risk for you guys.

---

1Password Version: 8.8.0
Extension Version: 2.3.6
OS Version: macOS 12.4
Browser:_ Safari 15.5

BobW

Of course, I meant uncontrollable auto-submit, not auto-fill.

esquared

+1 for documenting a real-world example of why this feature absolutely needs to make a return in 1P8. This has also been discussed in many other posts here and in the Beta group. We had it in 1P7, so clearly it had value to someone at AgileBits at one point. Please bring this back ASAP.

Shango0

Thanks @esquared for linking this into the other thread (https://1password.community/discussion/comment/647908/#Comment_647908) about this, and yes +1 here @BobW for another great example of how mandatory auto-submit is a bad idea and is something we really do need an option to disable.

PeterG_1P

Hi folks, thanks for the continuing feedback here! 👋

Some news for you: we're looking into adding an option to toggle auto-submit on and off. We can't provide a timeline about when that'll be ready, but we've been listening to the feedback and considering different user scenarios carefully, and we intend to build out that option for you. Thanks for making the case for it, and we hope that updates to come will delight you.

@BobW: regarding our previous thoughts on auto-fill, I wrote about that a bit here. The auto-fill feature today is implemented differently than the one we previously had, and the old one was removed for reasons of usability, not security. That said, we see the case for adding an on / off option to the current one, and appreciate the feedback you (and everyone in the community) have provided. Thank you!

ref: dev/core/core#14506

BobW

regarding our previous thoughts on auto-fill, I wrote about that a bit here. The auto-fill feature today is implemented differently than the one we previously had, and the old one was removed for reasons of usability, not security.

I appreciate that you guys are leaning toward adding the option back in, but I'm still puzzled at how you apparently can't see that things fundamentally haven't changed from when you removed the feature in 7.2, or how you don't seem to want to acknowledge that this feature presents security risks.

From the post you linked to, there were three primary reasons for the removal in 7.2:

1. One of them was related to a new macOS security limitation.
   This one may or may not be relevant still, but either way, it's not directly a usability concern. That said, this point arguably supports the feature being security-related since Apple yanked functionality used by 1P precisely because of security concerns.

2. One of them was pointing out a UX detail (leaving focus on the password field after autofilling).
   This point was included in the original article as support for pulling the autosubmit feature - leaving the focus on the form means the form can usually be submitted manually by just pressing return. This point is as true now as it was then, and is still just as much an argument for not using autosubmit.

3. The last point was about the negative UX consequences when the feature doesn't work properly.
   Presumably, this is the one of most concern, since UX is what you are now calling out as the biggest concern of the old feature and this is the only direct UX problem that was given at the time. Let's look at the full text:

Sometimes a website doesn’t behave as 1Password might expect, resulting in passwords being filled sub-optimally, or fields being left blank. If 1Password were to automatically submit forms in these cases, users are left with an experience that we don’t feel reflects how we want 1Password to work and can lead to confusion.

I think we can say that this part clearly hasn't changed. Not only have people posted lots of examples in these forums of cases where the feature behaves in an unpredictable or undesirable fashion, but many releases you guys put out fix bugs with how 1P interacts with various sites. From the extension's recent 2.3.5 release notes:

• Logins are now correctly suggested, saved, and filled on walmart.com, web.telegram.org, churchgiving.com, fialda.com, inovarmais.com, and register.it.
• Logins are now suggested on boxcryptor.com, and one-time passwords now fill in Italian.
• One-time passwords now fill on Twitter in Norwegian.
• Suggested passwords now fill in both password fields on the vanguard.com recovery page.
• Logins now save and fill correctly on c1c.hu and the change-password page on tickets.theegg.org.
• Logins now save and fill on myntra.com.
• Logins are now properly suggested on auth.services.adobe.com, id.condenast.com, and cockroachlabs.cloud.
• Logins are now suggested on accounts.firefox.com, radio.southcraven.org, ing.com.au, and bank.co-operativebank.co.uk.
• Credit cards are now properly suggested on capitalmedicalclinic.myezyaccess.com.
• Usernames now fill correctly on the French version of app.journalapetitspas.ca.
• Identity items now fill properly on x-kom.pl.
• Credit card numbers are no longer filled into the CVV field on amazon.in.

Some of these are not cases where autosubmit applies, but many of them are, including on some notable sites. And all of them relate to 1P's parsing, understanding, and interacting with a web page, which is precisely the part that happens right before autosubmit and thus sets up autosubmit to fail or succeed (the old GIGO principle). Taken altogether, it means autosubmit is frequently going to commit the user to sending bad data or incorrect data. Further, given how web pages are constructed, I don't see this changing anytime soon. 1P will always be chasing web site anomalies, just as it has been doing for years now.

All of which takes us back to the core point from the blog entry about 1P 7.2: "Sometimes a website doesn’t behave as 1Password might expect, [which can] can lead to confusion."

The underlying technical implementation may be totally different, but that core UX challenge is exactly the same. So, it seems the only thing of relevance that's changed are quality standards, particularly in terms of how much potential confusion is allowed in an experience.

As to security, while autosubmit itself isn't a known security problem, the fact that it's basic usage includes very common machine and human errors that frequently lead to security- and privacy-centric problems — leaking personal data, enabling sites to better track users by linking accounts, errantly adding people to mailing lists, etc., etc. — means that autosubmit is a security problem by proximity. Again, it's a lot like 1P's anti-phishing feature. Filling credentials onto any random site when the user has requested it is not itself a security fault, but it's clearly security-related because you know users will do dumb things like click a phishing link and then tell 1P to fill in a cred on the rogue site. The user is entirely responsible, but do you really want 1P facilitating that by turning a blind eye and just doing it, or do you want it protecting users from themselves? We all know where you stand on this one.

Also, as someone else pointed out, you guys placed the autosubmit removal defense under the security heading of the blog post. This strongly suggests that it was regarded as a security-centric concern internally, or at least security-adjacent. The fact that you're now basically trying to retcon it into a mere UX concern, that you won't warn users about it or even acknowledge possible security ramifications, gives me pause about other security-related decisions the team is making. 1P is all about security, so if your security posture is starting to weaken in favor of saving face or is becoming less transparent, that speaks to a far bigger problem than this one misguided feature. Bugs happen, bad decisions happen, etc. I get these things. But the basic posture is what I focus on. And I gotta say, this is the first time I've been concerned about 1P. Mind you, I've been a user of 1P since its "1Passwd" days, I'm directly responsible for multiple family and business accounts, and I can't even count how many individuals I've referred your way. It's been a long, occasionally bumpy road, but I've stuck by you guys because I believed in your competency around the core mission of security with some great features layered on top. Now, I'm not so sure.

esquared

Hear hear. Kudos to @BobW for writing many of the same thoughts I've been having, but too busy/lazy to write myself.

Unknown

This content has been removed.

Unknown

This content has been removed.

PeterG_1P

Hi folks, thank you for these questions and your thoughtful feedback here. We now have an option to disable auto-submit in Quick Access in the latest Nightly build of 1Password. If you're currently on the Nightly update channel (or open to switching), you can try it now.

1. Unlock 1Password
2. In your menu bar, select 1Password > Preferences
3. Under General, de-select autosubmit forms after filling with Quick Access

We'd love to have your feedback on how this works for you, or if you see any areas of potential improvement. Thank you again for providing us feedback on this aspect of the app, and we look forward to hearing from you!