HTML 5 Video Downloading January 29th, 2010

The new HTML 5 video feature being used in capable browsers like Google Chrome is purely awesome. It amazes me that a feature this new works so well, although it does have some quirks, it’s still better than Adobe’s Flash player, and it’s improvement isn’t bottlenecked by Adobe or any single entity. I chuckle knowing that Adobe has just recently began to address the concept of hardware acceleration in this arena, and luckily they are too late – because we hate Flash video. It was used as the tool it was, and the web will now abandon it.

This is open source  in motion. If Chrome, Webkit, FFMpeg, and various other projects where closed source, we’d be moving along at the rate of molasses, like we did with Adobe’s Flash player, IE, and other proprietary software.

With that praise, there are some interesting holes, and in time they will be filled correctly. Right now the biggest would easily be how HTML 5 video warrants videos going full-screen. There are security and usability land mines that must be dodged, such as allowing web pages to enter this mode without the users consent. While I want the feature right now, I don’t want to play API hopscotch like Adobe did, so I understand some delay in this area.

I also have a growing interest in editing video, which you can’t do on YouTube directly. Somewhere you’ll have to download that video. In the past I’ve used FireFox extensions that do some voodoo to rip the FLV or MP4 stream out, but now that we’re using HTML 5 video – it’s just a file. Without any extensions here is a way to save YouTube videos in Chrome:

  1. Go to http://www.youtube.com/html5 and make sure you’re in the HTML 5 beta. You can undo this if you want later.
  2. View the page of the video, like this: http://www.youtube.com/watch?v=Y3lzd9yJP9Q (ACTA debate)
  3. Right click the video and choose Inspect Element.
  4. Double click the div element below the one that is selected. It will have class="video-content-loading". This will expand that element.
  5. Click the link in the src element of the video tag.

If the video opens a tab, then you’ll want to change your Chrome settings on how it views/downloads that file. For me it started downloading a 300 mB MP4 file, which was throttled at about 96 kB per second.  It’s nice to have this rather simple workaround, but we can do better!

I’ve never developed Chrome extensions before, but getting started was easy. Having done some FireFox extensions, I would say this is much easier and has a lower barrier of entry. The extension I’m working on is called html5-video-dl and simply puts a button puts the video file URL into the download manager. Browsers that support HTML 5 video will probably do this on their own in the near future. The extension is being tested, packaged, and submitted to the repository. It should be available, and I’ll have a link so you can install it shortly.

Better HTML Form Cryptography November 11th, 2009

Everytime we submit a form over HTTP or HTTPS with our password, we present an opportunity for a man-in-the-middle to perform some voodoo and decipher our passwords. With SSL in shambles, and HTML Form “encryption” a complete obfuscatory waste of time, most of us turn to JavaScript to perform client-side authentication. I think authentication is pretty important, but I’ve not heard much about this relating to the proposed HTML5 specification.

The Problem

There are a lot of problems with web security, but the most important is when an attacker knows your password. It’s one thing for the attacker to compromise a key local to your server, such as by a replay attack, or through breaking your hashing algorithm(s), but to gain access to the plain-text password probably puts other accounts at risk. While we should all be using 100% unique passwords for every account we create, more importantly I think we shouldn’t be sending our password over the wire at all.

The Solution

As I mentioned, right now everyone is rolling their own implementations in JavaScript. Who knows how many different copies of MD5, SHA1, etc. are floating around in everyones caches. Nothing is shared, and browsers without JavaScript support are stuck in the plain-text password sending dark ages. As mentioned in this mailing list entry, support should be added to the INPUT tag in HTML. The effect would stop the contents of type=”password” elements from sending their contents, but instead send a Hash of the contents. The mailing list except also mentions using a Salt, which is probably worth doing, but I think the concept of a truly private key is warranted.

Shouldn’t HTTPS solve this?

Probably, but there is still no good reason to be giving out a plain-text version of your passwords.

Can’t an attacker just mitigate this?

This was a topic of debate during my conversations in the IRC channel. Indeed, a man-in-the-middle attacker that has control over content could modify the HTML to not include a hash attribute, and redirect the insecure form submission to another server, thus giving the attacker the plain-text password. This attack relies on the old technology, which should be deprecated, and eventually removed.

