Microsoft News

Hi,

In this post, I will introduce you to some of the most compelling Facebook add-ons for Internet Explorer 8.

Share with Facebook Accelerator

The Share with Facebook Accelerator allows you to share any text, link, or page with your Facebook friends with a single click. You can use this accelerator by selecting either some text or a link, or by right-clicking on any part of the page.

Install here: http://www.ieaddons.com/en/details/204/Share_on_Facebook/

The technical beauty of this add-on is that it is extremely simple. In fact, it is contained in a single XML file, which is based on the OpenServiceDescription specification.

Facebook Web Slice

The Facebook Web Slice allows you to stay up to date with what’s happening in your Facebook network. Regardless what website you are on, you can click at any time on the web slice title and display the recent messages from your friends on your board.

Install here: http://www.ieaddons.com/en/details/social/Facebook_Web_Slice/

The Web Slice uses the Facebook Connect APIs to connect to your account and it shows a notification when new content is available. Special thanks go to the MVP Konstantinos Pantos for his contribution to the community.

Facebook Search Provider

Do you need to search for someone on Facebook? You can start right away from the browser search box!

Install here: http://www.ieaddons.com/en/details/searchhelpers/Facebook/

Again, this extension is built on top of an XML file which describes the end-point for the search provider.

Facebook Toolbar

The Facebook Toolbar lets you to share with your friends while browsing anywhere on the web - get notified, share content, upload photos, and update your status no matter where you are!

Install here: http://www.facebook.com/toolbar#!/toolbar?v=app_4949752878

The source code of this toolbar is available on github.

Thanks to the Facebook Team for these great extensions!

If you have any feedback or you would like to highlight other great IE8 add-ons, please leave a comment to this post.

Giorgio Sardo
Web Technical Evangelist
Microsoft Corporation

We’re always excited to engage with members of the W3C including the developers of other browsers as well as the broader web development community to help shape the direction of emerging Web standards, particularly HTML5.  This includes participating in events like TPAC, which we wrote about in November, and on-going engagement with various working groups.  Patrick recently talked about joining the SVG working group, and I’d like to share a brief list of other happenings on the way to making HTML5 well-defined, well-tested, and accessible:

• Providing feedback on HTML5
  Tony Ross, Internet Explorer Program Manager, and Jonas Sicking of Mozilla, led a discussion about extensibility in HTML5 at TPAC after our initial submission.  While the working group hasn’t resolved the issue yet, we think the event helped inform everyone and generate the different proposals submitted since. 
• Testing HTML5
  Kris Krueger, Internet Explorer Test Lead, was appointed facilitator of the W3C HTML5 Testing Task Force.  The task force has set up necessary infrastructure like a wiki, Bugzilla, a work item tracker, and CVS repository for test cases.  With that in place, they’ve started to review DOM Level 2 HTML test cases to use as the start of HTML5 testing.  As with CSS2.1, we think a good test suite is critical to ensuring a specification results in interoperable implementations.
• Ensuring new specifications enable accessibility
  We care deeply about an accessible web so besides implementing accessibility-focused browser features, we’re working with Apple, IBM, and other interested parties to ensure the new HTML5 <canvas> and <video> elements have great accessibility support so everyone can use sites leveraging them.  This work is driven by the Accessibility Task Force.  Together, we’re working on <canvas> HTML prototypes to use as ‘proof of concepts’ to ensure the feature is well-designed, as discussed in a recent teleconference. 
• Indexed DB Proposal
  Together with Mozilla, we’re excited about a new design for local storage called Indexed DB.  We think this is a great solution for the web.  Look for another post with more information about this proposal.  In the meantime, you can read the latest working draft. 
• DOM Level 3 Events
  Travis Leithead, Internet Explorer Program Manager, continues to help close down open issues with the latest editor’s draft. It’s been awhile since the working group published the last working draft and the group plans to publish an update soon that will improve clarity for implementers and web authors alike. On a recent teleconference, we noted that DOM Level 2 Events was published as a Recommendation nearly 10 years ago; it’s exciting to have the next milestone in sight!

Finally, you can read an interview with Paul Cotton from Microsoft and co-Chair of the W3C HTML Working Group on the W3C Blog.

Adrian Bateman
Program Manager

The RSA 2010 Security Conference is just finishing up here in San Francisco, and I’m struck by how many of the conference sessions and keynotes have warned about the threat that socially engineered malware poses to the security of the Internet. Malware has become the scourge of the Internet, and it’s not just the security experts who are worried—the top story in my morning paper yesterday described how a typical malware attack compromised a financial firm’s network. Our data shows that one out of every 250 downloads is the result of a user being tricked into downloading malware to their PC.

