We’ve made some significant changes to how people can view our Security Seminar Series:

• We’re now offering h.264/mp4 versions of the seminar videos, both as downloadable files and in a spanking-new video podcast.  Look us up in iTunes or the Democracy channel guide, and you’ll find us.  The 320x240 videos are not only higher-quality than what we’ve previously offered, but are also playable on portable players than support h.264 (we’ve tested it on 5G iPods)
     
• We will also look at encoding all of our previous recorded seminars to h.264/mp4 in the next few months.  Those that we have on DVD will be easy, but the ones more than a couple years old we only have on VHS, so they will likely take a lot longer.
• In the near future — at latest by summer 2007 — we will stop encoding our videos in RealMedia format.  The popularity of Real has faded a lot over the years, and most folks (including us) aren’t interested in installing it.  This would leave us without a streaming video format, but we’re not sure there’s a lot of demand for one now.  If there is, we will likely go with an embedded Flash video player rather than something like Windows Media.

If there is strong interest in providing other video formats, please let us know.  We may consider moving to 640x480 resolution for our videos now that iPods support the larger size, but we don’t want to push the file size to high and make for lengthy downloads.

If you have problems or feedback, please let us know in the comments section.

You know, I would feel a lot better about this technology if someone had fixed basic problems with the way browsers handle JavaScript, about JavaScript policy specifications and compliance testing, and if there were good, usable and mature static analysis tools that could detect cross-site scripting vulnerabilities (Pixy by Jovanovic et al. comes to mind as a promising open source tool), and if people used them.  These problems have been known for a long time.

1. Same origin policy and shared servers.  So, my home page is http://homes.cerias.purdue.edu/~pmeunier/;  if I put a nasty javascript there, it can access or change the contents of other CERIAS home pages if you follow a link from my page, or if my page opens another home page for you.  I made a demo which for Safari users displays Adam Hammer’s home page url but with contents of my choosing (with apologies to Adam).  Firefox is a bit smarter and the url displayed is instead that of my page, which could clue attentive users to the fact that the content really comes from elsewhere.  Adam doesn’t actually have a home page there.
2. Modern browsers still can’t survive a visit to this site (WARNING!  Your browser will likely crash or become unusable when you click buttons on that site):  Nasty Javascript Bombs (I didn’t try all browsers, like Opera, but Safari died horrible deaths)
3. Modern browsers can still be captured:  Firefox users visit (WARNING!  you won’t be able to return) the jail, do not collect $200.
4. Searching for JavaScript-related vulnerabilities in 2006 in the National Vulnerability Database gives 124 matches (and the year is not even over).  3 of those are accidental hits (because “javascript” was part of a file name or such).  About 50% are cross-site scripting vulnerabilities, that could include the above Javascript (and likely worse code than changing your choice of hero). About 40% are coding errors in the JavaScript implementation.  About 10% are still issues with the enforcement of JavaScript default security policies, or things that should explicitly be stated as part of default policies (e.g, CVE-2006-2900 and CVE-2006-2894, abusing Javascript keystroke events to trick users into typing where they didn’t mean to).  Cross-site scripting vulnerabilities are hard to avoid because scripts can be embedded almost anywhere inside HTML.  The separation between code (JavaScript) and data (HTML) is flimsy and complex.  I predict that XSS vulnerabilities will be to AJAX applications what buffer overflows and format string vulnerabilities are to C:  a real pain.  There is no sign that browsers have matured enough yet to be trusted in handling JavaScript safely, and this will likely continue for many years.
5. Perfectly compliant JavaScript and browsers can be used to scan internal networks and even perform limited exploits.
6. JavaScript seems to be used most of the time to perform tasks that are user-unfriendly (hide user interface elements and generally remove control from the user, create pop-unders, show ads, track you by history, etc…).  So, I should expose myself to these, and the above and future vulnerabilities, so you can program something that’s a little slicker, or poorly duplicates the functionality of executables on my system?  Huh.

So, tell me again;  do you really want to build castles on that foundation?  It sounds like a bad idea to me.  We can always hope that eventually, AJAX horror stories (to come) will drive security improvements, but I’d rather not be in the crowd of early sufferers.  At least, please do me a favor and honor the principle of graceful degradation, so that if I visit your web site with JavaScript turned off, I can still make some use of it.