A world without passwords: Windows Hello in Microsoft Edge


In this Microsoft Edge blog post, my team and I discuss bringing biometric authentication to the web:

At Build 2016, we announced that Microsoft Edge is the first browser to natively support Windows Hello as a more personal, seamless, and secure way to authenticate on the web. This experience is powered by an early implementation of the Web Authentication (formerly FIDO 2.0) specification, and we are working closely with industry leaders in both the FIDO Alliance and W3C Web Authentication working group to standardize these APIs. Try out this Test Drive demo in Microsoft Edge on recent Windows Insider builds to experience Windows Hello on the web today!

WindowsHello

Passwords can be a hassle. Most people don’t create strong passwords or make sure to maintain a different one for every site. People create easy-to-remember passwords and typically use the same passwords across all of their accounts. Surprisingly – and if it’s not surprising to you, you may want to change your password – passwords like “123456” and “password” are very common. Malicious actors can use social engineering, phishing, or key logging techniques to steal passwords from your machine, or they can compromise the server where the passwords are stored. When the same password is used across several sites, compromising one account can expose many others to abuse.

We look forward to a web where the user doesn’t need to remember a password, and the server doesn’t need to store a password in order to authenticate that user. Windows Hello, combined with Web Authentication, enables this vision with biometrics and asymmetric cryptography. In order to authenticate a user, the server sends down a plain text challenge to the browser. Once Microsoft Edge is able to verify the user through Windows Hello, the system will sign the challenge with a private key previously provisioned for this user and send the signature back to the server. If the server can validate the signature using the public key it has for that user and verify the challenge is correct, it can authenticate the user securely.

Screen Capture showing Windows Hello prompt to log in to a web page

These keys are not only stronger credentials – they also can’t be guessed and can’t be re-used across origins. The public key is meaningless on its own and the private key is never shared. Not only is using Windows Hello a delightful user experience, it’s also more secure by preventing password guessing, phishing, and keylogging, and it’s resilient to server database attacks.

Web Authentication: Passwordless and Two Factor Authentication

We’ve been working at the FIDO Alliance with organizations from across the industry to enable strong credentials and help move the web off of passwords. The main goal of the FIDO Alliance is to standardize these interfaces, so websites can use Windows Hello and other biometric devices across browsers. The FIDO Alliance had recently submitted the FIDO 2.0 proposal to the W3C and the newly formed Web Authentication working group is standardizing these APIs in the W3C Web Authentication specification.

FIDO Alliance logo

The Web Authentication specification defines two authentication scenarios: passwordless and two factor. In the passwordless case, the user does not need to log into the web page using a user name or password – they can login solely using Windows Hello. In the two factor case, the user logs in normally using a username and password, but Windows Hello is used as a second factor check to make the overall authentication stronger.

In traditional password authentication, a user creates a password and tells the server, which stores a hash of this password. The user, or an attacker who obtains the password, can then use the same password from any machine to authenticate to the server. Web Authentication instead uses asymmetric key authentication. In asymmetric key authentication, the user’s computer creates a strong cryptographic key pair, consisting of a private key and a public key. The public key is provided to the server, while the private key can be held by the computer in dedicated hardware such as a TPM, so that it cannot be moved from that computer. This protects the users against attacks on both the client and the server – client attacks cannot be used to let an attacker authenticate from elsewhere, and server attacks will only give the attacker a list of public keys.

Microsoft Edge supports an early implementation of the Web Authentication spec – in fact, the latest editor’s draft has already been updated beyond our implementation and we expect the spec to continue to change as it goes through the standardization process. We have implemented our APIs with the ms-prefix to indicate that these APIs are very likely to change in the future. We’ll continue to update the APIs in future releases as the standard finalizes – so be sure to watch for changes.

The Web Authentication API is very simple – it supports two methods: window.webauthn.makeCredential and window.webauthn.getAssertion. You will need to make both server and client sides changes to enable Web Auth authentication in your web application. Let’s talk through how to use these methods.

Registering the user

To use Web Auth, you, the identity provider, will first need to create a Web Auth credential for your user using the window.webauthn.makeCredential method.

When you use the makeCredential method, Microsoft Edge will first ask Windows Hello to use face or fingerprint identification to verify that the user is the same user as the one logged into the Windows account. Once this step is completed, Microsoft Passport will generate a public/private key pair and store the private key in the Trusted Platform Module (TPM), the dedicated crypto processor hardware used to store credentials. If the user doesn’t have a TPM enabled device, these keys will be stored in software. These credentials are created per origin, per Windows account, and will not be roamed because they are tied to the device. This means that you’ll need to make sure the user registers to use Windows Hello for every device they use. This makes the credentials even stronger – they can only be used by a particular user on a particular origin on a particular device.

Before registering the credential to a user on your server, you will need to confirm the identity of the user. This can be done by sending the user an email confirmation or asking them to use their traditional login method.

The below code sample shows how you would use the makeCredential API. When you call the makeCredential API, you will need to supply as parameters data structures containing the user account information, crypto parameters, and an attestation challenge. The user account information contains information on the user’s name, profile image, site in which the user is logging into, and user identifier information on the site. We’ll cover later how this information is used. The crypto parameter is a data structure that contains the crypto algorithm you which to use. The attestation challenge is used by the authenticator to produce an attestation statement, which tells the server what security measures the authenticator implements for its credentials. There are a number of other optional parameters, which we’ll ignore here. The methods are all implemented as promises. When the promise returns, it will include an object that contains information on the credential ID, public key, crypto algorithm, and the attestation challenge. The credential ID will be used to identify the public and private key pairs. You will then send this information back to the server for validating future authentications.