We’re proud of the protection SmartScreen® Filter provides to protect IE8 users from such attacks, and I’d like share some of the latest numbers on our level of protection.

Since we launched IE8 in March 2009, SmartScreen has blocked over 560 million attempts to download malware, recently averaging over 3 million blocks per day! Hosted in datacenters around the world, SmartScreen’s URL Reputation Service (URS) has evaluated over 250 billion URLs to help keep IE8 users safe from malware. Even more impressively, since IE7’s Phishing Filter was introduced in 2005, the URS has processed over 5.7 trillion reputation requests in order to block malicious web sites. Every day, Microsoft receives around 300 million telemetry reports from IE8 users and processes 4.1 billion URLs looking for malicious websites and files. On the back end, our systems and analysts evaluate over 1 terabyte of binaries every day to help identify sites delivering malware.

The Q1 2010 NSS Lab’s test shows that Microsoft’s continued investment in SmartScreen is paying off. Since launch, IE8’s SmartScreen Filter has continued to improve its protection against Socially Engineered Malware threats.

IE6 and 7 don’t provide protection against socially-engineered malware. If your family and friends aren’t up-to-date, please encourage them to upgrade to IE 8 for a safer Internet experience.

While IE8 offers the best built-in protection any browser offers against socially engineered malware, you still should follow best-practices to stay safe online. For instance:

• Enable SmartScreen Filter using IE8’s Safety menu ().
• Install antivirus and antispyware software from trusted sources and keep it up-to-date. Microsoft Security Essentials is available for free.
• Turn on your firewall.
• Enable Automatic Updates for Windows and other Microsoft software using Microsoft Update.
• Keep your computer's other software, including browser add-ons, up-to-date.
• Before downloading software, consider the risks and be aware of the fine print. For example, make sure the license agreement does not conceal a warning that you are about to install software with unwanted behavior.

You can read more tips and learn about common Internet attacks over on the Security Tips blog.

Stay safe out there!

Eric Lawrence
Program Manager

Last week, the W3C HTML Working Group reached a decision to publish several new working drafts and these are now available. The discussion about what to publish and how to structure the HTML5 specification has taken several months. In November, at the TPAC meeting, a request was made for the Microdata section of the specification to be removed. Back in August, I posted about our support for a separate Canvas 2D API specification.

Some people in the community raised concerns about exactly what should be in scope for the HTML working group. Tim Berners-Lee shared his thoughts:

“I agree with the WG chairs that these items -- data and canvas -- are reasonable areas of work for the group.  It is appropriate for the group to publish documents in this area. On the one hand, they elaborate areas touched on in HTML4. On the other, these elaborations are much deeper than the features of HTML4, but also they form separate subsystems, and these subsystems have strong overlaps with other design areas. It is important (a) that the design be modular; (b) that the specifications be kept modular and (c) that the communities of expertise of the respective fields (graphics and data) be involved in the design process.”

We strongly support Tim’s call for modular design and modular specifications in web standards. Large monolithic documents are hard to consume and take longer to stabilise with well thought out engineering decisions. In fact, the decision to take these features from HTML5 and make them separate documents continues the process that started last year as the storage and networking APIs were moved out of HTML5 and into the W3C WebApps working group. Just like good software design, loose coupling and high cohesion are good principles for defining web standards. That doesn’t make them easy to apply and there is still more work to do to reduce the coupling between drafts. The group is working on improving the tools used to generate the documents to improve the cross-references, which will help towards this goal.

Microdata and Canvas 2D are now available as new working drafts alongside the core HTML5 draft. This also sets Microdata on a similar footing to the updated HTML+RDFa draft. You can review the full set of documents published yesterday here:

• HTML5
• HTML+RDFa
• HTML Microdata
• HTML Canvas 2D Context
• HTML: The Markup Language
• HTML5 diffs from HTML4

Adrian Bateman
Program Manager

Tab isolation has recently become a more popular topic. This post is a quick survey of what tab isolation is, how it works, and what it provides.

What is it?

Tab isolation is a way to improve a browser’s reliability by containing the impact of a crash. Depending on how it’s implemented, tab isolation can also help contain some security attacks. There are two different implementations available today, each with different benefits.

In a tabbed browser without isolation, a problem in one tab can crash the entire browser. For example, a crash in a webpage in Firefox 3.6 or IE7 will bring down the entire browser. While modern browsers have features to recover tabs after a crash, the point of isolation is to contain the problem and prevent the browser from stopping. You can see a demo of this here (starting around 13:25). 

A Quick Historical Survey

