I have a real beef with this "reasoning from axioms" stuff when it gets taken as a dogma. Maybe you don't take it as a dogma. I am also yet to see a working libertarian society, so it's all just academic posturing as far as I'm concerned, much like all this atheist utopianism I keep hearing about. Frankly, I don't see anything intrinsically immoral about forcing other people to do or not do things using force. You can't opt out of society with the numbers we have now.
The problem as I see it is not adhering to some principle or another it's that everything is too big and too centralised. I like a lot of what people like Ron Paul are saying, but if we were to give them a free run for a few decades we'd need a new reactionary movement to undo all the problems resulting from their own excesses. People need to let go of the idea that a person can "crack the code" of society and figure out the right ethics for all time.
I'm not saying you're a bad person. Hell, I've done plenty of unethical stuff in my time. But generating fraudulent views is a clear abuse of the system. You're simply rationalising it away.
SQL injection is a problem with the way database libraries are designed. Just because some idiotic piece of design has persisted for years doesn't change what it is: a vulnerability.
No. A property of a system that leads to compromises is a vulnerability. Let's not let give in to neo-essentialism. Just because the word "vulnerability" has been assigned some narrow meaning in the past is no reason to enforce that usage. This is a problem, and "vulnerability" is plainly as the sun shines the right word for it.
Yes, construction of raw SQL queries outside library code is a security hole. The same with writing browsers in C or C++. These bad design choices can be traced to countless security issues. The same for generating HTML using string manipulation. These are all stupid ideas, and until people realise that they're holes we will be stuck with endless security problems. And it's the coward's way out to hide behind the "sharper tools" nonsense. You don't hear chainsaw vendors wearing safety flaws as a badge of pride.
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.
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.
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.
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.
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.
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 find it in any way surprising that this has happened any more than I would find it surprising that if you put a big hole in a footpath that someone would fall into it.
Or you could disallow raw SQL strings and always construct programmatically (e.g. building ASTs). All of these recurring holes are due to bad design, period. Imagine if your microwave manufacturer said "ultimately it's up to the consumer to avoid irradiating himself". Nobody expects you to be saved from sticking a drill into your face, but nor should it electrocute you by forgetting to do something.
Even with good knowledge of a system people forget things. The blame for this incident falls 100% on rails and its awful design. It's like blaming the driver for crashing your car whose brakes can silently and unpredictably fail unless you press some button when you first get into the car. Critical failure points should be isolated aggressively. Many software "engineers" have not yet grasped this.
People do not learn from the past. People will keep reinventing these kinds of bad designs, and we will have security holes in web apps until it stops.
A system that is designed to rely on human diligence is inherently flawed. It's a mercy that drills and other dangerous tools aren't designed in the same way that a lot of software is.
Unfortunately people never learn from the past. Security holes directly traceable back to the design of C are still trickling out after 30 years. The entire construction of the web has failed to learn from this lesson. The whole design is "fail open", and one mistake ends with site credentials being dumped on pastebin.
Even a genius eventually makes a mistake. Systems should be safe by default unless there's a good reason (e.g. performance). Why bother with high level tools if they're not even protecting you from mistakes?
The attitude that Linode should refund the loss is a fragilising attitude. The more trust you keep pushing onto the provider the bigger everything is going to blow up when something goes wrong.
Yeesh, relax. Have you been injured by this? When they say they know what they're doing that's written from their perspective. It's not a declaration that they're going to live up to the expectations of every manchild who feels entitled to one of these devices.
Thanks! I didn't know about WebRTC, so this seems like good news. Is it tailored to video/audio or are we talking about something you can design a protocol on top of?