Firefox 3.6/AboutSupport Security Review: Difference between revisions
Jump to navigation
Jump to search
Line 7: | Line 7: | ||
* feature-tracking bug links | * feature-tracking bug links | ||
* specs or design docs | * specs or design docs | ||
* [[Firefox/Projects/about:support]] | |||
* [http://bugzilla.mozilla.org/show_bug.cgi?id=367596|Bug 367596: Create about:support page with troubleshooting information (e.g. list of extensions)] | * [http://bugzilla.mozilla.org/show_bug.cgi?id=367596|Bug 367596: Create about:support page with troubleshooting information (e.g. list of extensions)] |
Revision as of 23:50, 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
- 367596: Create about:support page with troubleshooting information (e.g. list of extensions)
- 516616: Add an "Installation History" section to about:support.
- 516617: Add an "Update History" section to about:support.
- 517312: FUEL: Application.prefs.all takes longer and longer each time you call it
- 518601: Troubleshooting Information page should not allow copy-and-paste of the profile directory.
- 518606: Troubleshooting Information page should have better support for copy-and-paste to plaintext.
- 518607: Move the Troubleshooting Information page into toolkit so other apps like Thunderbird and SeaMonkey can use it.
- 518989: Themes cannot give about:support an original design
- 519077: Do something about the modified prefs list on about:support (remove it, only display certain items, or add some type of warning)
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?