On March 5, 2008, Microsoft released the first IE8 beta with Loosely-Coupled IE (or LCIE for short). This was the first mainstream implementation of tab isolation. On September 2, 2008, Google Chrome’s first beta released with “process isolation.” Mozilla Firefox has recently discussed an “Out of Process Plugins” (OOPP) or Electrolysis project aimed at isolating Firefox plug-ins, such as Flash, from the rest of the browser.

How do isolation approaches differ today in approach and benefits?

There are a lot of different subsystems in a browser to isolate from each other, and different ways to do it.

IE8 isolates the frame process (title bar, back button, address bar, etc.) from the tabs processes (that show web pages). If anything causes a site to crash (an extension like Flash, or the rendering or scripting engine, etc.), the frame and other tab processes will not crash. IE isolates the whole tab – all of its code, data, and extensions – to keep IE resilient to webpages with issues.

In addition to using multiple processes, IE8 on Windows 7 and Vista (and IE7 on Vista) sandboxes the tab processes in Protected Mode for security reasons. Specifically, tabs run without permissions to install software, modify settings, or change files of any user. Protected Mode provides defense in depth so that (in most cases) security vulnerabilities in the browser or an add-on (like Flash) cannot be exploited to harm the computer. Isolation makes this additional security possible. (Technically, there are several different types of isolation (process isolation, origin isolation, etc.), and of sandboxing (integrity levels, restricted subsets, DOM mirroring, etc.) as well.)

Chrome’s isolation is a bit different, factoring the different subsystems of that browser along different lines. From their documentation, they have separate processes for rendering, for the frame, and for add-ons (native plug-ins, not extensions). As with IE7, part of Chrome runs with lower privilege. Unlike IE (where page add-ons run in low), plugins in Chrome by default run with more privileges. As with any architectural difference, there are scenarios that are better in one architecture and worse in another. Theoretically, for example, a vulnerability in the Flash control running in Chrome does not have a defense in depth protection like Protected Mode to contain it.

Isolation is a super important part of modern browsers.  It’s essential for delivering a more reliable browsing experience. It can also improve security. Depending on how it’s engineered, it can also have an impact on compatibility with sites and browser extensions.

Andy Zeigler
Program Manager

There are many tools in the market that allow you to customize your pages' cascading style sheets (CSS), but there are actually a very few that do the opposite—scan for all the CSS rules in the document and remove those that are not used. Cleaning out the CSS will not only reduce the bandwidth impact, but will also improve the performance of the browser (minimizing the time spent by the CSS engine to parse the style sheets).

In this post, I will describe how to build that tool using a bookmarklet and a new standard function introduced in Internet Explorer 8: document.querySelectorAll().

Let’s start with the basics: a Web page can include many cascading style sheets, each of which is composed of one or more selectors. For instance, #elementId { }, .className { }, and body{ } are each examples of selectors. Using the function querySelectorAll(), you can programmatically inspect the DOM tree and count the number of times each selector is actually used.

For instance, the following code snippet counts the number of times the CSS class Foo is used in the document:

var selectorCount = document.querySelectorAll(“.Foo”).length;

Now that we have this information, we need a way to run this script inside the document. For the purpose of this article, I didn’t want to change our server-side code.

I decided to create a bookmarklet, which is a special link that can interact dynamically with the currently loaded page. The syntax of the bookmarklet is fairly straightforward:

<a href="javascript:( 
    function() {          
        var c = document.createElement('script');
        c.type = 'text/javascript';
        c.src = 'http://demos.cloudapp.net/IE/CssCrunch/Scripts/CssCrunch.js'; 
        document.getElementsByTagName('head')[0].appendChild(c); })();">            
    CSS Crunch
</a>

As you can see, at runtime this injects a remote script file that runs the analysis and displays the result.

If you scroll to the bottom of the list of CSS rules, you’ll see an option to remove temporarily unused selectors. This allow you to test if the page still displays and behaves the same way, as shown in the picture below.

I’d like to stress the fact that the goal is not to reach 100% usage on any page; there are scenarios in fact where the same style sheet could possibly be used by multiple pages and it makes sense to pre-fetch some rule, or where the page compression balance well having additional styles to maintain. Instead you should use this tool to identify possible areas for improvement.

That’s it! You can try it here:

1. Right click Run CSSCrunch and select “Add to Favorites”
2. Accept the security warning (by default, any bookmarklet is considered unsecure due to its nature)
3. Choose a location (for example, Favorites Bar)
4. Installed! You can now browse to this test page (or any other site) and click "CSS Crunch" in the Favorites Bar

