Firefox 3.6/AboutSupport Security Review: Difference between revisions
Jump to navigation
Jump to search
(Created page with '== Overview == ''Describe the goals and objectives of the feature here.'' ;Background links * feature-tracking bug links * specs or design docs == Security and Privacy == * Is …') |
|||
Line 1: | Line 1: | ||
== Overview == | == Overview == | ||
Create an in-content (non-web-accessible) about page that support (both SUMO and third party tech support) can use to help users with problems. | |||
Should include basics like profile location, OS, buildID as well as details like installed addons and plugins, values of certain prefs, etc. to help debug user issues. | |||
;Background links | ;Background links |
Revision as of 23:39, 15 October 2009
Overview
Create an in-content (non-web-accessible) about page that support (both SUMO and third party tech support) can use to help users with problems.
Should include basics like profile location, OS, buildID as well as details like installed addons and plugins, values of certain prefs, etc. to help debug user issues.
- Background links
- feature-tracking bug links
- specs or design docs
Security and Privacy
- Is this feature a security feature? If it is, what security issues is it intended to resolve?
- What potential security issues in your feature have you already considered and addressed?
- 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.
- How are transitions in/out of Private Browsing mode handled?
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)?
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?
- 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?