Agent API for Third-party Developers?

Harry Warrior

I think you should open up the "one password agent api" to developers. It sort of already is, if your browser plugin code is in JS. However I would prefer official support for such an API.



I am *not* asking you to open up the database format OR open-source your app. I understand all of us need to make a living and I am glad to pay my part. oss-ing your browser client code might be good, but that is not strictly necessary either.



Your product will be even harder to replace (for the competition) once more and more apps are tightly integrated with it. Try to develop an ecosystem around 1p rather than one application.



Some of my long standing issues , ability to match more than one domain, tighter integration into non-web apps (ssh, iterm, bitbucket, github etc) are not that hard to implement for third-party developers.



--

Harry

jpgoldberg

That is an interesting idea, Harry. In the past we've been extremely reluctant to make 1Password scriptable, and I think that our reasons for that apply to explicitly opening up the protocol for talking to the Helper/Agent. Basically we don't want people to store or handle their master passwords insecurely. Once third parties start scripting things to talk to 1Password, then I think that it is inevitable that some third party tool could be distributed that doesn't handle master passwords well.



You are correct that it wouldn't be hard for someone to reverse engineer the protocol, and we can't prevent anyone from doing so; but we'd really rather discourage that than encourage it for the reason I've listed above.



Our data formats are another matter. Just as we've documented the format of the agilekeychain format, we have no objection to documenting the format used within the extensions or the forthcoming 1Password 4 format. Again, we don't want third parties manipulating these things (again for the reasons that I've outlined, and additionally the concern about data corruption), but we feel that it is good security practice to be as open about how your data are stored and encrypted. The only reason that those aren't yet documented is that there are still some design issues to be settled, but it's mostly because I haven't gotten around to it.



I really do understand the appeal of what you describe, and it would make "good business sense" as you also outline. And while you might treat master passwords well, I'm just fearful of a widely deployed "add-on" that doesn't.



I know that this isn't the answer you were looking for, but I hope that you understand its reasons.



Cheers,





-j

Harry Warrior

[quote name='jpgoldberg' timestamp='1332815110' post='59124']

I really do understand the appeal of what you describe, and it would make "good business sense" as you also outline. And while you might treat master passwords well, I'm just fearful of a widely deployed "add-on" that doesn't.

[/quote]



Even for that, you could follow the apple model (say, compared to Android) and guard your app-store with an "iron fist".



Also on another note, I think you shouldn't get in to the business of ensuring complete security for dumb users. From the comments I hear in your forum, your users know what they are doing. They are extremely security conscious. If the user is dumb enough to choose a bad plugin/addon, they would also be dumb enough to install a key-logger. So you can never completely protect a dumb one...

jpgoldberg

There is no way that we could control who or what interacts with 1Password in the way that Apple can control what goes into the iTunes store. If we release an API for interacting with 1Password anyone could distribute software that makes use of those. The only thing we could do is enter into litigation (or threats of it) we release the APIs with certain conditions. That would neither be effective nor a good use of our efforts.



Our users are great. And our forum participants are among the best. But there are a lot of people who use 1Password without a very deep understanding of the security requirements. We do have users who, were it not for 1Password, simply keep a list of their passwords in a spreadsheet or word processing document. They use 1Password not so much for the additional security, but for the convenience of the browser integration the management of those passwords.



You are absolutely correct that we can't prevent people from installing trojans on their machines or other practices that can wreck their security. But the idea of lots of 1Password plug-ins floating around and being developed or distributed outside of our control would be a 1Password specific security issue. It is something that is part of our job to worry about.



But reading over the integration ideas that you mentioned, I am wondering (and this is just off of the top of my head) whether we could have a way of querying for 1Password data if 1Password is already unlocked. That is, we would provide no way to unlock 1Password from third parties, but if 1Password is unlocked, then maybe allow a severely rate limited access to only those items which a user has marked as being exportable this way.



Unfortunately allowing third parties to pulling from an unlocked 1Password without providing the master password means that malicious apps could then start doing so without the users' involvement at all. So on the one hand, I don't want third parties to be dealing with master passwords, and on the other I want the use master passwords to authentication with 1Password. I can envision all sorts of protocols that could be used to deal with some of these, but the ones that come to mind immediately would involve very substantial complications.



We've been asked about this kind of thing before, but given our shift to interacting via the Helper/Agent running on a web socket, I do see that the idea is more appealing than it has been in the past. Still the best I can tell you is "we will keep it in mind."



Cheers,





-j