Sessions at Open Source Bridge 2011 about JavaScript on Thursday 23rd June

The release of "Firesheep":http://codebutler.com/firesheep last year and "the presentation by Reid Beels and Michael Schwern":http://opensourcebridge.org/sessions/484 at the last Open Source Bridge opened the industry's eyes to the fact that most web applications are inherently insecure. Any application that sends requests over plain HTTP and that uses cookies to track user sessions is vulnerable to "session hijacking":http://en.wikipedia.org/wiki/HTTP_cookie#Cookie_theft_and_session_hijacking.

Many applications have reacted to this by offering options to run all traffic through HTTPS. Examples include Gmail, Github, Facebook, and Twitter. Using HTTPS does go a long way in improving web application security. But in most cases HTTPS security is opt-in - probably due to difficulties in rolling out HTTPS on a large scale and added application complexity. This means that only relatively paranoid users benefit. Less fortunate users, like Ashton Kutcher, will often be "left vulnerable":http://techcrunch.com/2011/03/15/twitter-enables-always-use-https-setting/.

Furthermore, HTTPS by itself does little to protect against "cross-site request forgery":http://en.wikipedia.org/wiki/Cross-site_request_forgery. It is still necessary for developers to use "form tokens":http://www.thespanner.co.uk/2007/04/12/one-time-form-tokens/, "JSON obfuscation":http://directwebremoting.org/blog/joe/2007/04/04/how_to_protect_a_json_or_javascript_service.html, and the like to protect application resources. This results in extra complexity and statefulness.

CSRF(cross-site request forgery) does not just force complexity though. Its existence actively stifles innovation. The new "cross-origin resource sharing specification":http://www.w3.org/TR/cors/, which allows servers to opt-into cross-origin XHR(XMLHttpRequest) requests, presents many possibilities for rich interaction between web applications. Unfortunately this specification is infrequently used because it opens up XHR(XMLHttpRequest) as another vector for CSRF(cross-site request forgery) attacks in cases where cookie authentication is used. In the eyes of many developers this is just too dangerous to justify exploring a new technology.

All of these problems are products of the fundamental design of cookie authentication: what is essentially a temporary password is transmitted with every web request and that password is easily accessed - directly by eavesdroppers or indirectly by third-party web pages.

There are better options. There are now pure JavaScript implementations of various cryptographic algorithms, including "SHA-1":http://en.wikipedia.org/wiki/SHA-1, "SHA-256":http://en.wikipedia.org/wiki/Sha-256, "AES":http://en.wikipedia.org/wiki/Advanced_Encryption_Standard, and "RSA":http://en.wikipedia.org/wiki/RSA. There are also well-studied authentication mechanisms built on top of those algorithms designed specifically to prevent man-in-the-middle attacks, like session hijacking. And an authentication mechanism based on JavaScript rather than cookie data would be far less vulnerable to CSRF(cross-site request forgery).

I will explore authentication mechanisms such as "HMAC":http://en.wikipedia.org/wiki/Hmac, as seen in "OAuth":http://oauth.net/, and block cipher authentication, e.g. "CMAC":http://en.wikipedia.org/wiki/CMAC. I will present on the applicability and feasibility of implementing these solutions in JavaScript in ordinary web applications. I will analyze performance and cross-browser compatibility considerations. Finally, I will demonstrate my own recommendation for next-generation browser authentication.

If you didn't think JavaScript was ubiquitous enough being in every browser you're certainly happy now that it's taking over as a backend platform languages and even getting embedded in to databases :)

This talk will cover the common elements of different JavaScript environments in browsers, node.js and CouchDB and various strategies for breaking up and structuring code that can be modularly used across environments.

I'll also cover some real world use cases and a few libraries that straddle the different JavaScript worlds as well as the fate of CommonJS.

Open data, open source code and commodity hardware create the infrastructure to display when the next bus or train is coming at your favorite coffee shop, brew pub or building lobby.

A combination of JavaScript and CouchDB, coupled to transit agency web services come together in a simple JavaScript API for displaying transit arrivals from multiple agencies.