Book review: Programming the Mobile Web

"Mobile web" is vast landscape. It has always been fragmented, with standards bodies pulling one way and browser developers trying to ignore them and do their own thing—whether to stand out or to get that new release out the door quicker. A developer who wants their web site to work and look good on a wide variety of devices had to either be as conservative as possible (1990s-era HTML tends to look the same everywhere), or to buy a room full of mobile devices for testing.

With Programming the Mobile Web, the author Maximiliano Firtman put his roomful of mobile devices through their paces. For designers, the book explains what can be done on today's devices. For developers, it explains what protocols and file formats are supported on which devices, what screen resolutions to expect, how to query for capabilities, and how to gracefully degrade functionality when certain features are not available. The coverage of protocols and file formats is impressive, going all the way back to WML and covering all the way up to HTML5, CSS 3, and modern Javascript libraries. It also covers HTML5 new features, including local storage, geolocation, and improved media support.

Reading this book, you may feel like you're getting mentoring from a long-time, grizzly web developer who's been deep into it from the very beginning. An example of a bit of wisdom from the book:

When you load an image in a web application, the original file size matters only in the data transfer. Once the file is on the browser, it is decoded in memory and it is always treated as a bitmap. Therefore, the size in memory can be calculated as width × height × bits per pixel. We should be careful, therefore, about loading big image files even if they are small in terms of bytes. Just to give an example, a full-screen image on a third-generation iPad will typically use around 12 MB of RAM.

Using more RAM will impact website performance when loading, scrolling, and returning from a frozen state (for example, when changing tabs).

Obvious? Maybe, in retrospect. As a programmer, I've known that graphics chips and low-level rendering routines don't deal with PNG, but rather with bitmaps that occupy RAM. But I didn't apply this knowledge to mobile web until reading this. This book has more than its share of these.

However, this is not a programming book per se. The best way to treat this book is as a companion to web programming books like the classic JavaScript: The Definitive Guide. Programming for Mobile Web will tell you what to be aware of across a wide swath of devices to ensure a consistently reliable and pleasant user experience, and it'll guide you to make good design decisions. Then once you know what you want to do, programming books will see you through the implementation.

Programming the Mobile Web How do you take advantage of the new opportunities opening up in mobile web development? With this book, you'll learn the intricacies and pitfalls involved in building HTML and CSS-based apps that you can extend to work with particular devices, including the iPhone, Nokia, Blackberry, Android devices, and other smartphones. You'll not only learn how to deal with platform variations, finicky browsers, CSS compatibility, and other issues, but also how to create pleasant user experiences in a constrained environment.

O'Reilly's one-day massive sale

As you may know, I am a big fan of O'Reilly Media, a premier publisher for technical literature. I am a member of their Bloggers program, giving me an opportunity to read new ebooks and review them. I am also a member of their affiliate program, giving me a small cut if you buy anything through the below link.

Today, O'Reilly is having a massive sale on ebooks, in celebration of the Day Against DRM. O'Reilly, along with many other ebook publishers, had at one point made the difficult decision to not use any Digital Rights Management on their ebooks. This is a massive win for the consumer, and only an arguable win for the publisher, so I am grateful to O'Reilly for doing this.

The sale lasts today only!

Check out the multitude of technical books and videos and learn something new today!

Mac or Windows?

My new employer wants me to choose between a 13" MacBook Pro and a Lenovo machine running Windows. (That's all the specs I have.)

I've never used a Mac, beyond my brief, awkward experiences in tech stores where I try to interact with a Mac, get frustrated with how unusual things are, and walk away. (And this is after using Linux on the desktop for 10 years and leaving for Windows' greener pastures.) But the incredible popularity of MacOS X  -- and the neverending stream of defections from Windows -- is strong evidence that the Mac is worth learning.

Should I take the plunge, or should I stick with Windows?

This would be for web development, with actual development being on remote Linux servers. The machine would interface with the servers using sshfs or Samba.

Browsers should open the .md file extension

Inspired by this comment, I propose that web browsers should open and render the md (Markdown) file extension the same way browsers already support html, jpg, and many other file extensions.

Book review: Vintage Tomorrows

You may have heard that any movie based on a novel is forced to gut the novel to the bone in order to fit within the allotted time. You may have also read interviews by screenwriters, directors, and producers that it's a very challenging and painful task. The authors of Vintage Tomorrows have spared themselves. Vintage Tomorrows is 412 pages long. By god, I read at least the first third. I really tried to get into it. But after a while, I couldn't take it anymore.