function makeCredential() {
  try {
    var accountInfo = {
      rpDisplayName: 'Contoso',  // Name of relying party
      displayName: 'John Doe',  // Name of user account in relying partying
      name: 'johndoe@contoso.com',// Detailed name of account
      id: 'joed',                 // Account identifier
      imageUri: imgUserProfile,  // user’s account image
    }; 
    
    var cryptoParameters = [
      {
        type: 'ScopedCred',
        algorithm: 'RSASSA-PKCS1-v1_5'
      }      
    ];
 
    var timeout = { };
    var denyList = { };
    var ext = { };
 
    var attestationChallenge = getChallengeFromServer();
 
    window.webauthn.makeCredential(
           accountInfo, 
                  cryptoParameters, 
                  attestationChallenge, 
                  timeout, 
                  denyList, 
                  ext)
      .then(function (creds) {
       // If promised succeeds, send credential information to the server
        sendToServer(creds);
      })
      .catch(function(reason) {
        // User may have cancelled the Windows Hello dialog
      });
  } catch(ex) {
     // The user may not have setup Windows Hello, show instructions
   }
}

The Microsoft Edge implementation is ms-prefixed, so you’ll need to call window.msCredentials.makeCredential instead of window.webauthn.makeCredential. The Microsoft Edge implementation is also based on an earlier draft of the specification, so there are a number of other differences in implementation as well, like the credential type is “FIDO_2_0” instead of “ScopedCred”, we don’t yet implement the optional timeout, denylist, or ext parameters, or require the attestation challenge to make the credential. In Microsoft Edge, you would instead make this call using the following code:

    var accountInfo = {
      rpDisplayName: 'Contoso',        // Name of relying party
      userDisplayName: 'John Doe'      // Name of user account in relying partying
    }; 
    
    var cryptoParameters = [
      {
        type: 'FIDO_2_0',
        algorithm: 'RSASSA-PKCS1-v1_5'
      }      
    ];
 
    window.msCredential.makeCredential(accountInfo, cryptoParameters)
      .then(function (cred) {
       // If promised succeeds, send credential information to the server
        sendToServer({
                   credential: {type: 'ScopedCred', id: cred.id},
                   algorithm: cred.algorithm,
                   publicKey: JSON.parse(cred.publicKey),
                   attestation: cred.attestation
               }
     );
      });

Authenticating the user

Once the credential is created on the client, the next time the user attempts to log into the site, you can offer to sign them in using Windows Hello instead of a password. You will authenticate the user using the window.webauthn.getAssertion call.

The getAssertion call has a number of optional parameters, but the only required parameter is the challenge. This is the challenge that the server will send down to the client. This challenge is a random quantity generated by the server. Since the challenge is not predictable by an attacker, the server can be assured that any assertions it receives were freshly generated in response to this challenge and are not replays of earlier assertions. The allowList parameter also takes an optional list of credential ID information to locate the correct private key. This information is useful if you’re doing two factor auth and you can share the id from the server, where it is stored. In the passwordless case, you don’t want to share the id from the server because the user hasn’t yet authenticated.

If the user has multiple credentials for an origin in the TPM, the browser will show a user experience allowing the user to pick the account they meant to use (assuming they have multiple accounts with an application, and you don’t provide a credential ID). This is why we collect the user profile picture and account name upon registration.

Once the getAssertion call is made, Microsoft Edge will show the Windows Hello prompt, which will verify the identity of the user using biometrics. After the user is verified, the challenge will be signed within the TPM and the promise will return with an assertion object that contains the signature and other metadata. You will then send this data to the server. We’ll check the server code next to see how you verify the challenge is the same that you had sent.

function getAssertion() {
  try {
    var challenge = getChallengeFromServer(); 
    var allowList = 
          [
            {
              type: 'ScopedCred',
              id:  getCredentialID()
            }
          ];
    var timeout = { };
    var ext = { };
 
    window.webauthn.getAssertion(challenge, timeout, allowList, ext)
      .then(function(assertion) {
         // Send signed challenge and meta data to server
        sendToServer(assertion);
      }, function (e) {
        // No credential in the store. Fallback to password
      });    
  } catch (ex) {
    // Log failure
  }
}

In Microsoft Edge, you will need to call window.msCredentials.getAssertion instead of window.webauthn.getAssertion. The Microsoft Edge implementation also requires the credential ID and we don’t yet support the account picker experience. A side effect of this is that for the passwordless case, you’ll need to store your credential ID information in local storage on the client, either in indexDB or localStorage when making your credential. This mean that if a user deletes their browsing history, including local storage, they will need to re-register to use Windows Hello the next time they log in. We will very likely fix this issue in a future release.

Here’s how you would make the getAssertion call in Microsoft Edge. Note how the accept object is required for the filter parameter.

var filters = {
        accept:
          [
            {
              type: 'FIDO_2_0',
              id:  getCredentialIDFromLocalStorage()
            }
          ]
        };
