IEBlog

Sharing Links from IE10 on Windows 8

ieblog — Mon, 14 May 2012 20:53:50 GMT

Sharing a link to a Web page is a common activity on the PC, and it gets better with IE10 on Windows 8. One of the new features on Windows 8 is the Share charm, which allows you to seamlessly send content between apps on your PC. Previously, if you wanted to share an interesting article with your friend, or post a funny picture on your blog, you’d copy the link from the address bar, switch to a different site or app, and then paste it. Now, with the Windows 8 Share charm, you can share directly from the browser without ever leaving your current page.

When you use the Share charm to share a site from the browser, IE10 creates two data formats that contain relevant content – the URI, and some HTML that includes a rich representation of the page. Here are two examples of data that get shared for a YouTube video:

The URI (of the current site)

http://www.youtube.com/watch?v=4DbgiOCTQts

The HTML (with a link preview)

An example of IE10's rich preview of Web pages

Both of these data formats are created for an “implicit” share, which is the name for what happens when you share the site that you are currently viewing. Since Web pages can be represented as hyperlinks or a rich HTML link preview, IE10 includes both types of data. Of course, if you aren’t sharing the whole page, but rather, some content that you’ve highlighted, IE10 will share the HTML of your selection instead of the URI and the link preview. In this case, sharing a selection would be called an “explicit” share, and does not include the link. This post describes the link sharing case, how IE10 participates in the Windows 8 Share contract using HTML, and how Web developers can create link previews with just a few meta-tags.

The Share Charm and IE10

Here’s a video of how a user might share links from the browser to an app that uses HTML.

Sharing from IE10: Link Previews in Action

In this video, “Stash” is a sample link saving app that makes use of the Windows share charm with HTML. The sample app simply supports the HTML data format for sharing, and IE provides the link preview. Link previews are HTML that contains a title, image, and description for every shared link. This makes it easy for you to recognize the site content. If you have Windows 8 Consumer Preview and Visual Studio 11 Beta, you can download and run Stash on your own PC. Stash integrates with the Windows 8 Share contract as a target app, as you can see below. Below, you can see a high-level diagram that shows how links are shared from IE10.

Diagram: Sharing a link from IE10 to target apps, using the Share charm’s data package

Windows 8 Share charm handles the coordination between the source and target apps to provide an integrated sharing experience across all apps. This removes the need for target and source apps to be aware and coordinate between each other.

Sharing the Web is Better, Start to Finish

The Web is made up of HTML. That’s why HTML is one of the most important data formats in IE10’s integration with the Share contract. IE10 creates link previews to both provide a better sharing experience for users, and to help connect Web developers to Windows 8 Share. With a little extra meta-data markup, sites can define what information is included in their link previews. On the other end of the share contract, target apps that support the HTML data format can get the full experience of contextual Web hyperlinks without having to parse a single site. The end result is a rich, modern, and fluid sharing experience, from end to end.

Screenshot of target apps available in Share pane

Screenshot of Stash’s Share Pane

When you share a Web site, IE10 parses that site to create a link preview. In the example above, it’s a short snippet of content that represents a movie page on IMDb. The goal of sharing HTML, in addition to the URI, is to share the best possible representation of what the user intended to share, so IE10 creates link previews for all implicit shares. The benefits of HTML are that it can include more information than a URI, and the content of the HTML is more meaningful than a hyperlink. In the words of Leslie Knope, no one wants to share that “complicated nonsense.”

From NBC’s Parks and Recreation, Season 4, Episode 16

So, as you can imagine, we would have never ordered a sign with all this complicated nonsense because, you know, we’re not insane.

Depending on the target app, though, sometimes rich content is not the best kind of data, and a URI is more useful. For example, blogging apps can take advantage of rich HTML content, and SMS apps would do best to use the URI. Developers of Metro style apps choose the data format(s) that make most sense for their app to receive, following the Windows 8 Share guidance.

Sites Use Markup to Define What IE10 Shares

Since IE10 uses existing markup meant for sharing on the Web, many sites will already look great when sharing HTML link previews on Windows 8. We support the Open Graph protocol as a simple way to add meta-data about the page. When users share sites on Facebook and through Windows 8 and IE10, you can use OpenGraph to control the way your Web page appears to others.

Here’s an example of an IE test drive demo that uses this markup:


<head>
<meta name="description" content="Brick Breaker TestDrive Demo Game, Performance and Touch benchmark" />
<title>Brick Breaker</title>
<meta property="og:image" content="Views/Homepage/Icons/BrickBreaker.png" />
</head>

IE looks for the following tags in the site’s markup to create the page’s link preview.

Property	HTML tag	Character limit
Title 1	<meta name="title" content="Insert Site Title Here” />	160
Title 2	<title>Insert Site Title Here</title>	160
Description	<meta name="description" content="Insert Site Description Here” />	253
Image 1	<meta property="og:image" content="insert_image_link_here" />	2,048 (limit for image URI)
Image 2	<link rel="image_src" href="insert_image_link_here" />	2,048 (limit for image URI)
Image 3	<meta name="image" content="insert_image_link_here" />	2,048 (limit for image URI)
Image 4	<meta name="thumbnail" content="insert_image_link_here" />	2,048 (limit for image URI)

Note that this is the order in which we parse for each attribute. For example, if both Image 1 and Image 2 tags are present, we’ll use the Image 1 tag. Additionally, if more than one tag of any type is present, we use the first one you list in your markup.

For character limits, if the description is longer than the maximum length, IE will put a “…” at the end in the preview.

Make sure to include at least one of each property in your site markup to get your pages looking great for sharing in Windows 8. See this demo on the IE Test Drive site for more on how the markup works.

Apps Get the Benefit of a Powerful Web Browser

If your app supports the Share target app contract, you should consider whether it makes sense for it to support HTML as a shared data format. Apps that use HTML can benefit from the link previews shared by IE10 because IE10 does all of the heavy lifting. It parses the site and puts together a short and informative link preview, and all your app needs to do is display and host the HTML. The hyperlink is embedded within the preview, so it functions just like a Uri, but looks much better. This way, apps that don’t have the resources to parse the Web to condense pages into small, rich previews, can still display contextual links as HTML.

Many apps, in addition to IE10, will share HTML. Target apps that accept HTML must be agnostic about the source of the shared data. As noted above, IE10 shares HTML for both implicit and explicit sharing scenarios, so sometimes the HTML is a link preview, and sometimes it’s a user selection. In either case, the content of the HTML is the best possible representation of what the user intended to share. Here’s a snippet of what the link preview HTML generated by IE10 will look like when it’s added to the Share charm’s Data Package:


<html>
<body>
<!--StartFragment-->
<style>
/* IE10\uc1\u8217?s metro-style CSS attributes */
</style>
<a class="snippet-URL" href="http://site_link_goes_here">Website Title goes here</a>
<table>
<tr>
<td class="snippet-image">
<img src="image_link_goes_here" />
</td>
<td class="snippet-text">Website description goes here </td>
</tr>
</table>
<!--EndFragment-->
</body>
</html>

For an example of an app that uses HTML from IE10, download the sample app “Stash” seen in the video above. This app demonstrates how a Metro style app can use HTML data as a share target.

Here’s a code snippet from the app, which shows how Stash uses HTML sent from the Share charm.


function activatedHandler(eventArgs) {
// In this sample we only do something if it was activated with the Share contract
if (eventArgs.detail.kind
=== Windows.ApplicationModel.Activation.ActivationKind.shareTarget) {
// We receive the ShareOperation object as part of the eventArgs
var shareOperation = eventArgs.detail.shareOperation;
if (shareOperation.data.contains(
Windows.ApplicationModel.DataTransfer.StandardDataFormats.html)) {
shareOperation.data.getHtmlFormatAsync().then(
function (htmlFormat) {
// Extract the HTML fragment from the HTML format
var htmlFragment = Windows.ApplicationModel.DataTransfer
.HtmlFormatHelper.getStaticFragment(htmlFormat);
// Display the HTML in the Share pane.
id("htmlArea").innerHTML = htmlFragment;
});
}
}
}

The above code lets Stash accept HTML when the user selects it as their Share target. For more on developing a Share target app on Windows 8, see the MSDN Quickstart page for receiving shared content.

Happy sharing!

—Alex Feldman, Program Manager, Internet Explorer

Diagnosing JavaScript Errors Faster with Error.stack

ieblog — Thu, 10 May 2012 21:54:45 GMT

IE10 in Windows 8 Consumer Preview includes support for Error.stack, which enables Web developers to diagnose and correct bugs faster, especially those that are difficult to reproduce. Developers can build amazing apps with the capabilities of Web platforms that power today’s modern browsers. In Windows 8, we expose that power through both Internet Explorer 10 and Metro style apps in JavaScript. The increasing power and complexity of these apps means developers need better tools like Error.stack for handling errors and diagnosing bugs.

Debugging Applications

Structured error handling in JavaScript rests on throw and try/catch – where the developer declares an error and passes the control flow to a portion of the program that deals with error handling. When an error is thrown, Chakra, the JavaScript engine in Internet Explorer, captures the chain of calls that led up to where the error originated – also referred to as the call stack. If the object being thrown is an Error (or is a function whose prototype chain leads back to Error), Chakra creates a stack trace, a human-readable listing of the call stack. This listing is represented as a property, stack, on the Error object. The stack includes the error message, function names, and source file location information of the functions. This information can help developers rapidly diagnose defects by learning what function was being called, and even see what line of code was at fault. For example, it might indicate that a parameter passed into the function was null or an invalid type.

Let’s explore with an example of a simple script that attempts to calculate the distance between two points, (0, 2) and (12, 10):


(function () {
'use strict';
function squareRoot(n) {
if (n < 0)
throw new Error('Cannot take square root of negative number.');
 
return Math.sqrt(n);
}
 
function square(n) {
return n * n;
}
 
function pointDistance(pt1, pt2) {
return squareRoot((pt1.x - pt2.x) + (pt1.y - pt2.y));
}
 
function sample() {
var pt1 = { x: 0, y: 2 };
var pt2 = { x: 12, y: 10 };
 
console.log('Distance is: ' + pointDistance(pt1, pt2));
}
 
try {
sample();
}
catch (e) {
console.log(e.stack);
}
})();

This script has a bug – it forgets to square the differences of the components. As a result, for some inputs, the pointDistance function will simply return incorrect results; other times, it will cause an error. To understand the stack trace, let’s examine the error in the F12 developer tools and look at its Script tab:

The stack trace is dumped to the console in the catch clause, and because it’s at the top of the stack, it’s readily apparent that the Error is originating in the squareRoot function. To debug the problem, a developer wouldn’t have to go very deep into the stack trace; squareRoot’s precondition was violated, and looking one level up the stack, it’s clear why: the sub-expressions within the call to squareRoot should themselves be parameters to square.

While debugging, the stack property can help identify code for setting a breakpoint. Bear in mind that there are other ways to view the call stack: for instance, if you set the script debugger to “Break on caught exception” mode, you may be able to inspect the call stack with the debugger. For deployed applications, you may consider wrapping problematic code within try/catch in order to capture failed calls, and log them to your server. Developers would then be able to look at the call stack to help isolate problem areas.

DOM Exceptions and Error.stack

I noted previously that the object being thrown must be an Error or lead back to Error via its prototype chain. This is intentional; JavaScript supports throwing any object and even primitives as exceptions. While all of these can be caught and examined, they are not all specifically designed to contain error or diagnostic information. As a consequence, only Errors will be updated with a stack property when thrown.

Even though DOM Exceptions are objects, they don’t have prototype chains that lead back to Error, and therefore they don’t have a stack property. In scenarios in which you are performing DOM manipulation and want to surface JavaScript-compatible errors, you may want to wrap your DOM manipulation code within a try/catch block, and throw a new Error object within the catch clause:


function causesDomError() {
try {
var div = document.createElement('div');
div.appendChild(div);
} catch (e) {
throw new Error(e.toString());
}
}

However, you will probably want to consider whether you want to use this pattern. It is likely best-suited for utility library development; specifically, consider whether your code’s intent is to hide DOM manipulation, or to simply carry out a task. If it is hiding DOM manipulation, wrapping the manipulation and throwing an Error is probably the right way to go.

Performance Considerations

The construction of the stack trace begins when the error object is thrown; doing so requires walking the current execution stack. To prevent performance problems in traversing a particularly large stack (possibly even a recursive stack chain), by default, IE only collects the top 10 stack frames. This setting is configurable, however, by setting the static property Error.stackTraceLimit to another value. This setting is global, and must be changed prior to throwing the error, or else it will not have an effect on stack traces.

Asynchronous Exceptions

