
Douglas Crockford on JavaScript and HTML5  - iamelgringo
http://www.webmonkey.com/2010/05/douglas-crockford-on-javascript-and-html5/
======
pornel
He's wrong about security being ignored in HTML5.

HTML5 added postMessage that allows to isolated DOMs to communicate
(previously you'd have to give up isolation), sandboxed iframes (you can embed
untrusted content and e.g. disable plugins in it), blocking of link referrers
(webmail links won't leak your inbox URL), cleaned up content sniffing,
defined exactly how browsing contexts and window proxy objects behave (very
tricky balance of backwards compatibility and isolation of pages).

Almost every section of the spec has "Security considerations" subsection and
whole thing is plastered with security warnings:
<http://www.whatwg.org/specs/web-apps/current-work/multipage/>

All new features have same-origin restrictions, and are going to support CORS:
<http://www.w3.org/TR/cors/#origin-header>

There have been other advancements, like CSP and STS:
[https://wiki.mozilla.org/Security/Features#Origin_Header_.2F...](https://wiki.mozilla.org/Security/Features#Origin_Header_.2F_Sec-
From) which are going to be standardized by AppSec WG at W3C
(<http://www.w3.org/2010/07/appsecwg-charter>).

If there's something missing, he could report a bug (I don't recall anything
reported by him):
[http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20W...](http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG)
It's even possible to report bugs without registration straight on the spec
page: <http://www.whatwg.org/specs/web-apps/current-work/multipage/>

And many fundamental issues are really unfixable, i.e. a "fixed" browser would
"fail" to work "properly" with many major websites. Lots of simple payment
gateways (including some of PayPal) rely on CSRF vulnerability to pass payment
data. Google-hosted jQuery relies on XSS vulnerability. The only practical
solution is opt-in to new, stricter security models, which is what HTML5 and
other WGs are developing.

~~~
olavk
I think he is referring to a specific issue: He wants a security model that
allows "sandboxing" partially-trusted code so that it cannot take over the
whole page. Today, if you execute a piece of JavaScript you have to trust it
fully. This is an issue with e.g, ads. If an ad includes JavaScript, it can
steal your users passwords.

He mentions Caja (<http://code.google.com/p/google-caja/>) which is an attempt
to provide such a security model.

I guess this is a serious issue for the big ad-driven sites like Yahoo and
Google. He is frustrated that the other parties involved in standardization
(primarily browser vendors) does not prioritize this issue. I do agree that it
is disingenuous to state that security was ignored.

~~~
pornel
Not having his pet feature in the way he likes is not same as ignoring
security (and he repeats few times that HTML5 prioritised other stuff over
security, keeps making things worse, etc. which is not true).

<iframe seamless sandbox="allow-scripts"> allows embedding of untrusted
scripts. JS won't be able to escape the frame, but will be able to display
result within the frame or send you result via postMessage().

~~~
wvenable
Using an <iframe> this way is like securing your house by nailing your door
shut. Caja is more like just adding a lock to the door.

------
makeramen
Quoted from the video on JavaScript:

"eventually i discovered that there is actually brilliance in this language,
that it's right in a way that very few other languages ever get right"

Can someone please explain this? As someone who is not familiar with JS, I'm
very curious to what he means in this sentence.

~~~
pornel
It's "Lisp in C's Clothing"
(<http://javascript.crockford.com/javascript.html>)

JS has first-class functions with closures. This is simple concept that
enables lots of interesting constructs — callbacks, methods, currying.

It makes event handlers/callbacks very easy (so easy that node.js can rely on
them for everything).

It allows very flexible "fluid interface" like in jQuery.

Mixed with JS dynamism and prototypes allows you to invent your own OOP
variants (and JS's standard prototype-based OOP isn't bad either).

------
scrrr
Apparently everyone is happy with Javascript, or there would be different
scripting languages on the client-side. Apparently it wasn't an issue whether
Javascript should be used in HTML5.

Technically a <script type="text/python"> shouldn't be impossible either.

~~~
RyanMcGreal
It's not technically impossible but it would be challenging to get all the
browsers to support embedded Python, not to mention versioning issues (does
IE10 target Python 2.5, 2.6 or 3.1?).

~~~
bobds
This feature is already here: Appcelerator's Titanium

It supports Python, Ruby, PHP and you can do things like <script
type="text/python"> or <script type="text/ruby" src="myfile.rb"/>. They have
made an underlying object system that can act as a bridge between Javascript
and Python/Ruby/PHP, it's called Kroll.

Kroll's source code has been released: <http://github.com/appcelerator/kroll>

Obviously, there are bound to be multiple gotchas when using such a bridge
between languages, nevertheless I thought it was pretty impressive the first
time I saw it.

<http://developer.appcelerator.com/doc/desktop/python>

Scroll to the bottom of the page for an example of using jQuery via Python.

------
liamk
I'm wondering if security was ignored, when introducing HTML5, simply because
it isn't as sexy as adding new features? Removing XSS seems like a win to me,
especially -- as Crockford points out -- with new technologies like web
storage being introduced.

~~~
rimantas
What are you talking about? How do you "remove XSS" — it is not some feature
of HTML what you can just "remove". And no, security was not ignored.

~~~
points
navigator.allowXSSAttacks = false

If only the silly browser makers would set that flag to false _sigh_ It's so
easy!

------
anedisi
yup crockford is my hero :) his book showed me how to love javascript.