window.msCrendentials.getAssertion(challenge, filters)
.then(function(attestation) {
    // Send signed challenge and meta data to server
    sendToServer({
                   credential: {type: 'ScopedCred', id: attestation.id},
                   clientData: attestation.signature.clientData,
                   authnrData: attestation.signature.authnrData,
                   signature: attestation.signature.signature
                   };
    );
  });   

Server side authentication

Once you receive the assertion on the server, you will need to validate the signature. The below Node.JS code shows how you would validate the signature to authenticate the user on the server. We also have the same code available in C# and PHP.

var jwkToPem = require('jwk-to-pem')
var crypto = require('crypto');
 
var webAuthAuthenticator = {
   validateSignature: function (publicKey, clientData, authnrData, signature, challenge) {
       // Make sure the challenge in the client data 
       // matches the expected challenge
       var c = new Buffer(clientData, 'base64');
       var cc = JSON.parse(c.toString().replace(/\0/g,''));
       if(cc.challenge != challenge) return false;
 
       // Hash data with sha256
       const hash = crypto.createHash('sha256');
       hash.update(c);
       var h = hash.digest();
 
       // Verify signature is correct for authnrData + hash
       var verify = crypto.createVerify('RSA-SHA256');
       verify.update(new Buffer(authnrData,'base64'));
       verify.update(h);
       return verify.verify(jwkToPem(JSON.parse(publicKey)), signature, 'base64');
   }
};   

Evolving Web Authentication standard and Microsoft Edge implementation

As mentioned above, Microsoft Edge has an early implementation of Web Authentication and there are a number of differences between our implementation and the April 2016 spec.

  • Microsoft Edge APIs are ms- prefixed
  • Microsoft Edge does not yet support external credentials like USB keys or Bluetooth devices. The current API is limited to embedded credentials stored in the TPM.
  • The currently logged in Windows user account must be configured to support at least a PIN, preferably face or fingerprint biometrics. This is to ensure that we can authenticate the access to the TPM.
  • We do not support all of the options in the current Web Auth spec draft, like extensions or timeouts.
  • As mentioned earlier, our implementation requires that the list of acceptable credential IDs be included in every getAssertion call.

The specification is also going through the W3C standardization process and we expect a number of changes in the specification, like the object name recently changing from window.fido to window.webauthn in the latest’s editor’s draft.

We have a number of resources available to help you prototype and experiment with these APIs:

    • Webauthn.js polyfill. Using this polyfill, you can code to the standard instead of our early implementation. We’ll update this polyfill for every major published version of the specification.
    • Windows Hello in Microsoft Edge test drive sample. This test drive sample shows you the typical client side registration and assertion flow.
    • Server and client side WebAuth This sample code shows the end to end client and server side flow for registration and assertion.
    • C#, PHP, and JS server side sample. These code samples show how could implement your server side logic in a number of language options.
    • Web Authentication MSDN documentation and dev guide.
    • Edge Summit talk on Windows Hello in Microsoft Edge.

Call to Action

We’re excited to support Windows Hello and Web Authentication in Microsoft Edge and innovate in the biometric authentication and passwordless space in the web. Now is a great time to start prototyping and experimenting with these APIs and sharing your feedback with us in the comments below or on Twitter. We look forward to hearing from you!

Rob Trace, Program Manager, Microsoft Edge
Jatinder Mann, Program Manager Lead, Microsoft Edge
Vijay Bharadwaj, Software Engineering Lead, Security
Anoosh Saboori, Program Manager, Security

Continuing to make it easier for Enterprise customers to upgrade to Internet Explorer 11 — and Windows 10

Fred and I discuss Enterprise Mode on the Microsoft Edge blog:

Helping our Enterprise customers stay up-to-date with the latest version of the browser is a top priority for Microsoft. This is particularly important for Windows 7 customers who should upgrade to Internet Explorer 11 by January 12, 2016 to continue receiving security updates and technical support. We understand many customers have web apps and services designed specifically for older versions of Internet Explorer, so we’re continuing to improve our set of Enterprise Mode tools to help you run those applications in Internet Explorer 11. Upgrading to Internet Explorer 11 can ease the upgrade to Windows 10, too, since Internet Explorer 11 is supported on Windows 7, Windows 8.1, and Windows 10.

Continuing to improve Enterprise Mode

We continue to make significant improvements to Enterprise Mode, helping customers upgrade more easily to Internet Explorer 11 while also extending the ability to run older web apps. Customer feedback has told us that we’re on the right track with these tools, and that IE upgrades are going more smoothly than ever before.

Here are some features and resources available for you today:

IE8 Enterprise Mode
IE8 Enterprise Mode provides a higher fidelity emulation of the Internet Explorer 8 browser by turning on functionality not available in other document modes. You can use the Enterprise Mode Site List Manager to specify any web path to load in this mode.

IE7 Enterprise Mode
Internet Explorer 8 shipped with Compatibility View, a compatibility option that looks for the DOCTYPE tag, rendering a web page in IE7 document mode if it exists, or in IE5 document mode if it doesn’t.

While IE11 still has Compatibility View, you can use IE7 Enterprise Mode to provide a higher fidelity emulation of how the IE8 browser acts when running in Compatibility View. You can use the Enterprise Mode Site List Manager to specify any web path to load in this mode.

IE5, IE7, IE8, IE9, IE10, and IE11 Document Modes
Internet Explorer 11 supports document modes for emulation of the IE5, IE7, IE8, IE9, IE10, and IE11 rendering engines. While site markup can request the browser to load in these modes, you can also use the Enterprise Mode Site List to override the site to load in any document mode that makes the site work.