When a stack trace is generated from an asynchronous callback (for example, a timeout, interval, or XMLHttpRequest), the asynchronous callback, rather than the code that created the asynchronous callback, will be at the bottom of the call stack. This has some potential implications for tracking down offending code: if you use the same callback function for multiple asynchronous callbacks, you may find it difficult to determine by inspection alone which callback caused the error. Let’s slightly modify our previous sample so that, instead of calling sample() directly, we’ll put that into a timeout callback:


(function () {
'use strict';
function squareRoot(n) {
if (n < 0)
throw new Error('Cannot take square root of negative number.');
 
return Math.sqrt(n);
}
 
function square(n) {
return n * n;
}
 
function pointDistance(pt1, pt2) {
return squareRoot((pt1.x - pt2.x) + (pt1.y - pt2.y));
}
 
function sample() {
var pt1 = { x: 0, y: 2 };
var pt2 = { x: 12, y: 10 };
 
console.log('Distance is: ' + pointDistance(pt1, pt2));
}
 
setTimeout(function () {
try {
sample();
}
catch (e) {
console.log(e.stack);
}
}, 2500);
})();

Upon executing this snippet, you’ll see the stack trace come up after a slight delay. This time, you’ll also see that the bottom of the stack is not Global Code but rather is Anonymous function. In fact, it’s not the same anonymous function, but the callback function passed into setTimeout. Since you lose the context surrounding hooking up the callback, you may not be able to determine what is causing the callback to be called. If you consider a scenario in which one callback is registered to handle the click event of many different buttons, you will be unable to tell to which callback the registration refers to. That being said, this limitation is only minor, because, in most cases, the top of the stack will likely highlight the problem areas.

Exploring the Test Drive Demo

Check out this Test Drive demo using IE10 in the Windows 8 Consumer Preview. You can execute code in the context of an eval and if an error occurs, you’ll be able to inspect it. If you’re running the code within IE10, you’ll also be able to highlight the lines of your code as you hover over the error lines in the stack trace. You can type code into the Code area yourself, or select from several samples in the list. You can also set the Error.stackTraceLimit value when running the code samples.

For reference material, you may want to cruise over to the MSDN documentation for Error.stack as well as stackTraceLimit.

—Rob Paveza, Program Manager, Chakra Runtime

Building cross-browser plugin-free experiences

ieblog — Thu, 26 Apr 2012 22:04:49 GMT

We've talked about how the transition to a plug-in free Web is happening today. Lots of Web browsing happens on devices that simply don’t support plug-ins. Web sites that use plug-ins need to understand what their customers experience when browsing plug-in free. In case you missed it, check out Rey Bango’s blog post where he lays out clear guidance for developers on building cross-browser plugin-free experiences and addressing issues like cross-browser CSS, media playback, and touch.

-- John Hrvatin, Program Manager Lead, Internet Explorer

Guidelines for Building Touch-friendly Sites

ieblog — Fri, 20 Apr 2012 18:14:00 GMT

In Windows 8 Consumer Preview, IE10 enables fast and fluid multi-touch experiences on the Web. Most sites work fine with touch in IE10 with no changes to the site. This post provides four simple guidelines to ensure your customers who use touch can most effectively use your site.

We’ve written before about how new input devices and touch screens make the Web more fun, interactive, and immersive. We’ve also talked about the importance of ensuring a no compromise browsing experience in IE10 so the real Web works great with touch.

Of the four guidelines below, the first two make sure touch users can access all of your site’s functionality. The last two provide tips to make your site easier to use with touch.

DO NOT Hide Content Behind Hover

A mouse can hover content (point at it) without activating it (clicking it). However, with touch a tap is both hover and activation in one action. So functionality that requires hover without activating will not work for touch users. Instead, consider making all behaviors click (tap) based.

DO Configure the Browser for the Default Touch Behaviors That Work Well For Your Site

Users expect to be able to pan and zoom sites using touch. Therefore, the browser consumes touch moves, pinches, and double-taps by default and does not send events for these interactions. If your site needs to provide special functionality for these interactions instead, you must configure IE10 to provide only the default behavior you want, if any.

When a user touches an element, the -ms-touch-action CSS property determines the default behavior that IE10 provides.

-ms-touch-action: auto | none | manipulation | double-tap-zoom | inherit;

The table below describes the five possible values.

Value	Description
`auto`	The browser determines the behavior for the element. This is the default value for `-ms-touch-action`.
`none`	No default behavior is allowed.
`manipulation`	Only panning, pinch zoom, and swiping to navigate forward or back are allowed.
`double-tap-zoom`	Only double-tap zooming is allowed.
`inherit`	The element inherits the value of `-ms-touch-action` from its parent.

For example, a canvas painting application might use:

canvas {

-ms-touch-action: double-tap-zoom;

}

With this configuration, the user can double-tap to zoom in to the canvas element, but sliding a finger on the canvas element will send events to it rather than pan the page.

DO Identify Input Types Using HTML5 Forms

IE10 introduces support for HTML5 input controls, all of which are touch optimized. For text inputs, you can further improve your users’ touch experiences by identifying the specific input type, when applicable. Internet Explorer will show a tailored touch keyboard layout for that input type on Windows 8:

The touch keyboard shows @ and “.com” buttons for email addresses.

The touch keyboard shows a number pad for telephone numbers.

The touch keyboard shows forward slash and “.com” for URLs.

DO Provide Ample Room for Users’ Fingers

To build Windows 8’s touch-first experience, we’ve done a ton of research to formulate some helpful guidelines for developers. The average width of a finger is 11mm. As targets for tapping get larger, the percentage of accidental missed taps drops off quickly.

Ideally, a target is at least 11mm (about 40px) square with at least 2mm (about 10px) of padding around it.

			40px or more target size

10px or more between targets

If you want to adjust the spacing only for users with touch hardware, use feature detection.

To detect that user has touch hardware:

if (navigator.msMaxTouchPoints && navigator.msMaxTouchPoints > 1) {

// Supports multi-touch

}

Going Beyond These Basics

You can do much more to create a great touch-first experience. For example, you may choose to optimize for touch by supporting custom multi-touch interactions or gestures. Here are a few links to get you started:

We plan to write more about these methods in future blog posts. Applying these guidelines today will ensure your sites work well with touch in IE10.

— Jacob Rossi, Program Manager, Internet Explorer

IE 9.0.6 Available via Windows Update

ieblog — Tue, 10 Apr 2012 21:28:05 GMT

The April 2012 Cumulative Security Update for Internet Explorer is now available via Windows Update. This security update resolves five privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user visits a specially crafted Web page using Internet Explorer. An attacker who successfully exploited any of these vulnerabilities could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.

This security update is rated Critical for Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, and Internet Explorer 9 on Windows clients and Moderate for Internet Explorer 6, Internet Explorer 7, Internet Explorer 8, and Internet Explorer 9 on Windows servers. For more information, see the full bulletin.

Most customers have enabled automatic updating and do not need to take any action. We recommend that customers, who have not enabled automatic updating, enable it (Start Menu, type “Windows Update”). We recommend that administrators, enterprise installations, and end users who want to install this security update manually, apply the update immediately using update management software or by checking for updates using the Microsoft Update service.

—Tyson Storey, Program Manager, Internet Explorer

Pinned Sites in Windows 8

ieblog — Tue, 03 Apr 2012 20:42:01 GMT

The Windows 8 Start screen is the best place to find and stay connected to all your favorite apps and content. App tiles are alive with activity and show you fresh and tailored content so you know what’s new in your world.

We’ve written about Internet Explorer 10’s Metro style browsing experience on Windows 8. This post describes in detail IE10’s pinned sites and their availability on the Windows 8 Start screen—complete with site-centric visuals and badge notifications to let you know there is new content. We’ll also walk through the Web developer details to support pinned sites.

The following video shows pinned sites in action on Windows 8 Consumer Preview.

Pinned Sites in Windows 8

Pinned Sites – More than Favorites

Consumers on Windows spend most of their time on the Web and we know from Windows opt-in telemetry (officially, the Microsoft Customer Experience Improvement Program), that they go back to the same set of sites time and again. Pinned sites on Windows 8 make it fast and easy to immediately get to your sites. With badge notifications, site tiles come alive with up-to-date information and help you know when new content is available.

Developers can utilize pinned sites to better connect their site with their users and promote their site’s brand directly in the Windows start screen. We found that sites that used this feature with IE9 on Windows 7 see anywhere from a 15 percent to 50 percent increase in site visits. In Windows 8 the experience for consumers is even better with site tile updates, even when you don’t have the site open in the browser.

The following two screen shots illustrate pinned site tiles and badge notifications.

Pinned sites on the Start screen showing site-centric visuals and badge notifications

Example of a badge notification on a pinned site’s tile

Site-Centric Visual on the Pinned Site Tile

As a Web developer, you can provide a site icon (favicon) that IE10 uses throughout the browser to represent the site, in the address bar, on the new tab page, and on the Start screen. IE10 uses the large site icon (32 x 32 pixels) to identify the site when pinned to the Start screen the same way that IE9 used it for pinning to the task bar.

Screen shot of pinning a site with Metro style IE10 showing a preview of the site’s tile

IE10 extracts the dominant color from the icon and automatically uses it as the background color for the Start screen tile.

One tool for creating icons is x-icon editor. Use it to create the 32x32 icon for your site. It can also convert an image to the icon file format (.ico). Then associate the .ico using traditional favicon markup:


    
        <link
            href="testdrive.ico"
            rel="shortcut icon"
            />

Badge Notifications That Update In the Background

Windows 8 can poll for updates for pinned tiles on the Start screen. This works well for lightweight notifications such as new messages from other users (email & social networking), new discounts on a shopping site, new articles on a newsfeed etc.

With Internet Explorer 10 and Windows 8, you can offer badge notifications directly on your pinned site tiles. This means users get updates to their sites without the site being open in the browser. As an example, pin the Fresh Tweets demo using IE10 on Windows 8 Consumer Preview. The pinned site tile updates on a regular basis and notifies the user when there are new tweets available.

Background notifications require site-provided components. These are: (1) Badge Notification XML, an XML response that describes the badge notification for Windows, and (2) Pinned Site Meta Tags, Web page markup that points to the location which Windows should poll for notifications and the frequency of polling.

Badge Notification XML

Windows handles the polling and drawing of badge notifications. Windows polls the badge notification XML that describes the visual for the pinned site tile. The badge XML schema defines this simple XML response. For example, to update the tile with the number “3,” you send the following XML:


    
        <?xml
            version="1.0" encoding="utf-8" ?>
        <badge
            value="3"/>

Badges can be numbers or glyphs, such as ‘alert’ and ‘new message’ indicators. For a full list of what a badge can display, see Choosing a badge image on MSDN.

Pinned Site Meta Tags

The next step is associating the badge notification XML to the Web page. IE10 uses the meta tag “application-name” to determine if the Web page supports pinned sites capabilities like notifications and jump lists. To support badge notifications, include a new meta-tag in your markup with the URL of the badge notification XML and the frequency with which Windows should request it. IE checks to see if the “msApplication-badge” meta tag is present on the page at time of pinning, as well as on subsequent launches of the site from the pinned site tile.


    
        <meta
            name="msapplication-badge"
            value="frequency=360;polling-uri=http://ietestdrive2.com/PinnedSites/TweetCounter/microsoft/360"
            />

The value parameter has two parts: polling-uri (required) and frequency (optional).

polling-uri is the absolute URI from which Windows requests the simple XML document defined above.

frequency is an optional number of minutes between updates and must be one of the following values:

30 (Windows will poll the URI every 30 minutes)
60 (1 hour)
360 (6 hours)
720 (12 hours)
1440 (1 day. This is the default.)

If frequency is omitted or has a value other than one listed above, it defaults to daily updates (1440 minutes).

Developer APIs for updating Badge Notifications

You can also clear and refresh the site tile badge from the Web page directly to ensure that the site tile is up-to-date.

When a user launches the pinned site tile through the Start screen, the Web site is running in its own session called SiteMode and can use the following JavaScript functions to update the badge.

window.external.msSiteModeClearBadge() clears the badge notification on the tile. In the Fresh Tweets demo, when the user receives a notification and taps on the tile to launch the browser, the Web page uses msSiteModeClearBadge() to clear the notification from the tile. The next time the tile lights up with a badge update, the user knows there is new content.

window.external.msSiteModeRefreshBadge() calls Windows to update the badge on the site using the polling URI. As an example, the user sees a pinned site tile indicating three unread messages and clicks on the tile to return to the site. If he or she reads only the first update, you can trigger an update so the badge reflects the correct read/unread count of two.

