The problem likely is that part of the public API is in DLLS that use a private API to talk to the system. For example, public class AddressBook extends AddressBookBase, with 'Base' having a couple of private fields that may come in handy.

Third parties could figure out that private API and call it themselves.

I do not think it is practical to defend the system against thos. Moving that base class into the kernel takes performance and includes its own security risks. Shipping multiple versions of the OS with different layouts or even implementations for such subclasses might help a bit, but also would open the system for bugs that show up on only 1/N of the machines.

The sandbox (AppContainer) and the SDK API restrictions are two separate things. Capabilities and isolation are enforced by the AppContainer, not the set of available APIs. AppContainer is actually a general system feature that can be used by desktop apps too to sandbox plugins and such (IE10 uses it in "Enhanced Protected Mode").

Windows 8 Metro apps can be written in real C++. How could they sandbox a custom C++ app? There's no virtual machine to do it.

http://msdn.microsoft.com/en-us/library/windows/apps/hh46504...

You don't need a virtual machine to sandbox C++; or rather, there's already a virtual machine in action, in the form of virtual memory and CPU privilege levels. The only way C++ (or any other native language) has to access to the outside its world is through calls to the kernel. Without direct file I/O APIs, options are even more limited (e.g. you can't easily write your own DLL loader).

OS X/iOS use a 'sandbox' driver that utilizes TrustedBSD MAC infrastructure ( https://developer.apple.com/library/mac/#documentation/Darwi... ). Basically, most system calls can be verified against one or more policy modules, and blocked if non-compliant. Not really possible with Windows and its bajillion of syscalls (1000 in win32k alone afair)

>How could they sandbox a custom C++ app? There's no virtual machine to do it.

They could use NaCl [1] or develop a similar SFI technology just for Windows.

[1] http://en.wikipedia.org/wiki/Google_Native_Client

It may be C++ but it is managed C++ that runs on the above the WinRT layer just like C#, and Javascript for metro. It will have the same restrictions as the other languages. It is actually interesting, in fact when you start a metro project at least in beta, you get the WinRT libraries and that's it. A ton of the traditional .NET classes have been moved into the WinRT library or removed all together.

Virtual machine is not required for sandboxing C++ apps in 21st century.

[1] http://code.google.com/p/nativeclient/

[2] http://www.cl.cam.ac.uk/research/security/capsicum/

It's C++/CX. It's not just "real C++".

They can be written in ISO C++ (or if you're a masochist, in C) as well, just without some conveniences.

isn't it the same that happens on iOS ?

Yes, this is exactly the same (or at least awfully similar). iOS has some APIs that are technically available to 3rd parties, but disallowed by the terms of service. It was news in 2008 when Google Mobile violated the guidelines to access some useful features.

http://daringfireball.net/2008/11/google_mobile_uses_private...

(Disclaimer: I work for Microsoft, though not on Windows.)

Doesn't look like that: http://www.apple.com/iphone/business/docs/iOS_Security_Mar12...