I would host my own in a google app engine or heroku and avoid a 3rd party who is more attractive to hackers due to the number of accounts they host and potential gain to criminals.
I would host my own in a google app engine or heroku and avoid a 3rd party who is more attractive to hackers due to the number of accounts they host and potential gain to criminals.
Any self hosting would need to be fully connected with automated update notifications from the "crowd" of contributors and reviewers.
I guess, it becomes a managed service at that point (since as you point out it should have reliable and secure production characteristics which does require a high level of competency). I am imagining a cloud of one for my passwords (a stateless, secure container, with disabled user access to the OS and which connects to an encrypted simple file store to keep my small sized but precious passwords).
I was just pointing out that Open Source in and of itself isn't a security protection. If you follow the same design you'll have the same design weaknesses, Open Source or closed. The "more eyes" thing, may be true, but I'd argue popularity is more important than license in determining the number of "eyes."
I'd also caution you in assuming an exploit would be against the server side. The server holds a bunch of really hard to decrypt blobs. The client is the real crown jewel. The client browser has all of the usernames/passwords decrypted, so if you were either able to deliver an "evil" extension update, or find an exploit in the existing extension, you could extricate those credentials.
That's the real rub: You turn off extension updates and you're more secure against "evil" extension updates; but you're now more vulnerable to situations where a bug is discovered in the legitimate extension and the organisation pushes a real update to patch that. Auto-updaters in particular are both a huge benefit and a huge security hole.