Vintage Tomorrows sets a goal of defining steampunk. A relevant quote:

"A steampunk object arrives with the intention that it’s not meant to be used when it comes out of the package. You’re meant to do stuff with it… to make it yours. It has to be sized to fit. Stuff has to happen to it. It’s meant to be bodged and changed after it arrives. You can see how it’s been put together. It has obvious snags hanging off of it where you’re meant to add stuff, or fix stuff, or attach stuff, or even move stuff around." --a certain Cory

What an appropriate way to describe this book! The book is a cornucopia of the authors' musings on day-to-day minutiae, on their experiences and thoughts in local restaurants, on the most trivial details of numerous conversations that are presented, unsummarized, in their full glory. This is the closest to a stream of consciousness that I've experienced since reading House of Leaves many years ago. I can see how the book has been put together. But I don't buy a toothbrush where it's my job to attach the bristles.

Needless to say, I haven't figured out the point of the book. I hope it's simply that I don't see eye to eye with the authors.

Preventing filesystem traversal attacks

I am implementing a software feature that takes a filename from a client and accesses it on the server. The filename is supposed to be a simple filename, not a path. The server appends the simple filename to a predefined absolute path to access a file of the user's choice within a specific directory. (Symbolic links are not an issue.)

But of course, the client can send any filename whatsoever, exposing the server to a filesystem traversal attack.

Initially I had hoped that Boost::Filesystem would have a bulletproof solution. This module is already sensitive to the operating environment; it changes its behavior depending on whether it's on a POSIX-compatible system or Windows. I was hoping for something like path::contains_upward_traversal() or path::is_simple_filename(). But no such luck.

Instead, I cobbled together the following:
using boost::filesystem;
path p = get_untrusted_filename();
bool p_is_name_only = !p.has_root_path() && !p.has_parent_path();

Here's my test set:

hello	is name only
he/lo	reject
/	reject
.	is name only
..	is name only
/hello	reject
/../../../hello	reject
../../hello	reject

I have not found a way to combine path accessors to eliminate the dot and double-dot while still permitting a simple filename. But fortunately, those two false positives point to a directory. If you add Boost's is_regular_file(path)to the mix, only the simple filename gets accepted.

Another option is POSIX's realpath, which we can use like so:
#include <stdlib.h>
#include <limits.h>
char abs_path[PATH_MAX];
realpath(p.string().c_str(), abs_path); //check ret val

Now if p contains an absolute path, abs_path will contain the same absolute path, with relative traversal collapsed. If p contains a relative path, abs_path will contain an absolute path starting from the application's present working directory.

Lastly, to verify that the client's given filename is within the trusted directory, simply check whether abs_path starts with it. Any attempted traversal would cause this check to fail.

In my case, the client is trusted anyway, so this is a case of gold-plating. If the client was truly hostile, as would be true for public-facing servers, I would certainly consult a security specialist and do further research. But this suffices.

Is there an existing library for guarding against filesystem traversal attacks, or an improvement to what I have?

720p is irrelevant for Microsoft?

I have a laptop running Windows 8. It has an HDMI port. I've used this laptop to watch Netflix content using the Silverlight plugin and display it on my 720p projector. Normally it works fine.
But yesterday streaming was laggy; the video wasn't flowing as smoothly as the audio, and the two would get out of sync. Firefox's plugin container was meanwhile using 100% CPU.

So I thought, I am running Windows 8. I want to watch Netflix. Netflix offers an official Windows 8 app. Maybe it's higher quality than the browser plugin. So I fired it up, and...

On my home 720p projector.

At first I cursed out Netflix. But then I recalled that Microsoft imposes a minimum screen resolution for Metro-style apps. Sure enough, the minimum is 1024x768, while my projector — and any 720p TV, which is still very common — is a measly 48 pixels too short.

720 is a worldwide standard resolution, and is one of only two HD resolutions, the other being 1080[p].

So Microsoft chose to exclude a very large set of displays by increasing the minimum resolution by just 6.7%. But apps are supposed to support many resolutions anyway.

I can't imagine a not-antiquated desktop monitor with a resolution below 1024x768. On the laptop side, netbooks were pretty much defined by 1024x600. I can understand Microsoft not supporting such a small height; it's quite inferior to 768. But ignoring 720 while promoting the new app ecosystem? A mistake.

I bet Netflix is not happy with this.