Show HN: Let's Chat, a self-hosted chat app for small teams 11 years ago
You should probably file it as a bug or ask for support on github rather than HN! :)
HN user
ehsanf
79 karma
I am an application security expert with a good software development background. My favorite language is Python and I have some Linux admin experience before.
Posts3
Comments7
Lots of reasons. For example, you can't just paste a picture from your Clipboard into a IRC channel and expect it to work. Granted there are image hosting services out there, but if you want a chat server on your private network and you are a small company, you want it all in one. Same goes with highlighting mentions, Desktop notifications, saved transcriptions (IRC is transient by nature), LDAP/Kerberose integration, XMPP support (again, there are XMPP bridges for IRC, but not integrated in any free private IRC server I know of). UI is another aspect too.
Wow. That's a lot of servers exposed. I bet majority of them have the application/web server running on the same host. I think they should change the default to 127.0.0.1 and let people knowingly expos them to outside of localhost.
MongoDB manual has some good recommendations on operations here: http://docs.mongodb.org/manual/administration/security/#oper...
It certainly helps limit the damage. However, unless it is chroot-ed, it will still pose a very serious risk. And even with chroot, the damage is not totally eliminated. The attacker can start leveraging local vulnerabilities.
LLC vs. S-Corp vs. C-Corp 13 years ago
The article suggests, but doesn't explain why LLC / S-Corp is better if you are taking all the money out.
It feels to me that if you don't have to retain any money, then they both collapse to the same situation more or less. The only difference being C-Corp needing more expenses in accounting (and maybe legal) to just keep the books in order, but that is not a significant factor.
We should call it "insecurity by default" (in contrast to insecurity by design). A major problem is that nobody takes responsibility or pays attention for default choices.
A ton of packages have default choices that are inherently bad/insecure (mail servers listening on all interfaces by default, SSH servers accepting root login by default, and so on). Packaging is just as important as development.
I believe over-engineering is also a culprit here. We had a similar situation in JSON handling in browser. Some over engineered feature allows custom objects to replace built in object for lists, allowing XSS through JSON parser. The solution was to make every REST API to start with a top level dictionary object. It just sounds arbitrary over engineering!!