Nicer HTML Forms in Less Time September 7th, 2009

We just discovered JotForm – an online tool for making and editing HTML forms. Most of the abstractions we have for forms are on the back-end, so we end up writing boring form code manually. Not anymore. Now we can create nice looking forms during development!

Faster Pages by Making Less Requests with Diet HTTP August 23rd, 2009

We’ve been cooking up a new project called Diet HTTP, which are designed for use with PHP with support for Smarty. The idea here is to cut down on HTTP requests for .css and .js by serving the files in bundles instead of individually. This will improve your page load time by:

  • Cutting down on HTTP requests, which are limited to 2 per domain. If you know your front page will require 10 CSS files for the different components or widgets, then just serve it as one single request.
  • Lower total size of files due to increased compression dictionary. For instance, if a CSS property is used twice it will likely reference the dictionary second time. (Compare to making a tar.gz of all your cs/js files to just zipping them)
  • “Bundles” will stay cached on the client and each bundle is a unique ID. Areas that have different functionality on your site will require different bundles of stylesheets.
  • Minifies your Javascript and CSS (or uses minified files), but doesn’t alter any of your files. (Keeps a cache)

Basically bandwidth is better spent just transmitting the files you will likely need at a later time. A good example is with stylesheets. Most pages have a base stylesheet that gets applied to every page, let’s say that’s 15 KB. Let’s say the user navigates to another page, but they won’t have to download that base stylesheet again since it’s likely cached, but they will have to download the new stylesheet for things specific to that page. The idea is to create a “bundle” of stylesheets that should be loaded together, so they won’t have to load another until they navigate to some drastically different area.

The same concept is used for Javascript being served, although the impact is much greater. A common site will easily tip the scales at 150 KB of scripts before being optimized.

We’ll be making the Diet framework available under the LGPL license. While it will be part of our Twig framework, we think it’s important for it to be easy to separate.

Should HTML 5 have better security? August 8th, 2009

With all the talk of HTML 5 around the corner, I’ve been thinking of how passwords are sent over HTTP. Let’s not forget that SSL is pretty much busted now that anyone can sign a certificate. If you wanted to avoid your passwords being stolen while someone monitors your connection, a site has to have a custom client-side component. These components usually send a salted hash (such as MD5) of the password instead of the plain-text password.

This is a pretty good method, but relying on Javascript or heavier components like Flash, Java, or ActiveX could be avoided if the HTML and browsers adopted a newer forms encryption model. It would be nice to have the server push some a key to the user for a form field and have the browser perform the hashing.

Some might argue that this isn’t something that should be done by HTML, and I can see where they are coming from, but remember that form encryption does currently exist – and is so weak it’s practically worthless. It requires almost no work to see passwords as plain-text, and anyone at all who is monitoring a connection for that purpose probably has the tools to see the decrypted passwords.

There are large dictionaries of most hashes available, some over 1 Terabyte in size, but this isn’t a concern with this proposed idea. The hash is salted with data provided by the server. In order for a hash lookup table to be useful it would have to be exponential in size and targeted at a specific sites algorithm for generating salts.

Just let IE6 Rest In Pieces August 7th, 2009

It’s 2009 and I think it’s pretty safe to say that anyone who can read probably hates Internet Explorer 6.0. Making sites in IE6 is a pain, and requires useless knowledge specific to this time vampire of a web browser. Most sites are failing to provide any kind of reliable experience within IE6, and Google has basically dropped it from their list of supported browsers for complex applications like GMail.

There have also been a website created to promote the stoppage of IE6 and moving forward to anything else. I’m not going to use any version of Internet Explorer any time soon (except for testing), but I’ve had pretty good luck getting sites to work without issue in IE7 and IE8.

What are we missing by catering to the IE6 crowd?

  • Alpha transparent PNG images. This allows sites to create images that blend over one another, without having to create convoluted images stacked on a background color.
  • A consistent and sane display model. IE7 won’t be passing Acid 2 any time soon, but it’s leagues better than it’s little brother.
  • Legitimate CSS stlying. Right now any site that wants to work in IE6 has to use all kinds of hacks that work against the very concept of the CSS language.