Typinator Keyboard Shortcuts & 1PW6 Secure Keyboard Mode

whershfeld
whershfeld
Community Member

Hi -

I rely on Typinator and 1PW6 on a daily basis... and see that 1PW6 turns on the SECURE KEYBOARD mode in OS X - which stops Typinator from working! Is there a work-around?


1Password Version: 6.1
Extension Version: Not Provided
OS Version: 10.11.3
Sync Type: DropBox
Referrer: forum-search:secure keyboard

Comments

  • Hi @whershfeld,

    You're right, 1Password 6 currently enables Secure Input mode whenever you're editing anything in the app. For the time being there's nothing available to change this behavior. Can you tell us how you're using Typinator within 1Password? We're not closing the door to the idea of making this more configurable somehow, but we'd like to know how users would like this to work.

    The issue is that for Typinator (or TextExpander, or any of those kinds of apps) to work, they need to listen to every keypress on the system. We think that most, if not everything, you're typing into 1Password is secure information that you wouldn't want another app to know about. It's not just those apps that can listen to those keypresses, just about any app on the system can. So while Typinator is doing some good with it, there's a risk that some apps are doing malicious things with that information.

    I'd like to find a way to strike a balance here.

    Rick

  • whershfeld
    whershfeld
    Community Member

    My use involves setting up a new Server item in 1PW6... I have a number of values (IP address, etc) that are set as Typinator shortcuts... it's a great time saver... but, of course, they don't work now. Would it be possible to have a preferences panel to allow Typinator to "listen in" on 1Password6 and allow shortcuts to work?

  • Hi @whershfeld,

    Thanks for the additional information. I can understand that... having been a sysadmin for a few years, if I never have to type "255.255.255.0" ever again, I'll be a happy man. Unfortunately we can't allow only Typinator. If we could limit who had access to those keystrokes we would totally just have a whitelist of apps that we trust. There's unfortunately nothing you can do right now to get the behavior you're looking for.

    Right now we're trying to understand how users were using that ability to best come up with a solution that will please as many people as possible. Maybe that's a hidden preference to just disable what we've done. Maybe it's something in Preferences, maybe it's a button we display when editing an item. There's a ton of different options, and right now we aren't quite sure what would work best.

    Rick

  • whershfeld
    whershfeld
    Community Member

    Gotcha - thanks for the prompt response. I look forward to some sort of solution. Agile Bits rocks! Can't recommend your stuff enough.

  • You're welcome. Have a great day.

    Rick

  • Quantumpanda
    Quantumpanda
    Community Member

    If I might add my own voice...

    I also use Typinator extensively, and with 1P6, the big hassle for me comes with Software Licenses. I frequently acquire bundles of software, with several licenses being added at a time. Typinator saves me having to retype name and email with these. I know I can enter one license and then duplicate that entry, and change just the parts that are different (normally just name, version, and license code), but even that first one can be a hassle, as my email address gets annoying to type all the time.

    What if Secure Input mode could be optionally disabled by item type? For example, I personally feel little value in hiding the information added under a software license from keyloggers. The only reason I store license codes in 1P is because I can—I bought 1P for passwords. I previously kept license codes in a spreadsheet, which doesn't really hide anything from keyloggers. So if this option were available, I'd turn it off for software licenses only.

    Alternatively, instead of turning it off by item types, you might allow it to be disabled for non-secure fields, or just specific fields, regardless of item type. Under normal circumstances, for example, Secure Input mode might be turned on in some apps only when a field is set to display bullets instead of characters—1P could do the same, turning it on only for fields that would be hidden when "Conceal Passwords" is active. Or Secure Input could be deactivated specifically for fields that are hold data not normally kept secure from one's own system, such as name or email address.

    What bugs me here, though, isn't that you've activated this security feature—it's that it is a change from 1P5 that I don't recall seeing in the change log presented to me by the updater. If it was there, it wasn't made clear what it did, because I would have waited to upgrade had I known that this would prevent me from using Typinator shortcuts within 1P. Honestly, if I had a reasonable way to completely disable Secure Input mode on my system, I probably would, because I have yet to notice a situation where it was activated under circumstances that would actually put private information at risk (with the exception of bullet-masked password fields), but have encountered numerous situations where it slowed me down by interfering with an otherwise simple task because it blocked Typinator.

    Not trying to berate you, just offering another user's viewpoint on a question that you are actively researching.

  • Hi @Quantumpanda,

    Thank you for the feedback. We did publicize this change in the 6.0 release notes:

    Enabling secure text input when editing item details. {OPM-3210}

    We didn't specifically call out Typinator because Typinator is just one of many such apps, and so we used the correct technical term for what we're doing as it applies to all of those apps.

    I understand that this is a change that's annoying for you. We're still wanting to make this better somehow. This kind of thing is a gray area... everyone will argue for their shade of gray, and no one's right or wrong. It all depends on our comfort level with different things.

    Rick

  • rjtanner
    rjtanner
    Community Member

    As a long time 1Password & Typinator user, I've missed using Typinator since upgrading to 6.0. My preference would be to allow the user the option to disable that security feature. Managing security risks vs convenience/ease of use is something that each user does with various programs all the time. I say let the user decide.

  • AGAlumB
    AGAlumB
    1Password Alumni

    My preference would be to allow the user the option to disable that security feature. Managing security risks vs convenience/ease of use is something that each user does with various programs all the time. I say let the user decide.

    @rjtanner: Thanks for your vote! It's certainly something we can consider, though I'd want to see some serious warnings to go along with something like that, which can be rather annoying too.

    What if Secure Input mode could be optionally disabled by item type? For example, I personally feel little value in hiding the information added under a software license from keyloggers. The only reason I store license codes in 1P is because I can—I bought 1P for passwords. I previously kept license codes in a spreadsheet, which doesn't really hide anything from keyloggers. So if this option were available, I'd turn it off for software licenses only.

    @Quantumpanda: That's a really interesting point, and not a bad suggestion at all. It just isn't clear that this would help many people beyond you and I, who probably have similar perspectives on this.

    Alternatively, instead of turning it off by item types, you might allow it to be disabled for non-secure fields, or just specific fields, regardless of item type. Under normal circumstances, for example, Secure Input mode might be turned on in some apps only when a field is set to display bullets instead of characters—1P could do the same, turning it on only for fields that would be hidden when "Conceal Passwords" is active. Or Secure Input could be deactivated specifically for fields that are hold data not normally kept secure from one's own system, such as name or email address.

    While those are some inventive ideas, it really sounds too complex. We'd need a lot of different options for that, and I'm getting a headache just thinking about it. Consider any individual field, but especially custom fields: we'd either need to decide either all or none, or make it configurable on a per-field basis, and I'm not sure many people would be satisfied with any of those options.

    Honestly, if I had a reasonable way to completely disable Secure Input mode on my system, I probably would, because I have yet to notice a situation where it was activated under circumstances that would actually put private information at risk (with the exception of bullet-masked password fields), but have encountered numerous situations where it slowed me down by interfering with an otherwise simple task because it blocked Typinator.

    You bring up an excellent point. Your annoyance with the (relatively) new global SecureInput in 1Password highlights the importance of making this change now, before it becomes a real concern. We're fortunate as Mac users in that we're largely not being targeted the way that Windows users have been historically, but that's changing. Ransomware is now available to us "lucky" Mac users as well, and while malware in general is still not common, I'd much rather we make a change like this "too soon", rather than too late. :blush:

  • bizbeblu
    bizbeblu
    Community Member

    I'm a bit late to this discussion, but I just sent agilebits support a "burn before send." email. Normally I moderate my concerns, but I was so angry about this that I fired both barrels. I'd say sorry, except I'm really not. The current Mac OS system does allow "secure keyboard mode" but it mandates that the program release said "secure" when it is not in use. There are in fact several ways this can be done. This bit me hard for the first time after the most recent update. (V. 6.3.1) which I believe is current. You'll have to read the email with the subject line HEY! HEY! What the 8888!! for details.

    I powerfully object to the way you've handled this on two counts. First, you made a fundamental change and in NO WAY NOTIFIED YOUR CUSTOMER. I find that inexcusable. Second, not only does the user not know what happened, I can find absolutely no way to turn it off or at least modify its use. NO, NO, NO. I hate the Johnathon Ive "The user is stupid" mode forced on OS X that has now cascaded down to 3rd party developers. As you can tell I'm seriously POed by this. I had a simple abbreviation (t-o) that Typinator expanded to Tohono O'odham. Not only do I get their name spelled right every time, I seriously challenge you to write the whole tribe's name out - say 3-4 times in getting an article out on deadline. Typinator is not the only program affected by this secure mode. Surprisingly enough some of us will never have a FaceBook account, and we actually write, create, research, i.e., work with the computer as a tool.

    How about signing into a web site? I use strong, unique PW (1P generated) for every site. What would you like me to do? Open 1P (typing its PW) every time I try to login anywhere?

    Yes, keyloggers exist. Yes, security is an ever increasing problem in which the bad guys are always in the lead and we can only respond. Still, knowledgeable users can with the appropriate tools and awareness guarantee no such logger is in their system. Okay, maybe it's a responsibility to protect the uninformed or maybe just lazy users from harming themselves. However, there are a lot of us around that having been intensively using desktop Macs since well before 1P was someone's pipe dream.

    Please. Wake up! Listen! Give the users their innate right to control their environment. (You might have your coders actually let real users work with your updates before you lose them upon the unexpecting customers.)

    Robert Sorrels

  • AGAlumB
    AGAlumB
    1Password Alumni

    @bizbeblu: I think in your haste and frustration you're overlooking an entire class of users and insulting everyone as a result.

    Certainly there are novice users that you might feel are "lazy" or "stupid", but there's also the rest of us who are at competent and security-conscious (which I feel describes that vast majority of 1Password users — after all, these are the folks who go out of their way to use a password manager!) None of us is 100% vigilant. We all make mistakes and forget important things in the moment as we use technology in our daily lives — and I don't just mean saying rude things while cloaked in the relative anonymity of the internet.

    My point is that people depend on us to help them avoid the pitfalls of the digital age, whether that means preventing filling on non-matching URLs to protect against phishing attacks, block access to our sensitive data from 3rd party software, or offer a gentle reminder that everyone you address on the internet — even indirectly or in passing — is a person just like you.

  • bizbeblu
    bizbeblu
    Community Member

    Brenty,
    I apologize for the strident tone of my post. All I can say (which is no defense) is that I violated the first tenant of email or comment. Remember! step back and see if it is a "burn before send" message. I failed to do this so your remarks are pertinent, and I hope to re-remember this rule which I first encountered in ARAPnet days. Please note that I in no way called "users stupid and lazy." I was quoting - or perhaps more correctly - theorizing the way Ive has butchered the once coherent OS X interface and his blatant disregard of the "Tog's" cogent summary of an elegant and logical user interface. In your haste to chastise me - which I richly deserved - you did not carefully read my rant.

    On the other hand in re-reading this, I do acknowledge in my criticism of the 1P's handling of this program saying "1P had the responsibility to protect the uninformed or lazy". My bad. I have no clue about others' motivations but strongly suspect that if they've gone to the effort to buy and install 1P they are anything but "lazy." Dumb, stupid use of the word. I do directly apologize to anyone who read this.

    Now, having offered a complete mea culpa for the offensive part of my post, I stand by my criticisms of how Agilebits handled this undocumented and unalterable improvement to 1P. While the majority of users undoubtedly do not know or really want to know what is going on "under the hood" there are - I would suspect - a fair number of us that occasionally open the trapdoor to the BSD underpinnings of what is still the best OS in town. I'm sure most folks want to know that if you fill it up with gas and turn the key, the car will go. It is perhaps unfortunate that we as a culture (and I refer to human culture as a whole) have been increasingly cut off from our ability to control our tools.

    There was I time I could open the hood on a Chevy 1/2 ton, rebuild the Rochester single barrel carb, tweak the timing, and so on. Since everything went to electronic/processor controlled l, I now can't do much more than check fluids, rotate tires, change the oil and well, have the major maintenance procedures done before they normally arise.

    I am fully aware than many, I would guess probably most - users want the thing to just work so they can do their work. I know this to be a fact because I unofficially support a dozen or so people - some much older, some at a distance - who get stuck with something. Many of their problems seem a bit trivial to me for example: lots of people have no clue what a file structure is. However, I never insult them other than give an occasion sigh and carefully walk them thru a solution if it can be done hands off. More than once, I've encountered a problem in their Mac that clearly seemed to be hardware related and sent them to the closest Apple store. Mostly I preach with the fervor of an old-time tent evangelist Back up! Back up!

    I would love to have a coherent conversation, even debate, about 1P's responsibilities to the inadvertent negative impact on other programs. While I accept completely your criticism of the vehemence and at one point insulting nature of the post, you offered no response to the the completely valid point I raised.

    Should you tell users what you're doing? Should you allow the user to opt out of the feature or more importantly select applications that it should ignore? The conversation is multifaceted, and I in no way minimize the now deadly ocean of the Internet in which we swim. Though deadly it is also an environment of amazing beauty and great power. How can we hold off the one so we can experience the other? I also fully acknowledge that Apple's flailing about with the "New version every year" seems to make more problems than it fixes. Fix the problems, no matter how long it takes. Maybe we could have a "Grand Canyon" (oh, not in CA) release that does nothing but dig to bedrock and FIX things.

    Again, apologies for my ranting, but still hoping for real dialog with Agilebits on this subject.

    Robert Sorrels
    Ajo Az

  • Drew_AG
    Drew_AG
    1Password Alumni

    Hi @bizbeblu,

    I'm sorry the use of secure input fields in 1Password has been such an unwelcome change for you! Although I'm not sure there's anything I can say to change your mind about something that has clearly impacted your workflow in a negative way, I thought I should reiterate that this is not an undocumented change. As Rick mentioned earlier in this thread, it was included in the release notes for version 6.0:

    • Enabling secure text input when editing item details. {OPM-3210}

    1Password 6.0 for Mac was released on January 12, 2016. If you're curious, you can find the full release notes here: https://app-updates.agilebits.com/product_history/OPM4#600008

    We also mention this in our knowledgebase article about 1Password security:

    • Secure input fields. 1Password uses secure input fields to prevent other tools from knowing what you type in the 1Password apps. This means that your personal information, including your Master Password, is protected against keyloggers and only stored in the 1Password apps themselves.

    There were a lot of changes in version 6.0, just as there have been a lot of changes in the updates we've released since then. This particular one may have been easy to miss among all the other new features, improvements, and fixes, but we certainly didn't try to hide it from anyone.

    We'll be happy to have a discussion with you about the change itself if you want, although I think Rick has already given some good explanations in his replies earlier in this thread. Again, I'm sorry this change caused a problem for you, and I'll be sure to forward your comments to our developers. We always appreciate feedback and constructive criticism! Please don't hesitate to let us know if you need anything else. :)

  • AGAlumB
    AGAlumB
    1Password Alumni

    @bizbeblu: You're absolutely right: I glossed over your comments about communication and enabling Secure Input in general in 1Password 6. It's no excuse, but I felt we'd addressed that earlier in the conversation and we really don't have anything new to add at this time. However, I can appreciate that I may have seemed dismissive of your concerns, and I'm really sorry about that. If you're feeling especially generous, maybe we can call it even. :blush:

    I really appreciate you taking the time not only to reach out about this, but also to respond and call me on the carpet on that — and most importantly, your interest in a continued dialogue on this specific change in 1Password and also the broader issue of how we handle these sorts of things.

    The latter is an incredibly difficult and nuanced issue (perhaps worthy of its own discussion), and it's very much something we struggle with, in the sense that it's really a judgement call: do we make a big deal out of a change and potentially annoy a lot of people who don't know or don't care, or do we mention it in the release notes for those who follow closely while potentially others will be affected and not know why.

    We try to strike a balance here in a few ways by 1. avoiding doing things in the first place that we'll have to change later, 2. being conscientious about how changes affect users, 3. putting real effort into release notes, and 4. announcing things in where appropriate. Where we've failed in this regard, I apologize. Ultimately the only way we can know this is through feedback like yours (and others here), and I hope you won't hesitate to follow up on this or anything else where you believe that we can do better. Otherwise, we have only our own judgement, which is only as good as our best intentions and collective imperfection. Room for improvement. :blush:

  • bizbeblu
    bizbeblu
    Community Member

    Drew,

    Okay, I confess to not reading each and every release note. I know I never bother reading the EULA's anymore cause what could I say or do? After plowing thru a few - which have gotten longer and ever more obscure - it appears that not only do I not own the product I've just purchased, but the developer (owner?) also disavows any responsibility for anything including "we won't promise if this works or not." I just gave up on them (I swear down there somewhere they even refuse responsibility for the death of all known civilization :p )

    I do try to glance thru release notes particularly major ones but frankly, don't give them a lot of attention - though I should. In this case, you did note "Enabling secure text input when editing item details. {OPM-3210}" OK, exactly how does this statement allow a user to know the mechanism of said security and, more important, what possible side effects might occur? Good idea to block a possible keylogger from capturing input into "the secure box" but clearly this has had "unintended" consequences. I don't know if your testing did not notice this (did it?) or maybe you just assumed nobody would be affected.

    So I'm still disappointed in Agilebits' handling of this rather significant change - particularly in light of the fact that (1) It affects many utilities (It also had a persisting effect on BBEdit, a program I cannot live without) and (2) At least in my case, I could only find clues to the problem by reading the FAQ of the offending utilities. I confess that I also had not read the knowledge base article noted above, but even there I'm left unclear as to the possible consequences of the Secure input fields.

    So, the question remains. Are you going to allow your users to adapt this to meet their needs? I'm a long way from being a coder these days, but it doesn't seem like it would be a major issue. Perhaps a quick query to an array? Better, letting the owner know what this feature does and offering them a case by case choice for its action. Beyond this, you do have a significant bug. I've gone back and attempted to note repeatability in the bug but it is wildly erratic. Please note I'm discussing cases where there is no active input into 1P, it's just open and not active. While it is rare, 1P on occasion fails to release the secure state raising all sorts of havoc. Of course as per Murphy's Law this happened to me for the first time as I was fighting to meet a deadline. >_<

    So, can you find the bug, and will you allow the user to make exceptions to the rule albeit with strongly worded caution?

    Thanks,

    Robert

  • Drew_AG
    Drew_AG
    1Password Alumni

    Hi @bizbeblu,

    I confess to not reading each and every release note.

    No problem at all! I wouldn't expect all of our customers to read all the release notes (and even if they did, I certainly wouldn't expect them to memorize every single change). In fact, if I had to guess, I'd say that many (if not most) people skip release notes when installing an update, especially when those release notes are long. I only mentioned it in order to explain that this change was, in fact, documented there. Whenever we release an update, you can find a list of changes in the release notes.

    In this case, you did note "Enabling secure text input when editing item details. {OPM-3210}" OK, exactly how does this statement allow a user to know the mechanism of said security and, more important, what possible side effects might occur?

    To be fair, if the release notes included detailed information about every single change in every single update, including definitions of terms, explanations of how each feature works and how each one interacts with other apps and/or the operating system, and our best guess as to how each change would affect (or be noticed by) every customer, each set of release notes would be the length of a book and even fewer people would read them (I would probably fall asleep if I tried, to be honest).

    But I understand what you're saying - even if you read the release notes and saw that change, you wouldn't necessarily have understood what that really meant. I'm sorry we weren't more descriptive/detailed about that! We can try to make things like that clearer in the future, but please know that if you ever have a question about something like that, we'll be happy to elaborate. :)

    Good idea to block a possible keylogger from capturing input into "the secure box" but clearly this has had "unintended" consequences. I don't know if your testing did not notice this (did it?) or maybe you just assumed nobody would be affected.

    The consequences certainly weren't unintended - the whole point of using secure input fields is to prevent other apps from seeing what you type. That means keyloggers or other "bad apps" won't be able to read what you type in 1Password, but it also means "good apps" won't be able to either. As Rick explained earlier in this discussion:

    The issue is that for Typinator (or TextExpander, or any of those kinds of apps) to work, they need to listen to every keypress on the system. We think that most, if not everything, you're typing into 1Password is secure information that you wouldn't want another app to know about. It's not just those apps that can listen to those keypresses, just about any app on the system can. So while Typinator is doing some good with it, there's a risk that some apps are doing malicious things with that information.

    Most of us here use TextExpander or similar software for text expansion, which doesn't work in secure input fields, so we completely understand this can cause some inconvenience. Finding the right balance between security and convenience can be difficult. Personally, I feel much better knowing other apps can't "spy" on me when I'm typing something in 1Password. But others like yourself may prefer to have a bit less security so apps like Typinator or TextExpander will work in 1Password. We'd love to somehow allow only the "good apps" to see what you type in 1Password while blocking the "bad apps" from doing so, but in order to block one we have to block them all. Again, as Rick previously explained:

    Unfortunately we can't allow only Typinator. If we could limit who had access to those keystrokes we would totally just have a whitelist of apps that we trust.

    Right now we're trying to understand how users were using that ability to best come up with a solution that will please as many people as possible. Maybe that's a hidden preference to just disable what we've done. Maybe it's something in Preferences, maybe it's a button we display when editing an item. There's a ton of different options, and right now we aren't quite sure what would work best.

    Which leads us to your question:

    So, the question remains. Are you going to allow your users to adapt this to meet their needs?

    I can't make any promises one way or the other because I simply don't know. No one here does. But as you can see in Rick's comments, it's something we might consider as we know some customers would like to be able to disable secure input fields when editing items in 1Password. I can certainly let our developers know you'd also like to be able to do that. However, keep in mind that we don't have a way to only block certain apps from seeing what you type in 1Password. An option to allow other apps to see what you type would mean they could all do that.

    I'm sorry that's not the answer you want to hear, but I hope that at least helps to explain things a bit more. We really do appreciate your feedback about this! If you need anything else, please let us know. :)

  • bizbeblu
    bizbeblu
    Community Member

    Drew, Bently,

    First, I truly appreciate the time it takes to answer lengthy questions (and in this case at one that started angry). I utterly agree that I don't want to use Typinator or any such device while I am creating or editing something inside 1P. That is an absolutely correct choice on your part. What caused me to go off is that sometimes the "secure keyboard" doesn't release when I've left/finished a 1P entry. I've wasted 8-) a fair amount of time trying to get it to duplicate but the event is sporadic and only happens when I'm in a hurry. (You didn't put a Zen "mindfulness" meter in the code did you?) ;) I'll keep watching and maybe catch it in the act. It could well be that since I run a maxed out system making use of several plugins part for security both mostly as productivity tools as I work extensively in photography and have to do a lot of writing. Typinator, PopChar, etc., are important.

    While it may not have seemed that way from my first post, I do value your program immensely and know of at least 10-12 people who use it now at my urging. (NO! You just can't have your dog's name as your password for every site you visit!!!)

    Totally different subject.
    It's time to upgrade my box which I shudder to do as it seems to ruin at least 2 days. Checking your FAQ on this offers me the ability to buy into your cloud. Nothing personal guys, but if I don't want a keylogger to watch my app, I'm certainly not firing the bits off into space hoping that (1) they get there and (2) they stay - as in no one can crack your security. I'm not all that impressed with the state of (in)security on the Internet as a whole these days. Again, no slur on you, but clouds are nothing but batches of computers connected with wires sending info back and forth between user and your "farm." (I suspect that this part of your operation is contracted out as it isn't your core market.)

    It's no problem for me to back up data. I do this regularly to keep my Air in sync with the desktop. (Would love a computer to computer wireless sync though.) When I open my 1P data in 1P I have three entries (none of which are labeled past v.4.5.2). There is also a list of 5 icons labeled License.onepassword-license. So do I need to re-download the latest program, import the backup, and hope one of these 5 "attachments" does the job? Or count the angels dancing on the head of a pin, or sacrifice a virgin (mighty rare around here) or, well mark me confused.

    Robert Sorrels
    Ajo Az

  • khad
    khad
    1Password Alumni

    @bizbeblu,

    On behalf of Drew and Brenty (and the rest of us here at AgileBits), thanks for following up on this. :+1:

    It sounds like we're all in agreement about Secure Input being enabled while editing items in 1Password. We also agree that this part would be a bug in need of resolution:

    What caused me to go off is that sometimes the "secure keyboard" doesn't release when I've left/finished a 1P entry.

    Years ago there were some bugs related to Secure Input, and it caused all sorts of trouble. If I recall correctly, it had something to do with hiding or minimizing 1Password while the Master Password field on the lock screen had focus. It was really annoying, so I'm glad we fixed that a long time ago.

    If there is a bug related to Secure Input in the current version of 1Password, we'd absolutely love to get that resolved! It can be hard to resolve a problem we can't reproduce, though. Thankfully, you strike me as someone who can appreciate how hard it can be to resolve a bug without reproducible steps. I hope you can have some patience with the annoyance while it's under investigation. And please do let us know if you are able to figure out the exact steps to reproduce it. That would be immensely helpful.

    While it may not have seemed that way from my first post, I do value your program immensely and know of at least 10-12 people who use it now at my urging. (NO! You just can't have your dog's name as your password for every site you visit!!!)

    Haha! Thanks for the laugh and, more importantly, spreading the good word about 1Password. I've passed your kind words along to the rest of the team here. :lol:

    As for the optional subscription plans we recently introduced, we think they offer a lot of benefits, but you're under no obligation to subscribe to one. You can use your existing license for as many installations of 1Password as you can afford Macs. :)

    If you have any trouble with the license file(s) you have saved in 1Password, you can have your license resent.

    Just in case you wanted some bedtime reading, though, feel free to read the 1Password Security Design white paper [PDF] which outlines the security of the hosted service in all its geeky glory. We even tried to include some humorous anecdotes, so it didn't drag on. ;)

  • johnnygoodface
    johnnygoodface
    Community Member

    Wow! It's been a while since I witnessed such a tug of war! On one corner we have AgileBits, and on the other we have bizbeblu... And each contestant ultimatly wants to K.O. >_< the other.

    Ultimatly, AgileBits is trying to be a good father by securing his users against their own "stupidity"... But some users care about security, that's why we have full encryption on iPhone and thanks to Tim, we don't have a backdoor, and some users who care less, and others not at all.

    That's why MacOS has it's own little grey area:

    • Enabling Firevault or not
    • Allowing apps downloaded from Mac App store, Mac App store and identified developers, or Anywhere
    • Activating the Firewall or not...
    • and some more...

    Some will argu that we should enable ALL those security options, but I'm sorry, some are overkill for me, so I decide to lower my level of security for commodity. That being said, just the fact that we're opting for MacOS instead of Windows is telling a lot about how we perceive security. I feel MUCH more secured using MacOS (based on Unix) than stumbling on the bunch of security holes of Windows...

    So why won't you do like Apple: Just add a new "Enable secure text input when editing item details" option (checked by default, so that your "stupid" users would be secured by default). Add it in the Advance tab (where most novices won't venture into), and finaly add a nice question mark beside the option explaining the risks of disabling it.

    This way everybody would be happy: the "stupids", the "frustrated" (like me) and AgileBits (following Apple's footsteps and being a good father too).

    Cheers gang

    Maybe I'll live old enough to see that happening :p

    Johnny
    Simplicity is the Ultimate Sophistication. Leonardo Da Vinci

  • AGAlumB
    AGAlumB
    1Password Alumni

    @johnnygoodface: I really think that painting this in terms of "user stupidity level" is kind of awful, not only since we're talking about actual people here, but also because it detracts from a genuinely interesting and important discussion. The problem here isn't the user; it's the user interface. Having a bunch of buried options is bad enough for discovery, but even worse is that it is very rare to find a way of wording a setting that is clear to everyone. We each have different backgrounds, expectations, and ways of approaching technology, and it's impossible to account for all of that variation and make things usable for everyone.

    Would having Secure Input enabled by default with an option to disable it work? Possibly. But again, I think the fact that people are still just discovering this change now nearly 9 months after the fact speaks to its obscurity, which certainly doesn't help in the usability department. After all, if there's confusion now, adding more options that affect it won't reduce that. Unfortunately Secure Input really is an all-or-nothing thing. It's either enabled or it isn't. Right now it's enabled for the aforementioned reasons. Maybe we'll come up with a better solution, or perhaps Apple will add additional security features we can leverage. Either way, it probably isn't something that will change in the short term, but it's good to get a sense for the direction you'd like 1Password to go in the future.

  • johnnygoodface
    johnnygoodface
    Community Member

    Dear brenty
    I can't believe you haven't caught the irony of my message.
    You really wanna get YOUR opinion across.
    You are correct
    You have the truth
    Fine

    This topic has been on the table for more than a year (look at old messages before saying that we're complaining 9 months after the fact) and I'm soooo tired talking about that

    It's you guys who are making us feel "stupid"

    I gave it one last chance
    You won
    Fine
    Adios

  • Drew_AG
    Drew_AG
    1Password Alumni

    Hi @johnnygoodface,

    I'm very sorry if you felt like Brenty was downplaying your opinion about this! We absolutely appreciate receiving feedback from you as well as other customers, and we absolutely never want to make you or anyone else feel stupid. I know Brenty pretty well and that definitely was not his intention - all he was trying to do was explain why there isn't a setting to stop using secure input when editing items in 1Password. But 'tone' can often be a tricky thing to convey in a written message, and if his reply "sounded" differently to you than it did to me, I do apologize for that.

    I think there's actually some confusion about what's being discussed here, and perhaps that's leading to some misunderstandings. For example, I initially misunderstood bizbeblu - it sounded like they were complaining about the fact that secure input is enabled when editing items in 1Password in general. But as it turns out, the real problem seems to be that secure input isn't being correctly disabled on bizbeblu's Mac after saving those changes and exiting edit mode. And if secure input remains enabled, apps such as Typinator and TextExpander will not work.

    Is it possible you're experiencing a problem like that? In your first message, it sounded to me like you don't want secure input to be used at all when editing items in 1Password. But if the problem is that secure input isn't turning off when you're finished editing items, please let us know because we definitely want to look into that.

    This topic has been on the table for more than a year (look at old messages before saying that we're complaining 9 months after the fact) and I'm soooo tired talking about that

    If you're referring to discussions from more than a year ago, that's a different topic than what's being discussed in this thread. Just to be clear (and as Rick mentioned in his first reply above), enabling secure input in edit mode was first added in 1Password 6, which we released on January 12, 2016 (close to 9 months ago). Before that, secure input was used for the master password field on the lock screen of 1Password, but not when editing items.

    The OP started this thread because after he upgraded to 1Password 6, he discovered he could no longer use Typinator while editing items in 1Password. That is expected behavior. However, Typinator (and other apps that work by monitoring what you type) should work again after exiting edit mode in 1Password.

    If you're running into an issue where that isn't working as it should, please let us know and we'll be happy to help you with that. Cheers! :)

This discussion has been closed.