In Windows 8 Consumer Preview, these two APIs only function on sites running in the Local intranet or Trusted sites zones. This will be fixed in the next preview. To test these APIs in the Consumer Preview on your own site, add its domain to the Trusted sites list using the Security tab of the Internet Properties dialog.

Desktop Taskbar Notifications

Notifications that appear as icon overlays for pinned sites on the desktop taskbar will continue to work for Windows 8 and IE10 on the desktop. This form of notification is not available on the pinned site for the Windows 8 Start screen. Windows 8 handles notifications for all tiles on the Start screen and does so in a battery-efficient way.

Jump Lists to Quickly Navigate Within the Site

Many top sites such as NYTimes.com, CNN.com, and Amazon.com support IE9 pinned sites features such as jump lists to get to a specific task or part of a site. With IE10, jump lists are available as part of the navigation bar for a touch-friendly way to navigate the site.

When the user launches the site from the Start screen, the pin button shows that there are jump lists available for this site:

Screen shot showing the Fresh Tweets Demo’s jump list

The jump list displayed is the same as IE9 displays on the Windows 7 taskbar.

You can add static tasks to your site’s jump list via page markup (learn more) or dynamically based on user interactions (learn more). Badge and jump lists in Windows 8 are a site-centric feature. Each fully qualified domain name can have one and only one set of polling data and jump list data.

Conclusion

Internet Explorer 10 puts sites at the center of the experience through integration with the Windows 8 Start screen. Web developers can create site-centric visuals for pinned site tiles, share when there are new updates available for the site, and offer jump lists to navigate quickly around the site.

We look forward to you adding these simple features to your Web site to maximize their impact in Windows 8.

—Rahul Lalmalani, Program Manager, Internet Explorer

Launch Options for Internet Explorer 10 on Windows 8

ieblog — Mon, 26 Mar 2012 16:24:45 GMT

IE10 is a new browsing experience built in lockstep with Windows 8 to give you all the advantages that Metro style applications offer. We built that experience by extending IE’s underlying architecture to provide a fast, fully hardware accelerated browsing engine with strong security and support for HTML5 and other Web standards. IE10 also includes a desktop experience for when you are using desktop tools and wish to continue using them in your existing workflows.

Following last September’s release of the Windows 8 Developer Preview, we heard a lot about giving you the option to control which experience of Internet Explorer—Metro style or on the desktop —to launch when clicking a link in another application. In the Windows Consumer Preview, IE10 offers you that control.

By default, Windows 8 Consumer Preview opens links using the flavor of Internet Explorer that matches your current environment: if you’re running a Metro style application, following a link launches Metro style IE10; if you’re running a desktop application, following a link launches IE10 on the desktop. You can override this default behavior using the Programs tab of the Internet Properties dialog.

You can locate these settings quickly by using the Start screen’s search capability and searching for terms such as “links,” “launch,” or “open links.” Show below is the result of search for the term “launch.”

The following sections describe the available settings.

Opening Links

The first setting of the Browser Launch Settings (labeled “Choose how you open links”) controls what happens when you click a link in another program. Your choices include:

Options for Opening Links	Behavior
Let Internet Explorer decide	Launch links based on the environment you are in
Always in Internet Explorer	Launch links in the Windows 8 (Metro style) environment
Always in Internet Explorer on the desktop	Launch links in the desktop environment

The default for this setting is “Let Internet Explorer decide.” In other words, links will launch into the appropriate experience based on the invoking context—desktop or Metro style. Links will open in the desktop IE10 when a link is clicked from a desktop application, for example, Microsoft Word, and in Metro style IE10 when a link is opened from a Metro style application.

Opening Internet Explorer from the Start Screen

In addition to controlling how Windows opens links, the Browser Launch Settings also provide users with options on how Internet Explorer application tiles launch from the Start screen. Internet Explorer’s application tile is the default launching point for the browser on the Start screen. You create pinned site tiles when you pin sites to the Start screen. The setting “Open Internet Explorer tiles on the desktop” controls what happens when you click the Internet Explorer or pinned site tile.

Options for opening Internet Explorer Tiles	Expected behavior
(unchecked)	Launch in the Windows 8 (Metro style) environment
(checked)	Launch in the desktop environment

Launch Options and Browser Defaults

IE10 is available in both Metro style and desktop experiences when it is the default browser. If Internet Explorer is not your default browser, only desktop IE is available and you cannot change IE’s Browser Launch Settings. The “Choose how you open links” option on the Programs tab of the Internet Properties dialog will be disabled (“grayed out”) when IE is not the default browser:

To change the default browser, type “default” on the Windows 8 Start screen. The Start screen will search apps, settings, and files for this term. The Apps results will include Default Programs. Touch or click it to bring up the Default Programs control panel item. From its list of options, select “Set your default programs” to display a page containing a list of programs on the left.

Select “Internet Explorer” and then click or touch “Set this program as default.” This will set IE10 as the default browser on Windows 8 and enable its Metro style experience.

Conclusion

IE10 offers you a full-screen, immersive site experience. We’ve found that many people – even those with the most enthusiastic and intense browsing patterns – prefer Metro style browsing because it’s less manual and more focused on what you browse than on how you browse. That said, for some browsing, IE on the desktop continues to play an important role. The Browser Launch Settings allow you to change the default settings for a “no compromises” experience.

Try out these settings, and let us know what you think. We look forward to your feedback here and on Connect.

—Kevin Luu, Program Manager, Internet Explorer

Speed and Mobility: An Approach for HTTP 2.0 to Make Mobile Apps and the Web Faster

ieblog — Mon, 26 Mar 2012 04:02:00 GMT

This week begins face to face meetings at the IETF on how to approach HTTP 2.0 and improve the Internet. How the industry moves forward together on the next version of HTTP – how every application and service on the Web communicates today – can have a positive impact on user experience, operational and environmental costs, and even the battery life of the devices you carry around.

As part of this discussion of HTTP 2.0, Microsoft will submit to the IETF a proposal for “HTTP Speed+Mobility.” The approach we propose focuses on Web performance improvements at the same time it takes into account the important needs of mobile devices and applications.

You can read more here about this proposal and an approach to HTTP 2.0 which considers network speed, cost, and device battery life, and works for everyone from sites owners, content providers, to consumers.

-- Rob Mauceri, Group Program Manager, Internet Explorer

IndexedDB Updates for IE10 and Metro style apps

ieblog — Wed, 21 Mar 2012 20:12:22 GMT

The Internet Explorer team along with the broader Web community has continued to make improvements to the IndexedDB specification. IndexedDB is a W3C Working Draft that enables you to store, search, and retrieve data on the user's device, even when Internet connectivity is disabled. IndexedDB is a feature of the Web platform shared by IE10 and Metro style apps in the Windows 8 Consumer Preview.

This blog post describes changes we made in Internet Explorer 10 Consumer preview to implement the latest version of the W3C spec.

Changes to Versioning

The most significant change involves how developers update their database schemas (i.e. object stores, indexes) from one version to the next. The working group (including Microsoft) decided to replace the IDBDatabase.setVersion API with a new IDBFactory.open API. The new open API uses an additional parameter to detect if you want to use the current database version of the or if you want to update the database schema to a newer version. The open API now returns an IDBOpenDBRequest object which lets you register for the onupgradeneeded event. In the event handler you can update your database schema by adding additional object stores and indexes.

To update your existing code, add a version parameter to your open method, replacing the call to setVersion, and register a new onupgradeneeded event handler on the IDBOpenDBRequest (see below).

Old code example – green highlights the impacted code


function openDBTest(dbName) {
var rq = window.msIndexedDB.open(dbName);
rq.onsuccess = successOpenningDB;
rq.onerror = failureHandler;
}
 
function successOpenningDB(evt) {
var db = evt.target.result;
var rq = db.setVersion("1");
rq.onsuccess = successHandler;
rq.onerror = failureHandler;
}
 
function successHandler(evt) {
//create schema
}

New code example – yellow highlights the changed code


function openDBTest(dbName) {
var rq = window.msIndexedDB.open(dbName, 1);
rq.onsuccess = useDB;
rq.onupgradeneeded = successHandler;
rq.onerror = failureHandler;
}
 
function successHandler(evt) {
//create schema
}

Additional Changes

In addition, we made several smaller (but still significant) changes to the platform:

Added the IDBCursor.advance(count) method. This method enables you to skip records in a cursor, which in turn enables pagination scenarios. The count parameter defines the number of records you want to skip before accessing data. Valid values are 1 or greater.
Added the IDBObjectStore.count(key) and IDBIndex.count(key) methods. These enable you to count the records that match specific criteria. If the key value is not specified, a count of all records inside the index or the object store is returned.
Added the IDBFactory.cmp(first, second) method. This method compares two key values to determine if one value is greater than the other or both values are equal.
IDBKeyRanges now work with additional methods, including IDBObjectStore.count, IDBObjectStore.delete, IDBIndex.count. This allows you to match records that span groups of key values.
Values being added to the database needed no longer need to satisfy all previously defined indexes. This allows you to add records to an IDBObjectStore that fall outside the limits of previously defined indexes.
If an exception is thrown within the context of an active transaction, the transaction is aborted. This implies that if an exception is thrown within the onsuccess event handler of any request, the active transaction will be aborted. However, handling the exception will allow the database transaction to continue as normal.
// This won’t abort the transaction because there is no active transaction. function createTransaction() { var txn = db.transaction("test"); window.aaaaaa(); } // This will abort the transaction because the exception is thrown when there is an active transaction. var rq = objectStore.add(record); rq.onsuccess = function (event) { window.aaaaaa(); }
Added support to index properties on a Blob. This allows you to download binary data from the Web, store it locally, and use blob properties (e.g. name, size, etc.) as indexes or unique keys into the blob. This functionality enables scenarios like offline listening of your music collection or viewing of images and videos, while having the ability to search through your collection using the blob’s name. Our latest IE Test drive demo shows you how you can use this functionality to view your Facebook albums offline.

Screen shot of IE Test Drive demo Facebook Companion

We also submitted over 100 test cases to the W3C working group for IndexedDB, including new tests and updates to existing tests.

Controlling How Sites and Apps use IndexedDB

In addition to updates to match changes in the W3C specification, the Windows 8 Consumer Preview includes improvements that allow users to remain in control of how sites and apps use IndexedDB on their devices:

Introduced an uninstall handler for Metro style apps that use indexedDB. This handler ensures that any time end-users remove an application, the related data in the app’s IndexedDB database will be automatically deleted during the uninstall process.
Implemented a quotas (storage limits) to prevent sites from exhausting disk space. Quota limits can be updated by IT Admins via group policy settings or by users with administrative access to the Registry. However, quotas don’t apply to Metro style apps.
Added a new browser interface for end-users to manage their databases and manage quotas. Users can use the Caches and databases dialog to remove individual databases. Alternatively, you can remove all databases using the Delete Browsing History dialog to select the “Cookies and Web site data” checkbox.

Screen shots of the new Caches and databases tab of the Website Data Settings dialog and the updated Delete Browsing History dialog

Looking Ahead

The W3C WebApp Working Group continues to drive IndexedDB to completion by making important improvements and reducing the number and scope of changes made to the spec. This is an important step for Web developers building on this technology in the near future, including in Windows 8 and IE10.

We look forward to seeing how you use IndexedDB in your sites and apps, and welcome your feedback on IndexedDB in IE10.

—Israel Hilerio, Ph.D., Principal Program Manager, Internet Explorer

WebSockets in Windows Consumer Preview

ieblog — Mon, 19 Mar 2012 21:59:30 GMT

In Windows 8 Consumer Preview and Server Beta, IE10 and all other Microsoft WebSocket client and server features now support the final version of the IETF WebSocket Protocol. In addition, IE10 implements the W3C WebSocket API Candidate Recommendation.

WebSockets are stable and ready for developers to start creating innovative applications and services. This post provides a simple introduction to the W3C WebSocket API and its underlying WebSocket protocol. The updated Flipbook demo uses the latest version of the API and protocol.

In my previous post, I introduced WebSocket scenarios:

WebSockets enable Web applications to deliver real-time notifications and updates in the browser. Developers have faced problems in working around the limitations in the browser’s original HTTP request-response model, which was not designed for real-time scenarios. WebSockets enable browsers to open a bidirectional, full-duplex communication channel with services. Each side can then use this channel to immediately send data to the other. Now, sites from social networking and games to financial sites can deliver better real-time scenarios, ideally using same markup across different browsers.

Since that September 2011 post, the working groups have made significant progress. The WebSocket protocol is now an IETF proposed standard protocol. In addition, the W3C WebSocket API is a W3C Candidate Recommendation.

Introduction to the WebSocket API Using an Echo Example

