The WHATWG Blog

Please leave your sense of logic at the door, thanks!

Archive for September, 2008

This Week in HTML 5 – Episode 7

Monday, September 29th, 2008

Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.

Work continued this week on Web Forms 2, but I'm going to hold off on that until next week. And in case you missed it, Ian Hickson gave a tech talk on HTML 5, including live demos of some features recently implemented in nightly browser builds.

The big news this week is the disclosure of a vulnerability that researchers have dubbed "clickjacking." To understand it, start with Giorgio Maone's post, Clickjacking and NoScript. Giorgio is the author of the popular NoScript extension for Firefox. In its default configuration, NoScript protects against this vulnerability on most sites in most situations; you can configure it to defeat the attack entirely, but only at the cost of usability and functionality.

Of course, most web users do not run Firefox, and fewer still run NoScript, so web developers still need to be aware of it. Michal Zalewski's post, Dealing with UI redress vulnerabilities inherent to the current web, addresses some possible workarounds:

  1. Using Javascript hacks to detect that window.top != window to inhibit rendering, or override window.top.location. These mechanisms work only if Javascript is enabled, however, and are not guaranteed to be reliable or future-safe. If the check is carried on every UI click, performance penalties apply, too. Not to mention, the extra complexity is just counterintuitive and weird.
  2. Requiring non-trivial reauthentication (captcha, password reentry) on all UI actions with any potential for abuse. Although this is acceptable for certain critical operations, doing so every time a person adds Bob as a friend on a social networking site, or deletes a single mail in a webmail system, is very impractical.

Worried yet? Now let's turn to the question of what browser vendors can do to mitigate the vulnerability. Michal offers several proposals. It is important to realize that none of these proposals have been implemented yet, so don't go rushing off to your text editor and expecting them to do something useful.

  1. Create a HTTP-level (or HTTP-EQUIV) mechanism along the lines of "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" that permits a web page to inhibit frame rendering in potentially dangerous situations.
  2. Add a document-level mechanism to make "if nested <show this> else <show that>" conditionals possible without Javascript. One proposal is to do this on the level of CSS (by using either the media-dependency features of CSS or special classes); another is to introduce new HTML tags. This would make it possible for pages to defend themselves even in environments where Javascript is disabled or limited.
  3. Add an on-by-default mechanism that prevents UI actions to be taken when a document tries to obstruct portions of a non-same-origin frame. By carefully designing the mechanism, we can prevent legitimate uses (such as dynamic menus that overlap with advertisements, gadgets, etc) from being affected, yet achieve a high reliability in stopping attacks.
  4. Enforce a click-to-work mechanism (resembling the Eolas patent workaround) for all cross-domain IFRAMEs.
  5. Rework everything we know about HTML / browser security models to make it possible for domains and pages to specify very specific opt-in / opt-out policies for all types of linking, referencing, such that countering UI redress attacks would be just one of the cases controlled by this mechanism.

To this list, Colin Jackson added two more suggestions:

  1. New cookie attribute: The "httpOnly" cookie flag allows sites to put restrictions on how a cookie can be accessed. We could allow a new flag to be specified in the Set-Cookie header that is designed to prevent CSRF and "UI redress" attacks. If a cookie is set with a "sameOrigin" flag, we could prevent that cookie from being sent on HTTP requests that are initiated by other origins, or were made by frames with ancestors of other origins. In a CSRF or "UI redress" attack scenario, it will appear as though the user is not logged in, and thus the HTTP request will be unable to affect the user's account.
  2. New HTTP request header: Browser vendors seem to be moving away from "same origin restrictions" towards "verifiable origin labels" that let the site decide whether two security origins trust each other. ... [I]nstead of making it an "X-I-Do-Not-Want-To-Be-Framed-Across-Domains: yes" HTTP response header, make it an "X-Ancestor-Frame-Origin: http://www.evil.com" HTTP request header. This header could be a list of all the origins that are ancestors of the frame that triggered the request. If the site decides it does not like the ancestor frame origin it could reject the request. This could be added as a property of MessageEvent as well to detect client-side-only UI redress attacks.

This last approach moves us down a slippery slope towards site security policies for IFRAMEs and embedded content, similar to the Flash security model that allows trusted sites to access cross-domain resources. In practice, Flash crossdomain.xml files have a number of problems, and such an approach would still only cover a fraction of the possible use cases.

