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.
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.
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.
If you plan on taking the money out of the company immediately, the LLC/S-Corp is better because the company doesn't pay any tax on that income – it "passes through" to the members as regular income. Therefore, it's only taxed one time. With a C-Corp, the corporation pays taxes on its income for the year, and any money paid out to the shareholder is taxed at 15%. Thus, the actual earnings of the corporation are subjected to double taxation, which the LLC/S-Corp can avoid. The potential problem with an LLC that he's referring to is that LLC members are taxed on their share of annual income, whether or not it is actually distributed out.
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!!
Why can't there be a set of parsers for YAML, JSON, and XML that are tested, abused, and audited aggressively so that your interchange formats don't become attack vectors?
The current state of having a half dozen of each of these is complete chaos. Presumably nobody thinks they're accountable because everyone has the option of using another package instead if they're not happy, basically passing the hot-potato constantly.
Is there a non-Ruby project that has a good implementation of these worth studying?