Enterprise Site Discovery
If you want to prioritize your testing, you can use Enterprise Site Discovery with IE8, IE9, IE10, and IE11 to discover which web apps your users are visiting and how the apps are built, like what document mode or ActiveX Controls are used. The Enterprise Mode Site List Manager tool can even import this data to help you seed your Enterprise Mode Site List. Of course, using the F12 developer tools for manual testing is always an option, but Enterprise Site Discovery can help you quickly gather information from a broad set of users.

(New!) Support for HTTP ports in Enterprise Mode
We’ve also heard from many customers that they want the ability to apply Enterprise Mode compatibility features to sites with HTTP ports, such as http://contoso.com:8080, and we’ve listened: Enterprise Mode now supports HTTP ports. You can specify a HTTP port directly in your Enterprise Mode Site List XML, such as <domain>contoso.com:8080</domain>, or you can use the new Enterprise Mode Site List Manager tool to add HTTP ports. To use this feature on Windows 7 or Windows 8.1, you’ll need to also install the IE11 October Cumulative Update or later.

(New!) Web Application Compatibility Lab Kit
To help customers learn how to use Enterprise Mode and Enterprise Site Discovery, today we are introducing the Web Application Compatibility Lab Kit. This Lab Kit provides a walk-through of how to configure and set up Enterprise Mode in addition to Enterprise Site Discovery, the F12 developer tools, and the Enterprise Mode Site List Manager. The Lab Kit comes with VMs for Windows 7 SP1 Enterprise (Evaluation) and Windows 10 Enterprise (Evaluation), or you can download a “lite” version without the VMs.

For more information or assistance:

New improvements to Enterprise Mode in Windows 10

We’re also making it easier for customers to upgrade to Windows 10, because Windows 10 supports the same version of Internet Explorer 11—along with all of the Enterprise Mode features—available on Windows 7 and Windows 8.1. At the same time, we’ve continued to make improvements to Enterprise Mode in the Windows 10 Fall Update and higher to simplify management and better support Microsoft Edge. Many of these improvements will also be made available to Internet Explorer 11 on Windows 7 and Windows 8.1 early next year.

Microsoft Edge and IE11 work better together on Windows 10

Windows 10 features Microsoft Edge, a new browser that goes beyond browsing with features like Web Note and Cortana integration. Microsoft Edge is built from the ground up to improve productivity, to be more secure, and to correctly, quickly, and reliably render web pages. As we announced a few months ago, you can use Enterprise Mode with Microsoft Edge to open Internet Explorer 11 for your business’s sites that require IE proprietary technologies. This approach enables your users to run a modern browser designed for better productivity, security, and rendering web pages—without sacrificing compatibility with legacy line of business applications.

However, we also recognize that some customers have a significant number of sites that require IE proprietary technologies, and still need to use Internet Explorer 11 as their primary browser. For those customers, we have introduced a new capability in Enterprise Mode for Internet Explorer 11 to open Microsoft Edge for modern sites that need the latest web platform features. This feature has a very similar user experience to the analogous feature in Microsoft Edge to open IE11.

In this example below, we’ve setup Enterprise Mode with IE11 to open http://www.bing.com in Microsoft Edge.

Screen capture showing Internet Explorer 11 prompting the user to open a site in Internet Explorer 11.

With this change, customers now have the following options for browsers on Windows 10:

Use Microsoft Edge as your primary browser If your business sites primarily use modern web technologies, we recommend that you use Microsoft Edge as your primary browser.
Use Microsoft Edge as your primary browser and use Enterprise Mode to open sites in IE11 that use IE proprietary technologies If your business sites primarily use modern web technologies but you still have older sites that use IE proprietary technologies, we recommend that you use Microsoft Edge as your primary browser and use the Enterprise Mode Site List to open older sites automatically in Internet Explorer 11. This approach helps ensure your new site development continues to happen on a modern web platform, but that you can still use your older apps that were designed for older versions of IE. Your Enterprise Mode Site List also becomes a to-do list for sites that you need to modernize. Many customers tell us they plan to use this approach. We use this option at Microsoft, since we still have some older applications built for older IE technologies.
Use Microsoft Edge as your primary browser and open all intranet sites in IE11 If you have external sites that use modern web technologies, but still have a large number of internal business sites that use IE proprietary technologies, you can choose to use Microsoft Edge as your primary browser and open all intranet sites in IE11 using the Sends all intranet traffic over to Internet Explorer Microsoft Edge Group Policy or MDM setting. You can still use the Enterprise Mode Site List to ensure the internal sites that work with Microsoft Edge don’t open in IE11. This approach helps ensure your new site development continues to happen on a modern web platform, but balances it with your need to continue using older apps that were designed for older versions of IE.
Use IE11 as your primary browser and use Enterprise Mode to open sites in Microsoft Edge that use modern web technologies If you have more business sites built on IE proprietary technologies than modern web technologies, you can choose to use IE11 as your primary browser and use the Enterprise Mode Site List to explicitly define the modern web sites that should open automatically in Microsoft Edge. This approach helps ensure your new site development continues to happen on a modern web platform engine in Microsoft Edge, while balancing the fact that most of your web apps are still based on IE.
Use IE11 as your primary browser If you want the exact same environment on Windows 10 as on Windows 7 or Windows 8.1, you can choose to use IE11 as your primary browser. You can set IE11 as your default browser by using the Set a default associations configuration file in the File Manager Group Policy. While this is a great approach to quickly get to Windows 10, we recommend that customers consider using Microsoft Edge as a more secure, reliable browser instead. Developing new business applications using IE proprietary technologies could also make it harder for you to adopt modern web technologies in the future.

