Labs/Jetpack/Security Requirements: Difference between revisions

Added more
m (rewording)
(Added more)
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
The following are the characteristics that Jetpack's security model must possess:
''At minimum'', Jetpack's security model must:


* '''Principle of Least Privilege'''.  As outlined in the [http://en.wikipedia.org/wiki/Principle_of_least_privilege Wikipedia article], this is a standard security principle that all modern software needs to follow.
* '''Obey The Principle of Least Privilege'''.  As outlined in the [http://en.wikipedia.org/wiki/Principle_of_least_privilege 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.
''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.
:::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.
Line 9: Line 19:
:::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.
:::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.
* '''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 [https://developer.mozilla.org/en/XPCNativeWrapper XPCNativeWrapper] denies access to a user-defined property on a wrapped object, rather than merely returning <tt>undefined</tt>, 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.
:::For instance, when a [https://developer.mozilla.org/en/XPCNativeWrapper XPCNativeWrapper] denies access to a user-defined property on a wrapped object, rather than merely returning <tt>undefined</tt>, 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&mdash;that is, the way that requires the least effort&mdash;must be secure.  It should not be an "optional extra step" that developers are expected or encouraged to take.
* '''Be Secure By Default'''.  The default way of creating a Jetpack feature&mdash;that is, the way that requires the least effort&mdash;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&mdash;i.e., once the software is used by lots of people&mdash;is no good either, so effort should be made to make the platform and its API as secure as possible "out of the box".
:::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&mdash;i.e., once the software is used by lots of people&mdash;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++.
874

edits