Does the “sandbox” that HTML5 defines belong in your company’s Web applications? Long-time Web developer and IT manager Cameron Laird explains when and how a sandbox can improve the HTML your software developers use in creating the organization’s applications.
The HTML5 standard promises “to ease the authoring of Web-based applications,” according to the specification current in summer 2010. Improvements in security are a vital part of that “ease,” especially the
iframe “sandbox.” Let’s look at sandbox’s costs and benefits – not how to code with sandbox, but how to decide where to use it, and what the implications will be for your software development team. Before your in-house programmers baffle you by giving you more techie detail than you need to know, here’s what you should understand about the choices inherent in a migration to HTML5.
The purpose of HTML5 sandboxes is to manage
iframe “mash-ups,” web pages that pull together their content from more than one site. You might build an application, for instance, in which part of the screen shows price-and-availability from a third-party vendor. The easiest way to accomplish that could be simply to retrieve a Web page from the vendor, and display it within your application.
Think what that means from a security standpoint, though. Anyone who trusts your application is now implicitly willing to render the vendor’s page. Permission to run scripts, allow cookies, and so on, given to your application, are all extended to the vendor’s page. An
iframe-d page could pop up an annoying advertisement and make your application look vulgar.
That’s a steeper cost than many of us can bear, and it’s a situation that can and should make a CIO nervous. In fact, it’s even worse than this description suggests, for there are implementation reasons – state management, performance, and modularization, for instance – to use
iframe even when the user-view doesn’t directly involve a mash-up. Also,
iframe is an accessibility challenge; conventions for browsing
iframe-based pages with non-visual browsers are unsatisfying.
iframe has the reputation of being hazardous, and is probably used less than it should be. Web coders end up relying on more difficult or fragile codings, simply to avoid
iframe. Over-all security suffers both when
iframe is used and when it isn’t.
HTML5 Changes All That
The HTML5 sandbox changes that conclusion: It limits the trust the browser puts in
iframe-d content, to eliminate the damage a third-party site can do within your Web application.
A clear picture of the gain that the sandbox brings requires first an understanding of HTML5 and its role in construction of Web applications.
HTML5 is a medley, not a symphony. HTML5 is not a single definite standard, like, say, FORTRAN 77, or a specific recipe for farfalle; it’s more of a style, like “Italian cooking.” HTML5 isn’t fully “baked” yet, and probably never will be; it’s likely that, by the time all its many parts have been formalized, the Web world will have moved on to something new.
When someone says he’s writing HTML5 now, he probably means he’s using an HTML5
<!DOCTYPE html>, and perhaps the
canvas widget. He might be doing more in CSS these days, and relying less on
Beyond these general tendencies, it’s hard to pin down “HTML5″ as developers speak of it in terms of specific features. Different programmers do or don’t think of:
- scalable vector graphics (SVG)
- Web storage
- Web forms
- media playback
- …and at least another half-dozen major features
The point for an IT manager should be this: When a developer on your team talks about HTML5, and especially about browser support for HTML5, have the person say exactly what that means to her.
“HTML5 sandbox,” in contrast, is relatively well-defined. Web applications have experimented with several sandbox concepts and implementations before; from now on, though, the HTML5 sandbox as it appears, for example, in this July 2010 reference will be the winner. Browsers will increasingly support it, and coders will increasingly rely on it.
Direct support for HTML5 sandbox is narrow today. The only major browser to claim it as of this writing is Google’s Chrome. However, it’s widely assumed that all other browsers will support it in their next releases, and libraries and plugins implement compatibility patches for essentially all the browsers. Your front-line coders should be able to use
sandbox freely, and count on being in an environment that implements the standard correctly. (Unless you’re still committed to IE6, in which case, God help you.)
If your development team is thinking about HTML5 sandbox, it needs to do a serious analysis of the implications for your users. Keep in mind that HTML5 as a standard is so fragmented that any other analyses you’ve done are unlikely to bear directly on HTML5 sandbox. Whether you use
canvas or SVG or off-line storage doesn’t determine at all what is right for you with HTML5 sandbox. In most cases, though, the security enhancements HTML5 sandbox brings are so large that it’s easy to decide go with it. The only occasions I’ve seen for it not to be chosen are when a user population is particularly dependent on a legacy browser (IE5 or IE6, for example), and the team already has in place another solution for the security challenges
The bottom line is this:
iframebenefits your Web applications, then HTML5 sandbox is probably the safest way for you to use
- If you’re thinking about HTML5 sandbox, you need to design a compatibility strategy that fits your users and the browsers on which they rely. Which browsers will natively support sandbox when you roll out? Which will need auxiliary libraries?
- Once you’ve chosen to code against HTML5 sandbox, expect to use it with every
iframe. The security boost it gives is so strong, and its application so flexible, that there’s unlikely to be a good reason for any
iframeto be without it.
Related Information From Dell.com: Dell and Cloud Computing