6 ms·

so maybe some novice developers write an app using the generators and scaffolding baked into Rails, and as a result they get a security vulnerability that a mor

so maybe some novice developers write an app using the generators and scaffolding baked into Rails, and as a result they get a security vulnerability that a more experienced developer might have avoided by doing extra work, and you say that's not a security problem in Rails? Young man, do not take that flippant tone with me (raps ruler on desk). Those novice developers failed to RTFM. If you want a framework that produces secure applications for inexperienced developers who do not read the fine manual, you are setting a laudable goal for Rails, but I hardly think that “Secure even for people who are 1. novices and 2. compound their ignorance by refusing to RTFM” is synonymous with “security problem.” If you open your history book to when Rails was first becoming popular, there were many people grumbling that because it was built on top of a dynamic language that it was vulnerable to all sorts of bugs caused by novice developers getting their types wrong. The argument at the time was that Rails provided a certain type of freedom and power at the expense of certain safeguards. The same argument was played out when people started noticing that monkey-patching run amuck caused certain problems. I agree with you that this is a design choice. If you want to say that you disagree with the choice as it was originally made, I agree with that too. I won’t say that I would have made a different choice back when that feature was first baked in, I did not write the framework. But here we are today, and it seems like a very good time to make a different choice.

hartror 15y ago
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_revised.htm http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_rev...
- raganwald 15y ago
  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.
  - javascriptlol 15y ago
    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.
  - Drbble 15y ago
    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?
javascriptlol 15y ago
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.
- raganwald 15y ago
  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.
  - javascriptlol 15y ago
    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.
    - javascriptlol 15y ago
      Downvoted once again by people who have no reply.
    - aptwebapps 15y ago
javascriptlol 15y ago
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.
- ryanbrunner 15y ago
  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?
timr 15y ago
"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.)
- raganwald 15y ago
  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.
jordanb 15y ago
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.

hartror 15y ago

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_revised.htm http://www.aristeia.com/Papers/IEEE_Software_JulAug_2004_rev...

raganwald 15y ago
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.
- javascriptlol 15y ago
  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.
- Drbble 15y ago
  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?

javascriptlol 15y ago

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.

raganwald 15y ago
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.
- javascriptlol 15y ago
  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.
  - javascriptlol 15y ago
    Downvoted once again by people who have no reply.
  - aptwebapps 15y ago

javascriptlol 15y ago

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.

ryanbrunner 15y ago
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?

timr 15y ago

"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.)

raganwald 15y ago
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.

jordanb 15y ago

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.