The code snippets below use a simple echo server created with ASP.NET’s System.Web.WebSockets namespace to echo back text and binary messages that are sent from the application. The application allows the user to type in text to be sent and echoed back as a text message or draw a picture that can be sent and echoed back as a binary message.

For a more complex example that allows you to experiment with latency and performance differences between WebSockets and HTTP polling, see the Flipbook demo.

Details of Connecting to a WebSocket Server

This simple explanation is based on a direct connection between the application and the server. If a proxy is configured, then IE10 starts the process by sending a HTTP CONNECT request to the proxy.

When a WebSocket object is created, a handshake is exchanged between the client and the server to establish the WebSocket connection.

IE10 starts the process by sending a HTTP request to the server:


GET /echo HTTP/1.1
Host: example.microsoft.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://microsoft.com
Sec-WebSocket-Version: 13

Let’s look at each part of this request.

The connection process starts with a standard HTTP GET request which allows the request to traverse firewalls, proxies, and other intermediaries:


GET /echo HTTP/1.1
Host: example.microsoft.com

The HTTP Upgrade header requests that the server switch the application-layer protocol from HTTP to the WebSocket protocol.


Upgrade: websocket
Connection: Upgrade

The server transforms the value in the Sec-WebSocket-Key header in its response to demonstrate that it understands the WebSocket protocol:


Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

The Origin header is set by IE10 to allow the server to enforce origin-based security.


Origin: http://microsoft.com

The Sec-WebSocket-Version header identifies the requested protocol version. Version 13 is the final version in the IETF proposed standard:


Sec-WebSocket-Version: 13

If the server accepts the request to upgrade the application-layer protocol, it returns a HTTP 101 Switching Protocols response:


HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

To demonstrate that it understands the WebSocket Protocol, the server performs a standardized transformation on the Sec-WebSocket-Key from the client request and returns the results in the Sec-WebSocket-Accept header:


Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

IE10 then compares Sec-WebSocket-Key with Sec-WebSocket-Accept to validate that the server is a WebSocket server and not a HTTP server with delusions of grandeur.

The client handshake established a HTTP-on-TCP connection between IE10 and server. After the server returns its 101 response, the application-layer protocol switches from HTTP to WebSockets which uses the previously established TCP connection.

HTTP is completely out of the picture at this point. Using the lightweight WebSocket wire protocol, messages can now be sent or received by either endpoint at any time.

Programming Connecting to a WebSocket Server

The WebSocket protocol defines two new URI schemes which are similar to the HTTP schemes.

"ws:" "//" host [ ":" port ] path [ "?" query ] is modeled on the “http:” scheme. Its default port is 80. It is used for unsecure (unencrypted) connections.
"wss:" "//" host [ ":" port ] path [ "?" query ] is modeled on the “https:” scheme. Its default port is 443. It is used for secure connections tunneled over Transport Layer Security.

When proxies or network intermediaries are present, there is a higher probability that secure connections will be successful, as intermediaries are less inclined to attempt to transform secure traffic.

The following code snippet establishes a WebSocket connection:


var host = "ws://example.microsoft.com";
var socket = new WebSocket(host);

ReadyState – Ready … Set … Go …

The WebSocket.readyState attribute represents the state of the connection: CONNECTING, OPEN, CLOSING, or CLOSED. When the WebSocket is first created, the readyState is set to CONNECTING. When the connection is established, the readyState is set to OPEN. If the connection fails to be established, then the readyState is set to CLOSED.

Registering for Open Events

To receive notifications when the connection has been created, the application must register for open events.


socket.onopen = function (openEvent) {
document.getElementById("serverStatus").innerHTML = 'Web Socket State::' + 'OPEN';
};

Details Behind Sending and Receiving Messages

After a successful handshake, the application and the Websocket server may exchange WebSocket messages. A message is composed as a sequence of one or more message fragments or data “frames.”

Each frame includes information such as:

Frame length
Type of message (binary or text) in the first frame in the message
A flag (FIN) indicating whether this is the last frame in the message

IE10 reassembles the frames into a complete message before passing it to the script.

Programming Sending and Receiving Messages

The send API allows applications to send messages to a Websocket server as UTF-8 text, ArrayBuffers, or Blobs.

For example, this snippet retrieves the text entered by the user and sends it to the server as a UTF-8 text message to be echoed back. It verifies that the Websocket is in an OPEN readyState:


function sendTextMessage() {
if (socket.readyState != WebSocket.OPEN)
return;
 
var e = document.getElementById("textmessage");
socket.send(e.value);
}

This snippet retrieves the image drawn by the user in a canvas and sends it to the server as a binary message:


function sendBinaryMessage() {
if (socket.readyState != WebSocket.OPEN)
return;
 
var sourceCanvas = document.getElementById('source');
// msToBlob returns a blob object from a canvas image or drawing
socket.send(sourceCanvas.msToBlob());
// ...
}

Registering for Message Events

To receive messages, the application must register for message events. The event handler receives a MessageEvent which contains the data in MessageEvent.data. Data can be received as text or binary messages.

When a binary message is received, the WebSocket.binaryType attribute controls whether the message data is returned as a Blob or an ArrayBuffer datatype. The attribute can be set to either “blob” or “arraybuffer.”

The examples below use the default value which is “blob.”

This snippet receives the echoed image or text from the websocket server. If the data is a Blob, then an image was returned and is drawn in the destination canvas; otherwise, a UTF-8 text message was returned and is displayed in a text field.


socket.onmessage = function (messageEvent) {
if (messageEvent.data instanceof Blob) {
var destinationCanvas = document.getElementById('destination');
var destinationContext = destinationCanvas.getContext('2d');
var image = new Image();
image.onload = function () {
destinationContext.clearRect(0, 0, destinationCanvas.width, destinationCanvas.height);
destinationContext.drawImage(image, 0, 0);
}
image.src = URL.createObjectURL(messageEvent.data);
} else {
document.getElementById("textresponse").value = messageEvent.data;
}
};

Details of Closing a WebSocket Connection

Similar to the opening handshake, there is a closing handshake. Either endpoint (the application or the server) can initiate this handshake.

A special kind of frame – a close frame – is sent to the other endpoint. The close frame may contain an optional status code and reason for the close. The protocol defines a set of appropriate values for the status code. The sender of the close frame must not send further application data after the close frame.

When the other endpoint receives the close frame, it responds with its own close frame in response. It may send pending messages prior to responding with the close frame.

Programming Closing a WebSocket and Registering for Close Events

The application initiates the close handshake on an open connection with the close API:


socket.close(1000, "normal close");

To receive notifications when the connection has been closed, the application must register for close events.


socket.onclose = function (closeEvent) {
document.getElementById("serverStatus").innerHTML = 'Web Socket State::' + 'CLOSED';
};

The close API accepts two optional parameters: a status code as defined by the protocol and a description. The status code must be either 1000 or in the range 3000 to 4999. When close is executed, the readyState attribute is set to CLOSING. After IE10 receives the close response from the server, the readyState attribute is set to CLOSED and a close event is fired.

Using Fiddler to See WebSockets Traffic

Fiddler is a popular HTTP debugging proxy. There is some support in the latest versions for the WebSocket protocol. You can inspect the headers exchanged in the WebSocket handshake:

All the WebSocket messages are also logged. In the screenshot below, you can see that “spiral” was sent to the server as a UTF-8 text message and echoed back:

Conclusion

If you want to learn more about WebSockets, you may watch these sessions from the Microsoft //Build/ conference from September 2011:

If you’re curious about using Microsoft technologies to create a WebSocket service, these posts are good introductions:

I encourage you to start developing with WebSockets today and share your feedback with us.

—Brian Raymor, Senior Program Manager, Windows Networking

Media Capture Prototype: Improved Support for Real World Web Apps

ieblog — Fri, 16 Mar 2012 22:47:46 GMT

Today we updated on HTML5 Labs the previously released Media Capture prototype to better align it to the latest W3C editor draft.

The HTML Media Capture working draft continues to evolve alongside related discussions in the Web RTC workgroup, and we have blogged previously about why this feature is important and how our Media Capture prototype implemented it in the past.

Because the API surface for this feature is far from final, we are supporting a simple capture syntax with this update, which is based on the most current proposal. We expect the capture syntax to change as the requirements for media capture are clarified in the task force.

Latest Updates

In this update, we are specifically adding support for a version of the getUserMedia method (function names are ms-prefixed for prototyping purposes), the MediaStream interface, and its associated events and callbacks. getUserMedia allows Web developers to suggest what specific capture devices are desired. This then allows end users to authorize the browser to access the device they selected for the duration of the capture session.


    
        function onLoad() {
        navigator.msGetUserMedia(options, cameraStarted);
        }
         
        function cameraStarted(mediaStream)
            {
        msMediaStream = mediaStream;
        getReady();
        document.getElementById("previewWindow").style.display
            = "block";
        document["imgPreview"].src
            = URL.createObjectURL(mediaStream);
        }

The advantage of this is two-fold: it protects user security and privacy and lets them pick the optimal device for the capture task from the many options available to them on a modern PC.

Looking back at our earlier proposals, we believe those scenarios are still important and relevant to this update: last March we released a prototype implementation of the audio portion of a working draft of the W3C Media Capture API on HTML5 Labs. This prototype publicized some proposed API enhancements described in section 6.1 of Microsoft’s HTML Speech XG Speech API Proposal. We then updated the prototype to include the image and video capture features described in the proposal to support scenarios we’ve heard are important for Web developers, and incorporated your feedback on audio.

This past November, we took our experience with the development of this prototype and interest in media capture for the browser to the W3C's technical plenary meeting (TPAC). Travis Leithead shared some of our feedback with the Device APIs (DAP) Working Group and we continued existing discussions within the HTML Speech Incubator Group. One result of our engagement was the formation of a media capture joint task force in order to bring the best of local media capture and real-time communication scenarios together. We are actively participating in the task force and support the getUserMedia approach to capture.

We then released an updated prototype in December that gives Web developers early access to photo, video and audio media capture APIs in the browser. We anticipate evolving the prototype to share implementation feedback and experience with the new media capture task force. The end goal remains to create the best possible standard for the benefit of the whole Web community.

Then, as discussed earlier, today we have updated the previously released Media Capture prototype to better align it to the latest W3C editor draft, which supports a simple capture syntax that is based on the most current proposal.

Microsoft remains actively engaged in the Media Capture task force and continues to advocate for the creation of the highest quality API to support these scenarios.

We Welcome Your Feedback

As always, we look forward to hearing from you, especially your questions and comments on how we can make this feature as good as possible for both the Developer community and end users. Please contact us either in the comment section on this blog or here.

—Adalberto Foresti, Senior Program Manager, Interoperability Strategy Team
—Travis Leithead, Program Manager, Internet Explorer

Spring into St. Patrick’s Day with HTML5

ieblog — Fri, 16 Mar 2012 14:36:43 GMT

Another holiday brings us another opportunity to celebrate it with you. We’re pleased to mark the transition into spring as well as St. Patrick’s Day with Irish Spring, a new hardware-accelerated HTML5 experience that shows the benefits of Internet Explorer 10 on Windows 8 Consumer Preview.

Irish Spring incorporates HTML5 canvas and CSS gradients, opacity, transforms, and animation along with HTML5 audio. With the Windows Consumer Preview and IE10’s support for multi-touch you can propel the clovers and leaves around in a strangely satisfying fashion. Try it with multiple fingers on your touch device. Alternatively, you can use your mouse to move the clovers around the screen.

If you aren’t using Internet Explorer 10 and think your browser can still handle the heat, give it a shot. But don’t be surprised if the lack of multi-touch and full hardware acceleration leaves you wanting to install the Windows 8 Consumer Preview.

This video shows IE10's support for multi-touch and hardware acceleration in action with Irish Spring.

Put a little spring in your friends’ step by clicking the share controls at the top of the demo.

From the entire IE team, we wish you a happy, safe, and lucky St. Patrick’s Day!

—Tobin Titus, Program Manager, Internet Explorer

Enhanced Protected Mode

ieblog — Wed, 14 Mar 2012 16:41:21 GMT

Every release of Internet Explorer includes new security enhancements to help keep you safe as you browse the Internet. The new Enhanced Protected Mode in Internet Explorer 10 helps keep your data safe even if an attacker has exploited a vulnerability in the browser or one of its add-ons.

There is no single thing that can keep you secure by itself, so we pursue multiple strategies, including:

Protection from socially-engineered attacks

There are a variety of miscreants that want to steal your personal information or take over your computer by impersonating Web sites that you trust. SmartScreen Filter provides the best protection available against malware attacks and phishing. In Windows 8, this protection was added to the Windows Shell, to help keep you safe from malware no matter how it was downloaded.