Simpler, cleaner, and more scalable Enterprise Mode XML schema

We’ve heard that most customers are using the Enterprise Mode Site List to upgrade to IE11 on Windows 7, and will likely continue to use the site list going forward. We’ve also heard feedback that the existing site list XML schema isn’t always very easy to understand. Starting in the Windows 10 Fall Update, we’re now supporting a new v.2 Enterprise Mode XML schema, which is designed to be simpler, cleaner, more scalable, and to help ease list management. Internet Explorer 11 and Microsoft Edge on Windows 10 will continue to support the existing v.1 XML schema that is supported on Windows 7 and Windows 8.1 today, as well as the new v.2 XML schema.

Below is an example of an Enterprise Mode Site List based on the existing v.1 XML schema. Customer feedback included:

  • It’s not clear that if the same entry appears in the emie and docMode sections, the emie section wins.
  • The double negative of doNotTransition=”false” is confusing.
  • There are many ways to put a site in a document mode: entry in emie section, entry in docMode section, or forceCompatView attribute.
  • You have to break up an URL into the domain and paths separately for the emie and docMode sections.

EMIE v1 schema

Below, we have the same Enterprise Mode Site List using the v.2 XML schema. Here are some of the changes:

  • All entries are just URLs under the site element. This reduces the hierarchy and the need to split sites into domains and paths.
  • We’ve introduced a new compat-mode element where you can specify any compatibility mode: IE8Enterprise, IE7Enterprise, IE5, IE7, IE8, IE9, IE10, IE11, and default. This attribute replaces the emie and docMode sections, and forceCompatView and exclude attributes.
  • We’ve introduced a new open-in element where you can specify which browser the site should open in: IE11, MSEdge, or none (don’t open in another browser). This replaces the double negative of doNotTransition=”false”.
  • You can use a self-closing element with no children to declare a site should just use the browser defaults. This replaces the exclude attribute.
  • We include the date the list was created and the Enterprise Mode Site List Manager tool version number for easier site list version management. This information doesn’t impact how the browser interprets the site list.
  • This format makes it very easy for us to introduce new Enterprise Mode features as children elements to the site element.

EMIE v2 schema

We encourage customers to adopt the easier to read and manage v.2 version of the XML schema, starting with Windows 10 and coming in early 2016 to IE11 on Windows 7 and Windows 8.1. Going forward, we plan to bring new features only to the v.2 XML schema. For example, the new Enterprise Mode feature for IE11 to open sites in Microsoft Edge is only supported with the new v.2 XML schema.

Here is an example of how you can specify that IE11 open a site in Microsoft Edge:

OpenInEdge

In addition to the new v.2 version of the XML schema, we’re also supporting a new version of the Enterprise Mode Site List Manager tool for Windows 10. This version of the tool lets you import an existing v.1 Enterprise Mode Site List XML file and automatically convert it to the v.2 XML schema.

Important note:
To avoid adding extra work to migrate from the v.1 to v.2 XML schema while customers are trying to upgrade to IE11 on Windows 7 and Windows 8.1 before the January 12, 2016 support policy deadline, we’ve decided to wait before supporting the v.2 XML schema on Windows 7 or Windows 8.1 today. We recommend customers working on IE11 upgrades on Windows 7 and Windows 8.1 continue to use the existing v.1 XML schema and the existing Enterprise Mode Site List Manager tool for Windows 7 and Windows 8.1 Update. The existing schema continues to be supported on all versions of Windows where IE11 is supported, including Windows 10. We will make the v.2 Enterprise Mode XML available in Internet Explorer 11 for Windows 7 and Windows 8.1 early next year, and customers shouldn’t consider moving to the v.2 XML schema until that patch lands on all of their devices.

To learn more about this Enterprise Mode XML schema changes, see the following:

Better diagnostics and management with about:compat

In the Windows 10 Fall Update, we’ve also introduced a new about:compat page in Microsoft Edge and Internet Explorer 11 to help customers better manage their Enterprise Mode Site List. You can use about:compat to see all of the compatibility features you or Microsoft have applied to sites on the client machine. This tool is not only an easy way to visualize and search the Enterprise Mode Site List, but a great way to diagnose problems on a client machine, like whether the latest Enterprise Mode Site List is being applied.

On Internet Explorer 11 for Windows 10, you can view and search the Enterprise Mode Site List, local additions to the Enterprise Mode list, the Microsoft Compatibility List, and local additions to Compatibility View.

Screen capture showing the about:compat interface in Internet Explorer 11 on Windows 10.

On Microsoft Edge, you can view and search the Enterprise Mode Site List and Microsoft Compatibility List, as only those lists are applicable.

Screen capture showing the about:compat interface in Microsoft Edge

Upgrade guidance

Migrating to Internet Explorer 11 is easier than ever before, thanks to backward compatibility features like Enterprise Mode. Please start with the resources in this post, such as the Web Application Compatibility Lab Kit, to learn how to use Enterprise Mode and Enterprise Site Discovery effectively. If you still have a technical or business impediment that prevents you from upgrading, please reach out to your Microsoft account team or Microsoft partner, as we may be able to help.