This is just a starting point; if you are interested in doing more, you can find the source code here. I encourage you to look at the underlying code and customize it to suit your needs. For example, you might want to add support for multiple-pages analysis, or integration with server-side tools such as Visual Studio or IIS, or a compression capability such as Microsoft Ajax Minifier.

Ok, time to go! I'm checking the CSS on this blog now… :)

Have fun!

Giorgio Sardo
Web Technical Evangelist
Microsoft Corporation

This post describes how IE8 determines what Document Mode such as Quirks or Standards Modes to use for rendering websites. This topic is important for site developers and consumers.

It’s related to the Compatibility View List that we recently updated. This list is down by over 1000 websites, from over 3100 to just over 2000, since IE8 released last March. As we work with site developers and standards bodies, we’re excited to see the sites that need to be on the Compatibility View (CV) List continue to go down.

Data-driven Design

Before we dig in to the design details, I want to share some of the data we use to design the compatibility experience.

When looking at the doctype and X-UA-Compatible meta tag and header on thousands of high traffic websites worldwide such as qq.com, netlog.com and those on the initial CV List,

• 26% specify Quirks such as amazon.com, tworld.co.kr, and unibanco.com.br.
• 41% specify a Transitional doctype that puts them in Almost Standards Mode.
• 14% have already added an X-UA-Compatible meta tag or HTTP response header to render in IE7 Standards Mode.

Here’s why this makes sense; many high traffic websites want to render in as many browsers as possible, which is why they write for Quirks. Many websites have pages written specifically for IE7 and many web authoring tools such as Aptana Studio and Expression Web specify the Transitional doctype by default:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Thinking in terms of web-scale, there are billions of pages written specifically for either Quirks, IE7, Almost Standards, or the latest Standards. IE needs to support all of these web platform variations to ensure that our broad, world-wide, user-base has the best experience.

With this data in hand, we designed IE8 with a few principles in mind:

1. Render websites in the most standards compliant way by default.

   As stated in previous posts, we’re committed to interoperability, which means rendering websites in the most standards compliant way possible by default.

2. Users expect the web to just work in IE.

   A small set of users will tinker to get websites that expect and work best in IE7 Standards Mode to work in IE8’s more standards-compliant default mode. For everyone else, IE8 includes Compatibility View Settings.

   The best experience here is one that works automatically as the web developer intended. This is why we created the Compatibility View List. It’s also important to give users the ability to fix websites that aren’t on the list yet through the Compatibility View button.

3. Web developers are in control of how their content renders.

   The X-UA-Compatible meta tag and header override IE and user settings. They also provide web developers with fine-grain control over how each webpage renders in IE.

   For example, some websites have pages written for Quirks and others for IE7 Standards. When IE receives an X-UA-Compatible header with an EmulateIE7 value from servers, it renders each page in the appropriate Quirks or IE7 Standards Mode.

4. Give web developers tools and time to help transition their content to IE8 Standards.

   IE8 introduced the X-UA-Compatible meta tag and header to provide web developers time to transition their websites to IE8 Standards. As mentioned above, many websites have already used this mechanism to specify that their content should run in IE7 Standards Mode.

A Diagram on How IE8 Determines Document Mode

Given the above principles, there are four rules that you can remember about how IE handles doctype, X-UA-Compatible meta tag and header, Developer Tools, and Compatibility View Settings. These rules follow the diagram below from top to bottom:

1. The Developer Tools settings override all Document Modes for pages displayed in a tab.
2. The X-UA-Compatible meta tag and then header override Compatibility View Settings and the doctype unless the X-UA-Compatible value is EmulateIE7 or EmulateIE8.
3. The user’s Compatibility View Settings override the Microsoft Microsoft Compatibility View List.
4. If none of the above rules apply, the doctype determines whether the webpage renders in IE8 Standards, IE8 Almost Standards or Quirks Mode.

Compatibility and interoperability are complex. To reduce complexity for developers and users alike, we would love to see websites transition from legacy browser modes. We respect that the choice of mode is up to the site developer. We’re excited to work with sites and standards bodies to continue improving IE’s implementation of interoperable standards.

Many thanks to Jesse Mohrland for verifying the diagram.

Marc Silbey
Program Manager

This post discusses some of the work we’re doing on the IE team to fulfill our commitment to document our support of web standards. A good starting point is Microsoft’s interoperability principles, something we’ve written about here on this blog before, and a principle that’s easy to see in action in our products, like IE8.

