To clarify, I'm more looking for closure, as seeing this behaviour on HN first-hand (as opposed to the N times witnessing these sorts of issues raised by someone else) has made me question the ethicality behind how HN is operated. The escalation of frustration comes in response to experiencing it first hand.
I will try to restate my points, in as neutral of manner, so they aren't misinterpreted as attacks. This is my thought process, and I'm providing it as genuine feedback.
This project in particular:
- attacked otherwise neutral competitors, misrepresenting them.
FTP is a protocol associated with a general air of insecurity and poor practice. Most technical people would immediately say not to use it, and that there are far better solutions which aren't fundamentally insecure. Vault is not anything like that. That is a misrepresentation and additionally an attack on the usability of their competitor's product, which is unmerited.
- does not observe the best practice of having security-oriented products be open source.
It is crucial for software in this category be open source, in order to have them widely vetted, and for vulnerabilities not to be incentivized to hold onto (and sold), vs reporting to the vendor. The team have reached their decision that they will NOT open source it https://news.ycombinator.com/item?id=24720669 If I cannot build my own binaries (even if unreproduceable builds), I cannot trust the vendor. Additionally, I must trust them to operate and secure it as a public multi-user system better than one could in their own infrastructure under several layers separating it from the public. Humans are prone to mistakes, closed source software engineers make the same mistakes made in open source, only they have employees who's primary task is shipping new features-not fixing a bug which no one may see until it comes out that it's been actively exploited for years; let people improve the overall security, and encourage the only people looking for vulnerabilities to be those who would benefit from exploiting them personally, or by reselling them to the highest bidder.
- demonstrated that the are willing to say things which aren't true, or that they just didn't care to verify the details before stating them as fact.
The authors make the black/white distinction between "you use Dropbox if you aren't paranoid" and "there are self-hosted options if you care about that, but they aren't qualified because you can only use them this way", despite it not being the case. It's a spectrum, and you can achieve the same results with either offering, only with one your only choice is to trust them and that they have things so tight that several malicious employees would be subverted.
- used their employees' previous employers to legitimize their product.
As someone who may be selecting security-oriented tools for a project, and as a someone who has experienced a lot of issues specifically with their engineering/operations firsthand, Uber engineering as a point pushes me away from considering this tool. Uber has also been criticized many times for unethical actions; sure, engineers may often be simply heads-down and following a spec, but I would rather work with someone who didn't just "follow orders". As someone evaluating your offering, my specific feedback is that you will push people like myself away by leaning on that as part of your marketing/branding, particularly when it involves secret management - a topic which is highly dependent on unbreakable morals.
---
I'll stop there, but these are all legitimate concerns, which their prospective customers may consider. My contribution to the conversation is raising those concerns, rather just just discounting them and two years down the line this tool is everywhere and a real problem happens to a company or individual as a direct result of people being led to trust this tool/team.
Some people aren't going to politely state these things, most won't at all and will just pass by; I think the team should be prepared to address these sorts of concerns, for a variety of reasons, including risk assumed by their own investors. If they make a mistake, it's important that they own it, and not just brush things under the rug and ignore those concerned enough to raise such issues.