Extension Manager:Security Review
Status
- Feature tracking bug
- bug 257155 - Support shipping of localized user-facing addon text
- bug 391730 - Add-ons Manager Plugins UI for Firefox 3.0
- bug 252830 - Blocked XPI install should have allow once feature
- bug 369075 - Add permanent button for restarting Firefox to Add-ons Mgr
- bug 297903 - Extension updates should link to further information
- bug 384956 - Provide access to extension options from app options
- bug 378216 - Disable insecure extension updates by default
Has a design review been completed? The UX team, Pike and dveditz have reviewed relevant aspects of the features though nothing so formal as a design review has occurred.
When do you anticipate the feature landing The main parts of all of the above have new landed with some final fixes still to be implemented.
Overview
Describe the goals and objectives of the feature here. Goals for the new work:
- Simplify the installation and management of all types of add-ons where possible
- Present information about add-ons in an appropriate locale for the user at all times
- Provide the user with more information about updated add-ons and protect them from installing updates insecurely
Use Cases
Describe the primary use cases for the feature here.
Requirements
List functional and non-functional requirements for the feature here, with links back to any relevant product PRD. These requirements should be prioritized. PRD: http://wiki.mozilla.org/Firefox3/Product_Requirements_Document#Add-ons
Schedule
Describe the rough schedule here, linking back to relevant product release milestones, as well as linking to any build/release notes. The restart button and l10n work landed for alpha 6, the other parts landed for alpha 8. Specific bugs have the target milestone set appropriately.
UI Design Documentation
use cases and expected user knowledge (terminology, metaphors, etc) design mockups (of whatever fidelity is easiest) links to relevant user data, bugs, reports, examples, etc
Design Impact
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?
Web Compatibility
- Does the feature had any impact on Web compatibility?
Performance
- How will the project contribute (positively or negatively) to "perceived performance"?
- What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?
- Will it require large files/databases (for example, browsing history)?
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?
l10n and a11y
- are any strings being changed or added?
- are all UI elements available through accessibility technologies?
Installation, Upgrade/Downgrade/Sidegrade, and platform requirements
- Does it equally support all Tier-1 platforms?
- Does is have a hardware requirement (or increase minimum requirements)?
- Does it require changes to the installer?
- Does it impact updates?
- list the expected behavior of this feature/function when Firefox is upgraded to a newer minor release, downgraded by installation of an earlier revision, or re-installed (same version)
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?
Documentation
- Do built-in Help pages need modified?
- Documentation for developer.mozilla.org?
Other
any other implementation or design related documentation
Discussion & Implications
Caveats / What We've Tried Before
links to previous design documents, discussions, etc.
References
links to external documents that could inform the design of the feature