вторник, 28 августа 2012 г.

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 smoothlywhen 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%
8Sample text in IE8 mode at 100%Sample text in IE8 mode using GDI-compatible font metrics at optical zoom 150%
10Sample text in IE10 mode at 100%Sample text in IE10 mode using sub-pixel font metrics at optical zoom 150%

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 list but 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

понедельник, 20 августа 2012 г.

IE9’s faster, more capable Compatibility View List


We have talked about our goal with IE9 to run the same standards-based markup as other browsers by default. It is also our goal for IE9 to successfully run the Web that you browse today. For sites that are designed to run in older versions of IE, IE9 includes support for compatible document modes and a Compatibility View (CV) Listthat’s similar to what shipped with IE8.
The CV List and compatible document modes are good for site developers because they enable developers to transition between IE8 and IE9 on their own schedule. We only add a site to the CV List when the site is designed to run in an older version of IE, doesn’t run well in IE9’s Standards mode, and doesn’t declare an X-UA-Compatible meta tag or header. The CV List is good for users because it means that IE9 works great with popular sites the day they upgrade and without users having to click on the Compat View button.
We want the CV List to be as small as possible when IE9 ships and to get smaller over time because more and more of the web works well in IE9 by default. This is good for users and site developers. To achieve this, we want sites to update now to work well in IE9’s Standards mode and serve the same markup they use with other browsers. At a minimum, sites should take advantage of the IE7 or IE8 document mode by declaring an X-UA-Compatible value until they can update.
The IE9 Beta CV List currently has just over one thousand sites listed. This is a third of the size of IE8’s CV List, which originally shipped with 3122 sites listed.
The IE9 CV List is capable of customizing how each website runs. 
We want as many sites as possible to render in IE9’s Standards mode so that they can take advantage of HTML5 capabilities and performance improvements. Today many sites use browser detection instead of feature and behavior detection to give IE different markup that is not interoperable with IE9’s Standards mode or other browsers. This can result in major functionality breaks on sites rendered in IE9’s Standards mode.
For example, IE9’s Standards mode strictly follows the createElement() DOM standard to be interoperable with other browsers. A simple test for this behavior is even part of Test 22 of Acid 3, which checks that browsers throw an INVALID_CHARACTER_ERR exception when a webpage tries to pass invalid characters into createElement().
    function () {
      // test 22: createElement() with invalid tag names
      var test = function (name) {
        var result;
        try {
          var div = document.createElement(name);
        } catch (e) {
          result = e;
        }
        assert(result, "no exception for createElement('" + name + "')");
        assertEquals(result.code, 5, "wrong exception for createElement('" + name + "')"); // INVALID_CHARACTER_ERR
      }
      test('
'
); test('0div'); test('di v'); test('di); test('-div'); test('.div'); return 2; }
Passing this Acid3 test and being interoperable unfortunately leads to breaking sites with IE-specific code in IE9’s Standards mode. For example, the page header and menus aren’t displayed on verizonwireless.com in IE9’s Standards mode because it relies on IE8’s more lenient behavior for createElement(), which accepts valid HTML in addition to specific element names.
To keep sites working well in IE9’s Standards mode instead of reverting to IE8 or IE7 Document modes, the IE9 CV List includes a new capability called a “featureSwitch.” This makes specific APIs in IE9’s Standards mode behave as they do in previous IE versions.
For example, the IE9 CV List has a “featureSwitch” called “createElementWithMarkup.” This re-enables IE8’s more lenient behavior for createElement() in IE9’s Standards mode, but only for specific sites on the CV List.
verizonwireless.com
We intend to remove feature switches as soon as sites update themselves to use the same markup across browsers. We reserve feature switches for specific, high-impact changes that we’ve found through testing to affect many web sites. We won’t create feature switches for every change in behavior and sites cannot opt-in to them. Instead, sites should opt-in to the IE7 or IE8 Document Mode through the X-UA-Compatible meta tag or header to get compatible until they can update to IE9’s Standards mode.
Sometimes Conditional Comments are used to make webpages work in IE6 and IE7. In IE9’s Standards mode, a site doesn’t need them. The IE9 CV List can make Conditional Comments targeted at old versions of IE work in IE9 Mode or turn them off for a site. This is a temporary solution until the site developer has a chance to make updates to stop using them in IE9’s Standards mode. In addition to featureSwitches and the ability to turn off Conditional Comments, the IE9 CV List can put sites in Compat View, just like the IE8 CV List did. The IE9 CV List can also change the Document Mode that a site renders in to IE7 or IE8.
We’ve updated how we populate the CV List to avoid putting websites on it that don’t need it. 
Different from IE8, before adding a site to the IE9 CV List we verify that it is incompatible with IE9. We also verify what Document Mode it works best in. This will help us make sure that we ship with the smallest CV List possible at Beta, RC and RTM.
The CV List continues to be community-data-driven. For the IE9 Beta CV List, we use data from site compat testing and internal usage to determine what sites go on the list. For the RC and RTM CV Lists, we’ll rely more on data from Beta and RC selfhosters.
Process to populate the Compatibility View list. The IE team collects URLs that users click the CV Button on. Test confirms that a site needs to be on the CV list and IE authors and publishes the CV list based on this.
The IE9 CV List is quickly and simply deployed as a webpage.
We just shipped a CV List update to IE9 Beta and it only took a few minutes to ship. We added sites including ted.com, mkb.hu, and hoyts.com.au based on IE9 Beta customer response. The IE9 CV List is an XML file on Microsoft.com. We can update the list daily through this mechanism, which means we can quickly accommodate site developer requests to remove updated sites.
Another benefit of deploying the CV List as a webpage is that users automatically get updates instead of having to download the optional IE8 CV List packages from Windows Update or Download Center (users can opt-out just as easily as IE8 too).
You will be able to view the IE9 Beta CV List on your local machine by navigating to this file path:
File:\\%LOCALAPPDATA%\Microsoft\Internet Explorer\IECompatData\iecompatdata.xml
The server version, which is used to ship updates to IE9 is located here.
Ask to site developers
While verifying that your site works well in IE9 Beta, please check to see if it is on the IE9 Beta CV List here. If it is on the list, uncheck “Include updated website lists from Microsoft” in the Compatibility View Settings (Alt –> Tools --> Compatibility View Settings).
Compatibility View Settings dialog box with 'Include updated website lists from Microsoft' checked
Use IE9’s improved Developer Tools to resolve compatibility issues. Lastly, please email iepo@microsoft.comwith the information at the bottom of this webpage and ask to be removed from the IE9 CV List when your updates are live on the web. This will help make sure users have an amazing experience when they install IE9 and browse to your site.
Thanks,
Marc Silbey
Program Manager

Add-ons: Detecting and Displaying Add-on Version Numbers


In the past months we worked with add-on developers to release new versions of their add-ons that follow IE’sguidelines and requirements for add-on development. We used the Upgrade Advisor to help update their users to the new versions. Some add-on vendors asked how IE determines and displays an add-on’s version. This post answers this question so that all add-on developers can design their versioning schemes to be compatible with IE features such as Manage Add-ons and the Upgrade Advisor.
There are two fields denoting the version of a binary file in Windows: file version and product version. Since IE add-ons are dynamic link library (DLL) files loaded into the browser, each add-on contains both of these version numbers. Here’s a screenshot of the properties dialog for one of our sample toolbars. Though the file version and product version are separate fields, they typically contain the same version string:

The file version and the product version of the Contoso Toolbar can be seen in the DLL file’s Properties window
IE displays the add-on DLL’s product version in Manage Add-ons. This is also the version that IE checks when determining whether the Upgrade Advisor dialog needs to be displayed for the add-on. IE looks directly into the DLL’s properties to extract the product version each time, and does not store the version in the registry. This design prevents incompatibilities when an add-on is auto-updated to a newer version.
We recommend add-on developers to update both version fields at the same time for consistency. It’s important to update the right version. For example, an error may result in the Upgrade Advisor dialog showing up for the wrong version of an add-on or the user believing that they have an older version of an add-on installed when looking at Manage Add-ons.
Thanks again to add-on developers for providing feedback and submitting questions. We wanted to answer this particular question as a blog post so that all developers have access to the information. We look forward to continue working with add-on developers in the coming months.
Herman Ng
Program Manager

Full-page Animations Using CSS


Internet Explorer 9 introduced support for CSS 2D Transforms. Internet Explorer 10 Developer Preview added support for CSS 3D Transforms and CSS Animations. By tapping the power of your GPU and running asynchronously from regular JavaScript, these IE10 features provide a more performant and flexible alternative to traditional script-based animations for Web content.
In previous blog posts, we covered CSS 3D Transforms as well as CSS Animations and Transitions. In this post, we introduce a more “unconventional” use case for these technologies by describing the concept of “full-page animations” that can be used during the navigation process to add fluidity and continuity to browsing. Our target is to achieve a seamless browsing experience in which content smoothly appears into view when the user visits a page and transitions away when he clicks on a link or performs a relevant action.
These effects can be accomplished by transforming the HTML  element using CSS Animations. However, this use case presents some considerations that we felt were worthy of discussion, such as the effect of layout and sizing on transforming , as well as how to appropriately time page navigations so that they mesh properly with our animations.
The code samples in this post use unprefixed CSS markup as supported by IE10 Release Preview; other browsers may require vendor prefixes for the CSS Animations and CSS Transforms properties used.

Transforming a Page’s Entire Content

CSS Transforms are defined on the stylistic properties of an HTML DOM Element. For example, the markup for rotating an element 45 degrees along its Z axis would look like this:
#element {
transformrotateZ(45deg);
}
Attaching a transform to the  element of your HTML document works exactly the same way. So performing in order to declaratively add the same effect to your document’s  you could do something like this:
body {
transformrotateZ(45deg);
}
Let’s look at a before-and-after shot of a page when applying a transform to the body element:
Screen shot showing applying a rotateZ(45deg) transform to the body element of a document
Applying a rotateZ(45deg) transform to the body element of a document.
For three dimensional transformations, the CSS Transforms specification defines the perspective property that can be specified on the parent of the element that we transforming. When transforming the  element of your content, it has to be applied to the  element that resides above it in the DOM hierarchy. Doing so is straightforward:
html {
perspective500px;
}
Combining this with a rotateY(45deg) transform on the  element yields the following result:
Screen shot showing applying a rotateY(45deg) transform to <body> with perspective: 500px set on <html>
Applying a rotate(45deg) transform to with perspective: 500px set on .
We can manipulate the transform-origin property on the body element for interesting results. Let’s look at a couple of examples:
body {
transform-origin50% 100%;
transformrotateX(45deg);
}
The above markup sets a rotation along X for the body element while shifting the origin of rotations to the bottom of the element using transform-origin. Effectively this rotates the document’s contents “into” the screen like this:
Screen shot showing applying transform: rotateX(45deg) and transform-origin:  50% 100% to <body>
We can also manipulate the perspective-origin property on the root element of our document to achieve an off-axis projection effect. Changing the style for  to:
html {
perspective500px;
perspective-origin90% 50%;
}
Our page now looks like this:
Screen shot showing applying perspective: 500px and perspective-origin: 90% 50% to the <html> element
By using CSS Transforms, we can easily manipulate the visual appearance of the entirety of our page’s content. Since the usual layout and sizing rules still apply, some transforms on the body element (particularly ones that use percentage values or rely on the transform-origin property) can result in different visual effects depending on the content of our page. Recall our previous rotateX(45deg) example with transform-originset to 50% 100%.
Below you can see the results before and after the transform is applied.
Screen shot highlighting the difference in scroll bars before and after the application of a transform under perspective projection
Notice how the content does not actually pivot on the bottom of the window but rather at some point outside of the viewport. This is expected behavior for CSS Transforms: the  is laid out normally, then it is rotated along its bottom edge that is somewhere off screen. You will also notice that the actual foot print of the content has expanded (take a look at the scroll bars in the “after” picture) in order to accommodate the transformed content (the fact that we are using perspective projection makes this effect even more pronounced).
So how do we deal with arbitrarily sized content when applying transforms to our body element? Custom tailoring all content in order to ensure that the size of the body does not expand more than a certain amount may be unrealistic. Instead, we can use a simple HTML/CSS pattern that allows us to fix the size of the body element to that of the browser window and append content inside a wrapper 
. The following markup achieves just that:
htmlbody {
width100%;
height100%;
min-width100%;
max-width100%;
padding0;
margin0;
overflowhidden;
}

#Wrapper {
positionabsolute;
width100%;
height100%;
overflowscroll;
}
The illustration below shows what happens when a page is scrolled vertically and we apply a rotateY(45deg)transform to the  element of our document directly (left) and using the wrapper pattern (right):
Screen shot showing what happens when a page is scrolled vertically and a rotateY(45deg) transform is applied to the <body> element under perspective projection, with and without a wrapper CSS/HTML pattern
The direct application of the transform results in a skewed visual result due to the off-axis projection (since we are no longer looking at the “center” of the body element). Using the wrapper pattern ensures that the element’s perspective-origin property (50% 50% by default) will always be correctly centered with relation to the  element, giving us a pleasant visual effect.
By utilizing the above pattern and setting up CSS Transforms with percentage values whenever possible, we can affect our  element in consistent ways, regardless of the size of its contents.