Protection from attacks designed to exploit vulnerabilities in Web sites

“Good” Web sites can have security vulnerabilities that can allow evil Web sites to steal your data or perform actions as if they were you. We protect you with the XSS Filter, which automatically prevents certain types of attacks, and make it easier for Web sites to secure themselves with Declarative Security features, like IE10’s new support for the HTML5 Sandbox.

Protection against attacks designed to exploit the browser or operating system

Automatic updating ensures that you have the latest updates installed. This protects you against security issues that have been fixed. IE9 added memory protection features to make it harder to exploit certain types of vulnerabilities and we enhanced these features in IE10. We also added a new layer of protection in IE10 called Enhanced Protected Mode.

Enhanced Protected Mode

Protected Mode, which was added in IE7 for Windows Vista, is defense in depth feature that helps prevent attackers from installing software or modifying system settings if they manage to run exploit code. It is an extra layer of protection that locks down parts of your system that your browser ordinarily doesn’t need to use. For example, your browser doesn’t usually need to modify system settings or write to your Documents folder. Protected Mode is based on the principle of least privilege -- by reducing the capabilities that Internet Explorer has, the capabilities available to exploit code are reduced as well.

“Enhanced” Protected Mode takes this concept further by restricting additional capabilities. Below is a list of some of the new ways that Enhanced Protected Mode helps keep you safe:

64-bit processes

Most PCs shipped in the last few years have 64-bit CPUs, and many have a 64-bit version of Windows installed. “64-bit” is usually thought of as a way to extend the amount of memory that a program on your computer can use: because 64-bit processors use 64-bit memory addresses instead of 32-bit ones, a program can “address,” or use, more memory if it’s available.

A 32-bit number is large – it’s a little more than 4 billion. A 64-bit address is much larger number – roughly 18 pentillion and change (18,446,744,073,709,551,616). Not only does a 64-bit number let you address more memory, it also makes existing memory protection features such as ASLR (Address Space Layout Randomization) much more effective. Heap spray attacks, which are used by attackers to plant malicious code at predictable locations, become much more difficult because it isn’t practical to “fill up” a 64-bit address space – you’ll run out of memory and disk space long before any sizable fraction of the address space is sprayed.

Protecting your personal information

When you run a program, it has access to anything on the computer that you have access to, including your personal documents. Enhanced Protected Mode restricts Internet Explorer from locations that contain your personal information until you grant permission to it. This helps prevent exploit code from accessing your personal information without your permission.

For example, consider Web-based email. If you want to attach a file from your Documents folder to the email, then Internet Explorer needs permission to access the file and upload it to your email provider. With Enhanced Protected Mode, a “broker process” will grant Internet Explorer temporary access to the file only if you actually click on “Open” on the file upload dialog:

Notice that there are no extra prompts. Brokering is done automatically after you choose to open a file. This is like providing a single safe deposit box to Internet Explorer when requested, instead of giving access to the entire safe all of the time.

Protecting your corporate assets

Most corporate networks, or “intranets,” contain valuable information that must be protected from attackers. Enhanced Protected Mode restricts an exploit’s ability to access corporate network resources in three ways. First, Internet tab processes, which is where untrusted Internet pages load, do not have access to a user’s domain credentials. Second, they cannot operate as local webservers, which makes it more difficult to impersonate an Intranet site. Third, Internet tabs cannot make connections to intranet servers.

Default Settings and Compatibility

Metro style Internet Explorer always runs with Enhanced Protected Mode enabled – there isn’t anything that you need to configure – just browse. Because Metro style Internet Explorer offers plug-in free browsing, the compatibility impact of this security feature is minimal.

Many add-ons, such as Adobe Flash and certain toolbars are not yet compatible with Enhanced Protected Mode. Some Web sites still require Adobe Flash in order to work, and some users enjoy the additional functionality offered by some toolbars. In Windows 8 Beta, Enhanced Protected Mode can be enabled in the desktop under Internet Options->Advanced:

After you enable Enhanced Protected Mode, incompatible add-ons will automatically be disabled. If you encounter a site that needs an add-on such as Flash in order to work, you can disable Enhanced Protected Mode just for that particular Web site.

This allows you to continue using the site, and have Enhanced Protected Mode enabled on the rest of the Internet. Keep in mind that you should only do this if you know and trust the Web site.

Of course, if you prefer to browse without add-ons, you can always turn on ActiveX Filtering, which will prevent you from seeing this prompt.

Summary

Defense-in-depth is an area of continual investment for the Windows team. It’s a widely-applied principle in the real world as well. Safety deposit boxes have locks on them. But they are also kept inside of a locked room, inside of a bank, which is locked and is armed with an advanced security system. Enhanced Protected Mode is another layer of protection that helps protect your data from malicious attackers.

—Andy Zeigler, Senior Program Manager, Internet Explorer

Enhanced Memory Protections in IE10

ieblog — Tue, 13 Mar 2012 00:05:00 GMT

Internet Explorer 10 introduces significant improvements in memory protections to help make vulnerabilities harder to exploit, helping to keep users safe on the sometimes-hostile Web. These improvements will increase the difficulty and development cost of exploits, making life harder for the bad guys.

While socially-engineered malware is the primary way that bad guys get their code onto victims’ computers, that is largely because browser vulnerabilities have become less common and harder to exploit over the last few years. However, as more and more users upgrade to IE9 and benefit from the protection provided by SmartScreen Filter, bad guys have a renewed interest in attacking the browser and its add-ons directly.

In today’s post, I explain the threat environment, survey the existing protections available in IE9, and explain how IE10’s new memory protections provide even more security.

Attacking Web Browsers

The goal of an attacker exploiting a memory-related vulnerability is to cause the browser’s path of code execution to deviate into code of the bad guy’s choosing. To achieve this, the attacker needs two things to be successful. They need to have code available on the victims’ machine that they wish to run. The techniques used to obtain such code can be grouped into two classes. An attacker can place their own malicious code into memory using techniques like heap spraying. Or an attacker can select code to execute that is already present in memory using a technique called Return Oriented Programming.

The attacker also needs to be able to exploit a vulnerability that allows the flow of code execution to be altered from design, such as a buffer overflow vulnerability. Then they can change the code path to “jump to” the address of the code they want executed.

In a typical buffer overflow attack, a carefully crafted data set is placed on the thread’s stack, overflowing its assigned buffer and overwriting other data structures. Attackers attempt to overwrite structures like exception handler records, or the return address of the function, which would allow them to change the flow of code to a location in memory of their choosing.

Other types of attacks include use-after-free vulnerabilities, in which the application is tricked into accessing a released object whose memory has been reused for some other purpose.

Defending the Browser

Memory protection technologies provide a front line of defense to block attackers from achieving their goals. These technologies exist to make exploiting vulnerabilities more difficult, less reliable, and in some cases impossible. Memory protections aim to safely terminate a browser process under attack before a vulnerability can be successfully exploited to run the attacker’s code. In many cases, protections allow vendors time to produce and distribute a fix before a vulnerability can be exploited to cause damage.

The Memory Mitigation Technologies employed by Internet Explorer have evolved over time to help defend against new attack techniques as they are developed and popularized. Many defenses, like the /GS compiler flag, have been used by previous versions of Internet Explorer but are updated and enhanced over time. Some defenses, like ForceASLR (described shortly) are new to IE10 and rely on new operating system features.

Compile time mitigations

Compiler mitigations are available to software developers and should be applied as part of a development best practice. The Internet Explorer team includes these mitigations during the development Internet Explorer as a requirement of our Security Development Lifecycle. We encourage software developers to adopt their own SDL process that include implementation of these compile time mitigations.

The /GS flag was first introduced in Visual Studio .NET 2002 and has been used by all supported IE versions. It is a compiler technology which adds a Buffer Overrun Detection capability to an application’s stack. Security secrets known as “canaries” are added to application’s stack boundaries at runtime. For example, a canary placed between a stack buffer and a return address, will be overwritten by a buffer overflow attack targeting the return address. This provides a means for the process to detect that an overflow has occurred. An exception will be raised and the process can be safely terminated before the attacker’s code is run.

This basic protection concept has been improved in each new version of Visual Studio. The latest version of Enhanced /GS, used by Internet Explorer 9+, includes greatly improved heuristics to protect more functions, including Non-Pointer arrays and pure data structures. In addition, improved optimization has eliminated unnecessary checks, decreasing the performance cost of the defense.

The /SAFESEH flag is a linker option that provides a mechanism for an application’s registered exception handlers to be stored in a lookup table in a secure memory location. In the event of an exception, the exception handler addresses on the application’s stack are validated against the lookup table. If the values do not match, the process will be terminated.

One problem with the /SAFESEH flag is that it requires all DLL modules to opt-in to the protection to reliably protect the process. If any module does not opt-in, protection is less effective. While the SDL requires that all of Microsoft’s code be compiled with SAFESEH, third-party add-ons might not be compiled with the flag.

The /DYNAMICBASE flag is a linker option that opts an application into an operating system mitigation known as Address Space Layout Randomization (ASLR), discussed in more detail later in this post.

Similarly to the /SAFESEH limitation, a problem with the /DYNAMICBASE flag is that any DLL module that doesn’t opt-in to this protection reduces the value of ASLR as an exploit mitigation. Any module at a predictable location can be targeted by an attacker, and an exploit may only require one such predictable target. Many recent exploits target browser add-ons that don’t opt-in to the protection of ASLR. For instance, an Adobe Reader and Acrobat 0-day exploit in 2010 relied on the predictable location of functions within a module named icucnv36.dll that failed to opt-in to ASLR.

Run time mitigations

Runtime mitigations allow the operating system to help participate in keeping the process secure.

DEP/NX is an operating system mitigation that relies upon key security features (Data Execution Prevention or No eXecute) of modern CPUs. This mitigation enables memory pages to be marked as non-executable (Data); the processor will refuse to run code on a memory page so marked.

In the second stage of a memory exploit, an attacker may try to execute their own code which they have added to a data page in memory. In scenarios where the data page has been marked as non-executable, the attacker’s code will fail to run and the process will be safely terminated.

DEP/NX support was first enabled by default in IE8, and remains enabled in IE10.

SEHOP is a runtime mitigation that provides an exception-handler tamper-protection mechanism much like the /SAFESEH compiler flag. This protection works by inserting a symbolic exception record as the tail record in the thread’s exception handler list. In the event of an exception, the exception handler list is walked to ensure that the symbolic record can be reached. If it cannot be reached, this indicates that the exception handler chain is corrupted and the process will be safely terminated. Unlike SafeSEH, SEHOP does not require each individual module to opt-in, and thus it provides protection even if add-ons were not compiled with the most secure flags.

SEHOP was first enabled in IE9 and remains enabled in IE10.

Address Space Layout Randomization was first introduced in Windows Vista and has been greatly improved in Windows 8. ASLR assigns applications a random base memory address when they are initially loaded into memory. In addition, other memory structures such as the Process Environment Blocks (PEB), Thread Environment Blocks (TEB), Stacks and Heaps are also assigned to random locations in memory.

Randomizing the location of objects and functions in memory helps prevent an attacker from discovering where they are, which helps prevent a technique called Return Oriented Programming. This randomization can be thought of as securing the attacker’s payload with a combination lock. If an attacker doesn’t have the combination, they only get one guess. Guessing wrong means the attack will fail and the process will safely be terminated.

The following illustration depicts how core system components are loaded in random memory addresses on system startup.

ASLR in Windows 8 has seen a number of improvements, all of which are utilized by Internet Explorer 10.

All Bottom-Up and Top-Down allocations are now randomized using 8 bits of entropy. This improvement significantly reduces predictable memory regions including VirtualAlloc and MapViewOfFile.

High Entropy Address Space Layout Randomization (HEASLR) takes advantage of the increase in 64bit address space and assigns more bits to entropy. This has the effect of drastically increasing the number of potential addresses that may be assigned to a 64bit process. All 64bit processes can opt-in to the increased entropy made available by HEASLR. Processes can opt-in either at link time (/HIGHENTROPYVA) or at load time via a new Image File Execution Option.

By default, the Metro style browser runs in 64bit mode on 64bit computers, providing a much larger address space and thus more random memory layout.

ForceASLR is arguably the most important change to ASLR in Windows 8. ForceASLR is a new loader option used by Internet Explorer 10 to instruct the operating system to randomize the location of all modules loaded by the browser, even if a given module was not compiled with the /DYNAMICBASE flag. The ForceASLR protection was added to the Windows 8 kernel, and the feature is now available as an update to Windows 7 that will be installed when Internet Explorer 10 is installed on that platform.

