Android (and Chrome OS?) security model

http://d.android.com/guide/topics/security/security.html

"A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or e-mails), reading or writing another application's files, performing network access, keeping the device awake, etc. ... An application's process is a secure sandbox. It can't disrupt other applications, except by explicitly declaring the permissions it needs for additional capabilities not provided by the basic sandbox. These permissions it requests can be handled by the operating in various ways, typically by automatically allowing or disallowing based on certificates or by prompting the user. [...]

All Android applications (.apk files) must be signed with a certificate whose private key is held by their developer. This certificate identifies the author of the application. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates. The certificate is used only to establish trust relationships between applications, not for wholesale control over whether an application can be installed. The most significant ways that signatures impact security is by determining who can access signature-based permissions and who can share user IDs. [...] Each Android package (.apk) file installed on the device is given its own unique Linux user ID [...]

 At application install time, permissions requested by the application are granted to it by the package installer, based on checks against the signatures of the applications declaring those permissions and/or interaction with the user. No checks with the user are done while an application is running: it either was granted a particular permission when installed, and can use that feature as desired, or the permission was not granted and any attempt to use the feature will fail without prompting the user. [...]

To enforce your own permissions, you must first declare them in your AndroidManifest.xml using one or more <permission> tags.

For example, an application that wants to control who can start one of its activities could declare a permission for this operation as follows:[...]  telling the system how the user is to be informed of applications requiring the permission, or who is allowed to hold that permission, as described in the linked documentation.[...]"

I think this kind of model is the future of security on consumer operating systems.  The Unix/Windows style ACL model was designed to protect the system and the administrator from users, not to protect users from programs, and the attempt to use it for the latter purpose by having admins do most of their work as standard user and elevate to root when necessary (either manually or through some automated system like gksudo or UAC) is basically a hack.  It doesn't provide all the protection that users need (e.g. doesn't protect their personal data, only system data), and it doesn't make sense to them because it doesn't make sense.  That's why UAC was rejected on Windows (it was only accepted on Linux and Mac because their users are cultists).  Meanwhile, the iPhone model of locking down everything will eventually start to be seen as too restrictive even among the general public.

I bet, and hope, Chrome OS will use a similar model, and also that this will spur Microsoft to follow suit.  I think Midori is based on capability security so let's hope it comes out of incubation sooner than later, and/or aspects of it are incorporated into Windows in advance.