From Transforms to Animations

Having sorted out the intricacies of applying CSS Transforms to the  element, CSS Animations are the next step. By following the principles described above, we can create animations that bring our Web content into view (or remove it from view) in interesting ways.
Consider this basic @keyframes rule:
@keyframes rotateInLeft {
from {
transform-origin0% 0%;
transformrotateY(180deg);
}
to {
transform-origin0% 0%;
transformrotateY(0deg);
}
}
When applied to an element, this animation will cause it to rotate on its left side. When applied to a element that uses our wrapper pattern the visual result is more interesting. The document will actually rotate from outside of the visible area of the browser window and into full view:
Three screen shots in sequence showing the affect of applying the "rotateInLeft" animation
Similarly, we can compose animations that fluidly remove our Web content from view. For example, if we wanted our page to disappear into the distance while rotating, we could use something like this:
@keyframes whirlOut {
to {
transformscale(0) rotateZ(1260deg);
}
}
With the visual result being:
Three screen shots in sequence showing the affect of applying the "whirlOut" animation
Since we can use the full power of CSS Animations to affect the entirety of our Web content, we have a lot of flexibility in terms of generating these page effects (and we are certainly not limited to just using CSS Transforms). But once we have composed the effects that we want to apply to our content, how do we cause them to trigger during the page navigation process?

