874
edits
Labs/Jetpack/Security Requirements: Difference between revisions
Labs/Jetpack/Security Requirements (view source)
Revision as of 17:51, 28 August 2009
, 28 August 2009rewording
(Origination) |
m (rewording) |
||
| Line 11: | Line 11: | ||
* '''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. | * '''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 [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 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—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. | * '''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". | :::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". | ||