Future of Microsoft Edge

Faster Updates, Cross Platform, 4 Channels

Edge

 

Microsoft had made an announcement some time ago stating that they were adopting Chromium as the foundation of the Edge browser. They are making more information available about their plans. A computer will be able to have up to 4 Edge. In addition to the general release version there will be a beta , development, and canary channel where canary is the most experimental channel.

Microsoft is going to make a web view control available. This is a feature I wish had been available a couple of years ago. I worked on a project in which it was necessary to insert a Chromium based web view and that required making modifications to the Chromium source. Compiling Chromium can take hours!

Microsoft Edge is the only browser that has achieved a 100% score in accessibility evaluation. Microsoft is planning to make contributions to Chromium which should help improve the scores of Chromium based browsers across the board.  One example of a change coming from Microsoft is a media query for detecting when a user has turned on high contrast in either their computer or browser. The web developer can choose to change the appearance of a page accordingly.

Windows Biometric sign in is also going to be available to web sites (see navigator.credentials.get). This allows for a more secure way of logging in that doesn’t require a password. Edge also has a hardware backed feature named “Play Ready” that allows for secure playback of premium media.

The user agent-string for Edge Chromium will be Edg (that’s not a type, there is no E on the end). Note that the non-chromium version of edge uses the user token Edge instead. But it is recommended that instead of using the user agent string for enabling or disabling functionality in a web page it is better to use feature detection; new features are being added to browsers all the time and relying on the user agent alone can lead to a page not using a feature that was actually available within a browser.  Edge gets supports for module import and much better much better speech synthesis.

Obtaining the Connection String for a Provisioned Windows IOT Device

Playing with the code that I was using to get data from my car and stream it to the cloud I did something that I knew was a no-no; I hard coded the connection string in the code. There’s a number of reasons to not do this*; it’s less secure as someone can potentially extract the connection string and use it for unauthorized access and if the connection string ever needs to change then code needs to be recompiled and redeployed.

When a Windows IOT device is provisioned there is a connection string that is managed by the device; your application can take advantage of this and need not worry about the details of how it is stored. To make use of this there are a few libraries that you need to add to your UWP project. These include the followings.

  • Microsoft.Azure.Devices
  • Microsoft.Azure.Devices.Client
  • Microsoft.Devices.Tpm

With the classes in these libraries you can obtain the ID of the device and then use that ID to request an Azure DeviceClient class that is initialized with the connection string that the device is managing.

Here’s the code to do this.

DeviceClient _deviceClient;

void InitClient()
{            
    TpmDevice tpm = new TpmDevice(0);
    string hostName = tpm.GetHostName();
    string deviceId = tpm.GetDeviceId();
    string sasToken = tpm.GetSASToken();            
    var client = DeviceClient.Create(
        hostName, 
        AuthenticationMethodFactory.CreateAuthenticationWithToken(deviceId, sasToken),
        TransportType.Mqtt
    );
}