On the spectrum of openness | Hacker News Reader

On the spectrum of openness

openeveryone.substack.com

24 pointserlend_sh9 comments

Presenting source available licensing as a threat to open source as a whole or "open source done wrong" has always seemed a little dubious to me. Doubly so when it comes from the likes of Amazon or Google.

I am curious how advocates for source availability and free access to source code think about security through obscurity.

At my company, all our libraries are open source and all our server code is private.

There is something to be said for keeping architectural details hidden from would-be attackers to make their lives that much more difficult. I would go so far as to say that, if you run servers that handle sensitive data, then it is unethical for you to not take every possible measure to protect that data including hiding your server code from potential attackers.

> There is something to be said for keeping architectural details hidden from would-be attackers to make their lives that much more difficult.

That's an empirical question. Do the security benefits of going Open Source outweigh the security costs? I don't know if there's a general answer.

> Do the security benefits of going Open Source outweigh the security costs?

Only if there are enough eyeballs. In practice that's only true for bigger projects.

On the other hand, would hackers target something that small? It seems to me like the benefits and drawbacks of open source for security would kick in around the same scale.

Yes and no. Popularity or user base and number of engineers looking at the code are probably correlated, but there are definitely exceptions, like:

* small NPM packages depended on by popular ones

* video game mods and tools

* open source end user utilities

> It is unethical for you not to take every possible measure...

Sidestepping open source for a moment, I don't believe this is the best way to think about security.

Or safety, for that matter. There's a reason we don't walk around in crash helmets all day despite it being a "possible measure" we could take to reduce head injuries.

Security measures can expand unto infinity often in ways that impose costs on other areas of the project.

Any given project has finite resources.

Therefore a better way to think about individual security processes, mitigations or measures is in terms of their cost-benefit.

An ineffective or costly security measure can have net-negative security impact if it consumes resources that could have been used doing something more effective or important.

Therefore the activities you undertake must maximise net benefit - while ensuring you have an effective answer for the highest priority risks that fall out of your threat model.

IMHO the hardest part of executing on this is quantifying risks and benefits, most security decisions are not data driven and must rely on expert judgement or intuition :/

You are right, instead of "every possible measure", it should be "every reasonable measure", where reasonable is defined by the cost-benefit analysis you mentioned.

It is hard to think of an instance where not open sourcing your server code has a high cost. It is easy to think of instances where open sourcing it has high cost - e.g. leaked deployment keys, mistakenly committed data - both of which I have seen happen in the wild working with healthcare data.

You have a valid point and open-sourcing definitely creates known risks we could enumerate without too much trouble.

If open-source were part of your mission then you would have to treat those risks like all the other risks you assume by providing your service or doing business at all.

If not, then I agree that closed-sourcing looks more attractive in most cases.

Reply on news.ycombinator.com