Attaching Animations to

Our goal is to use trigger animations at strategic times during the browser experience in order to give the appearance of content transitioning into view when a page loads and out of view when the user clicks on a link.
The first intuitive place to add an animation to the body element would be the onload JavaScript event. As it turns out however, adding an animation when onload fires is actually too late. This event actually triggers when the entirety of the content in our page has finished loading (including any images or other bandwidth-intensive resources). Attaching an animation to onload on a bandwidth-intensive page would result in our content displaying “normally,” followed by the animation triggering and re-bringing the content into view. Not exactly the effect that we were aiming for.
Alternatively, we could utilize the DOMContentLoaded event that triggers when the browser has finished parsing the DOM structure of our content (but potentially before resources have finished loading). The IE Test DriveDOMContentLoaded demo illustrates the difference between these two events. However, in cases of complex Web content, a modern browser may choose to perform “progressive” rendering, displaying the page before the entirety of the DOM tree has been loaded. In these situations, the visual result would be similar to theonload scenario.
The optimal place to set up an animation that transitions our page content in view is inline at the top of the element. This ensures that the animation will commence right as the content is being rendered (and that the starting position of the content will be that of the from keyframe of our selected animation). A pleasant side effect of this approach is that the animation may actually mask any progressive rendering, re-layout or resource loading that can occur with complex content.
Setting up the animations that transition our content out of view is also interesting. One could assume that we could attach an onclick handler to all elements of interest in our content (for instance all  tags) and just set the relevant animation properties (animation-nameanimation-duration, etc.) in the callback function. However, if we do not actually delay the navigation from happening, we will not see our expected fluid transition.
This is a good opportunity to utilize the animation events described in the CSS Animations specification. In particular, we can use the animationend event to detect when the animation has completed and then trigger a navigation (by setting window.location.href, for instance). Thus our onclick will trigger the “remove-from-view” animation and register a handler for animationend on  that will ensure that the navigation event occurs.

