Hacker News Reader

Scott Meyers (author of Effective C++ et al.) has talked about this subject many times (including in the aformentioned book) and it puts the ball squarely in the Rails team's court.

Let's make the reasonable assumption that your clients—the people using your interfaces— are trying to do a good job. They're smart, they're motivated, they're conscientious. They're willing to read some documentation to help them understand the system they're using. They want things to behave correctly.

That being the case, if they make a mistake when using your interface, it's your fault. We're assuming they're doing their best—they want to succeed. If they fail, it's because you let them. So, if somebody uses your interface incorrectly, either they're working hard at it (less likely) or your interface allowed them to do something easy that was not correct (more likely). This puts the shoe on the foot not used to wearing it: it means that responsibility for interface usage errors belongs to the interface designer, not the interface user.

Source: Scott Meyers: The Most Important Design Guideline? http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_rev...

I think we’re in agreement. I don’t like the design, I don’t use it myself. I just think that it’s not correct to say that Rails has a security vulnerability and especially that Rails is vulnerable by default. Both of these expressions carry the false connotation that all rails apps are vulnerable and that the fix for the vulnerability lies in patching Rails, when in actuality Rails has a questionable design problem, and every developer has the power in their own hands to secure their application.

Scaffolding is part of rails, so fixing the bug does involve patching rails.

"Windows has no security vulnerabilities itself, since you can edit the exe of any malfunctioning app. A security conscious app developer is responsible for auditing Windows and making necessary changes. Heck, most vulnerabilities have already been documented, and sometimes the workaround doesn't even involve coding. " See how silly that is?

If I make something and it has a property that can be directly traced to recurring security problems, then that is a vulnerability. That it might not be cut out of whatever neat template you've built in your mind doesn't change that fact.

"Young man, do not take that flippant tone with me (raps ruler on desk). Those novice developers failed to RTFM."

I suppose that the github developers all failed to RTFM, too, right? So either they're all n00bs, or we can safely assume that everyone makes mistakes when the framework makes mistakes easy to make.

(Also, I suspect that you're joking about the "young man" thing, but it's probably worth pointing out that I've been coding for a long time. I may even be older than you. But I still make mistakes, and I definitely appreciate it when my frameworks make the Right Way the Only Way. It's not just about novices.)

Of course I was joking about the young man thing. As I suspected you were with the “Gee” thing. It’s not a formal debate, a little “local” colour makes comments like this more enjoyable to read.

I used to see this argument a lot from PHP people. You know, it's not PHP that's insecure, it's all those novices writing insecure PHP code.

Except that PHP makes it so easy to write insecure code that novices are pretty much guaranteed to produce vulnerabilities and even experts have to be vigilant to avoid accidentally stepping on one of the many landmines in the language.

If the designers of the language (or framework) put a landmine in it, and a developer steps on it, the designers of the language absolutely bear some responsibility for the fact that the landmine was there to be stepped on.

So in other words: bad design is justified by the notion that people shouldn't make mistakes. Praise the lord you don't design anything that can burn, irradiate or cut people.

I don’t think you should try to rephrase my words in your words, because in doing so you are completely misrepresenting what I said. So please, stick to just reading my words, and if you want to disagree with what I actually write, do that. What I said was:

If you want to say that you disagree with the choice as it was originally made, I agree with that too. Meaning, I disagree with the design. At no time did I say that this or any design was “justified.” That’s your word, not mine. So I think you should stick to espousing your opinions, not disagreeing with things I didn’t say.

I’m very clear that I don’t like the design and don’t use the feature myself. But as I posted elsewhere, I just think that it’s not correct to say that Rails has a security vulnerability and especially that Rails is vulnerable by default. Both of these expressions carry the false connotation that all rails apps are vulnerable and that the fix for the vulnerability lies in patching Rails, when in actuality Rails has a questionable design problem, and every developer has the power in their own hands to secure their application.

My issue is entirely with the nomenclature, not with whether I like or dislike mass assignment.

I'm not interested in your sophistry. You're saying it is not a vulnerability in rails, on the basis that it can be fixed by users. That's tantamount to justifying it, regardless of the degree. Rails is dead wrong here and I'm not interested in playing the "try to be right on the Internet" game with you.

It's not sophistry, the distinction raganwald is making is relevant.

However, even if it is not technically accurate, in the interest of getting the topic in front of as many Rails developers as possible, it's probably better to sweep that distinction under the rug and let them figure out for themselves whether it applies to them.

So your contention is that because something is "relevant" that prohibits the possibility of it being sophistic? The distinction is completely artificial. This bug in rails can be directly traced to recurring security problems. If that's not a vulnerability, then we speak a different dialect of English.

Ok, look, I actually think it is a vulnerability to most approximations which isn't what comes across in what I wrote.

That said, I don't think what raganwald was saying was sophistry at all. Sophistry implies an attempt to deceive. He was just being pedantic and a little narrow with his definition of vulnerability.

So when you say his argument sophistry, and then follow up with "... and I'm not interested in playing the "try to be right on the Internet" game with you." you're just lashing out. So that's probably why people (not me) where downvoting without replying.

  I'm not interested in playing the "try to be right on the Internet" game with you.

Just as well, it seems that we agree on so much that focusing on where we are saying different things devolves into pedantry precisely because we agree on the important matters.

As I said elsewhere:

We probably agree that this feature should be taken out and shot, but are quibbling over which charge should be read off the indictment before giving the order to fire ;-)

Downvoted once again by people who have no reply.

By the way, this is the perfect example of modernistic trash-thought that focuses on details and not behaving usefully. You navel gaze over the "correct" usage and nitpick my argument instead of getting behind the position that is going to prevent harmful behaviour.

raganwald likes to put all the blame on "novices" and tell people to "RTFM" then take umbrage to the suggestion that he's defending the existence of bad design based on an idiotic, legalistic approach to conversation.

Especially ironic considering the thing that sparked this whole discussion was a vunerability on GitHub, of all places. If the developers at GitHub are lumped in with the uneducated "novices", who exactly are the experts?