To help ensure compatibility with this feature, and to provide memory-randomization protection to older Internet Explorer versions that don’t support ForceASLR, we continue to recommend that add-on developers make use of the /DYNAMICBASE flag.

Summary

I hope this brief overview of the memory protections present in Windows 8 and Internet Explorer 10 has proven valuable. Under the covers, we’ve made many other tweaks for enhanced security, but many of them are so esoteric that we don’t even have names for them. We do have a few more security-related announcements coming, so stay tuned for updates as we continue our mission to deliver a secure Web browsing platform.

—Forbes Higman, Security Program Manager, Internet Explorer

Web Platform Features in Windows Consumer Preview

ieblog — Fri, 02 Mar 2012 19:18:00 GMT

Internet Explorer 10 in the Windows Consumer Preview introduces a number of new or updated Web platform features when compared to the IE10 in the Windows Developer Preview released September 13, 2011. Some of these shipped in the fourth IE10 platform preview released November 29, 2011, and have been blogged about since; some are new in the Consumer Preview.

New or Updated Web Platform Features

The following Web platform capabilities in the Consumer Preview were not in the Developer Preview:

Cross-Origin Resource Sharing (CORS) for XMLHttpRequest (spec / post / dev guide)
CSS -ms-user-select property (post / dev guide)
CSS3 font-feature-settings property to access advanced OpenType® features (spec / post / dev guide)
Document setting to enable floating point values in CSS-OM (post / dev guide)
HTML5 BlobBuilder API and new APIs to save or open files (spec / post / dev guide)
HTML5 track element for HTML5 video captions (spec / post / dev guide)
Interoperable HTML5 Quirks mode (post / dev guide)
JavaScript Typed Arrays (post)
Meta tag to alert user that site requires ActiveX add-ons available only in desktop IE10 (post)
Removal of legacy graphics features from IE10 standards mode (post)
Changes to support latest HTML5 WebSocket API (spec)
Web Worker thread pooling

Across the board, we’ve improved performance and addressed feedback on the platform features that were available in the Windows Developer Preview but not IE9:

CSS-OM media query list listeners (spec / dev guide)
CSS3 3D transforms (post / dev guide)
CSS3 gradients (post / dev guide)
CSS3 grid, flexible box, and multi-column layout and exclusions (post / grid / flexbox / multicol / exclusions)
CSS3 regions and hyphenation (post / regions / hyphenation)
CSS3 text-shadow property (post / dev guide)
CSS3 transitions and animations (post / transitions / animations)
HTML5 AppCache and IndexedDB (post / appcache / indexeddb)
HTML5 async attribute of the script element (spec / dev guide)
HTML5 drag and drop APIs (spec / post / dev guide)
HTML5 File API (spec / dev guide)
HTML5 forms and validation (dev guide)
HTML5 History API (post)
HTML5 parsing algorithm (post / dev guide)
HTML5 sandbox (post / dev guide)
HTML5 Web Workers (spec / post / post / dev guide)
HTML5 WebSocket API (spec / post / dev guide)
Pointer events and multi-touch input (post / post / dev guide)
SVG filter effects (post / dev guide)
XMLHttpRequest enhancements (dev guide)
and more. See Windows Internet Explorer 10 Consumer Preview Guide for Developers

More to Come: User Interface Improvements

Metro style Internet Explorer in the Windows Consumer Preview contains many user interface changes and additions compared to the Windows Developer Preview. You can get a taste for these in what Gizmodo wrote about Internet Explorer 10. We will be blogging about these new features in the coming days both here and on Building Windows 8.

—Ted Johnson for IEBlog

Windows Consumer Preview: The Fifth IE10 Platform Preview

ieblog — Wed, 29 Feb 2012 15:30:00 GMT

With IE10 in Windows 8, we reimagined the browser. We designed and built IE10 to be the best way to experience the Web on Windows. Consumers can now enjoy more touch-friendly and beautiful, fast and fluid Web applications with the updated IE10 engine included in the Windows Consumer Preview. This fifth Platform Preview of IE10 delivers improved performance and support for more HTML5:

This video shows some of the touch-friendly HTML5 technologies in the fifth IE10 Platform Preview, included with the Windows Consumer Preview.
View this video on YouTube

You can read more about the improvements to the Metro style browsing experience on the Building Windows 8 blog. The remainder of this post discusses the underlying HTML5 engine.

Windows 8 includes one HTML5 browsing engine that powers both browsing experiences (the Metro style one and desktop one) as well as Metro style applications that use HTML5 and JavaScript. The common HTML5 engine provides consistently fast, safe, and powerful support for Web standards and the Web programming model, for both browser experiences as well as for Metro style applications.

Consumers experience this power with rich, beautiful visual effects that take full advantage of the underlying hardware safely. Some examples that you can try at the IE Test Drive site with the Consumer Preview include fast and fluid multi-touch support in Web pages and the latest database APIs, which enable you to take photos from a Web site offline. The Test Drive site demonstrates how much better the Web can be with rich visual effects, sophisticated page layouts, and the advances to the Web programming model. You can read the full list in the IE10 developer guide.

A Better Web Ahead

Working closely with the developer community, we see a much better Web ahead.

IE10 in the Metro style experience is plug-in free. Almost all phones and devices are already plug-in free and many sites already run plug-in free for them. To deliver the richest experience, and one experience that scales across different devices, we continue to recommend that developers detect when plug-ins are not available and rely on native browser patterns.

Similarly, we recommend that developers update their sites’ older, out of date libraries (like this one) that don’t work well with new browsers like IE10.

We also recommend that developers use feature, not browser, detection. Often, the compatibility problem reports we receive have more to do with sites detecting IE and sending it different content than they send other browsers than any particular issue in IE. You can see some examples of how IE makes up for certain sites by adjusting the information it sends to particular sites (e.g. sending an iPad identification token) based on the Compatibility View (CV) list in the post script to this blog entry.

Developers can find sample feature detection code patterns in several IE blog posts, including this one.

The quality and correctness of different browsers’ HTML5 engines continue to vary widely. We continue to contribute to the test suites under development at the HTML5 standards bodies to further the goal of interoperability and same markup. We’ve submitted 456 new tests to them that you can view at the IE Test Center as well. As different browsers improve their support of the same markup to produce the same results, we can all realize the promise of HTML5.

You can find a full list of new functionality available to developers in the IE10 developer guide here. Download the Windows 8 Consumer preview to try this update to IE10. We look forward to continued engagement with the developer community and your feedback on Connect.

―Dean Hachamovitch, Corporate Vice President, Internet Explorer

Protecting Consumers’ Privacy Online

ieblog — Thu, 23 Feb 2012 23:56:00 GMT

This morning in the United States, the White House announced a new “Consumer Privacy Bill of Rights” as part of the effort to improve consumers’ online privacy. As I’ve mentioned before, Microsoft is actively participating in the industry initiative for Tracking Protection at the W3C to produce Web standards for online privacy.

The Tracking Protection Working Group is chartered to work on two complementary initiatives: Tracking Preference Expression (Do Not Track) and Tracking Selection Lists (TSL). The TSL editor’s draft defines a format for interchangeable lists for blocking or allowing tracking elements from Web pages. Last month, at the W3C face-to-face meeting, the working group decided that a sub-group (or “task force”) of those interested in TSLs should work on the specification together.

Work on Do Not Track (DNT) is continuing and the W3C expects this to become a standard sometime in 2012. In the meantime, IE’s Tracking Protection feature is available to IE9 and IE10 users today. This is the only technology that can filter out unwanted cookies, beacons, and other tracking devices without requiring Web sites, advertisers, and publishers to change.

At the CPDP 2012 conference in Brussels, Simon Davies and Alexander Hanff of Privacy International launched two new tracking protection lists designed to protect consumers from Web Analytics and Behavioural Tracking. These lists are available from http://www.privacyonline.org.uk/. Check out the complete set of Tracking Protection Lists available from the IE Gallery (including the popular EasyPrivacy and Fanboy lists).

--Adrian Bateman, Program Manager, Internet Explorer

Note: Correction in last paragraph

Google Bypassing User Privacy Settings

ieblog — Mon, 20 Feb 2012 18:31:00 GMT

When the IE team heard that Google had bypassed user privacy settings on Safari, we asked ourselves a simple question: is Google circumventing the privacy preferences of Internet Explorer users too? We’ve discovered the answer is yes: Google is employing similar methods to get around the default privacy protections in IE and track IE users with cookies. Below we spell out in more detail what we’ve discovered, as well as recommendations to IE users on how to protect their privacy from Google with the use of IE9's Tracking Protection feature. We’ve also contacted Google and asked them to commit to honoring P3P privacy settings for users of all browsers.

We’ve found that Google bypasses the P3P Privacy Protection feature in IE. The result is similar to the recent reports of Google’s circumvention of privacy protections in Apple’s Safari Web browser, even though the actual bypass mechanism Google uses is different.

Internet Explorer 9 has an additional privacy feature called Tracking Protection which is not susceptible to this type of bypass. Microsoft recommends that customers who want to protect themselves from Google’s bypass of P3P Privacy Protection use Internet Explorer 9 and click here to add a Tracking Protection List. Customers can find additional lists and information on this page.

Background: Google Bypassing Apple’s Privacy Settings

A recent front page Wall Street Journal article described how Google “bypassed Apple browser settings for guarding privacy.” The editor and CEO of Business Insider, a business news and analysis site, summarized the situation:

Google secretly developed a way to circumvent default privacy settings established by a… competitor, Apple… [and] Google then used the workaround to drop ad-tracking cookies on the Safari users, which is exactly the sort of practice that Apple was trying to prevent.

Third-party cookies are a common mechanism used to track what people do online. Safari protects its users from being tracked this way by a default user setting that blocks third-party cookies. Here’s Business Insider’s summary:

What Safari does NOT allow, by default, is for third-party … cookies on users' computers without their permission. It is these ad-tracking cookies that cause lots of Internet users to freak out that their privacy is being violated, so it's understandable that Apple decided to block them by default.

But these default settings have created a problem for Google, at least with respect to its goals for its advertising business.

Google’s approach to third-party cookies seems to have the side effect of Safari believing they are first-party cookies.

What Happens in IE

By default, IE blocks third-party cookies unless the site presents a P3P Compact Policy Statement indicating how the site will use the cookie and that the site’s use does not include tracking the user. Google’s P3P policy causes Internet Explorer to accept Google’s cookies even though the policy does not state Google’s intent.

P3P, an official recommendation of the W3C Web standards body, is a Web technology that all browsers and sites can support. Sites use P3P to describe how they intend to use cookies and user information. By supporting P3P, browsers can block or allow cookies to honor user privacy preferences with respect to the site’s stated intentions.

It’s worth noting that users cannot easily access P3P policies. Web sites send these policies directly to Web browsers using HTTP headers. The only people who see P3P descriptions are technically skilled and use special tools, like the Cookie inspector in the Fiddler tool. For example, here is the P3P Compact Policy (CP) statement from Microsoft.com:

P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"

Each token (e.g. ALL, IND) has a specific meaning for a P3P-compliant Web browser. For example, ‘SAMo’ indicates that ‘We [the site] share information with Legal entities following our practices,’ and ‘TAI’ indicates ‘Information may be used to tailor or modify content or design of the site where the information is used only for a single visit to the site and not used for any kind of future customization.’ The details of privacy are complex, and the P3P standard is complex as well. You can read more about P3P here.

Technically, Google utilizes a nuance in the P3P specification that has the effect of bypassing user preferences about cookies. The P3P specification (in an attempt to leave room for future advances in privacy policies) states that browsers should ignore any undefined policies they encounter. Google sends a P3P policy that fails to inform the browser about Google’s use of cookies and user information. Google’s P3P policy is actually a statement that it is not a P3P policy. It’s intended for humans to read even though P3P policies are designed for browsers to “read”:

P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 for more info."

P3P-compliant browsers interpret Google’s policy as indicating that the cookie will not be used for any tracking purpose or any purpose at all. By sending this text, Google bypasses the cookie protection and enables its third-party cookies to be allowed rather than blocked. The P3P specification (“4.2 Compact Policy Vocabulary”) calls for IE’s implemented behavior when handling unknown tokens: “If an unrecognized token appears in a compact policy, the compact policy has the same semantics as if that token was not present.”

Similarly, it’s worth noting section “3.2 Policies” from the P3P specification:

3.2 Policies

In cases where the P3P vocabulary is not precise enough to describe a Web site's practices, sites should use the vocabulary terms that most closely match their practices and provide further explanation in the CONSEQUENCE field and/or their human-readable policy. However, policies MUST NOT make false or misleading statements.