Live Demo Available

We’ve created a demonstration and tutorial on bringing pages alive with CSS Transforms & Animations that provide depth and examples beyond what we’ve been able to show here. The tutorial itself utilizes full page animations during page navigation that work in Internet Explorer 10 on Windows 8 as well as recent versions of Chrome and Firefox..
To simply enjoy the page-to-page animations, step through the pages of the tutorial using the “Continue to ...” links in the lower right corner of each page.
At the end of the tutorial we provide some additional guidance and sample code on how to incorporate these animations with your own Web content.

Conclusion

CSS Transforms and CSS Animations are two powerful feature-sets that enable richer and more immersive Web experiences. This blog post outlined the considerations of using CSS Transforms and CSS Animations to bring the entirety of your Web content to life. With a small amount of effort you can create Web pages (even static ones) that provide a fluid and almost app-like navigation experience.
—Charilaos “Harris” Papadopoulos, Program Manager Intern, Internet Explorer Graphics

среда, 15 августа 2012 г.

Microsoft SmartScreen & Extended Validation (EV) Code Signing Certificates


Today two Certificate Authorities (CAs), Symantec and DigiCert, announced the introduction of EV code signing certificates. Their announcement is a positive development for users and businesses because it helps both sides reduce fraud and increase trust. We want to provide some more details about what this means for Microsoft’s SmartScreen and the Windows 8 application ecosystem in general.