We made these product improvements and upgrade resources based on customer feedback, and hope the new features help you manage browser compatibility more easily than ever before. Like other customers, you may also find that upgrading to Internet Explorer 11 with Enterprise Mode is easier and less costly than previous upgrades. Best of all, the upgrade to Internet Explorer 11 should help ease your migration to Windows 10 and Microsoft Edge.

– Jatinder Mann, Senior Program Manager Lead
– Fred Pullen, Product Marketing Director

Bringing automated testing to Microsoft Edge through WebDriver

My team has been working very hard to deliver WebDriver support in Microsoft Edge. Here’s a blog we wrote on the Microsoft Edge Blog.

Today we’re announcing support for automated testing of Microsoft Edge through the W3C WebDriver standard. To use WebDriver with Microsoft Edge, you need the MicrosoftWebDriver server on a Windows Insiders build of 10240 or newer. You can also out our test drive to learn more7 about WebDriver!

WebDriver is an emerging standard through which Web developers can write tests to automate Web browsers for site testing. It provides a programmable remote control for developing complex user scenarios and running them in an automated fashion against your website in a browser. WebDriver is used by top web properties like Bing, Azure, SharePoint, Facebook, Google, and others to automate testing their sites within a browser. With this new capability, Microsoft Edge can be run through the same regression testing as other browsers, helping developers identify issues with less effort and making sites just work for our end users.

As we described in “Building a more interoperable Web with Microsoft Edge,” the Web is built on the principle of multiple independent, interoperable implementations of web standards, and true interoperability means that all web content, browsers, and specifications should align to the same well-defined behavior. Keeping that principle in mind, our implementation supports both the W3C WebDriver specification and the JSON Wire Protocol. The Browser Testing and Tools working group has been doing a great job of standardizing automation testing interfaces as a part of the emerging WebDriver specification. For backwards compatibility with existing tests, we have implemented the JSON Wire Protocol, so existing tests should also just work. We’re not done yet, as the WebDriver specification is still in an early stage of standardization, and we still have more features to implement. You can find out more about all of the WebDriver interfaces we have implemented on our Platform Status page here.

Borland contributions to Microsoft Edge

MicroFocus Borland logoMicrosoft has a long history of collaborating with industry technology leaders to bring the best-in-class experiences. In order to truly build an interoperable implementation that our customers can use, we have partnered with the Borland Silk team from Micro Focus, an industry leader in automation testing tools, to help contribute code to the WebDriver implementation in Microsoft Edge. The Borland team is also bringing their expertise in automation testing to help inform the next level of changes we should pursue in the W3C standard. Our thanks to the Borland team for all of their help in making the Web better!

How WebDriver works

To get started using WebDriver, you will need to download a testing framework of your choice along with an appropriate language binding and the MicrosoftWebDriver server. We have submitted updates to the C# and Java Selenium language bindings and are hoping to add support to other languages in the future.

WebDriver is disabled by default for security. In order to enable using WebDriver, you will need to download and install the MicrosoftWebDriver in a location with your test repository. You should be able to use Microsoft Edge’s WebDriver implementation just like you would use any other browser’s implementation.

Diagram of WebDriver and Microsoft Edge

Here’s an example of C# code opening a new browser Window, navigating to http://www.bing.com and searching webdriver. For more example commands, check out our test drive.

We’re excited to deliver WebDriver in Microsoft Edge and look forward to hearing what you think! Take it for a spin and share your feedback in the comments below or @MSEdgeDev on Twitter.

Clay Martin, Program Manager, Microsoft Edge
John Jansen, Principle Software Engineer, Microsoft Edge
Jatinder Mann, Senior Program Manager Lead, Microsoft Edge
– Mark Conway, Director, Micro Focus

Making it easier for Enterprise customers to upgrade to Internet Explorer 11 — and Windows 10

In this IE Blog Post, I talk about making it easier for Enterprises to stay up-to-date with Internet Explorer.

As we shared last year, a top priority for Microsoft is helping our Enterprise customers stay up-to-date with the latest version of Internet Explorer. This is particularly important for Windows 7 customers who are upgrading to Internet Explorer 11 by January 12, 2016 to continue receiving security updates and technical support. We understand many customers have Web apps and services that were designed specifically for older versions of Internet Explorer and we provide a set of tools, like Enterprise Mode, the Enterprise Mode Site List, and Enterprise Site Discovery, to help you run these applications in Internet Explorer 11 — and ease the upgrade to Windows 10.

Enterprise Mode helps customers extend their investments in older Web apps through higher compatibility with the IE8 rendering engine in a more modern browser like Internet Explorer 11. In the ten months since we released Enterprise Mode, we’ve heard from our customers that it is very effective at improving legacy app compatibility and that the upgrade to Internet Explorer 11 was easier than ever before. To help us tell this story, Microsoft commissioned Forrester Consulting to interview and survey large customers in the US, UK, Germany, and Japan who have started their IE11 upgrades. Customers found that:

  • Upgrading from IE8 to IE11 was 1.8 times faster than expected, thanks to Enterprise Mode.
  • The effort to rewrite applications to modern browser standards was reduced by 75%.
  • Ongoing browser support and critical applications testing were significantly reduced.
  • Many business users saw improved productivity from using a single browser.

