Labs/Jetpack/Security Requirements

The following are the characteristics that Jetpack's security model must possess:

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

• Simple Things Stay 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.

• Overcoming Barriers Must Be 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.

• 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++.