If you use the sideloading facility to install apps without using the Windows Store in Windows 8.1, the new Windows 8.1 Update adds two new features that possibly makes it more usable in an enterprise setting.

Side-loading overcomes the problem of needing to use the Windows Store as the source of Windows 8.1 apps. Most apps that users install will come from the Windows Store, but organizations that develop their own apps can install them directly using the ‘sideloading’ mechanism.

One improvement to the Windows 8.1 Update is the ability to use sideloading for all Windows 8.1 Pro devices that are joined to an Active Directory domain. This was already the case for companies running Windows 8.1 Enterprise. 

The features for sideloaded Windows Store apps mean they can operate with desktop processes, either apps or local services, outside the app container.

The first feature is the ability to use network loopback. Your app in the Windows store connects to a desktop service via a localhost address, which resolves to the local machine. Once connected, your app can send requests to and receive responses from the service as if that service were on a remote server.

The advantage this provides is that it means your app can perform actions that might otherwise be prevented by the Windows Store app sandbox or security model. You can also use existing business-logic code without having to rewrite it. T

he MSDN description of the new features, says that “this solution is especially helpful when the Windows Runtime app can be installed on both a remote device and the same PC that runs the desktop server”. It’s worth noting that apps that use network loopback will not be accepted in the Windows Store.

There is a whitepaper about this feature.

The second new feature is a brokering mechanism that allows you to mix desktop and Windows Store app code within the same app. This can be used both to use existing business-logic code, and also to use the Windows Store app UI and UX tools. The way this is being achieved is via a new project type that supports marshaling Windows Runtime types between Windows Store apps and desktop components by using an interprocess contract. There’s also a whitepaper about how this works. 

While the changes represent an improvement to the draconian way Windows 8 originally worked Microsoft is still assuming organizations are too stupid to work out which apps are acceptable for themselves.

As a comment on the Windows blog post about the announcement points out,

“the restrictions on which users are allowed to side load are still a major problem and make these technical advances unusable on a large number of our projects. For apps that aren't built only for an enterprise's internal use, we can't make assumptions about being domain joined or even being in an org where activation keys will be effectively  purchased and deployed. These restrictions, while better than 8.0, are still unnecessarily blocking adoption of the modern platform.”

The commenter, RLevy, makes the very valid point that the restrictions don’t help with security, because if desktop code has been sideloaded, whether or not a user can also sideload a companion modern app does not change how much damage a malicious desktop code could do. RLevy concludes

“make the sideloading policy for modern apps be the same as that for desktop apps - let organizations block it if they choose but by default, empower devs to exercise the migration path to the new platform.”

Of course this balance of security and usability is not confined to just Microsoft's app store. It is a problem that all app stores present to business use of their protected platform. 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info