Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Why Support Client-Side (javascript) Scripting?
2 points by jcr on April 18, 2011 | hide | past | favorite | 7 comments
I already know the topic of client-side scripting and plugins is controversial and my views will be wildly unpopular on HN. It does feel a bit trollish writing and contemplating posting this, but I would really like to politely understand the other side of the debate, even if I might not ever agree with it.

With DOM headaches aside, I'll be the first to admit that coding in javascript and other client-side execution venues (swflash, java, ...) can be very interesting and a whole lot of fun. Racing motorcycles and trick driving are also a lot of fun. But none of these things are safe or smart.

If you're on a race track or driving range, the risk your wild motor vehicle fun poses to others is mostly mitigated. In contrast, your reckless and hopefully wreckless fun would be extremely dangerous to others if preformed in a shared public place. The world wide web is a shared public place.

I give due respect to jwz and friends at Netscape for developing javascript in a mad rush to prevent Microsoft from cramming a proprietary scripting solution into the nascent web. But scripting was a horribly flawed and dangerous idea from the very start.

Think about it this way; if browser scripting and plugins did not exist, then the vast majority of browser based exploits would not exist.

The most fundamental tenet of system security is, if someone else can run code on your machine, then it is not your machine. Sure, with java, javascript, swf and similar, there is supposed to be a "sandbox" where scripts can play safely, but in reality, a sandbox is where dumb kids play and cats crap.

Sandboxing has failed, and failed, and failed. It violates the most fundamental tenet of system security so it will never work. The reality is unfortunate, and means less-fun coding, but ignoring reality is putting other people in jeopardy.

The web would be much safer if it was merely a way to transfer and display data, rather than a way to transfer and execute code. It certainly is possible to mess up data handling in exploitable ways, but the reduction of complexity and avoidance of execution would most likely be more secure than what we have today. The web as it exists with scripting and plugins is a classic example of failing to think through the implications of a decision to determine if the idea can be abused and if the risks are worth the rewards.

I'm sure the vast majority of HN is not concerned since you consider yourself technically proficient enough to avoid the dangers of scripting and plugins. Unfortunately, you're wrong. Worse yet, you're being horribly inconsiderate to the rest of the population including the people you supposedly care about like your mom who hates computers.

Have you ever had the "pleasure" of trying to show a non-technical friend how to use noscript after they got owned, or did you just let them fend for themselves?

Letting MY idea of fun put others in jeopardy is more than just irresponsible and unfair, it's entirely unconscionable. I just hope the "unpopular" view on scripting and plugins comes to mind the next time someone you care about gets owned, tracked or manipulated through a web browser. I won't pull out the thread-bare rhetoric of, "Part of the solution or part of the problem," or worse, "For us or against us," but I will wave my hand and suggest that you want to go home and rethink your life.

Though I refuse to deployed it, I've played with javascript a lot, and enjoyed it, so I guess I'm part of the problem too. I certainly don't think you're "evil" for supporting or using javascript or any of the other client-side execution venues, but I do believe you are making a mistake in supporting the status quo of putting others at risk unnecessarily. I believe we can do better than client-side execution, and I believe we can do better at keeping our friends and families safe.

If you're already rethought your life and have a viable reason for putting others at risk, I'd like to know and understand your reason. On the other hand, if your reasoning boils down to just profiting and competing, or everybody does it, then you really don't want to sell me any death sticks.

And lastly, yes, maybe I'm just too old and pine for the imaginary better days long past when things were a lot more simple. It might be just nostalgic or formally provable, but keeping it simple at least seems easier to secure.




The problem is, that with every new development comes new risks. We could go back to living in caves and bashing animals with clubs, and cooking them over fire we set with a bunch of rocks and wood. That would be a lot safer than cycling to work each day, with nuclear missiles looming over our heads, not to mention the countless other risks one takes just by stepping outside of the door.

It's the same with the web. You could take away the scripting, but you'd end up with technology that would be as useless for today's man as a hunt & gather culture of a caveman would be. We've grown to depend on it, just like we depend on cars (that pollute the air, and are the cause of many a deaths - more than client-side code execution, I'd think) and nuclear power.

With technology, comes a risk, and I don't think there's a way around it.


Yes, there are risks in everything, even just handling data as I mentioned. As for whether the risks are worth the rewards with scripting, it's debatable, but calling a web without scripting "useless" is incorrect; at the moment you're using a purely data driven website. HN is certainly not useless by modern standards.


There are exceptions, of course. Try imagining Twitter, Facebook or any of the other popular (not-such-geeky) sites without javascript, or any client-side scripting for that matter.

(FYI, HN has an onclick='return vote(this)' on votes, so it does use javascript too - although, very little, and it's optional)


Running an application written in Javascript in my browser is more convenient and surely no more dangerous than installing and running an application written in C/C++/Java/whatever directly on my computer?


In total, it would be more dangerous. If you have an audited application to handle a particular type of data, then downloading countless unaudited applications from unknown sources is less secure.


Sure, but how many applications are audited?


Not enough, and worse, auditing is never a guarantee.

None the less, at least the perceived risks of audited code seem to be less than unaudited code, and there is at least some data to support the assertion. It's not a guarantee of perfection, but it does seem better than the alternative.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: