Labs/Jetpack/Security Requirements

At minimum, Jetpack's security model must:

• Obey The Principle of Least Privilege. As outlined in the Wikipedia article, this is a standard security principle that all modern software needs to follow.

For end-users, Jetpack's security model should:

• Respect The User's Train of Thought. Users should never be presented with a modal dialog box that interrupts them and, worse still, makes it difficult for them to get back to something they were trying to do.

• Have An Agile UI. Security UIs will be a target for exploitation by black hats, so we need to be able to respond to new threats easily by changing it. Because security UIs are a relatively unexplored frontier, it should also be easy for developers to experiment with different kinds of security UIs.

• Leverage The User's Social Connections. Most non-technical people have friends and advisors whom they trust on technical matters; allowing them to easily delegate their security decisions to these individuals and organizations greatly facilitates this reasonable practice.

For developers, Jetpack's security model should:

• Keep Simple Things Simple. The target audience for Jetpack is the amateur developer, not a professional. Examples laid out in the Jetpack tutorial should still work fine even when security is in place.

This means, for instance, that it may be better to use static analysis or symbolic execution to infer the capabilities that a program requires—at least in the simple cases—rather than force the developer to create a security manifest.

It should be noted that more complex functionality, such as modules, may have a slightly higher barrier to entry because their security characteristics are necessarily more complex.

• Make Overcoming Barriers Discoverable. In situations where security is a necessity that presents a barrier to the developer, it must be easy for the developer to learn why the barrier is there and how to solve their problem securely.

For instance, when a XPCNativeWrapper denies access to a user-defined property on a wrapped object, rather than merely returning undefined, it should log a message or throw an exception that lets the developer know why their code can't access the user-defined property, and what options are available to access it.

• Be Secure By Default. The default way of creating a Jetpack feature—that is, the way that requires the least effort—must be secure. It should not be an "optional extra step" that developers are expected or encouraged to take.

The argument in favor of this can be stated economically: there's no incentive to take extra steps to make software secure when few people are using it, because nobody exploits software with no users: a developer's time would be better spent in the early stages of a project adding functionality that would make the program more useful for more people. Yet adding security as an afterthought—i.e., once the software is used by lots of people—is no good either, so effort should be made to make the platform and its API as secure as possible "out of the box".

A usability argument can also be made here: making the platform and API secure in the first place massively reduces the burden on the developer, which leads to a platform that's much easier to use. For example, compare memory-safe programming languages like Python and JavaScript to memory-unsafe ones like C and C++.