Blue's Clues: How to enable WebGL in Internet Explorer 11

Last week, web developer Francois Remy published an initial analysis of Internet Explorer 11 -- the next version of IE that surfaced via a leaked copy of Windows "Blue". In his analysis, he noted that he found references to various WebGL APIs but ultimately wrote them off as non-functional.

Picking up where Remy left off, I dug a little deeper and discovered WebGL support is indeed incomplete but is coming and can be enabled for experimentation. (Paul Thurrott has the background on why Microsoft has been hesitant to adopt this technology to date.)

Yep, that's Internet Explorer 11 with WebGL code running!

Yep, that's Internet Explorer 11 with WebGL code running!

To enable WebGL, just execute the registry script below and restart Internet Explorer 11. You may also want to ensure you install the latest vendor-provided display drivers. (Inbox drivers don't typically provide much in the way of OpenGL support.)

Update 3/31: Remy has discovered that the FEATURE_WEBGL_HLSL_SHADERS flag actually instructs IE 11 to use IESL vs. the more standard OpenGL GLSL. If you leave that at zero, you'll run in a configuration that more closely matches what's out there today. I edited the script below to reflect this.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl]

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBGL]

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_WEBGL_HLSL_SHADERS]

To reproduce the blue WebGL screenshot above, cut/paste this sample code into an .html file and display it in IE 11.

<body onload="demo()">
<canvas style="height: 100%; width: 100%" id='webgl' />

var gl = {};
function demo()
  var canvas = document.getElementById("webgl");
    gl = canvas.getContext("experimental-webgl");
  } catch(e) { }

  if (gl) {
    gl.clearColor(0, 0.678, 0.937, 1.0);

Blue's Clues: Sync more with Windows "Blue"


As Paul posted, Microsoft is adding the Start Screen to the list of features synchronized between your Windows PCs.

But that's not the only addition.

Rummaging around in the registry reveals a heap of new additions, a couple of which I'll cover briefly below.

Internet Explorer Tracking Protection and tabs

Internet Explorer will be syncing its tab and Tracking Protection configuration to the cloud, allowing you to take your browser experience on the go -- perhaps with, say, Windows Phone?

Device Associations

Pairing your laptop with a device, say a Bluetooth keyboard, can be a surprisingly onorous task. But "Blue" will only require you do this once, syncing the association with the cloud and enabling you to move your devices to and from your PCs with ease.

Other synchronized items include:

  • Picture Password
  • File History
  • Input Personalization
  • Explorer Quick Links
  • App Secondary Tiles
  • Tethering
  • Installed Apps

You can check out the raw Settings Sync provider configuration in the registry at:

HKLM\Software\Microsoft\Windows\CurrentVersion \SettingSync\WindowsSettingHandlers.

Blue's Clues: IE 11 Desktop to get IE 11 Metro swipe navigation

Just a few days ago, an early build of Windows 8 "Blue" leaked to the Internet. In the past, Paul and I would collaboratively write up a feature and feed both of our blog machines. For "Blue", we will instead write separate but complementary posts where Paul focuses on the end-user while I stick to the technical grit.

As Paul notes, Internet Explorer 11 Desktop now features a swipe-based navigational feature, similar to the one found in the "Metro" versions of the browser.

But it's not enabled by default nor configurable via the UI yet. You can enable this feature via Internet Options -> Advanced -> Turn on the swiping motion on Internet Explorer for the desktop.

So to play with this feature, navigate -- using the Registry Editor -- to HKCU\Software\Microsoft\Internet Explorer\DesktopSwipe and set the Enabled value to 1.

A restart of Internet Explorer 11 is required.

Dissecting the //build/ Badge (Part 2)

A little under a month ago, I dissolved Paul Thurrott's //build/ badge to reveal an embedded NFC integrated circuit (IC). But I had to stop short of actually reading its data due to the lack of a proper NFC reader. (Windows Phone 8 doesn't give you raw NFC access.) I purchased an ACS ACR122T and after weeks of waiting and experimenting I can now complete the story. So, let's start off with a correction. In Part 1, I incorrectly guessed that the IC was a MIFARE Ultralight. Turns out, it's an older MIFARE Classic 1K complete with key-based security. But before I wrote the IC off as encrypted and inaccessible, I learned that these ICs were compromised back in 2008 -- with a card-only attack following in early 2009.

Let's take a brief moment to talk about these keys.

Without getting too technical, these NFC ICs have chunks of data. Each chunk of data can be secured via a pair of keys -- A and B. Each of these keys can be used separately to access the data it protects. (For example, you may give a read-only key A to conference vendors, while maintaining the read-write key B for administrative purposes.)

Back to the badge.

Without access to an authorized //build/ badge reader, I had to use a software implementation (mfcuk) of the card-only attack I mentioned earlier to recover keys A and B. After weeks of painfully fiddling with the timings of the attack, I successfully recovered key B on one chunk of data. (I then made quick work of the rest of the keys/chunks using another attack [mfoc].)

Key A was recovered but isn't worth sharing because it appears to be unique per badge. (Tested with two badges.) Key A is usually programmed as a read-only key -- presumably for vendors on the conference floor. But given its uniqueness I'm confused as to how vendors would obtain a valid key at scan time. Perhaps the readers were networked to a key management system? Or maybe Key A is computed at runtime using a mash of the badge unique ID and a shared secret? Or maybe there's a handful of keys per attendee group (e.g. media, student, presenter). What do you think?

Key B is static, thankfully. On two badges I examined, Key B was given write permissions card-wide. So I named it The //build/ Badge Administrative Key. That key is f4a9ef2afc6d.

Using the Badge Administrative Key, I dumped out the entire //build/ badge. Surprisingly, it's not empty! It contains the following information:

  • Two sets of identifiers(?) (6 digit, 4 digit) (e.g. 756552, 1269)
  • Badge Full Name
  • Badge Title
  • Full address
  • Phone number
  • Email address
  • Affiliation label, if applicable (e.g. Media)

So if you're planning to toss the badge into the trash, you may want first wipe the IC. An alternate solution involves hammering the shit out of the badge. But if you're a developer looking to dip into NFC, you may want to salvage the tag and format it to NDEF specs so you have something Windows Phone compatible to play with.

Regardless, case closed. Oh, and Paul -- Sorry about your badge, bro.