P3P is designed to support sites that convey their privacy intentions. Google’s use of P3P does not convey those intentions in a manner consistent with the technology.

Because of the issues noted above, and the ongoing development of new mechanisms to track users that do not involve cookies, our focus is on the new Tracking Protection technology.

Next Steps

After investigating what Google sends to IE, we confirmed what we describe above. We have made a Tracking Protection List available that IE9 users can add by clicking here as a protection in the event that Google continues this practice. Customers can find additional lists and information on this page.

The premise of Tracking Protection in IE9 is that tracking servers never have the opportunity to use cookies or any other mechanism to track the user if the user never sends anything to a tracking server. This logic underlies why Tracking Protection blocks network requests entirely. This new technology approach is currently undergoing the standardization process at the W3C.

This blog post has additional information about IE’s cookie controls, and shows how you can block all cookies from a given site (e.g. *.google.com) regardless of whether they are first- or third-party. This method of blocking cookies would not be subject to the methods Google used. We recommend that users not yet running IE9 take steps described in this post.

Given this real-world behavior, we are investigating what additional changes to make to our products. The P3P specification says that browsers should ignore unknown tokens. Privacy advocates involved in the original specification have recently suggested that IE ignore the specification and block cookies with unrecognized tokens. We are actively investigating that course of action.

―Dean Hachamovitch, Corporate Vice President, Internet Explorer

Sub-pixel Rendering and the CSS Object Model

ieblog — Fri, 17 Feb 2012 20:22:00 GMT

With Windows 8, you have an unprecedented choice of devices for browsing the Web, from large desktop screens to small slates. In order to accommodate this range of devices, the browser must be able to scale and layout the Web at many different screen sizes and dimensions. We've previously blogged about some of the features in IE that support these scenarios. Sub-pixel positioning (of text and layout) is one of the core platform technologies which enable Web pages to look beautiful and consistent at any scale.

In this post, we describe changes made in IE10 to better support sub-pixel positioning through the CSS-OM.

Web developers can build beautiful layouts through a variety of platform technologies. Generally, developers use CSS style sheets to describe the layout a Web site. In some scenarios, Web developers also depend on JavaScript code to measure, align, or position elements of a Web page with pixel-perfect precision. For example, some online editors carefully position an edit box exactly over the top of existing content so that it only appears as if you are directly editing the existing content. Scenarios such as this one may use the CSS object model (CSS-OM) APIs to read and/or set element position. The CSS-OM is a set of JavaScript APIs for programmatically manipulating CSS.

Measuring and aligning layout elements using the CSS-OM APIs can be problematic because of the way that those APIs round or truncate sub-pixel positioned values to whole-pixel numbers.

A Quick Note about Pixel-perfect Layouts

In general, pixel-perfect layouts on the Web tend to conflict with the goals of enabling accessible, compatible, and adaptable content, and consequently are not a best practice. The following collage illustrates some of the bugs that can occur when the Web designer attempts to create a pixel-perfect design but unexpected Web platform differences cause their designs to go awry.

Examples of pixel-perfect designs gone wrong

When using the CSS-OM to dynamically generate a layout, Web developers should allow for a few pixels of potential error. Better yet, IE10 provides several new layout options that developers can use to better achieve many of these desired layouts without requiring pixel-perfect alignment using the CSS-OM.

An Illustration

To illustrate how the CSS-OM APIs may cause subtle positioning problems, consider a simple example. Sub-pixel positioning allows four boxes to be evenly distributed inside of the container, despite the container's size not being evenly divisible by four.

Consider the following HTML markup fragment:

<div>content 1</div><div>content 2</div><div>content 3</div><div>content 4</div>

</footer>

with this partial CSS markup:

footer { width: 554px; border: 1px solid black; text-align: center; }

footer div { display: inline-block; width: 25%; }

footer div:nth-child(even) { background-color: Red; }

footer div:nth-child(odd) { background-color: Orange; }

Now, let’s add a function that runs on load and reports the widths of these items:

onload = function () {

var footerBoxes = document.querySelectorAll("footer div");

var s = "";

var totalSize = 0;

for (var i = 0; i < footerBoxes.length; i++) {

// Reporting

var offsetWidth = footerBoxes[i].offsetWidth;

s += "content " + (i + 1) + " offsetWidth = " + offsetWidth + "px" + "<br />";

totalSize += offsetWidth;

}

s += "Total <i>calculated</i> offsetWidth = " + totalSize + "px" + "<br />";

s += "Container width = " + document.querySelector("footer").clientWidth + "px" + "<br />";

document.querySelector("#message").innerHTML = s;

}

The result of running this markup and code in IE9 is something like this:

content 1content 2content 3content 4 content 1 offsetWidth = 139 content 2 offsetWidth = 139 content 3 offsetWidth = 139 content 4 offsetWidth = 139 Total calculated offsetWidth = 556 Actual container width = 554

Note that summing the values returned by the CSS-OM API offsetWidth results in the total calculated offsetWidth differing from the actual container width by two pixels, due to rounding that occurs in the offsetWidth of the individual div elements.

The results in other browsers show a similar discrepancy, though sometimes the total is less than the actual and sometimes greater.

When the rounding/truncation leads to a sum total that overflows the container size (as illustrated), content will start to wrap or cause unwanted scroll-bars to appear. Additionally, many containers are sized according to the text and the font used to render the text, and those font metrics may be different across browsers or alternate fonts may be selected if the requested font isn't available.

The offsetWidth API, along with many other widely used CSS-OM properties (most dating back to IE4 in 1997), provide a convenient and fast way to extract integer pixel values for an element from a variety of different coordinate systems. All major browsers implement most of these APIs for compatibility and they are also part of the CSS-OM View module, a W3C draft standard.

New browser features continue to demonstrate the shortfall of limiting CSS-OM properties to whole-value pixels. For example, features like SVG and CSS 2D/ 3D Transforms allow an element's dimensions to easily fall between pixels.

Addressing the Problem

