Hacker News new | ask | show | jobs
by mcdonje 1474 days ago
Libraries are generally larger because they are usually written for more use-cases. If your program is only referencing a small portion of a library, then rolling your own doesn't mean rewriting the library. Your code will be more minimal because it's only written for your program.

Assuming you're fallible and write code with exploits like everyone else, your program will probably have different exploits from mine. An attacker won't be able to target a widely used library and enjoy being able to pick from several targets. Instead, they'll have to tailor an attack for your code base. Each exploit found yields less of a reward, which will frustrate less motivated attackers.

2 comments

This comment inflates the upside risk (risk that every developer reinventing the wheel creates lower chance of hack of their code succeeding) and discounts the downside risk (the increased costs associated with elimination of specialization/consolidation of code into reusable libraries).

> Instead, they'll have to tailor an attack for your code base.

This misstates the actual threat.

Assume detection of exploits is automated (even if it isn’t completely automated now). Assume exploit code is modularized and passed around on hacker markets, because they are.

Your recommendation only increases the cost to exploit by a small factor, but it also increases the inevitable costs of legitimate usage by possibly a much larger factor (patching the inevitable bugs which are found). Because developers aren’t specializing (in how to efficiently+safely write logging code) bugs both in the designs phase and implementation phase will be higher than in a counterfactual specialization world.

This is just security through obscurity. It's no different than skipping password-hashing because you think you are too small be attacked (after all you can minimize one more dependency). It works up until the point your business is actually worth anything.

Libraries are not only larger because they are written for more use-cases, but also because they cover more tested edge cases.