He's wrong about security being ignored in HTML5.<p>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).<p>Almost every section of the spec has "Security considerations" subsection and whole thing is plastered with security warnings: <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/" rel="nofollow">http://www.whatwg.org/specs/web-apps/current-work/multipage/</a><p>All new features have same-origin restrictions, and are going to support CORS: <a href="http://www.w3.org/TR/cors/#origin-header" rel="nofollow">http://www.w3.org/TR/cors/#origin-header</a><p>There have been other advancements, like CSP and STS: <a href="https://wiki.mozilla.org/Security/Features#Origin_Header_.2F_Sec-From" rel="nofollow">https://wiki.mozilla.org/Security/Features#Origin_Header_.2F...</a> which are going to be standardized by AppSec WG at W3C (<a href="http://www.w3.org/2010/07/appsecwg-charter" rel="nofollow">http://www.w3.org/2010/07/appsecwg-charter</a>).<p>If there's something missing, he could report a bug (I don't recall anything reported by him): <a href="http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG" rel="nofollow">http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20W...</a> It's even possible to report bugs without registration straight on the spec page: <a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/" rel="nofollow">http://www.whatwg.org/specs/web-apps/current-work/multipage/</a><p>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.
Quoted from the video on JavaScript:<p>"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"<p>Can someone please explain this? As someone who is not familiar with JS, I'm very curious to what he means in this sentence.
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.<p>Technically a <script type="text/python"> shouldn't be impossible either.
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.