[AGKyle]

Hi there,

Could you give me some details on what we've done to make you feel like a second-class citizen? I'm sorry if we've made you feel that way, it certainly isn't our intent but clearly we've done something that hasn't sat well with you.

Licenses aren't going away and we are definitely offering them for version 7. There are a variety of new features that both license and subscription users will see in version 7 as well.

The command line tool was made possible because our server component was written in Go and so we had a great deal of the work done as the command line tool is also written in Go. So there's a great deal of shared code there.

The original intent of the CLI was to allow administrators to automate the creation and deletion of users and vaults. They do this type of stuff all the time and having a tool accessible to them for this purpose was a goal of ours. It has the ability alter items and all that but I think for the most part it's used as an admin tool more than anything. Very little of this applies to the way the standalone vaults work.

Either way, I'd love to understand more about what we did to wrong you so I can pass that information along to the teams that need to see it.

Thanks,

Kyle

AgileBits

[curun1r]

Sorry I missed your message from a couple of days ago, but in case you read this:

The feeling of being a second-class citizen comes from recently purchasing a new computer and the process of getting 1password configured.

- First, the webpage. The 'Try it free', 'pricing' and 'get started' links all go to a sign-up page that makes no mention of the non-subscription option. To download the software, I had to find the little 'download' link in the footer of the page. Given that it's still possible to signup for the subscription service after downloading, I'd like to see a more prominent 'download' to both support people like me who have an existing license and people who want to install first and sign-up second.

- Second, there's the experience when first starting the app. It actually took me about 30 seconds to figure out how to connect it to my existing vault that I keep in Dropbox. The sign-up flow is so prominent. It may have been different if I'd installed my license before connecting my vault, but I keep my license in my vault, so that's a bit of a chicken-and-egg problem.

- Third, on my new computer I discovered the Station app, which seems like a cool way to separate my persistent, always open tabs from my normal browser tabs. It has 1Password integration, but uses the CLI client to accomplish that, which means I'm out of luck and stuck having to copy-paste my password every time GMail wants to reverify. Adding support for non-subscription to the CLI would mean a lot since it's used to integrate with other apps.

Alternately, if you'd like to publish developer documentation on the native message protocol used by the Chrome extension, I'm happy to write code myself. I've wanted a modern version of http://sudolikeaboss.com for a while, but reverse engineering your protocol crosses my not-worth-the-effort boundary.

None of this is major, but it's all the little things that contribute to the feeling of being second-class in the eyes of AgileBits.

[AGKyle]

Thanks for providing this.

