[rmorey]

I tend to think this is a fair trade-off for services like this because: 1) for end-to-end encrypted services, I think what you most want to verify is: is my data actually being encrypted with my keys before being sent over the network, which open-source clients allow you to do 2) you can't personally verify what code is running on a company's servers anyway

and to a lesser extent: 3) there could be legitimate security reasons to keep server code confidential 4) there could be legitimate competition reasons to keep server code confidential

Overall I think it is a fine tradeoff. And of course, there is already a great "full-stack open source" password manager out there, in Bitwarden.

There's an argument to be made we shouldn't call the whole thing "open source" and perhaps call it "open client" or something.

[josephcsible]

> there could be legitimate security reasons to keep server code confidential

If this is ever the case, it means the server code has been written in a horribly vulnerable way and you should never use it.

[renaudg]

Not necessarily : defense in depth is a thing.

[helpfulclippy]

While it is theoretically possible that the proprietary software is well-written, I would feel much safer if “defense in depth” were achieved by opening the server code and exposing it to as much audit and commentary as possible.

[rmorey]

Yeah you're probably right

[e12e]

There's a big difference in that with bitwarden you can host the server part yourself - and that is a great guarantee for continuity of service (and bug fixes) if upstream goes away for some reason.