

Ask HN: Why Support Client-Side (javascript) Scripting? - jcr

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.<p>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.<p>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.<p>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.<p>Think about it this way; if browser scripting and plugins did not exist,
then the vast majority of browser based exploits would not exist.<p>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.<p>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.<p>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.<p>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.<p>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?<p>Letting <i>MY</i> 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.<p>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.<p>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.<p>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
<i>seems</i> easier to secure.
======
madhouse
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.

~~~
jcr
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.

~~~
madhouse
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)

------
mooism2
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?

~~~
jcr
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.

~~~
mooism2
Sure, but how many applications are audited?

~~~
jcr
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.

