Firefox3/Security Review Template: Difference between revisions
< Firefox3
Jump to navigation
Jump to search
mNo edit summary |
No edit summary |
||
| Line 3: | Line 3: | ||
''Describe the goals and objectives of the feature here.'' | ''Describe the goals and objectives of the feature here.'' | ||
Background links | ;Background links | ||
* feature-tracking bug links | * feature-tracking bug links | ||
* specs or design docs | * specs or design docs | ||
== Security and Privacy == | == Security and Privacy == | ||
| Line 12: | Line 11: | ||
* Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? | * Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing? | ||
* Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. | * Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project. | ||
== Exported APIs == | == Exported APIs == | ||
* Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.) | * Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.) | ||
| Line 18: | Line 18: | ||
* Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully? | * Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully? | ||
* Does it change any existing interfaces? | * Does it change any existing interfaces? | ||
== Module interactions == | |||
* What other modules are used (REQUIRES in the makefile, interfaces) | |||
== Data == | |||
* What data is read or parsed by this feature | |||
* What is the output of this feature | |||
* What storage formats are used | |||
== Reliability == | == Reliability == | ||
* What failure modes or decision points are presented to the user? | * What failure modes or decision points are presented to the user? | ||
* Can its files be corrupted by failures? Does it clean up any locks/files after crashes? | * Can its files be corrupted by failures? Does it clean up any locks/files after crashes? | ||
== configuration == | == configuration == | ||
| Line 34: | Line 36: | ||
* What ranges for the tunable are appropriate? How are they determined? | * What ranges for the tunable are appropriate? How are they determined? | ||
* What are its on-going maintenance requirements (e.g. Web links, perishable data files)? | * What are its on-going maintenance requirements (e.g. Web links, perishable data files)? | ||
== Relationships to other projects - are there related projects in the community? == | == Relationships to other projects - are there related projects in the community? == | ||
* If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa? | * If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa? | ||
* Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? | * Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose? | ||
Revision as of 18:01, 23 July 2008
Overview
Describe the goals and objectives of the feature here.
- Background links
- feature-tracking bug links
- specs or design docs
Security and Privacy
- What security issues do you address in your project?
- Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?
- Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.
Exported APIs
- Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)
- Does it interoperate with a web service? How will it do so?
- Explain the significant file formats, names, syntax, and semantics.
- Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?
- Does it change any existing interfaces?
Module interactions
- What other modules are used (REQUIRES in the makefile, interfaces)
Data
- What data is read or parsed by this feature
- What is the output of this feature
- What storage formats are used
Reliability
- What failure modes or decision points are presented to the user?
- Can its files be corrupted by failures? Does it clean up any locks/files after crashes?
configuration
- Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?
- Are there build options for developers? [#ifdefs, ac_add_options, etc.]
- What ranges for the tunable are appropriate? How are they determined?
- What are its on-going maintenance requirements (e.g. Web links, perishable data files)?
- If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?
- Are you updating, copying or changing functional areas maintained by other groups? How are you coordinating and communicating with them? Do they "approve" of what you propose?