Windows Store & Windows 8 Apps

The introduction of the Windows Store and Windows 8 Applications will be a significant opportunity for developers to distribute and monetize their applications. Windows 8 Applications are required to pass the Windows Store developer onboarding and application review process. This process is designed to give users confidence in the safety of their purchase while also making the install process as frictionless as possible. Windows 8 applications are not in scope for SmartScreen Application Reputation checks or warnings – these apps are reviewed, code signed, licensed & distributed by the Windows store directly.

Desktop Apps

Desktop applications remain an important part of the Windows experience and Microsoft remains committed to the safety of the desktop experience and our users. We recognize that Internet Explorer (IE) isn’t the only way users download applications from the Internet, so Windows 8 now uses SmartScreen to perform an application reputation check the first time users launch applications that were downloaded from the Internet.
This evolution of SmartScreen from IE-only to system wide is a significant improvement for Windows users. We have seen incredible results with this feature in IE9 (more here & here). Hundreds of millions of users have avoided malware infections due to these new experiences and we’re happy to bring this protection to Windows users, regardless of browser choice. For more details on the IE9 application reputation feature and the data models read this post. For more information on security & safety features in Windows 8 (including Windows SmartScreen) read this post.
The deeper integration of SmartScreen Application Reputation also means that desktop app developers have an additional motivation to sign their code and establish reputation. We’ve talked in the past about the importance of digitally signing code for both establishing reputation and proving the authenticity of programs. I’m happy to say the development community has responded to this call to action. Since the release of SmartScreen Application Reputation in IE9 we’ve seen a 10% global increase in signed downloads, from 73% at IE9 RTM to >83% today.
As we’ve discussed in the past, SmartScreen builds reputation for both individual programs and for the certificate used to sign that code. Code signing is important to our reputation intelligence because this higher level identity allows us to build reputation across multiple programs signed by a publisher. It is also important for publishers because signed programs inherit the reputation of the certificate with which they are signed; this means every program a publisher distributes doesn’t need to build reputation individually.

EV Code Signing

