Douglas Crockford on JavaScript and HTML5 | Hacker News Reader

Douglas Crockford on JavaScript and HTML5

webmonkey.com

36 pointsiamelgringo14 comments

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

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.

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).

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.

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.

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).

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.

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?).

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.

I don't think everyone is necessarily happy with JavaScript, but it is the de-facto standard, and there is no realistic alternative.

Sure, we could add a new language, but with various competing implementations we will probably get at least the same amount of interoperability problems as we have had with JavaScript.

And because of backwards compatibility browsers will still have to support JavaScript indefinitely in addition to the new language.

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.

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.

navigator.allowXSSAttacks = false

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

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

Reply on news.ycombinator.com