IE 9.0.10 Available via Windows Update

Today we released Security Update MS12-063 to address limited attacks against a small number of computers through a vulnerability in Internet Explorer versions 9 and earlier. We also released an update that addresses vulnerabilities in Adobe Flash Player in Internet Explorer 10 on Windows 8. The majority of customers have automatic updates enabled and will not need to take any action because protections will be downloaded and installed automatically. For those manually updating, we encourage you to apply this update as quickly as possible.

Microsoft Security Bulletin MS12-063

This security update resolves one publicly disclosed and four privately reported vulnerabilities in Internet Explorer. The most severe vulnerabilities could allow remote code execution if a user views 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 current user. Users whose accounts are configured to have fewer user rights on the system could be less impacted 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. Internet Explorer 10 is not affected. For more information about the vulnerabilities, see the full bulletin. This security update also addresses the vulnerability first described in Microsoft Security Advisory 2757760.

Recommendation. Most customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871. For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using theMicrosoft Update service.

Microsoft Security Advisory (2755801)

Microsoft is announcing the availability of an update for Adobe Flash Player in Internet Explorer 10 on all supported editions of Windows 8 and Windows Server 2012. The update addresses the vulnerabilities in Adobe Flash Player by updating the affected Adobe Flash libraries contained within Internet Explorer 10. For more information, see the advisory.

—Tyson Storey, Program Manager, Internet Explorer

Towards Interoperable Pointer Events: Evolving Input Events for Multiple Devices

Today, the W3C has accepted and published Microsoft’s member submission describing a new way for Web sites to support multiple pointing devices such as mouse, pen, and multi-touch. Our proposal for a new Pointer Events Web standard is based on the APIs available today in IE10 on Windows 8.

The Web is more exciting and interactive for users when sites enable experiences for multi-touch. It is even better when the same site continues to work if you switch to using a mouse or pen. We believe the Web should not be fragmented into sites designed for only one type of input. We designed Pointer Events to make it easier for developers to avoid this fragmentation by abstracting the differences of input devices while still allowing for device-specific enhancements when desired.

Our goal with this submission is to work with other browser vendors and the wider Web community to move to adopt a new approach to multi-touch input. In the future, we hope that Web developers will only need to write to one pointer input model no matter if their users are using mouse, pen, touch, or whatever comes next. The W3C noted, “This Submission comes at a time of significant developer concern about creating content that works well on multiple input modalities, and in light of some disadvantages to the touch event model currently under standardization.”

Other approaches to supporting multi-touch input require Web developers to write their code once for mouse input and again for touch, dealing with the sometimes complex interactions between the two models (for example, when touch events are mapped to mouse events for compatibility). Throughout the development of IE10, and thanks to your feedback, we designed the Pointer Events model to be more compatible with the existing Web and avoid these complexities.

We encourage you to review the proposal and share your thoughts. The specification is a starting point and calls out several open issues for discussion and we look forward to making improvements based on your feedback.

—Adrian Bateman and Jacob Rossi, Program Managers, Internet Explorer

XSS Trends and Internet Explorer

As far back as 2005, cross-site scripting (XSS) was recognized as the most commonly reported type of software vulnerability. A more recent study by Veracode using data from the Web Hacking Incident Databaseshows that XSS is the most prevalent vulnerability in Web applications and the second most likely to beleveraged in real-world attacks.

Chart courtesy of Veracode; used by permission

Data from the Microsoft Security Response Center (MSRC) demonstrates the growth in reported XSS vulnerabilities:

Growth in reported XSS vulnerabilities 2004 – 2012 (first half)

The chart above illustrates how we are seeing XSS actually start to crowd out other types of reported vulnerabilities percentage-wise, year-over-year.

To help protect users, Internet Explorer pioneered the implementation of multiple overlapping mitigations targeting XSS, including httpOnly cookies, security=restricted IFRAMES, toStaticHTML(), and the IE XSS Filter. IE10 introduces support for the new HTML5 standard IFRAME Sandbox, which allows developers of Web applications to more tightly control the behavior of embedded content. We’re intent on continuing these investments, as real-world data continues to show an uptick in the relative quantity of XSS vulnerabilities in the wild.

To review the impact of the IE XSS Filter, we’ve done a deep analysis of all vulnerabilities reported to MSRC in the first half of 2012. This analysis has shown that currently the IE XSS Filter applies for 37% of all legitimate vulnerabilities that are reported to the MSRC. (For some perspective, another highly reported vulnerability class is memory safety, accounting for 24% of vulnerabilities within the same data set.)

The IE XSS Filter is just one example of how our browser’s threat-mitigation strategy doesn’t stop with memory safety mitigations like ASLR and DEP/NX. As more customers and businesses leverage Web technologies, mitigating XSS and other Web application vulnerabilities has become increasingly important. We are happy to see the impact mitigations have made against the threat of XSS, and are looking to continuously innovate in this space going forward.

—David Ross, Principal Security Software Engineer, Microsoft Security Response Center

Optical Zooming in Legacy Document Modes

Internet Explorer 9 introduced sub-pixel font positioning as part of its hardware-accelerated rendering of HTML5 content as described in this IEBlog post. That was an important step into the future as it enabled zoom-independent text metrics—an important characteristic when pinch-zoom is part of the browsing experience as it is in IE10 on Windows 8 touch-enabled devices.