Today we are announcing our support for an important advance in code signing - the availability of EV code signing Certificates. We’re also announcing that EV code signing certificates will integrate with the SmartScreen Application Reputation technology in Internet Explorer 9, Internet Explorer 10 and in Windows 8.
Microsoft has been working with the CA industry over the past year to help make EV code signing certificates available. This code signing standard has a couple of key advancements from a safety and identity perspective. First, they require a more rigorous vetting and authentication process similar to that of EV SSL certificates that are in use today. This process requires a comprehensive identity verification and authentication process for each developer. Secondly, the EV code signing certificates require the use of hardware to sign applications. This hardware requirement is an additional protection against theft or unintended use of a code signing certificate.
Programs signed by an EV code signing certificate can immediately establish reputation with SmartScreen reputation services even if no prior reputation exists for that file or publisher. Other factors are considered when generating reputation and determining product experiences and EV-signed programs will be closely monitored over time. We think the improvements in the vetting and security of these certificates are a great development for both users and developers.
Starting today, EV code signing certificates are now being issued by Symantec and DigiCert, and the integration with SmartScreen is already live (IE9, IE10 & Win8).
Detractors may claim that SmartScreen is “forcing” developers to spend money on certificates. It should be stressed that EV code signing certificates are not required to build or maintain reputation with SmartScreen. Files signed with standard code signing certificates and even unsigned files continue to build reputation as they have since Application Reputation was introduced in IE9 last year. However, the presence of an EV code signing certificate is a strong indicator that the file was signed by an entity that has passed a rigorous validation process and was signed with hardware which allows our systems to establish reputation for that entity more quickly than unsigned or non-EV code signed programs.

Best Practices

Developers should still follow the best practices we’ve suggested in past blog posts. We have added to that guidance the additional options of distributing apps thru the Windows Store and the option of EV code signing:
  • Distribute your apps through the Windows StoreWindows 8 Applications are required to pass the Windows Store developer onboarding and application review process. Windows 8 applications are not in scope for SmartScreen application reputation checks or warnings in Windows 8.
  • Digitally sign your programs (Standard or EV code signing)
    Reputation is generated and assigned to digital certificates as well as specific files. Digital certificates allow data to be aggregated and assigned to a single certificate rather than many individual programs. Although not required, programs signed by an EV code signing certificate can immediately establish reputation with SmartScreen reputation services even if no prior reputation exists for that file or publisher. EV code signing certificates also have a unique identifier which makes it easier to maintain reputation across certificate renewals. Only Authenticode Certificates issued by a CA that is a member of the Windows Root Certificate Program can establish reputation.

    At this time, Symantec and DigiCert are offering EV code signing certificates.
  • Don’t sign or distribute malicious code
    Distributing code detected as malicious will remove the reputation from a file and also any reputation from the associated digital certificate – even if signed with an EV code signing certificate.
  • Apply for a Windows Logo or Windows 8 Desktop App Certification
    Learn more about these programs here:
We’re pleased with the announcement today of the availability of EV code signing certificates and we’re also happy to be able to bring SmartScreen Application Reputation to a new set of Windows users soon with Windows 8.
—Jeb Haber, Lead Program Manager, SmartScreen

IE 9.0.9 Available via Windows Update


The August 2012 Cumulative Security Update for Internet Explorer is now available via Windows Update. This security update resolves 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 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

воскресенье, 12 августа 2012 г.

ActiveX Filtering for Consumers


ActiveX Filtering in the IE9 Release Candidate gives you greater control over how Web pages run on your PC. With ActiveX Filtering, you can turn off ActiveX controls for all Web sites and then turn them back on selectively as you see fit. While ActiveX controls like Adobe Flash are important for Web experiences today for videos and more, some consumers may want to limit how they run for security, performance, or other reasons.
In this post, we’ll show how you can improve your browsing experience with ActiveX Filtering. We’ll walk through how this feature works in IE9 and share details on how IT administrators can deploy this feature in corporations. In a future post we’ll share some best practices that Web site authors should use to ensure that their sites work well with ActiveX Filtering.
You can try out ActiveX Filtering in the Release Candidate using this demo from the IE TestDrive site. You can also see the feature in action in this short video:

Background: ActiveX Controls & Browsing

