Service Workers: Going beyond the page

Ali and I announce Service Worker and Progressive Web App support on the Microsoft Edge blog:

We’re thrilled to announce that today’s Windows Insider build enables Service Workers by default in Microsoft Edge for the first time.

This is an exciting milestone for us and for the web! These new APIs allow the web to offer better experiences when devices are offline or have limited connectivity, and to send push notifications even when the page or browser isn’t open.

This milestone also establishes the foundation for full-featured Progressive Web App experiences in Microsoft Edge and the Microsoft Store. We’ve carefully tailored our implementation together with Windows and are excited to be the only browser on Windows 10 to provide push handling in the background to optimize for better battery usage. We’ll have more to share about PWAs on Windows in the weeks ahead, so be sure to stay tuned!

We believe Service Workers are a foundational new tool for the web with the potential to usher in a new golden age of web apps. You can try out web experiences powered by Service Workers in Microsoft Edge on starting with today’s Windows Insider release, 17063.

The state of the web

Not too long ago, the web’s capabilities were lagging behind what native apps could do. Browser vendors, standards bodies, and the web community have relentlessly attacked this gap over the last decade, with the goal of enabling richer web experiences.

A particularly egregious sore spot for the web has always been how it handled—or failed to handle—the lack of an internet connection, or a poor-quality connection. Offline and the web never really went well together—in most cases, we were given a frustrating error page that only made it clearer that the web’s greatest asset was also its greatest weakness: the internet. In contrast, native apps are typically designed to provide a good experience even while offline or experiencing spotty service.

On top of that, native apps can re-engage their users with push notifications. On the web, after the browser or the app disappears, so does your ability to deliver relevant information or updates to your users.

In the rearview: Application Cache

By 2012, we were able to do offline on the web by introducing a new standard: Application Cache (or App Cache for short). A site author could list URLs for the browser to keep in a special cache called the App Cache so that when you visited the page you would see something other than an infuriating error page that would make you want to smash your keyboard and throw it against the wall.

Unfortunately, this wasn’t the silver bullet we were looking for in terms of bringing offline to the web. There are more than a few well-documented limitations for App Cache that made it confusing and error prone for many users and web developers. The sum of it all was that there was little control in how the App Cache would work since most of the logic occurred behind-the-scenes in the browser.

That meant if you ran into an issue, it would be exceedingly difficult to understand how to resolve it. There was an obvious need for something that gave greater control to developers by offering the capabilities of App Cache but made it more programmatic and dynamic while doing away with many of its limitations that made it difficult to debug.

Hit Rewind

App Cache left a lot to be desired. For the next swing at enabling offline scenarios, it was clear that browsers needed to provide web developers true control over what would happen when a page and its sub-resources were downloaded, rather than having it automatically and transparently handled in the browser.

With the ability to intercept network requests from a page and to prescribe what to do with each, site authors would be able to respond back to the page with a resource that it could use. Before we get there, it seems that we would need to revisit one of the most fundamental aspects of the web: fetching a resource.

How fetching!

As you may recall from my last post on Fetch, we now have the fetch() method as well as the Request and Response primitives. As a refresher, here’s how you might retrieve some JSON data using the fetch API:

Every request that happens on a page (including the initial navigation, CSS, images, scripts and XHR) is defined as a fetch. The fetch() method (as shown in the code sample) is just a way to explicitly initiate a fetch, while implicit fetches occur when loading a page and all of its sub-resources.

Since we’ve unified the concepts of fetching resources across the web platform, we can provide site authors the chance to define their own behavior via a centralized algorithm. So, how do we pass that control over to you?

Service worker: the worker that serves

Web workers have long been a great tool to offload intensive JavaScript to a separate execution context that doesn’t block the UI nor interaction with the page. Given the right conditions, we can repurpose the concept of a web worker to allow a developer to write logic in response to a fetch occurring on a page. This worker wouldn’t just be a web worker, though. It deserves a new name: Service worker.

