javascriptlol

6 ms·

61.
by javascriptlol 15y ago
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, m
62.
by javascriptlol 15y ago
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.
63.
by javascriptlol 15y ago
This is completely unethical.
64.
by javascriptlol 15y ago
That is, assuming it hasn't been tried before. We don't really know.
65.
by javascriptlol 15y ago
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.
66.
by javascriptlol 15y ago
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.
67.
by javascriptlol 15y ago
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 manipul
68.
by javascriptlol 15y ago
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 no
69.
by 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.
70.
by javascriptlol 15y ago
Downvoted once again by people who have no reply.
71.
by 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.
72.
by javascriptlol 15y ago
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
73.
by 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 intereste
74.
by 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.
75.
by javascriptlol 15y ago
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.
76.
by javascriptlol 15y ago
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
77.
by javascriptlol 15y ago
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
78.
by javascriptlol 15y ago
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.
79.
by javascriptlol 15y ago
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.
80.
by javascriptlol 15y ago
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 "
81.
by javascriptlol 15y ago
There is no reason to be introducing "fail open" design flaws at any level above the bare metal.
82.
by javascriptlol 15y ago
Wrong. The system should not fail open.
83.
by javascriptlol 15y ago
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?
84.
by javascriptlol 15y ago
People keep saying this, but how does the untrusted system the code is being executed on decode the output stream without knowing the key?
85.
by javascriptlol 15y ago
Being motivated by a living wage isn't the same as being motivated by the lure of millions.
86.
by javascriptlol 15y ago
Exactly. The attitude of pushing more and more trust onto the provider is just going to cause bigger blowups when something inevitably goes wrong.
87.
by javascriptlol 15y ago
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.
88.
by javascriptlol 15y ago
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
89.
by javascriptlol 15y ago
Excellent. Someone else pointed this out. This is good news.
90.
by javascriptlol 15y ago
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?

More ›