To display interactive content and video, many of today’s Web sites use plug-ins like Adobe Flash or Microsoft Silverlight. “ActiveX” is the technology these plug-ins use to run inside of IE. Like other add-ons, they are essentially Windows applications that run in the browser. Poorly written add-ons and ActiveX controls can therefore affect IE’sperformancereliabilitysecurity and privacy in similar ways.
Some controls may be used to display undesirable or malicious content, preventing you from having a good experience when viewing a Web site.
Screen shot showing page with no blocked ActiveX content
ActiveX content may prevent you from having a good experience viewing a Web site
Some consumers are concerned about the potential impact of ActiveX controls and would want to limit them to run only on Web sites where you need them to view the content. ActiveX Filtering is a built-in, more generalized version of browser extensions like FlashBlock and ClickToFlash.

Introducing ActiveX Filtering

With ActiveX Filtering, you choose which sites are allowed to use your ActiveX controls, while all other Web sites cannot use them. ActiveX Filtering helps limit the impact that ActiveX controls have on your browsing experience since the controls can run only on specific sites. ActiveX Filtering also prevents Web pages from showing potentially unwanted content that relies on ActiveX controls.
Screen shot showing page with blocked ActiveX content
ActiveX Filtering enables you to focus on the content you want to view
By default, IE9 does not filter any ActiveX controls on Web sites to ensure you experience the sites as intended by their authors. If you desire increased control of ActiveX controls while browsing, you can enable ActiveX Filtering via the Tools menu:
Tools / IE9 Tools Menu Icon > Safety > ActiveX Filtering
Once you enable ActiveX Filtering, IE prevents ActiveX controls from running on all Web sites. When you visit a Web page that contains ActiveX controls, notice that ActiveX content is blocked from loading on the page. IE displays fallback content chosen by the site’s author if it is available.
Instead of displaying a prominent notification prompting you to install or enable controls, IE stays out of the way of your browsing while it also makes it easy for you to turn off filtering when you need to. IE displays an icon in the address bar to indicate that some content has been filtered on the site.
Screen shot showing some ActiveX content blocked icon in address bar
If a Web site contains ActiveX content that you want to view, you can turn off filtering for just the current Web site. When you click on the icon in the address bar, IE displays the fly-out window:
Screen shot showing some ActiveX content blocked fly-out window
You can click “Turn off ActiveX Filtering” for just the current site. Once you take action, IE refreshes the Web page to ensure that ActiveX controls are properly instantiated in place of any fallback content that was originally present on the page. ActiveX controls from other Web pages under the same domain (in the above case, msn.com) will also be unblocked.
The icon on the address bar changes color to indicate that you have turned off filtering on this Web site. After you’ve finished viewing the content, you can turn ActiveX Filtering back on by clicking on the icon again, which re-displays the fly-out window:
Screen shot showing no content blocked fly-out window
The address bar icon and fly-out window are also used for the Tracking Protection feature. If you have installed a Tracking Protection list you may see this icon appear on sites that only contain content blocked by Tracking Protection. In these cases you’ll need to launch the fly-out window to determine what content has been blocked. If you want to reset all the exceptions you’ve made for ActiveX Filtering and Tracking Protection, you can use Delete Browsing history. Be sure to select just this one checkbox:
Screen shot showing section to delete ActiveX Filtering data from the Delete Browsing History dialog
Section to delete ActiveX Filtering data from the Delete Browsing History dialog

ActiveX Filtering for Managed Desktops

Administrators can deploy ActiveX Filtering for their organizations easily by setting a group policy. The feature is disabled by default for the Local Intranet Zone so that intranet Web sites and LOB applications can continue to use ActiveX controls without disruption, and can be adjusted separately for each security zone.

Try it out!

To have a trustworthy browsing experience, it’s important that you are in control of the applications running in your browser. With ActiveX Filtering, you can now browse the Web with more control of your ActiveX controls. You can easily turn on the controls on sites that contain ActiveX content you want to view. This feature successfully limits the content that is allowed to run ActiveX controls, thus minimizing any potential performance, reliability, security or privacy impact on your browsing experience.
We encourage you try out this feature on the Internet Explorer 9 Release Candidate today, using the demo available from the TestDrive site. Please let us know if you find sites that don’t work properly with ActiveX Filtering. We look forward to hearing your feedback through blog comments and the Connect site.
—Herman Ng, Program Manager, Internet Explorer