Recognizing this limitation (in part), the W3C CSS-OM View spec describes the coordinates returned via the getBoundingClientRect() API to be floats; in other words, in values that can represent sub-pixel precision. (getBoundingClientRect() is another CSS-OM API that provides an element's bounding-box position and dimension using the same origin as the offsetWidth API.)

In IE10 we've updated the getBoundingClientRect() API to return sub-pixel resolution by default in IE10 standards mode in order to be interoperable with other browsers and align with the W3C standard.

Updating our example above to report the width component of the rectangle returned by getBoundingClientRect(), IE10 now reports these fractional values:

content 1content 2content 3content 4 content 1 offsetWidth = 139, getBoundingClientRect().width = 138.5 content 2 offsetWidth = 139, getBoundingClientRect().width = 138.5 content 3 offsetWidth = 139, getBoundingClientRect().width = 138.5 content 4 offsetWidth = 139, getBoundingClientRect().width = 138.5 Total calculated offsetWidth = 556 Total calculated getBoundingClientRect().width = 554 Actual container width = 554

Taking Sub-pixel Values Everywhere

In addition to getBoundingClientRect, we also report sub-pixel position for mouse/pointer events in IE10 standards mode by default. It's only possible for the mouse/pointer to land between pixels when the zoom factor is set to a value other than 100%. Specifically, the affected mouse/pointer APIs are:

MouseEvent.offsetX/Y
MouseEvent.layerX/Y
MouseEvent.clientX/Y
MouseEvent.pageX/Y
MouseEvent.x/y

To continue our commitment to compatibility with legacy Web pages (pages which may not be prepared to handle sub-pixel values from the CSS-OM in general), IE10 continues to reports whole-value pixel units by default for the other CSS-OM properties. These APIs are:

Element.clientHeight
Element.clientWidth
Element.clientLeft
Element.clientTop
Element.scrollTop
Element.scrollLeft
Element.scrollWidth
Element.scrollHeight
HTMLElement.offsetWidth
HTMLElement.offsetHeight
HTMLElement.offsetTop
HTMLElement.offsetLeft
TextRange.offsetLeft
TextRange.offsetTop

However, if necessary, IE10 now allows Web developers to enable sub-pixel positioned values from the above-listed CSS-OM properties as well. Use of this special feature requires that the site run in IE10 Standards mode and opt-in by setting the following property on the document object:

document.msCSSOMElementFloatMetrics = true;

When enabled by setting document.msCSSOMElementFloatMetrics to true, all CSS-OM APIs in the previous list will begin reporting their values in sub-pixel precision that will reflect exactly the calculations used internally by the layout and rendering engine. Note that JavaScript will convert 1.00 into 1 so you may not always see a decimal point in returned values.

Going back to our example and setting document.msCSSOMElementFloatMetrics to true results in this in IE10:

content 1content 2content 3content 4 content 1 offsetWidth = 138.5, getBoundingClientRect().width = 138.5 content 2 offsetWidth = 138.5, getBoundingClientRect().width = 138.5 content 3 offsetWidth = 138.5, getBoundingClientRect().width = 138.5 content 4 offsetWidth = 138.5, getBoundingClientRect().width = 138.5 Total calculated offsetWidth = 554 Total calculated getBoundingClientRect().width = 554 Actual container width = 554

Note the fractional values returned by offsetWidth and that all totals now match.

Summary

It is sometimes helpful (and, in rare cases, necessary) to be able to use the CSS-OM properties for pixel-perfect layout calculation. When using the CSS-OM, be aware of the whole-pixel-reporting characteristics of those APIs. When designing layouts either with CSS or the CSS-OM APIs, be sure to accommodate a few pixels of tolerance in order to ensure a more robust site across multiple browsers and/or devices.

—Travis Leithead, Program Manager, Internet Explorer

Editor's note: Updated to correct a few typographic errors.

HTML5 Love is in the Air!

ieblog — Tue, 14 Feb 2012 16:57:40 GMT

To help celebrate Valentine’s Day, we’re pleased to offer another new HTML5 experience that makes the most of your PC hardware and touch on Windows 8. Check out Love is in the Air and feel the warm embrace of hardware accelerated HTML5.

This experience brings together hardware-accelerated HTML5 canvas, SVG, CSS transforms & transitions, WOFF, audio, and more. On Windows Developer Preview with support for multi-touch in IE10, you can reach out and swipe to reveal a special message of love -or just use your mouse. If you think your browser can keep up, turn up the volume to 1000 floating hearts. Using another browser and not feeling the love? Try it with IE9 (or IE10) using the hardware acceleration built into the browser.

Click the image to feel the love

Demos like this are best when shared, so we made it easy for you to experience Love is in the Air and send a special message to your friends.

From the entire IE team, we want to share the love for HTML5 and wish you a Happy Valentine’s Day.

—Rob Mauceri, Group Program Manager, Internet Explorer

IE 9.0.5 Available via Windows Update

ieblog — Tue, 14 Feb 2012 16:00:00 GMT

The February 2012 Cumulative Security Update for Internet Explorer is now available via Windows Update. This security update resolves 5 privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user visits a specially crafted Web page using Internet Explorer. An attacker who successfully exploited any of these vulnerabilities could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less affected than users who operate with administrative user rights.

This security update is rated Critical for Internet Explorer Windows Clients, except IE6 client, where it is rated Moderate; and Moderate for Internet Explorer on Windows servers, except IE6, where it is not rated. For more information, see the full bulletin.

—Ceri Gallacher, Program Manager, Internet Explorer

CORS for XHR in IE10

ieblog — Fri, 10 Feb 2012 00:08:17 GMT

The fourth platform of IE10 simplifies building cross-site scenarios that work consistently across browsers by supporting Cross-Origin Resource Sharing (CORS) for XMLHttpRequest (XHR). CORS for XHR makes sharing data across sites simple and flexible. In the most basic scenario CORS enables creating data sources accessible from any site, and with a few small tweaks you can choose to constrain allowed sites, support data modification, and even allow authentication. Most importantly CORS keeps existing sites secure by requiring server participation.

Simple Cross-Origin XHR

Let’s look at how a cross-origin XHR request compares to a same-origin request. From script, the only difference is the URL passed to the open method. For example, say we’re working on a script that fetches a list of photo albums.

Traditional XHR


// Script running on http://photos.contoso.com
var xhr = new XMLHttpRequest();
xhr.onerror = _handleError;
xhr.onload = _handleLoad;
xhr.open("GET", "/albums", true);
xhr.send();

Now we want to access the list of albums from another origin. The other origin can be a completely different domain or a different host with the same base domain. Either way, just pointing at the full URL from another site is enough to get the browser to automatically send a CORS request.

CORS-Enabled XHR


// Script running on http://www.contoso.com
var xhr = new XMLHttpRequest();
xhr.onerror = _handleError;
xhr.onload = _handleLoad;
xhr.open("GET", "http://photos.contoso.com/albums", true);
xhr.send();

Sites can provide fallback for older browsers by wrapping this in feature detection. Checking for “withCredentials” is the best approach since it directly relates to CORS support for XHR.

CORS-Enabled XHR with Feature Detection


// Script running on http://www.contoso.com
var xhr = new XMLHttpRequest();
if ("withCredentials" in xhr) {
xhr.onerror = _handleError;
xhr.onload = _handleLoad;
xhr.open("GET", "http://photos.contoso.com/albums", true);
xhr.send();
} else {
// Fallback behavior for browsers without CORS for XHR
}

At this point our client code makes a CORS request directly to "http://photos.contoso.com", but the request fails to return any data. The failure occurs because the server isn’t participating yet. Taking a quick look at the developer tools gives us an idea what went wrong.

Here we can see the server needs to send an “Access-Control-Allow-Origin” header in the response. In our scenario we’re not opening up our albums for any site to access, but want to enable access solely from “http://www.contoso.com”. Doing this requires allowing the server to identify where the request originated. Examining our outgoing request reveals a new header containing precisely this information, “Origin”.

Simple CORS Request Headers


GET http://photos.contoso.com/albums HTTP/1.1
Origin: http://www.contoso.com
...

Using this information the server can choose to limit access to any set of sites. If the server always adds an “Access-Control-Allow-Origin” header with a value of '*' then all sites will have access. For our scenario, we’ll have the server verify the origin and then set “Access-Control-Allow-Origin” to allow only “http://www.contoso.com”.

Simple CORS Response Headers


HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.contoso.com
...

With the above updates in place, our “http://www.contoso.com” client can now access album lists from the server at “http://photos.contoso.com”.

Cross-Origin XHR with Preflight

The “simple” CORS requests discussed so far are great for basic, read-only scenarios, like downloading a photo album. Taking the next step by modifying data across sites requires a bit more work on the server. For example, say we’re adding code in the client to create a new album.


var xhr = new XMLHttpRequest();
xhr.onerror = _handleError;
xhr.onload = _handleLoad;
xhr.open("PUT", "http://photos.contoso.com/albums", true);
xhr.send(JSON.stringify({ name: "New Album" }));

Running this as-is doesn’t work. Examining the network traffic reveals a request is sent, but not the one we expected.

What the browser actually sent is known as a preflight request. Preflight requests are sent before requests that may result in data modification on the server. Such requests are identified by the presence of non-simple properties as defined in the CORS specification. These properties range from certain HTTP methods like “PUT” to custom HTTP headers. Browsers send preflight requests to ask the server for permission to send the actual request. In our example the browser is verifying a “PUT” request is allowed.

Preflight Request


OPTIONS http://photos.contoso.com/albums HTTP/1.1
Origin: http://www.contoso.com
Access-Control-Request-Method: PUT
...

Getting the browser to send the actual request requires some changes on the server. Once again we can take a look at the developer tools for more information.

The first step is to make the server recognize the “OPTIONS” preflight request as distinct from other requests for the same URL. After the server verifies the preflight request by ensuring “Access-Control-Request-Method” is asking for “PUT” from an allowed origin, it sends the appropriate approval via the “Access-Control-Allow-Methods” header.

Preflight Response


HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.contoso.com
Access-Control-Allow-Methods: PUT
...

Once preflight is out of the way and approved the actual request takes place.

Actual Request


PUT http://photos.contoso.com/albums HTTP/1.1
Origin: http://www.contoso.com
...

Adding the album is technically complete at this point, but our client code won’t know that unless the server responds correctly. Specifically the server must still include “Access-Control-Allow-Origin” in the response.

Actual Response


HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.contoso.com
...

With that the client can add a new album cross-origin and recognize whether or not the action completed successfully.

Next Steps

Pairing CORS with other new platform features enables interesting scenarios. One example is the Cross-Site Upload Test Drive which tracks cross-origin file uploads using CORS, XHR, FileAPI, and progress events.

—Tony Ross, Program Manager, Internet Explorer

High performance HTML5 content in Metro-style Apps

ieblog — Tue, 07 Feb 2012 22:33:04 GMT

Metro style apps in Windows 8 have all the performance benefits of IE10 when showing Web content. In Metro style apps, Web content is always JIT compiled and hardware-accelerated. Other platforms do not provide the same level of performance in apps. For example, Cocoa apps on iOS offer significantly worse JavaScript performance (via the UIWebView control) than the same content running in Safari. These Cocoa apps do not enjoy JIT compilation, and these apps cannot show and use Web content the same way the browser on the system can:

Testing configuration: http://www.webkit.org/perf/sunspider/sunspider.html.
iPad: 1st Gen, iOS 5.0.1.
Windows 8: Developer Preview, Dell Optiplex 745, 64-bit OS.
Kindle Fire v1.

Why is this important?

Many applications embed HTML to provide a richer and always up to date experience for consumers. For example, the developer of a restaurant guide app might want to include a live map showing the locations of the list of restaurants the user is choosing from. If you write an app on iOS, common actions like panning and zooming the map will run twice as slow in an app compared with Safari.

Anyone writing a Metro style app for Windows 8 can easily include Web content in their app. In an HTML or XAML app, just include an <iframe> element or a WebView control to get the full benefit of IE 10 performance. To see a sample HTML app that demonstrates this, check out the “Building Your First Metro Style App Using Javascript” hands-on lab at http://www.buildwindows.com/Labs.

Figure 1: HTML Content from Bing Maps in an HTML Metro Style App

With Metro style apps, it’s easy to integrate many existing Web services seamlessly into your app. It’s also possible to build new services for your app that let you deliver dynamic HTML content without having to update your application.

When you include Web content in your Metro style app, your app gets all the performance benefits of IE10 automatically without any additional or special work. JavaScript code continues to run fast with JIT compilation, and your app will automatically use GPU to accelerate HTML graphics.

—Andy Zeigler, Senior Program Manager, Internet Explorer

CSS3 3D Transforms in IE10

ieblog — Thu, 02 Feb 2012 18:07:08 GMT

CSS3 features make it easier to build rich and immersive Web experiences. A recent post described how Web developers add personality to their sites with CSS3 Transitions and Animations. CSS3 3D Transforms add another dimension (literally) for developers to enhance their sites. For example, the Windows 8 Metro style Start page uses subtle 3D transforms to highlight pressed tiles, as shown below.

Internet Explorer 10 tile shown not pressed (left) and pressed (right)

Adding a 3rd Dimension to CSS Transforms

Like CSS3 2D Transforms, 3D Transforms provides functions and values for the CSS transform and transform-origin properties that apply geometric transformations operations to HTML elements. CSS 3D Transforms extends the transforms functions to enable 3D transforms. The rotate(), scale(), translate(), skew(), and matrix() transform functions are expanded to encompass the 3D space with a z-coordinate parameter—or in the case of matrix3d(), an extra 10 parameters—and by spawning additional transform functions, for example, rotateZ() and scaleZ().

A new perspective transform function gives transformed elements depth by making distant points appear smaller.

CSS3 3D Transforms also adds a few new CSS properties. In addition to the transform and transform-origin properties, IE10 supports vendor-prefixed perspective, perspective-origin, backface-visibility, and the flat value of transform-style.

Note: The markup examples in this post all use unprefixed properties as defined in the W3C standard. However, at this time all browsers that implement these features do so with vendor-specific prefixes. Please remember to add your browser’s prefix to the example markup when experimenting.

Perspective

The perspective transform function is important for 3D transforms. It sets the viewer’s position and maps the viewable content onto a viewing pyramid, which it subsequently projects onto a 2D viewing plane. Without specifying perspective, all points in z-space are flattened onto the same 2D plane and there is no perception of depth in the resulting transform. For some transforms, such as the translation along the Z-axis shown below, the perspective transform function is essential for visibly seeing any effect from the transform.

In the examples below is the original, untransformed element and is the transformed element


`transform: perspective(500px) translate(0px, 0px, -300px);`		`transform: translate(0px, 0px, -300px);`


`transform: perspective(500px) rotateY(30deg);`		`transform: rotateY(30deg);`

A shortcut for adding the perspective transform to several elements is to use the perspective property on their parent element(s). The perspective property applies the perspective transform to each of its child elements:


#parent {
perspective: 500px;
}
 
#div1 {
position: absolute;
transform-origin: 0px 0px;
transform: rotateY(30deg);
}
 
#div2 {
position: absolute;
transform-origin: 0px 0px;
transform: rotateY(30deg) translate(220px);
}

The perspective-origin property can also be used in conjunction with perspective to shift the viewpoint away from the center of the element:

Below, you can see that shifting the perspective origin to the left makes the content to the right of the original perspective origin appear farther away.


#parent {
perspective: 500px;
perspective-origin: -300px 0px;
}

backface-visibility

The backface-visibility property is useful for hiding the backface of content. By default, the backface is visible and the transformed content can be seen even when flipped. But when backface-visibility is set to hidden, content is hidden when the element is rotated such that the front side is no longer visible. This can be useful if you want to simulate an object with multiple sides, such as the card used in the example below. By setting backface-visibility to hidden, it’s easy to ensure that only the front-facing sides are visible.

CSS markup:


.card, .card div {
position: absolute;
width: 102px;
height: 143px;
}
 
.card div:nth-child(1) {
background-image: url('redback.png');
}
 
.card div:nth-child(2) {
background-image: url('8clubs.png');
backface-visibility: hidden;
}

HTML markup for one card:


<div class="card"><div></div><div></div></div>

Creating six cards as defined above and giving each a style="transform: rotateY(ndeg)" property with a different rotation value n, results in this:


rotateY(0deg);	rotateY(36deg);	rotateY(72deg);	rotateY(108deg);	rotateY(144deg);	rotateY(180deg);

What’s happening in this example is that when there’s no rotation, you see the second div, the 8 of clubs—because it’s the one on top in drawing order. As we apply a rotation to the card and pass 90 degrees, the backface-visibility: hidden; property of the second div causes it to become invisible thereby exposing the first div, the card back.

3D Transforms with Animations and Transitions

Best of all, you can even use 3D transforms in conjunction with CSS transitions and animations. If you are using IE10 or another browser that supports CSS3 Animations of CSS3 3D Transforms, try this example of scrolling text, built by animating the transform property.

This is the CSS markup that achieves the effect shown in screen shots below.


#parentDiv {
perspective: 500px;
perspective-origin: 150px 500px;
}
 
#div1 {
transform-origin: 150px 500px;
animation: scrollText 200s linear infinite;
}
 
@keyframes scrollText {
0% { transform: rotateX(45deg) translateY(500px); }
100% { transform: rotateX(45deg) translateY(-8300px); }
}

Try It Today

Try this out in IE10 on the Windows Developer Preview. The test drive demo Hands On: 3D Transforms can help visualize the possibilities that CSS 3D Transforms enables.

We’d love to see your creations!

—Jennifer Yu, Program Manager, Internet Explorer Graphics

Web Sites and a Plug-in Free Web

ieblog — Tue, 31 Jan 2012 17:12:23 GMT

The transition to a plug-in free Web is happening today. Any site that uses plug-ins needs to understand what their customers experience when browsing plug-in free. Lots of Web browsing today happens on devices that simply don’t support plug-ins. Even browsers that do support plug-ins offer many ways to run plug-in free.

Metro style IE runs plug-in free to improve battery life as well as security, reliability, and privacy for consumers. Previously, we wrote about how we use IE’s Compatibility View List to make sure sites that have a plug-in free experience for other browsers provide that same experience to IE10 users. This post describes a way for sites that continue to rely on plug-ins to provide consumers browsing with Metro style IE the best possible experience.

Developers with sites that need plug-ins can use an HTTP header or meta tag to signal Metro style Internet Explorer to prompt the user.

HTTP Header


    
        X-UA-Compatible: requiresActiveX=true

META Tag


    
        <meta
            http-equiv="X-UA-Compatible"
            content="requiresActiveX=true"
            />

Metro style IE10 detects these flags, and provides the consumer a one-touch option to switch to IE10 on the desktop:

In addition to respecting these X-UA-Compatible flags specified by the developer, the Compatibility View List can also specify a site that needs to run in the desktop.

This mechanism provides a short-term mitigation. The desktop browsing experience and most plug-ins were not designed for smaller screens, battery constraints, and no mouse. Providing an easy way to the Windows desktop is the last resort when no comparable plug-in free fallback content exists.

A plug-in free Web benefits consumers and developers and we all take part in the transition. IE10 makes it easy to provide the best possible experience while you migrate your site.

—John Hrvatin, Program Manager Lead, Internet Explorer