Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It was probably a wrong way to put it. I apologise.

I don't doubt the integrity, diligence and efforts the Rails project is putting into security as a whole.

Secure defaults are very important. Crypto is important, but not all security is crypto.

In this particular case, and I don't claim that it applies everywhere, this transparency has a potential cost.

I agree that it should be as transparent as possible, and also prefer convention over configuration. But some time the convention means some added risk, and particularly an unknown risk (because by following the convention I don't even have to think about this risk). In such a case, I think configuration might be preferable. Conversely, for any built-in security to be transparent, it really needs to be watertight and fit 100% of the users. Otherwise it puts some users at a risk they are completely unaware of.



> not all security is crypto

Yes, but you started off talking about crypto so that's what I'm going to address...

Unless you're a cryptographer (and even then), any time you're using any type of crypto the risk model in your head is probably going to be completely wrong. I recently blogged about this:

http://tonyarcieri.com/all-the-crypto-code-youve-ever-writte...

Unless you plan on becoming a crypto expert your best bet is leaving cryptography to the experts.


> Yes, but you started off talking about crypto so that's what I'm going to address...

I didn't talk about crypto at all, and I don't see any connection whatsoever to this subject. Admittedly, even my comment was off-topic. Now it really goes way off.


That's the case wherever trust is involved, though. Your ideal is also unattainable.




Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: