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.
> 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.
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.
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. :)
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