Hacker News Reader

Comment by dos1 | Hacker News Reader

Good for Egor Homakov. I don't necessarily agree with his methods in this case, but in the end, the net result of his actions was positive for web security. And as so many others have pointed out, when the proper channels aren't working, sometimes a little spectacle is just what you need to instigate change.

In other news, I'm not sure why the rails core team was so against this in the first place. Making things safe by default is usually a good idea. This change doesn't seem to add too much additional ceremony, and people had been asking for this for some time.

View on HN

   I'm not sure why the rails core team was so against this in the first place.

Lack of humility.

That's a bit harsh, it is at least a grey area.

Mass-assignment by-default, with disabling fields you want to protect

Mass-assignment off by default, with enabling fields you want to mass-assign.

It's hardly just outright arrogance.

In other words:

Security vulnerabilities by default, with the ability to patch the vulnerability on a project-by-project basis.

Security by default, with the ability to allow potentially insecure assignment on fields you want to assign.

This seems like an intentional oversimplification. Having mass-assignment on by default and therefore requiring the developer to create a whitelist of attributes for each of their models has a complexity cost associated with it. Failing to mention this at all shows a lack of objectivity.

I happen to believe it's worth it for the increased security, however I'm not going to pretend that there isn't an associated cost.

It is 2012, we should no longer have to debate about the acceptability of unvalidated inputs in a web application. Even PHP ditched register globals long ago.

Reply on news.ycombinator.com