Organizations save money, reduce risk, and experience higher productivity by upgrading to IE11. Best of all, upgrading to Internet Explorer 11 now can help ease your migration to Windows 10. Download The Total Economic Impact of Microsoft Internet Explorer 11.

Better Backward Compatibility with the Enterprise Mode Site List

Enterprise Mode can be very effective in providing backward compatibility for older Web apps. In January, for example, Microsoft held an Enterprise Customer Summit with about 100 large customers, and we found that every broken site brought by a customer to our IE App Compatibility Workshop was fixed by using Enterprise Mode. Depending on your environment, you may not need to use Enterprise Mode for better emulation of the IE8 engine, but may still benefit from using the Enterprise Mode Site List and its new <docMode> functionality.

In November, we expanded the functionality of the Enterprise Mode Site List to include the ability to put any Web app in any document mode, without changing a single line of code on the Web site. This new functionality adds a <docMode> section to the Enterprise Mode XML file, separate from the <emie> section for Enterprise Mode sites. Using this new functionality, Microsoft’s own IT department saw our internal line of business application pass rate go from 93% to 100% with 24 document mode entries in our Enterprise Mode Site List and only a single Enterprise Mode entry.

Web paths added to the Enterprise Mode Site List can now be rendered either in Enterprise Mode—which provides higher-fidelity emulation for IE8—or any of the document modes listed below:

Enterprise Mode Site List diagram

Enterprise Mode (in green above), with its higher-fidelity emulation for IE8, was added to Internet Explorer 11 in April, 2014. The blue capabilities were added to the Enterprise Mode Site List in November, 2014, and can particularly help IE9 or IE10 customers upgrade more easily. Enterprise Mode can be further improved by using it in combination with Compatibility View, a mode added in IE8 for better compatibility for sites designed for IE7, as indicated in orange.

Compatibility View is basically a switch: If a web page has no DOCTYPE, the page will be rendered in IE5 mode. If there is a DOCTYPE, the page will be rendered in IE7 mode. You can effectively get Compatibility View by specifying IE7 in the <docMode> section—as this falls back to IE5 automatically if there’s no DOCTYPE—or you can use Enterprise Mode with Compatibility View for even better emulation. See below for details.

Speaking with customers, we found that IT Pros aren’t always the ones doing the app remediation work. Much of this work is often done by IT Developers, who don’t always understand all of the IE backward compatibility offerings. In this post, we want to provide a clearer set of mitigations for IT Pros and IT Developers to help make your upgrade as easy as possible.

Call to action for IT Pros

We know that upgrading to a new browser can be a time-consuming and potentially costly venture. To help reduce these costs, we introduced the Enterprise Site Discovery toolkit to help you prioritize which sites you should be testing based on their usage in your enterprise. For example, if the data shows that no one is visiting a particular legacy Web app anymore, you may not need to test or fix it. This tool also gives you information on what document mode the page runs in your current browser, so you can better understand how to fix that site if it breaks in a newer version of the browser. This tool is currently only supported in IE11, but we are bringing Enterprise Site Discovery support to IE8, IE9, and IE10 very soon.

Once you know which sites to test and fix, the following remediation methods may help fix your app compatibility issues in IE11 and Windows 10.

If you’re on IE8 and upgrading to IE11…

  • Use the Enterprise Mode Site List to add sites to IE5, IE7, and IE8 modes.
  • Sites with x-ua-compatible meta tag or HTTP header set to “IE=edge” may break in IE11 and need to be set to IE8 mode. This is because Edge in IE8 meant IE8 mode, but Edge in IE11 means IE11 mode.
  • Sites without a DOCTYPE in zones other than Intranet will default to QME (or “interoperable quirks) rather than IE5 Quirks and may need to be set to IE5 mode.
  • If you have enabled Turn on Internet Explorer Standards Mode for local intranet group policy setting, sites with a DOCTYPE in the Intranet zone will open in IE11 mode instead of IE7 mode, and may need to be set to IE7 mode. Sites without a DOCTYPE will open in QME and may need to be set to IE5 mode.
  • Some IE5, IE7, and IE8 sites may need to be added to Enterprise Mode to work.
  • Some sites may need to be added to both Enterprise Mode and Compatibility View to work. You can do this by adding the site both to the Enterprise Mode section of the Enterprise Mode Site List and to the Use Policy List of Internet Explorer 7 sites group policy.

If you’re on IE9 and upgrading to IE11…

  • Use the Enterprise Mode Site List to add sites to IE5, IE7, and IE9 modes.
  • Sites with x-ua-compatible meta tag or HTTP header set to “IE=edge” may break in IE11 and need to be set to IE9 mode. This is because Edge in IE9 meant IE9 mode, but Edge in IE11 means IE11 mode.
  • Sites without a DOCTYPE in zones other than Intranet will default to QME rather than IE5 Quirks and may need to be set to IE5 mode.
  • If you have enabled Turn on Internet Explorer Standards Mode for local intranet group policy setting, sites with a DOCTYPE in the Intranet zone will open in IE11 mode instead of IE7 mode, and may need to be set to IE7 mode. Sites without a DOCTYPE will open in QME and may need to be set to IE5 mode.
  • If your sites worked in IE9, you won’t need Enterprise Mode but can still take advantage of the newer <docMode> section of the Enterprise Mode Site List.

