microsoft, professional, software development

Microsoft appeals to Windows 8 Metro developers not to stray from the official API

6 Comments

Microsoft’s John Hazen has posted on the official Building Windows 8 blog about the security and reliability principles in the Metro platform in Windows 8. Hazen explains how apps are installed from the Windows store, use contracts to interact with the operating system, and have to ask user consent for access to device capabilities such as the webcam or GPS, or to access user data such as documents and music.

The most intriguing part of the document comes when Hazen appeals to developers to stick to the API that is referenced in the official Windows 8 Metro SDK:

Resist the temptation to find ways to invoke APIs that are not included in the SDK. This ultimately undermines the expectations that customers have for your app. APIs that are outside the SDK are not guaranteed to work with Metro style apps either in this release or in future releases, so you may find that your app doesn’t function properly for all customers. These APIs may also not function properly in the async environment that is foundational to Metro style app design. Finally these APIs may undermine customer confidence by accessing resources or data that Metro style apps would not normally interact with. For all these reasons, we have provided checks in the Windows App Certification Kit to help you catch places where you might have inadvertently called interfaces not exposed by the SDK.

While it is possible to hide or obfuscate calls to APIs that are not included in the SDK, this is still a violation of customer expectations and Store policy. In the end, we have created this platform to help developers like you to build amazing apps that work well with the system and with other apps and devices to delight customers. Working with the Metro style SDK is fundamental to your realizing that goal.

The worrying aspect of this appeal to developers to play nice is Hazen’s admission that crafty developers may find ways to escape the Metro sandbox, undermining both the security and the privacy protection built into Metro. The main protection against this is such such an app should be blocked from the Windows Store, but can Microsoft check with 100% confidence that no hidden or obfuscated API calls exist? How effective is the Metro sandbox?

My guess is that the danger will be greater on the x86 version of Windows 8 than in Windows RT, which is locked down to prevent any third-party desktop applications from being installed. Nevertheless, a large part of the non-Metro Windows API must exist in Windows RT, to support the desktop, Explorer and Microsoft Office.

6 thoughts on “Microsoft appeals to Windows 8 Metro developers not to stray from the official API”

  1. This indeed sounds like there is no sandboxing involved, and that you can even end up using those other APIs without knowing you do, no hacking involved… And the tool to check the issues sounds rather primitive if it can’t catch “obfuscated” calls… This is a managed environment after all…

    Does this really mean that the runtime environment is leaking like a sieve from a security POV, and isn’t even trying?

  2. So, anybody got a demo of a Metro application spawning, say, a Shell Common File Dialog? Just for laughs anyway.

  3. As Microsoft has proudly emphasized, WinRT is pure native code on both platforms. Under the hood it’s simply COM with some tweaks. So I expect there are plenty of system libraries and functions that you can link to, even though you shouldn’t…

  4. “This indeed sounds like there is no sandboxing involved, and that you can even end up using those other APIs without knowing you do, no hacking involved… And the tool to check the issues sounds rather primitive if it can’t catch “obfuscated” calls… This is a managed environment after all…

    Does this really mean that the runtime environment is leaking like a sieve from a security POV, and isn’t even trying?”

    No, there is sandboxing involved at a low level (the AppContainer) but that doesn’t enforce restrictions on API access, just restrictions on system/resource access.

  5. To be clear: the security restrictions on store apps are separate from the API restrictions on store apps. AppContainers are a general system mechanism, desktop apps can use them too to sandbox their plugins or whatever. (IE10 uses it for “Enhanced Protected Mode”).

    “Metro” really isn’t a separate system or separate mode that runs alongside, on top of or underneath the existing system, it’s just a set of features added to the existing system.

Comments are closed.