Web Performance APIs Rapidly Become W3C Candidate Recommendations


We’re pleased to share that three new W3C Web Performance Working Group specifications moved to W3C Candidate Recommendations. Accurately measuring the performance characteristics of Web applications is critical to making the Web faster. In addition, developers need the ability to effectively use the underlying hardware to improve the performance of their applications. Over the last two years, companies including Microsoft, Google, Mozilla, Intel, and Facebook have been working toward these goals through the working group. This is a great example of what’s possible when the industry and community come together through the W3C.
The Navigation TimingResource TimingUser Timing and Performance Timeline specifications help developers accurately measure Web application performance. The first three specifications provide developers with information related to the navigation of the document, resources on the page, and developer scripts, respectively. The Performance Timeline specification defines a unifying interface to retrieve this timing data. Prior to these API’s it was not possible for developers to accurately measure their site performance.
To ensure these performance metrics are measured in the most accurate way possibly, the High Resolution Timespecification defines a sub-millisecond clock resolution. This interface not only benefits accurate measurements of performance metrics, but also allows better frame rate calculations and synchronization of animations or audio cues. For the first time developers can measure operations with sub-millisecond accuracy.
The Page VisibilityTiming control for script-based animations, and Efficient Script Yielding specifications help developers write more CPU- and power-efficient Web applications. The Page Visibility API allows for programmatically determining the current visibility state of the page. Developers can use this data to make better CPU- and power-efficiency decisions, e.g., throttling down activity when the page is in the background tab. TherequestAnimationFrame API, from the Timing control for script-based animations specification, allows for creating more efficient JavaScript animations. Finally, the setImmediate API, from the Efficient Script Yielding specification, allows developers to efficiently yield control flow to the user agent and receive an immediate callback, efficiently leveraging the CPU.
In order to ensure Web developers only have to write code once and have it work interoperably in all browsers, the Working Group has worked diligently these last two years to standardize these APIs. The table below shows the maturity level of all the specifications currently being edited in the Working Group.
SpecificationEditor’s DraftFirst Public Working DraftLast CallLast Call 2Candidate RecProposed RecRec
Navigation TimingSept 2010Oct 2010Jan 2011Feb 2011July 2012
Resource TimingSept 2010May 2011June 2011May 2012
User TimingOct 2010Aug 2011Aug 2011May 2012July 2012
Performance TimelineJuly 2011Aug 2011Aug 2011May 2012July 2012
High Resolution TimeMar 2012Mar 2012Mar 2012May 2012
Page VisibilityApr 2010June 2011July 2011July 2012
Display Paint NotificationsMay 2011June 2011Feb 2012
Efficient Script YieldingJune 2011
Navigation Timing 2(NEW)Apr 2012May 2012
Table showing the status of W3C Web Performance Specifications
As of this month, the Navigation Timing specification has been published as a Proposed Recommendation (PR). This stage of standardization is the final step before a Web standard becomes an official W3C Recommendation. Additionally, this interface has been broadly adopted in browsers, including support since Internet Explorer 9, Chrome 6 and Firefox 7. The working group recently started incorporating feedback and working on Navigation Timing 2, the next version of the specification.
As of this month, User Timing, Performance Timeline and Page Visibility specifications have been published as aCandidate Recommendation (CR). This stage of standardization is prior to the PR stage and reflects that the W3C believes this specification has been widely reviewed and satisfies the Working Group's technical requirements. Resource Timing was published as CR just two months ago, along with High Resolution Time, which went from an Editor’s Draft to CR in just three months.
These APIs are a great example of how quickly new ideas can become interoperable standards that developers can depend on in modern HTML5-enabled browsers. Thanks to everyone in the W3C Web Performance Working Group for helping design these APIs and to other browser vendors for starting to implement these APIs with an eye towards interoperability.
—Jatinder Mann, Program Manager, IE Performance