If you’re on IE10 and upgrading to IE11…

  • Use Enterprise Mode Site List to add sites to IE5, IE7, and IE10 modes.
  • Sites with x-ua-compatible meta tag or HTTP header set to “IE=edge” may break in IE11 and need to be set to IE10 mode. This is because Edge in IE10 meant IE10 mode, but Edge in IE11 means IE11 mode.
  • If you have enabled Turn on Internet Explorer Standards Mode for local intranet group policy setting, sites with a DOCTYPE in the Intranet zone will open in IE11 mode instead of IE7 mode, and may need to be set to IE7 mode. Sites without a DOCTYPE will open in QME and may need to be set to IE5 mode.
  • If your sites worked in IE10, you won’t need Enterprise Mode but can still take advantage of the newer <docMode> section of the Enterprise Mode Site List.

If you’re on IE11 and upgrading to Windows 10…

  • Use Enterprise Mode Site List to add sites to IE5, IE7, IE8, IE9, IE10, and IE11 modes as needed.
  • The x-ua-compatible meta tag and HTTP header will be ignored for all sites not in the Intranet zone. If you enable Turn on Internet Explorer Standards Mode for local intranet group policy, all sites, including those in the Intranet zone, will ignore x-ua-compatible. Look at your Enterprise Site Discovery data to see which modes your sites loaded in IE11 and add those sites to the same modes using the Enterprise Mode Site List tool.

We recommend that Enterprise customers focus their new development on established, modern Web standards for better performance and interoperability across devices, and avoid developing sites in older IE document modes. We often hear that due to the Intranet zone defaults to Compatibility View, IT Developers inadvertently create new sites in IE7 or IE5 modes in the Intranet zone, depending on whether they used a DOCTYPE. As you move your Web apps to modern standards, you can enable the Turn on Internet Explorer Standards Mode for local intranet group policy and add sites that need IE5 or IE7 modes to the Site List. Of course, testing is always a good idea to ensure these settings work for your environment.

Call to action for IT Developers

An IT Pro may ask you to update your site if it worked in an older IE version but no longer works in IE11. Here are the set of steps you should follow to find the right remediation:

Try Document Modes

Try to see if the site works in one of the following document modes: IE5, IE7, IE8, IE9, IE10, or IE11.

  • Open the site in IE11, load the F12 tools by pressing the ‘F12’ key or selecting ‘F12 Developer Tools’ from the ‘Tools’ menu, and select the ‘Emulation’ Tab.

'Emulation' tab in the IE11 F12 Developer tools

  • Try running the site in each document mode until you find one in which it works. You will need to make sure the user agent string dropdown matches the same browser version as the document mode dropdown. For example, if you were testing if the site works in IE10, you should update the document mode dropdown to “10” and the user agent string drop down to “Internet Explorer 10.”
  • If you find a mode where your site works, inform your IT Pro to add the site domain, sub-domain, or URL to the Enterprise Mode Site List in the document mode where the site works. While you can add the x-ua-compatible meta tag or HTTP header, this approach will only work in Windows 10 for sites in the Intranet zone when the Turn on Internet Explorer Standards Mode for local intranet group policy is not enabled.

Try Enterprise Mode

If a document mode didn’t fix your site, try Enterprise Mode. Enterprise Mode only benefits sites written for IE5, IE7, and IE8 document modes.

  • Enable the Let users turn on and use Enterprise Mode from the Tools menu group policy setting locally on your machine. You can do this by searching and running gpedit.msc, going to ‘Computer Configuration’ ‘Administrative Template’ ‘Windows Components’ ‘Internet Explorer’, and enabling the Let users turn on and use Enterprise Mode from the Tools menu group policy setting. After making this change, run gpupdate.exe /force to make sure the setting is applied locally. Make sure to disable this setting once you’re done testing. Alternately, you can use a regkey; see Turn on Enterprise Mode and use a site list for more information.
  • Restart IE11 and open the site you’re testing, then go to Emulation Tab in F12 tools and select “Enterprise” from the Browser profile dropdown. If the site works, inform your IT Pro that the site needs to be added to the Enterprise Mode section.

Try Compatibility View with Enterprise Mode

If Enterprise Mode doesn’t work, setting Compatibility View with Enterprise Mode will give you the Compatibility View behavior that shipped with IE8.

  • While browsing in Enterprise Mode, go to the ‘Tools’ menu and select Compatibility View Settings, and add the site to the list.
  • If this works, inform your IT Pro to add the site to both the Enterprise Mode section and the Use Policy List of Internet Explorer 7 sites group policy setting. Please note that adding the same Web path to the Enterprise Mode and docMode sections of the Enterprise Mode Site List will not work, but we are addressing this in a future update.

Update site for modern Web standards

If you have the time and budget, you should update your site for established, modern Web standards, so you don’t need to use compatibility offerings to make your site continue to work.

More Resources

For more information on all of these tools, please see the following resources:

As always, we suggest that consumers upgrade to the latest version and enable automatic updates for more secure browsing. If you use an older version of Internet Explorer at work, encourage your IT department to learn more the new backward-compatible features of Internet Explorer 11. Like many of our other customers, you may find that upgrading to the latest version of Internet Explorer is easier and less costly than previous upgrades. Best of all, the upgrade to Internet Explorer 11 can help ease your migration to Windows 10.

– Jatinder Mann, Senior Program Manager Lead

– Fred Pullen, Senior Product Marketing Manager