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.

Standalone IE6 Installation August 10th, 2009

All of my development is done on Ubuntu Linux, so testing things with Windows can be a bit of a chore. I’ve got VirtualBox running my Windows XP installation with IE7 for testing, but what about IE6? It’s a dying browser, but some testing has to be done in it. Running two versions of IE can seem to be quite the chore, but really all you need is the IE6 Standalone Installer.

I mainly wrote this post because I noticed so many places where linking to an older place on the browsers.evolt.org website. There where some scripting and PHP errors on their page since it was being linked to an older location, but the files are still there and the site does work.

Update: It seems that even if you’re using IE6 standalone (from the link above) conditional comments will still report it as 7.0 or, I assume, whatever version you have install. You can verify this by going to About in the Help menu. So, if you really want to test IE6 you’re probably going to want the Trendsoft installer. Interestingly, this will also display the wrong version number in the About dialog, but behaves as IE6 in regards to conditional comments, cookies, etc.

What should I use instead of IE6? August 9th, 2009

There is an all-out war on Internet Explorer 6.0 being waged. On the one side we’ve got developers that are tired of performing the voodoo needed to make anything function inside of that browser. The other side is usually people who don’t use the internet very often and typically think it’s a bunch of worthless hype to be upgrading your browser.

If you think the web looks fine to you and you’re not interested in upgrading, you might want to consider:

  • Web pages have to significantly limit their interfaces for IE6. Google’s GMail and Yahoo’s Mail both provide a more limited interface to this browser.
  • The browser is a security nightmare. Users can accidentaly allow malicious software to be installed and executed on the system without even knowing it. It’s history is heavily tainted with security issues of every kind.
  • It’s much slower than newer browsers like Google Chrome or even it’s bigger brothers, Internet Explorer 7.0 and 8.0.

So, you’ve decided to upgrade, but to what browser? My personal opinion is that Google Chrome blew everything else out of the water.

Installing Google Chrome

Everything from Google is so easy to do: Just go to http://google.com/chrome and choose their installer. It’s available for most versions of Windows, as well as Mac OS X and Linux. Chrome will allow you to import your old settings from Internet Explorer. Chrome will automatically keep itself updated without bugging you.

Installing Firefox

Mozilla also makes it very easy to get started with using their Firefox. Just download their setup for Windows or Mac OS X. Firefox will allow you to import your old settings from Internet Explorer. Firefox will automatically tell you about updates.

Upgrading Internet Explorer

You can upgrade to a new version of Internet Explorer by either:

Depending on your system there may be an additional step that requires you prove to windows that your copy of Microsoft Windows is “genuine”. Internet Explorer updates come through Windows Update, so you’ll have to have automatic updates enable or check for them manually.

CSS Sprites: HTTP Traffic and Compression Ratios August 9th, 2009

I’m kinda disappointed in the web development community for being such a lumbering beast. New ideas and methods come out regularly that are proven to work great, but often times we fail to adapt if there isn’t a lot of external pressure.

CSS Sprites, simply put, are a win-win. Steve Souders explains this well in his High Performance Web Sites: 14 Rules for Faster Pages on YUI Theater. I think the most critical element here is that it significantly cuts down on HTTP requests, which are the serious bottleneck due to a standard limit of 2 per unique domain name.

A common complaint about this method is that combining all the images into a larger one creates a “waste of space”. Indeed there will be small gaps between your images, however:

  • You should be using PNG (8-bit if you can) for this image. These image formats use lossless compression, and long contiguous areas of empty space will be compressed so well it won’t affect the size of the resulting file.
  • Multiple images inside a PNG-8 will share the same palette and may reduce the file size. Before compression this is about 0.7 KB per image. Creating just a 3×3 grid of CSS sprites this yields 20KB of savings.
  • The compression dictionary will be much better with multiple images. With a single 16×16 icon there likely isn’t many data patterns that can be used to reduce the size of the file. With multiple images you’re compression ratio will become higher because there is more similarities to take advantage of in the image.

Cutting down on file size is always nice, but really it’s the fact that you’ll be making much less HTTP requests to the server. Anyone using Firebug will notice that most of the time is spent establishing a connection to the server. This is because many servers have a limitation on concurrent HTTP transactions.

Don’t forget to put different types of content on different sub-domains if you have that option. Stylesheets, scripts, and images can all be on separate domains, although it can be tedious to get stylesheets and images on separate domains since you’ll lose relative pathing.

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.