You can read the full thread for all the gory details and back-and-forth among browser vendors (Maciej Stachowiak works on WebKit, Robert O'Callahan works on Firefox) and other interested parties. As Maciej notes, user experience may suffer: "[Under proposal #3] iGoogle widgets would become disabled if scrolled partially off the top of the page under your proposal. And even if scrolled back into view, would remain disabled for a second. With possibly a jarring visual effect, or alternately, no visual indication that they are disabled. Hard to decide which is worse." As Rob notes, any solution will also need to deal with IFRAMEs styled with opacity:0, related attacks using some little-known (but widely supported) capabilities of SVG, and possibly other vectors that the world collectively hasn't figured out yet. If you're getting a mental image of the game "Whack-a-Mole," you're not alone.

Ironically, the best example of "clickjacking" is the download page for the NoScript extension, which uses it for good rather than evil. Thanks to some fancy JavaScript (search for "installer"), Giorgio embeds the addons.mozilla.org download page for NoScript in an IFRAME on his own page on noscript.net, sets the IFRAME to "opacity:0" (an attack vector that Robert O'Callahan specifically warned about), scrolls the embedded addons.mozilla.org page to the top corner of its "Add to Firefox" button, and sets the z-index of the IFRAME to 100. Thus, the IFRAME is floating (due to "z-index:100") invisibly (due to "opacity:0") over Giorgio's own "Install Now" button (due to the positioning of the IFRAME element itself). When you think you're clicking the button on noscript.net you are actually clicking the button on addons.mozilla.org. What's the difference? By default, Firefox treats addons.mozilla.org as a trusted download site, so it immediately pops up the extension installation dialog instead of blocking the installation with an infobar saying "Firefox prevented this site (noscript.net) from installing software on your computer." From a user experience standpoint, this is great -- one less click to download and install an extension. From a security standpoint, this is incredibly scary -- the end user has no idea they're interacting with a third-party site.

Ian Hickson, the editor of HTML 5, weighed in with his opinion:

I would like feedback from browser vendors on this topic, ideally in the form of experimental implementations. Personally I think the idea of disabling the contents of a cross-origin iframe that has been partially obscured or rendered partially off-screen is the best idea, but whether we can adopt it depends somewhat on whether browser vendors are willing to adopt it and implement it. It requires no standards changes to implement.

Tune in next week for another exciting episode of "This Week in HTML 5."

Posted in Weekly Review | 9 Comments »

Google Tech Talk: HTML5 demos

Friday, September 26th, 2008

I gave a talk at Google on Monday demonstrating the various features of HTML5 that are implemented in browsers today. The video is now on YouTube, so now you too can watch and laugh at my lame presentation skills!

The segments of this talk are as follows. Some of the demos are available online for you to play with and are linked to from the following list:

  1. Introduction
  2. <video> (00:35)
  3. postMessage() (05:40)
  4. localStorage (15:20)
  5. sessionStorage (21:00)
  6. Drag and Drop API (29:05)
  7. onhashchange (37:30)
  8. Form Controls (40:50)
  9. <canvas> (56:55)
  10. Validation (1:07:20)
  11. Questions and Answers (1:09:35)

If you're very interested in watching my typos, the high quality version of the video on the YouTube site is clear enough to see the text being typed. More details about the demos can be found on the corresponding demo page.

Posted in Browser API, Browsers, Conformance Checking, DOM, Elements, Events, Forms, Multimedia, Syntax, WHATWG | 7 Comments »

This Week in HTML 5 – Episode 6

Tuesday, September 23rd, 2008

Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.

There is no big news this week. Work continued on last week's orgy of Web Forms-related check-ins. This week adds the <label> element and the jack-of-all-forms <input> element. [r2191, r2192, r2197, r2200, r2202, r2204, r2205, r2207, r2211, r2212, r2213, r2214, r2218, r2219, r2220, r2222, r2223]

Laura Carlson and others have begun to review the accessibility of multimedia on the web. Most accessibility discussions revolve around the needs of visually impaired users, but hearing impaired users are also important and too often ignored. There was a long discussion last month (and continuing into this month) about the accessibility implications of the <audio> and <video> elements for hearing impaired users. YouTube (owned by Google, my employer) recently announced support for captions on YouTube videos and published a tutorial on adding them to your own videos.

Ian Hickson (the HTML 5 editor) gave an interview about HTML 5 in which he reiterated his goal of having two independent, complete, interoperable implementations of HTML 5 by 2022. (By contrast, HTML 4.0 was "finalized" 11 years ago but still doesn't have two independent, complete, interoperable implementations.) This led to a mini-firestorm among bloggers who misunderstood "2022" as "the date when I can start using HTML 5 features." It bears repeating that the "2022" date has no significance at all for web developers. Most browser vendors are actively involved in HTML 5, several browsers are already shipping HTML 5 features, and developers who are holding their breath until 2022 are going to find themselves seriously behind the curve.

On that note, Brenton Strine asks a very good question: "Is there some place that documents the parts of HTML 5 that are already up and running? Can I use <canvas> or <video>? In which browsers? What other tags can I use? What other fancy HTML 5 stuff can I do today in 2008?" On the video front, Mozilla will be shipping Ogg Theora support in Firefox 3.1. (You can read more about why Ogg matters.) Last year, Opera released experimental builds with Ogg Theora support, and they now have video-enabled builds on 3 platforms. The Wikimedia Foundation has a few Theora-encoded videos you can watch.

Tune in next week for another exciting episode of "This Week in HTML 5."

Posted in Weekly Review | 6 Comments »

This Week in HTML 5 – Episode 5

Monday, September 15th, 2008

Welcome back to "This Week in HTML 5," where I'll try to summarize the major activity in the ongoing standards process in the WHATWG and W3C HTML Working Group.

The big news this week is the merging of the Web Forms 2 specification into the HTML 5 specification, and updating it with the collected feedback of the last two years.

Meanwhile, revisions 2160, 2161, 2163, 2164, and 2165 begin the long, hard process of defining when and how a form is submitted. This is one of those things that "everybody knows" but nobody has actually, you know, documented. For example, do you submit a form when you toggle a checkbox? Of course not, "everybody knows" that. Is an unchecked checkbox included in the form data when it is submitted? No, "everybody knows" that too. How do you submit to an ftp:// URL? A mailto:// URL? A data:// URL? What are the three values of the enctype attribute, and how do they affect the form data when it is submitted to a data:// URL with the PUT method?1 Umm... How exactly do you construct the names of the X and Y coordinates to submit a server-side image map? (By the way, server-side image maps are inaccessible, so don't use them unless you provide an accessible fallback form with equivalent functionality.) Web Forms 2 (and now HTML 5) will tell you.

Another interesting set of changes revolves around character encoding. If you don't know anything about character encoding, I would strongly recommend Joel Spolsky's The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) Tim Bray's three-part series, On the Goodness of Unicode, On Character Strings, and Characters vs. Bytes, and anything written by Martin Dürst.

Now then: r2125 warns against using EBCDIC on public-facing web pages. For those of you under 30, EBCDIC is a character encoding invented by IBM in the 1960s for their System/360 mainframe. On non-IBM hardware, EBCDIC lost the encoding war to ASCII, and later Unicode, and it is rarely seen on the public web. r2131 says that browsers should ignore an out-of-band encoding definition that they do not support. For example, if a web page is served with an HTTP Content-Type header with a charset parameter that defines a character encoding the browser does not support, the browser should ignore it and continue the process of determining the character encoding by other means. And finally, r2137 says that browsers should treat US-ASCII as Windows-1252 when determining character encoding. As the HTML 5 specification notes, "The requirement to treat certain encodings as other encodings according to the table above is a willful violation of the W3C Character Model specification."

Other interesting changes this week:

Tune in next week for another exciting episode of "This Week in HTML 5."


Footnotes:

  1. When submitting to a data:// URL with the PUT method, the three values of enctype are application/x-www-form-urlencoded, multipart/form-data, and text/plain. Amaze your friends at the next tech conference!

Posted in Weekly Review | 15 Comments »

2022

Friday, September 12th, 2008

There has been a certain amount of controversy over the supposed date of 2022 for HTML 5 to be "finished". It is somewhat important to realise the significance that should be attached to this date:

None at all

OK, strictly speaking that's not quite true, but it's a pretty good approximation to the truth. What really matters is when browsers ship HTML5 features. Given that's already happening, there is really no cause for alarm. By 2022 we hope to have a full testsuite and two full implementations but then we also expect to see products shipping with features from HTML 6.

Posted in Processing Model, WHATWG | 4 Comments »