Regarding your first point. I've filed this feedback to our team in charge of the 1Password.com page. I don't have much more than that right now but I generally agree with you. There are probably reasons for why we focus this a bit differently... Notably, if I had to guess, that paying through IAP (which is how they'd likely end up paying if they sign up in app) costs us a significant amount more and offers far less flexibility. Just one potential reason I think.

For the second. We've rewritten this welcome screen multiple times... turns out getting it right is incredibly difficult. I think we've gone through something like 50 different variations of this single pane now. I honestly don't have anything on in mind that I can share here.. it's both frustrating for us because we know people are confused by it, but we also aren't sure how else we can present that information that's going to be more clear. It's always a teeter totter, trade one thing for something else, but we lose something as well. I do appreciate you commenting on this though, I'll pass it along to the rest of the team as well.

Station is one we don't generally recommend using in this way... First the blog post where we talk about this general concept: https://blog.agilebits.com/2013/03/06/you-have-secrets-we-do...

Then the quote from it that matters most:

> We have to advise you to never enter your 1Password Master Password into anything that isn’t 1Password. We aren’t casting aspersions on the integrity or competence of any developers, but we simply can’t advise otherwise.

So our general stance here is, you really shouldn't enter your Master Password/Secret Key into third party apps. We can't vouch for it and you're basically giving Station full access to your data doing this. Entering it into the CLI directly is great, but.. Station is gaining access to this information which is the issue we generally have with suggesting this type of thing.

Adding support for standalone vaults to our CLI is... difficult. The 1Password.com server is written in Go. As is the CLI. We were able to make the CLI in super fast form because we could piggy back on the code we have for the server, move a couple modules over to a new project, write some glue, wah-la. The CLI also started as a tool for management of accounts... think adding users, deleting users, adding vaults, granting access, etc. Admin type stuff. Literally none of this applies to standalone vaults.

At best we could write a CLI (separately) as part of the 1Password app that is in Objective-C/Swift, since we could piggy back on existing libraries we have in 1Password for Mac/iOS. But I really don't see very many people needing this... would it be cool? Absolutely... but... I don't think there's this great demand for it.

Regarding sudolikeaboss, I think we'd ultimately like to see something like that again. But the way sudolikeaboss worked was incredibly hacky and it was bound to break because of this. We'll have to take a look at this for future updates, but I don't see sudolikeaboss coming back as a thing, perhaps we can do something internally though. There was simply no time for this for 7.0 though. But maybe it's a neat idea for 7.1 or 7.2... both of which have some already huge features planned.

So to kind of re-iterate a little bit. The CLI exists because it was super easy to glue pieces together from existing code. It's not like we set out to write this to stick it to anyone, we wrote it because we seen a demand for it by administrators who were on unix type systems and they wanted ways to admin their accounts. It gained some editing/using features as well but those came after. Interestingly the CLI talks directly to the server for this, it doesn't have a copy of data locally... it doesn't really have any idea about data formats and such.

And sudolikeaboss, while cool, wasn't an officially endorsed product of ours... that isn't an excuse for breaking it, but it also shouldn't be a huge surprise that it did break due to the way it functioned. I personally would like to see something similar in the future though.

Hope that helps some... I understand these are all important to you though and I hope my response doesn't dismiss any of that importance. I'm only trying to explain from our side so you can see thought process a little bit. You also don't have to agree with our decisions, and I'm not trying to convince you that we did the right thing. I just find understanding why we do something makes it easier to at least accept how/why something happened.

Please do let me know if you have questions though. I'll keep an eye on this for a few more days. Otherwise, please email in and mention me and I'd be happy to help get you answers.

Kyle

AgileBits

[curun1r]

> We have to advise you to never enter your 1Password Master Password into anything that isn’t 1Password

Correct me if I'm wrong, but couldn't you re-use the plumbing that you have for the Chrome extension? The blog post was here: https://blog.agilebits.com/2017/07/19/introducing-native-mes...

That way, software could integrate with 1Password by triggering 1Password to prompt the user for the master password, choose a password entry and send that data back to the application that triggered 1Password. That way, the master password is never sent to anything that isn't 1Password. This was the workflow of sudolikeaboss. The implementation of that, however, was hacky since it used a reverse engineered websocket connection behind the scenes. It would seem that the native messaging stuff is a little cleaner and would allow third-party apps to trigger 1Password in a way that, at most, a single password would ever be exposed.

I guess the ask would be to make that native messaging protocol that the Chrome extension uses a documented and stable thing. And since the 1Password application is used by both subscribers and licensees, that can become the preferred way for 3rd parties to integrate with 1Password in a way that users know only exposes individual passwords at the single point in time when they're used rather than the entire vault, for exactly the security reasons you mentioned.

BTW...as much as I've felt frustrated by some of the decisions AgileBits has made, in the few interactions I've had with people at your company, everyone has always been the above-and-beyond type, as you've exhibited here, so thank you for the effort to engage in this discussion, likely long after others have stopped reading this thread.

[AGKyle]

There are a few security related issues with how we handle the native messaging stuff.

There are two important things:

1. We check code signatures and compare them against what we know and expect. 2. The more we approve for this the more it feels like we're screening and supporting the ones we do approve.

We have opted to remove all browsers except those that are mainstream (Chrome, Firefox, Safari and Opera). I believe everything else has been removed. We also don't allow this to be disabled, for security reasons, as of recent versions.

sudolikeaboss would also require that we add their code signature to the app and it breaks the new rule we have on that.

If sudolikeaboss ever came back, it'd be a home grown solution internal from us. It's the only way we could make this work I think.

Security is really tough. We didn't want to start feeling like we had to screen all apps and vouch for them. It's a really slippery slope. Maybe we'll find other ways to accomplish this though. There are indeed some .. plans.. that might actually really impact this in the future! We'll have to see what comes from WWDC this year before we make next steps though.

And thanks for the kind words. I like hacker news, I hang out here and read stuff during my lunch and stuff, so it's a pleasure getting to converse with people here. :)

Kyle

AgileBits