A service worker, like a web worker, is written in a JavaScript file. In the script, you can define an event listener for the fetch event. This event is special, in that it gets fired every time the page makes a request for a resource. In the handler for the fetch event, a developer will have access to the actual Request being made.

You can choose to respond with a fetch for the provided Request using the JavaScript APIs which returns a Response back to the page. Doing this essentially follows the typical browser behavior for that request—it’s not intrinsically useful to just do a fetch for the request, ideally it would be more useful if we save previous Response objects for later.

Cache it!

The Cache API allows us to look up a specific Request and get its associated Response object. The APIs give access to a new underlying key/value storage mechanism, where the key is a Request object and the value is a Response object. The underlying caches are separate from the browser’s HTTP cache and are origin-bound (meaning that they are isolated based on scheme://hostname:port) so that you cannot access caches outside of your origin. Each origin can define multiple different caches with different names. The APIs allow you asynchronously open and manipulate the caches by making use of Promises:

These caches are completely managed by the developer, including updating the entries and purging them when they’re no longer needed – this allows you to rely on what will be there when you may not necessarily be connected to the internet.

Although the Caches API is defined as part of the Service Worker spec, it can also be accessed from the main page.

So now you have two asynchronous storage APIs to choose from: Indexed DB and the Caches API. In general, if what you’re trying to store is URL-addressable, use the Caches API; for everything else, use Indexed DB.

Now that we have a way to save those Response objects for later use, we’re in business!

Back to the worker

With a service worker, we can intercept the request and respond from cache. This gives us the ability to improve page load performance and reliability, as well as to offer an offline experience. You can choose to let the fetch go through to the internet as is, or to get something from the cache using the Cache API.

The first step to using a service worker is to register it on the page. You can do this by first feature-detecting and then calling the necessary APIs:

As part of the registration, you’ll need to specify the location of the service worker script file and define the scope. The scope is used to define the range of URLs that you want the service worker to control. After a service worker is registered, the browser will keep track of the service worker and the scope it is registered to.

Upon navigating to a page, the browser will check if a service worker is registered for that page based on the scope. If so, the page will go on to use that service worker until it is navigated away or closed. In such a case, the page is said to be controlled by that service worker. Otherwise, the page will instead use the network as usual, and will not be controlled by a service worker.

Upon registration, the service worker won’t control the page that registered it. It will take control if you refresh the page or you open a new page that’s within its scope.

After initiating the registration of a service worker, it will go through the registration process. That will involve going through the different phases of its lifecycle.

The service worker lifecycle

Let’s unpack the different phases of the service worker’s lifecycle, starting with what happens once you try to register it:

  • Installing: This is the first step that any service worker goes through. After the JavaScript file has been downloaded and parsed by the browser, it will run the install event of your script. That’s when you’ll want to get everything ready such as priming your caches.

In the following example, the oninstall event handler in the service worker will create a cache called “static-v1” and add all the static resources of the page to the cache for later use by the fetch handler.

  • Installed: At this point, the setup is complete, and the service worker is awaiting all pages/iframes (clients) that are controlled by this service worker registration to be closed so that it can be activated. It could be potentially problematic to change the service worker for pages that are still actively using a previous version of the service worker, so the browser will instead wait until they’ve been navigated away or closed.
  • Activating: Once no clients are controlled by the service worker registration (or if you called the skipWaiting API), the service worker goes to the activating phase. This will run the activate event in the service worker which will give you the opportunity to clean up after the previous workers that may have left things behind, such as stale caches.

In this example, the onactivate event handler in the service worker will remove all caches that are not named “static-v1.”

  • Activated: Once it’s been activated, the service worker can now handle fetch and other events as well!

In this example, the onfetch event handler in the service worker will respond back to the page with a match from the cache if it exists and if there isn’t an entry in the cache, it will defer to making a fetch to the internet instead. If that fetch fails, it will resort to returning a fallback.

  • Redundant: The final phase of the service worker is when it is being replaced by another service worker because there’s a new one available that is going to take its place.

There’s more to it: the big picture

So far, we’ve explored the following service worker events: install, activate, and fetch. Install and activate are considered lifetime events while fetch is considered a functional event. What if we could expand on the service worker’s programming model and introduce other functional events that could plug in to it? Given that service workers are event-driven and are not tied down to the lifetime of a page, we could add other events such as push and notificationclick which would present the necessary APIs to enable push notifications on the web.

Push it to the limit

Push notifications provide a mechanism for developers to inform their users in a timely, power-efficient and dependable way, that re-engages them with customized and relevant content. Compared to current web notifications, a push notification can be delivered to a user without needing the browser/app or page to be opened.

The W3C Push API and Notification API go hand-in-hand to enable push notifications in modern browsers. The Push API is used to set up a push subscription and is invoked when a message is pushed to the corresponding service worker. The service worker then is responsible for showing a notification to the user using the Notification API and reacting to user interaction with the notification.

A standardized method of message delivery is also important for the W3C Push API to work consistently across all major browsers where application servers will need to use multiple push services. For instance, Google Chrome and Mozilla Firefox use Firebase Cloud Messaging (FCM) and Mozilla Cloud Services (MCS), respectively while Microsoft Edge relies on the Windows Push Notification Service (WNS) to deliver push messages. To reach reasonable interoperability with other browsers’ messaging services, WNS has now deployed support for the Web Push protocols being finalized within IETF, as well as the Message Encryption spec and the Voluntary Application Server Identification (VAPID) spec for web push. Web developers can now use the Web Push APIs and service workers to provide an interoperable push service on the web.

To start, you’ll first need to make sure your web server is setup to send pushes. The Web-Push open-source library is a great reference for anyone new to web push. The contributors have done a reasonable job in keeping up with the IETF specs. After starting up a node.js server based on the web-push library, you’ll need to setup the VAPID keys. Keep in mind that you’ll need to use HTTPS as it is required for service workers and push. You only need to set up the VAPID keys once which can be generated easily using the corresponding function in the web-push library.

Once that’s all sorted out, it’s time to take advantage of push in your site or app. Once the page loads, the first thing you’ll want to do is get the public key from the application server so that you can set up the push subscription.

With the public key in hand, as before, we’ll need to install the service worker, but this time, we’ll also create a push subscription.

Before a new push subscription is created, Microsoft Edge will check whether a user granted permission to receive notifications. If not, the user will be prompted by the browser for permission. You can read more about permission management in an earlier post about Web Notifications in Microsoft Edge. From a user’s perspective, it’s not obvious whether a notification will be shown via the page or through a push service, so we are using the same permission for both types of notifications.

To create a push subscription, you’ll need to set the userVisibleOnly option to “true” – meaning a notification must be shown as a result of a push – and provide a valid applicationServerKey. If there is already a push subscription, there is no need to subscribe again.

At any point when a push is received by the client, a corresponding service worker is run to handle the event. As part of this push handling, a notification must be shown so that the user understands that something is potentially happening in the background.

Of course, after a notification is shown, there is still the matter of dealing with when its been clicked. As such, we need to have another event listener in the service worker that would handle this case.

In this case, we first dismiss the notification and then we can choose to open a window to the intended destination. You’re also able to sort through the already open windows and focus one of those, or perhaps even navigate an existing window.

Push: The Next Generation

As part of our ongoing commitment to expanding the possibilities of the web, Microsoft Edge and PWAs in Windows will handle these service worker push event handlers in the background. That’s right, there’s no need for Microsoft Edge or your PWA to be running for the push to be handled. That’s because we’ve integrated with Windows to allow for a more holistic approach to push notifications. By leveraging Windows’ time-tested process lifetime management, we’re able to offer a system that reacts appropriately to system pressures such as low battery or high CPU and memory usage.

For our users it means better resource management and battery life expectations. For our developers, it means a push event handler that will get to run to completion without interruption from a user action such as closing the browser window or app. Note that a service worker instance that is running in the foreground for the fetch event will not be the same as the one in the background handling the push event.

Notifications in Microsoft Edge and PWAs will be integrated in the Windows Action Center. If you receive a notification and didn’t get the chance to act on it, it will get tucked away into the Action Center for later. That means that notifications never get left unseen. On top of that, the Action Center will group multiple notifications coming from the same domain so that users have an easier time sorting through them.

Service worker: properties

I’d like to take a moment to go over some things you should keep in mind when using service workers in your web app or site. In no particular order, here they are:

  • HTTPS-only. Service workers will not work in HTTP; you will need to use HTTPS. Fortunately, if you’re testing locally, you’re allowed to register service workers on localhost.
  • No DOM access is allowed. As with web workers, you don’t get access to the page’s object model. This means that if you need to change something about the page, you’ll need to use postMessage from the service worker to the page so that you can handle it DOM changes from the page.
  • Executes separate from page. Because these scripts are not tied to the lifetime of a page, it’s important to understand that they do not share the same context as the page. Aside from not having access to the DOM (as stated earlier), they won’t have access to the same variables available on the page.
  • Trumps App Cache. Service workers and App Cache don’t play well together. App Cache will be ignored when service worker is in use. Service workers were meant to give more control to the web developer. Imagine if you had to deal with the magic of App Cache while you’re trying to step through the logic of your service worker.
  • Script can’t be on CDN. The JavaScript file for the service worker can’t be hosted on a Content Distribution Network (CDN), it must be on the same domain as the page. However, if you like, you can import scripts from your CDN.
  • Can be terminated any time. Remember that service workers are meant to be short-lived and their lifetime is tied to events. In particular, service workers have a time limit in which they must finish executing their event handlers. In other cases, the browser or the operating system may choose to terminate a service worker that impacts the battery, CPU, or memory consumption. In either case, it would be prudent to not rely on global variables in the service worker in case a different service worker instance is used on a subsequent event that’s being handled.
  • Only asynchronous requests allowed. Synchronous XHR is not allowed here! Neither is localStorage, so it’s best to make use of Indexed DB and the new Caches API described earlier.
  • Service worker to scope is 1:1. You’ll only be able to have one service worker per scope. That means if you try to register a different service worker for a scope that already has a service worker, that service worker will be updated.

Recap

As you can see, service workers are so much more than an HTTP proxy, they are in fact a web app model that enable event-driven JavaScript to run independent of web pages. Service workers were brought in to the web platform as a necessity to solve offline, but it’s clear that they can do so much more as we continue to extend their capabilities to solve other scenarios. Today we have push, but in the future, there will be other exciting capabilities that will bring the web that much closer to offering the captivating and reliable experiences we’ve always wanted.

Go put a worker to work!

So, what are you waiting for? Go and install the latest windows insider preview build and test out service workers in Microsoft Edge today. We’d love to hear your feedback, so please file bugs as you see them!

— Ali Alabbas, Program Manager, Microsoft Edge
— Jatinder Mann, Program Manager, Microsoft Edge

Advertisements

Get better quality video with Microsoft Edge

My team and I wrote this post on the Window Experience blog:

When it comes to video, the closer to the hardware, the better.  From video hardware acceleration to PlayReady Content Protection and the Protected Media Path, Windows 10 is designed to provide the highest quality, most secure, and most power-efficient video playback available on any version of Windows.  Microsoft Edge has been engineered to optimize for and take advantage of these Windows 10 built-in media capabilities, providing the best video experience of any browser on Windows 10 based on our data and testing. So go ahead, binge watch your favorite shows on Microsoft Edge!

Most Power Efficient Video Playback

As we recently blogged, you get more out of your battery with Microsoft Edge.  This time-lapse video test shows Microsoft Edge lasting three hours longer than Google Chrome streaming the same content side by side on identical Surface Book machines.  Our results have shown that Microsoft Edge outlasts the rest, delivering 17%-70% more battery life than the competition. Today, we are publishing details on the test methodology that was used and in this post, we’ll dig into the technologies that make Microsoft Edge so much more efficient.

Battery life comparison

Microsoft Edge has the most power efficient video playback because it was engineered to take advantage of Windows 10 platform features that keep the CPU in low power states during video playback.  It does this by offloading CPU intensive video processing operations to power efficient peripheral hardware found in modern PCs and mobile devices. This starts with the use of Microsoft DirectX video acceleration (DXVA) to offload decoding of compressed video.  For rendering, Microsoft Edge also works with Multiplane overlay display hardware and sophisticated graphics and UI compositing features to offload video rendering operations. This significantly reduces memory bandwidth required for video processing and compositing at the display.

CPU management in the Windows 10 media stack keeps the CPU running in the lowest power states possible, without compromising UI responsiveness.  It is also able to run the display at lower refresh rates during full screen playback of film based content.  This saves power by reducing memory bandwidth and improves the quality of film playback by reducing video judder caused by the conversion of the film frame rate (24 Hz, for example) on displays running at 60 Hz.  And Microsoft Edge also takes advantage of a feature of the Windows 10 audio stack to offload audio stream processing from the main CPU to dedicated power-efficient audio processing hardware.

Power savings from these features are available to other browsers, but it requires other browser vendors to optimize performance on Windows devices, while Microsoft Edge was designed to provide these power savings innately.  And to be clear, the power difference playing higher quality content, like 1080p, becomes even greater.  Tight integration with Windows media, graphics, and composition stacks allows Microsoft Edge to render the highest quality content with minimal power draw.

Higher Quality Video

In our video tests, not only was Microsoft Edge the most power efficient, but the premium video site we used also sent higher resolution and bitrate video to Microsoft Edge compared to the other browsers.  Here are the details:

Maximum Resolution Maximum Bitrate
Microsoft Edge (EdgeHTML 13.10586) 1080p 7500
Opera 38 720p 4420
Mozilla Firefox 46 720p 4420
Google Chrome 51 720p 4420

The fact that Microsoft Edge received 1080p content in our power test means it actually ran a somewhat higher power draw than it otherwise would have playing 720p content like the other browsers.  Microsoft Edge provided the highest quality content and also delivered the longest battery life.

Content owners that stream premium video on the web need to make choices that balance providing the best quality possible, while also ensuring that the content is protected.  As quality increases, so does the need for strong Digital Rights Management (DRM), systems that protect media streams so that they can only be played by users authorized by the streaming service.  This is important now as companies make decisions to stream 1080p, and will become even more important as video resolutions increase. Content owners will not stream premium content if it can be easily saved and shared outside the service.

Microsoft Edge was built to take advantage of platform features in Windows 10.  It is optimized to use PlayReady Content Protection and the media engine’s Protected Media Path, whereas Chrome and Opera implement Widevine, and Firefox implements both Adobe Access and Widevine.  Like video decode efficiency, content protection in the platform and closer to the hardware can offer superior performance.  Likewise, the better the content protection, the better the video quality the service is likely to provide to that browser.

What Does the Future Hold?

Displays have already moved beyond Full HD/1080p to UltraHD/4K video.  Upcoming improvements to audio and video quality go beyond just more audio channels and more pixels.  We will see an increase in the number and intensity of colors displayed (color gamut), higher frame rate, high dynamic range (HDR) and broad availability of immersive, spatial or 3-D audio. In the Alliance for Open Media, Microsoft and other leading internet companies are developing next-generation media formats, codecs and other technologies for UltraHD video.

Microsoft is working with industry leading graphics chipset companies to expand support for hardware acceleration of new higher quality content.  We are also working with chipset companies to support Enhanced Content Protection that moves the Protected Media Path into peripheral hardware for an even higher level of security.  The code running in the peripheral is isolated from the main OS, which provides an increased level of protection, and will likely enable content owners to stream 4k or higher resolution video with confidence.  We call the improved security from hardware based DRM “Security Level 3000”.

Chipsets that support hardware based DRM have been shipping in newer PCs.  The full support system awaits completion of software components that are coming in Fall of 2016.  The Windows 10 platform has significant power and security advantages for media playback available to any application.  Paired with the media features built into Windows 10, Microsoft Edge has best-in-class battery life and video playback quality on Windows 10 devices, including PCs, Mobile, Xbox, HoloLens, and other devices.

Let us know what you think over at @MSEdgeDev!

  • Jatinder Mann, Senior Program Manager Lead, Microsoft Edge
  • Jerry Smith, Senior Program Manager, Microsoft Edge
  • John Simmons, Principal Program Manager, Windows Media

Managing Microsoft Edge in the enterprise

In this Microsoft Edge blog post, we discuss Microsoft Edge manageability options for Enterprise customers:

At last year’s Microsoft Ignite conference, we introduced the enterprise story for the web on Windows 10. Microsoft Edge is designed from the ground up to provide a modern, interoperable, and secure browsing experience; in addition, Internet Explorer 11 is also a part of Windows 10 to help bring all your legacy line of business (LOB) applications forward.

Microsoft Edge and Internet Explorer 11 work together to help ease IT management overhead, and also provide a seamless user experience for your users. In this post, we’ll walk through the policies you can use to manage Microsoft Edge in the enterprise for both PCs and mobile devices, including some new policies coming in the Windows 10 Anniversary Update.

Policies currently supported in Microsoft Edge

With Microsoft Edge, we set out to provide a simple, consistent set of scenario-driven management policies to help manage Windows 10 browser deployments on both desktop and mobile. The policies for Microsoft Edge on desktop are available as both Group Policy settings and MDM settings. On mobile they are available as MDM settings.

Here is a summary of all the policies supported by Microsoft Edge grouped by Windows 10 releases:

  • Available in Windows 10 version 1507 or later:
    • Configure Autofill
    • Configure Cookies
    • Configure Do Not Track
    • Configure Password Manager
    • Configure Pop up Blocker
    • Configure search suggestions in the Address bar
    • Configure the Enterprise Mode Site List
    • Configure the SmartScreen Filter
    • Send all intranet sites to Internet Explorer 11
  • Available in Windows 10 version 1511 or later:
    • Allow Developer Tools
    • Allow InPrivate browsing
    • Allow web content on New Tab page
    • Configure Favorites
    • Configure Home pages (see additional note below)
    • Prevent bypassing SmartScreen prompts for files
    • Prevent bypassing SmartScreen prompts for sites
    • Prevent sharing LocalHost IP address for WebRTC

What’s new in Windows 10 Anniversary update

We have added support for the following new Microsoft Edge management policies as a part of the Windows 10 Anniversary Update:

  • Allow access to the about:flags page
  • Allow usage of extensions
  • Show a transitional message when opening Internet Explorer sites

We’ve made a few updates to existing policies based on feedback from customers.  First, all of the Microsoft Edge Group Policy settings on desktop are now available in both the User and Machine policy hives. Second, the home page policy configured on a domain-joined device will no longer allow the user to override the setting.

You can find further details on all Microsoft Edge policies on TechNet, including info about Windows 10 policies that also apply to Microsoft Edge, such as Cortana and Sync settings. Your feedback is important to us, so please let us know what you think or if you have any questions about these changes!

– Dalen Abraham, Principal Program Manager Lead

– Jatinder Mann, Senior Program Manager Lead

– Josh Rennert, Program Manager

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