The essence of interoperability in this context is that the same web page markup works the same way across different browsers. There are many challenges in getting to this goal. Even with the best intentions, as an industry we are still learning and working through how to do this well. You can look at how different tests run even today in modern browsers (for example here at 19:57). You can look at how standards evolve, like how quickly CSS2 became CSS 2.1, or the process to finish CSS 2.1 and make it a final Recommendation, or what happened between XHTML and HTML5. You can look at the challenge of delivering interoperable products while specifications are under construction (as in the case of 802.11 wireless). There are many challenges, and the web standards process, primarily at the W3C and similar organizations, is an important means to get the different communities involved to a consensus agreement.

The work in developing a public CSS 2.1 test suite and contributing it to the W3C, our recent work on different aspects of HTML5, and the improvements in IE9’s interoperability we showed at PDC are all examples of our principles in action. You can try out some of the tests yourself, in different browsers and on different operating systems.

As part of our commitment to interoperability, we’re going to make more interoperability information available about IE and keep it up-to-date. Today we’re publishing the first pieces of documentation here. These documents are drafts, and are not final. We will post more here on the IE blog about interoperability documentation (e.g. how we engineered creating this documentation, the process for keeping the documentation up to date).

Thanks –
Dean Hachamovitch

In addition to our engagement in the SVG Working Group, Doug Schepers, W3C Team Contact for the SVG Working Group, and I are going to be presenting SVG: The Past, Present and Future of Vector Graphics for the Web, at MIX 2010 in Las Vegas this coming March to share help developers understand where SVG is headed.  At Microsoft we have been investigating how SVG can deliver graphics for the next generation of the Web Development. Its inclusion in HTML5 promises many opportunities for developers to enhance their sites. We will provide an overview of SVG and how the standard is evolving to support a broader range of applications on the Web.

Patrick Dengler
Senior Program Manager

This post describes a set of best practices for setting the default search provider. Our goal continues to be keeping users in control of their browser, following our published Guidelines and Requirements for add-on development.

If you write software that modifies Internet Explorer’s search settings or defaults through direct registry manipulation, your software may be contributing to user confusion and frustration.

Whenever a program tries to modify the default search provider through direct registry manipulation (e.g. modifying the DefaultScope registry key directly as described in an earlier blog post ), IE8 intercepts the change and prompts users to confirm what they want:

Figure 1: In this dialog, the software requests a search default change using the recommended SetDefault API and clear attribution is displayed. In this case, it is the Contoso Internet Toolbar software.

If multiple search providers try to reset the registry key every time it changes, it causes a confusing and frustrating user experience. The above dialog box will re-appear every time the key is modified directly.

IE8 includes a Search Provider Default configuration experience designed for this scenario. When your software uses the IOpenServiceManager API (to install a search provider) and the SetDefault API (to request users set it as their default), users will see clearer communication about what is happening. This transparency is an important part of the user being in control.

The following code sample shows how to install a search provider and request that the user set it as the default using the recommended APIs.

#include <windows.h>
#include <atlbase.h>
#include <openservice.h>

    HRESULT hr = E_FAIL;
    BOOL fComInitialized = FALSE;

    if (S_OK == CoInitialize(NULL))
    {
        fComInitialized = TRUE;

        //Open a handle to the OpenService manager
        CComPtr<IOpenServiceManager> spManager;
        hr = spManager.CoCreateInstance(CLSID_OpenServiceManager);

        if (SUCCEEDED(hr))
        {
            CComPtr<IOpenService> spService;

            //Install my search provider
            //URL-OF-SERVICE: See http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_description_elements 
            hr = spManager->InstallService(URL-OF-SERVICE, &spService);

            if (hr==S_OK)
            {
                //Request that the user changes their search default
                hr = spService->SetDefault(TRUE, NULL);
            }
        }
    }

    if (fComInitialized)
    {
        CoUninitialize();
    }

When called, the SetDefault API will show the above dialog (See Figure 1 above) requesting the user to change their search default. The user can approve or deny this request from the software. If approved, the software can change the default setting. If denied, however, the software will not be allowed to change the user's default settings. The user can change the setting at any time by opening the Manage Add-ons window.

If the binary that is calling the SetDefault API is signed with a valid code signing certificate, the program name and publisher will be displayed in the Search Provider Default dialog box as in Figure 1 above. Code that calls SetDefault should be signed.

In summary, if your software monitors the DefaultScope registry key directly, please update your code to use the recommended APIs. This will allow the user to see the search provider default dialog only once and lets them be in full control of their default, in support of the Guidelines for add-on development.

If you are new to OpenSearch Extensibility and would like to learn how to offer your services or how to get started, check out the article Search Provider Extensibility in Internet Explorer.

Until next time,

Duc (Cash) Vo
Programmer Writer
Internet Explorer