As noted in that post 18 months ago, IE9’s legacy compatibility modes use whole-pixel text metrics. This compatibility-driven decision continues in IE10 with IE5 quirks, IE7 standards, and IE8 standards modes all running with whole-pixel font metrics; IE10 document modes Standards, Quirks, and IE9 Standards all use sub-pixel text metrics.

As a result, the text in sites running in legacy document modes 5, 7, and 8 does not scale smoothly when the page is zoomed by pinch-zoom, double-tap zoom, or when the page is auto-zoomed for display in Windows 8’s snap and fill views.

Zoom Example: Legacy vs. Standards Modes

Below are side-by-side comparisons showing text from a popular news site in 8 and 10 document modes at 100% and 150%. Note the especially poor letter spacing between some letters in the 150% 8 mode example (upper right).

	Default size (100%)	Optically zoomed to 150%
8
10

Move to Standards Today

The best fix for this behavior is to move your pages to IE9 or IE10 Standards mode. IE10 Compat Inspector is a valuable tool to help you migrate to IE9 or IE10 mode. Compat Inspector identifies potential issues and offers steps you can take to resolve them. In general, the HTML, CSS, and JavaScript markup and code you use with other browsers will work great in IE10 once any browser detection is replaced with feature detection and vendor-specific CSS prefixes are updated to include -ms- or unprefixed versions. Modernizr is a JavaScript library that can help with these issues.

Specifying Sub-pixel Metrics in Legacy Modes

If moving to standards-based markup is out-of-scope for your site at this time, you may enable sub-pixel text metrics in legacy document modes using an HTTP header or  tag. Based on our testing, most sites will work fine with natural text metrics.

The format of the HTTP header is:

X-UA-TextLayoutMetrics: Natural

The syntax of the  tag is:

<meta http-equiv="X-UA-TextLayoutMetrics" content="natural" />

Support for this HTTP header and  tag are new in the final release version of IE10 on Windows 8.

To improve the Windows 8 out-of-box experience for touch-enabled devices, we’ve added a section to the IE10 Compatibility View List that enables natural metrics for approximately 570 popular sites that currently run in legacy document modes. If your site is included on the listbut you would prefer it not be, email iepo@microsoft.com. Include your name, company, title, and contact information along with the domain you want removed.

Be Ready for IE10

Move your legacy document mode site to IE9’s default standards mode today and be ready for IE10 tomorrow. Visitors to your site using IE10 on Windows 8 will thank you.

—Ted Johnson, Program Manager Lead for Web Graphics

Exploring Device Orientation and Motion

Today, we released a prototype implementation of the W3C DeviceOrientation Event Specification draft onHTML5Labs.com. This specification defines new DOM events that provide information about the physical orientation and motion of a device. Such APIs will let Web developers easily deliver advanced Web user experiences leveraging modern devices' sensors.

How This Helps Developers

With the Device Orientation API, developers can explore new input mechanisms for games, new gestures for apps (such as “shake to clear the screen” or “tilt to zoom”) or even augmented reality experiences. The prototype’s installation includes a sample game to get you started in understanding the API.

Video showing the concepts explained in this post in action

How This Works

The Device Orientation API exposes two different types of sensor data: orientation and motion.

When the physical orientation of the device is changed (e.g. the user tilts or rotates it), the deviceorientationevent is fired at the window and supplies the alpha, beta, and gamma angles of rotation (expressed in degrees):

<div id="directions"></div>

<script>

window.addEventListener("deviceorientation", findNorth);

function findNorth(evt) {

var directions = document.getElementById("directions");

if (evt.alpha < 5 || evt.alpha > 355) {

directions.innerHTML = "North!";

} else if (evt.alpha < 180) {

directions.innerHTML = "Turn Left";

} else {

directions.innerHTML = "Turn Right";

}

}

</script>

When a device is being moved or rotated (more accurately, accelerated), the devicemotion event is fired at the window and provides acceleration (both with and without the effects of gravitational acceleration on the device, expressed in m/s²) in the x, y, and z axis as well as the rate of change in the alpha, beta, and gamma rotation angles (expressed in deg/s):

<div id="status"></div>

<script>

window.addEventListener("devicemotion", detectShake);

function detectShake(evt) {

var status = document.getElementById("status");

var accl = evt.acceleration;

if (accl.x > 1.5 || accl.y > 1.5 || accl.z > 1.5) {

status.innerHTML = "EARTHQUAKE!!!";

} else {

status.innerHTML = "All systems go!";

}

}

</script>

Trying Out The Prototype

You can download the prototype at HTML5Labs. This prototype requires Internet Explorer 10 running on devices with accelerometer sensors supported by Windows 8. The prototype works as an extension to Internet Explorer on the desktop, where developers can get a first-hand look at the APIs. To get started building your own pages with the prototype, all you need to do is install the prototype and then include a reference to the DeviceOrientation.js script file (copied to the desktop after installing the prototype):

<script type="text/javascript" src="DeviceOrientation.js"></script>

We Want Your Feedback

We want to hear from developers on this prototype implementation of the W3C Device Orientation Event Specification, so please let us know what you think by commenting on this post or sending us a message.

—Abu Obeida Bakhach, Program Manager, Microsoft Open Technologies Inc.
Jacob Rossi, Program Manager, Internet Explorer