Secure Input is Enabled

Hi @jms_1p,

We use Secure Input all over 1Password for Mac to let macOS know that other apps shouldn't be able to see what you're typing into your vault. Users have the expectation that everything in their 1Password vault is protected from anyone other than themselves, so we do not disable Secure Input even for theoretically "less" sensitive fields like notes.

We've done our best to make sure that this is minimally intrusive for folks who use awesome time-saving programs like TextExpander (which we ourselves use) or Keyboard Maestro. However (recognizing that this isn't perfect), we don't currently have the means to disable Secure Input when you enter text into other apps while having an item in edit mode in 1Password in the background. Done otherwise, this could open up what you're typing in 1Password to more than just TextExpander.

I like the idea of the scratchpad, but to stop Secure Input from being active, the item would have to be saved and then re-edited. Unfortunately, I don't think there's a way to use TextExpander or Keyboard Maestro in 1Password.

In short, we've chosen security over convenience here—it's important that we take every precaution possible to make sure that what users type in 1Password stays in 1Password, private to them.

Hi @jms_1p,

I have no doubt that some users will feel some of the decisions made are a bit paranoid, the fact that 1Password will only work with whitelisted browsers is a common one but it is all done with the focus on keeping your data as secure as possible. As a user of Text Expander I do sometimes bump into this issue as well, especially when during testing filling when I'm often editing an item. Our approach is maybe a bit blunt but it is effective. The trouble comes if we try to get smart and a bug creeps in. The reward would need to justify the risk and I'm not sure it does here. One great thing about the forum being public though is if other people agree with you then hopefully they'll post and we'll realise there was a demand we didn't know existed.

@jms_1p: Discussions are automatically closed after more than 6 months of inactivity. It's certainly come up in the past, but not frequently at all. We hear from thousands a week via this forum, email, and across multiple social media channels, about a wide variety of things, and far more often than they have issues with Secure Input, our customers are overwhelmingly concerned about the security of their data, and want to be sure it's safe in 1Password. Apart from the risks of introducing bugs with added complexity, trying to split hairs and say "your data is secure in 1Password, but only in these places and/or under these conditions" can unnecessarily confuse things for users. We know this from experience, because we didn't used to use Secure Input for everything. To be sure, it can be inconvenient for those individuals who both happen to use these kinds of tools and want to use them in 1Password itself, but that's not a large number of people. And because Secure Input is a great security feature that we can get "for free" on macOS, we have no plans to discontinue its use. Perhaps Apple will add more granularity to it in the future, or introduce something newer, but that's not within the scope of 1Password, and far outside the perspective of you and me, not being Apple engineers working on their OS.

@brenty, thanks for the reply. I appreciate the forum and especially hearing from the 1Password Team Members. Unless there's some advantage of closing a thread, I suggest leaving them open indefinitely.

@jms_1p: I'd agree with you in principle, but leaving old threads with outdated information open does more harm than good in practice. And, frankly, there's a consideration for those who started/participated in a discussion, like the one you referenced from more than two and a half years ago, getting email notifications in 2019 if and when you or someone else resurrect it. Similarly, this thread can remain open for a time, but if there is no activity for more than six months, it will likely be closed (I say "likely" because it's possible that setting could be tweaked at some point, if it's deemed necessary).

Does AgileBits need added granularity to activate and deactivate Secure Input? As it is programmed now, Secure Input is deactivated when a 1Password item is closed (from Editing). I suspect that Secure Input could also be deactivated if the user's cursor was in a less-sensitive field (e.g., notes). If so, is that the level of complication that AgileBits prefers to avoid?

I considered mentioning this earlier but thought it was a bit too far into the weeds. But since you mentioned it, yes, there's additional complexity with trying to do something like that, but not only for 1Password. Secure Input isn't our feature. It's built into the OS, so we don't have control over its granularity or behaviour, and, frankly, when it's enabled and disabled rapidly (as is the case navigating between different fields, some using Secure Input, some not), it doesn't always disable as it should. Sometimes I've got to restart macOS to get it working again when it gets "stuck", as TextExpander will not work anywhere because a password field in Safari invoked Secure Input but did not release it afterward. So not only is using Secure Input when interacting with text fields in 1Password more secure (as opposed to discriminating and saying "we don't care about this field, only that one"), it's more reliable this way. And, of course, it's always possible that if we're trying to do a dance like that, the added complexity in our own code can result in bugs. So, given all of that, I do think it's best to have 1Password activate Secure Input in its text fields when adding/modifying data in items. It keeps things working consistently, and the user doesn't have to second-guess themselves either. "Is the text I am entering in this field safe, or not?" is not really a question we want 1Password users to have to ask, and from experience that's what most users expect.

@jms_1p: Likewise, thanks for the detailed workaround! I wouldn't have thought of putting those particular "pieces" together myself. I haven't actually tried Unclutter yet, but that sounds really cool. :) I'm sorry that we don't have a solution for this that doesn't just cause other problems, either from a security or usability perspective. But it's something we'll continue to evaluate as things develop. Thanks for your understanding, and for your encouragement in this area. Perhaps there will be a smoother solution in the future. :+1:

Hi @HenryTheFox

How are you dismissing 1Password when you aren't using it?

Ben

@HenryTheFox

thanks for your reply. That's the thing, I already dismissed 1Password.

Yes, I understand. My question was how you're going about doing that? E.g. Are you using ⌘Q, or ⌘H, or ⌘W, or clicking on the red close bubble at the top left of the 1Password window, or something else?

It's also very hard to reproduce the error. Here is a diagnostic screen I found in aText which shows the process which enabled Secure Input:

loginwindow is not part of 1Password.

Ben