canmove, Confirmed users
1,570
edits
Extension Manager:Security Review: Difference between revisions
Jump to navigation
Jump to search
Extension Manager:Security Review (view source)
Revision as of 10:17, 22 October 2007
, 22 October 2007no edit summary
No edit summary |
No edit summary |
||
| Line 8: | Line 8: | ||
* {{bug|384956}} - Provide access to extension options from app options | * {{bug|384956}} - Provide access to extension options from app options | ||
* {{bug|378216}} - Disable insecure extension updates by default | * {{bug|378216}} - Disable insecure extension updates by default | ||
* {{bug|299716}} - Need for em:targetApplication marker for "the toolkit" | |||
'' Has a design review been completed?'' | '' Has a design review been completed?'' | ||
| Line 21: | Line 22: | ||
* Present information about add-ons in an appropriate locale for the user at all times | * 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 | * Provide the user with more information about updated add-ons and protect them from installing updates insecurely | ||
* Give add-on authors additional functionality | |||
== Use Cases == | == Use Cases == | ||
| Line 47: | Line 49: | ||
== Security and Privacy == | == Security and Privacy == | ||
'' What security issues do you address in your project?'' | |||
New work involves ensuring that MITM attacks cannot occur during the add-ons update process, this involves ensuring that updates are either delivered by ssl secured connections or have been signed by a cryptographic key pair, the public part of which is already known to the application. | New work involves ensuring that MITM attacks cannot occur during the add-ons update process, this involves ensuring that updates are either delivered by ssl secured connections or have been signed by a cryptographic key pair, the public part of which is already known to the application. | ||
'' Is system or subsystem security compromised in any way if your project's configuration files / prefs are corrupt or missing?'' | |||
The Add-ons manager attempts to recover in the event of corrupt/missing configuration files. | The Add-ons manager attempts to recover in the event of corrupt/missing configuration files. | ||
'' Include a thorough description of the security assumptions, capabilities and any potential risks (possible attack points) being introduced by your project.'' | |||
The ability to install extensions into the application is itself a potential risk since the extension runs as a privileged component of the application able to perform any operation that the regular application can. | The ability to install extensions into the application is itself a potential risk since the extension runs as a privileged component of the application able to perform any operation that the regular application can. | ||
| Line 62: | Line 64: | ||
== Exported APIs == | == Exported APIs == | ||
'' Please provide a table of exported interfaces (APIs, ABIs, protocols, UI, etc.)'' | |||
[http://mxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/public/nsIExtensionManager.idl nsIExtensionManager | [http://mxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/public/nsIExtensionManager.idl nsIExtensionManager] [http://mxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/public/nsIBlocklistService.idl nsIBlocklistService] | ||
'' Does it interoperate with a web service? How will it do so?'' | |||
The Add-ons manager retrieves update information about installed and add-ons to be installed from remote servers. This is done using the regular HTTP protocol retrieving a file in an RDF format as described in the [http://developer.mozilla.org/en/docs/Extension_Versioning%2C_Update_and_Compatibility#Update_RDF_Format update manifest documentation]. | The Add-ons manager retrieves update information about installed and add-ons to be installed from remote servers. This is done using the regular HTTP protocol retrieving a file in an RDF format as described in the [http://developer.mozilla.org/en/docs/Extension_Versioning%2C_Update_and_Compatibility#Update_RDF_Format update manifest documentation]. | ||
'' Explain the significant file formats, names, syntax, and semantics.'' | |||
Each add-on is delivered as an xpi file which is just a simple zip file. | Each add-on is delivered as an xpi file which is just a simple zip file. | ||
| Line 85: | Line 87: | ||
* extensions.cache contains a list of all the known add-ons together with state information about the last modified time and any operations waiting to be performed. This is used to increase startup performance by allowing the add-ons manager to avoid loading extensions.rdf unless necessary. | * extensions.cache contains a list of all the known add-ons together with state information about the last modified time and any operations waiting to be performed. This is used to increase startup performance by allowing the add-ons manager to avoid loading extensions.rdf unless necessary. | ||
'' Are the externally visible interfaces documented clearly enough for a non-Mozilla developer to use them successfully?'' | |||
yes | |||
'' Does it change any existing interfaces?'' | |||
There have been incremental updates to the [http://mxr.mozilla.org/seamonkey/source/toolkit/mozapps/extensions/public/nsIExtensionManager.idl nsIExtensionManager] interface as features were developed | |||
== Web Compatibility == | == Web Compatibility == | ||
'' Does the feature had any impact on Web compatibility?'' | |||
None | |||
== Performance == | == Performance == | ||
'' How will the project contribute (positively or negatively) to "perceived performance"?'' | |||
The Add-ons manager adds a small startup cost for evaluating existing add-ons and a larger cost if there are any operations to be performed (installs, uninstalls etc). '''Rob, do we have any metrics on this?''' | |||
Add-ons themselves generally impose a performance cost on Txul unfortunately increasing for every add-on installed. This can make an application running many add-ons perform significantly worse than one with no add-ons. | |||
'' What are the performance goals of the project? How were they evaluated? What is the test or reference platform and baseline results?'' | |||
'''Rob?''' | |||
'' Will it require large files/databases (for example, browsing history)?'' | |||
The largest of the state files (extensions.rdf) is not loaded on startup due to performance considerations. | |||
== Reliability == | == Reliability == | ||
'' What failure modes or decision points are presented to the user?'' | |||
The main failure presented to user is that of a failure to install an add-on which can happen for a variety of reasons (corrupt/invalid file, invalid application etc). | |||
Most other failures are hidden from the user, failure during automatic attempts to check for updates are not shown. | |||
'' Can its files be corrupted by failures? Does it clean up any locks/files after crashes?'' | |||
This is possible, {{Bug|396695}} is the main instance that users are experiencing. Generally the add-ons manager tries to operate safely even being able to rollback installs/uninstalls of add-ons in the event that the operation cannot complete successfully. | |||
== l10n and a11y == | == 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 == | == Installation, Upgrade/Downgrade/Sidegrade, and platform requirements == | ||
'' Does it equally support all Tier-1 platforms?'' | |||
Yes | |||
'' Does it have a hardware requirement (or increase minimum requirements)?'' | |||
No | |||
'' Does it require changes to the installer?'' | |||
No | |||
'' Does it impact updates?'' | |||
Yes, when performing an update check we have to check whether the installed add-ons are compatible with the updated version of the application. We must now not only check the version of the updated application but also the toolkit version of the updated application. | |||
'' 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)'' | |||
Reinstalling the same version should not have any effect. Installing a different version of the application should cause the Add-ons manager to disable any installed add-ons not compatible with the new version and enabled any add-ons that are now compatible. | |||
== configuration == | == configuration == | ||
'' Can the end user configure settings, via a UI or about:config? Hidden prefs? Environment variables?'' | |||
The only relevant setting in the UI is that of the installation whitelist. All other settings are only visible in about:config and only really useful to developers. | |||
'' Are there build options for developers? [#ifdefs, ac_add_options, etc.]'' | |||
No | |||
'' What ranges for the tunable are appropriate? How are they determined?'' | |||
The only tunables are the intervals between checking for add-on updates and blocklist updates. Both of these default to a day, there is little point in them being any lower than this. | |||
'' What are its on-going maintenance requirements (e.g. Web links, perishable data files)?'' | |||
None | |||
== Relationships to other projects - are there related projects in the community? == | == Relationships to other projects - are there related projects in the community? == | ||
Many community projects take the form of add-ons. Also many applications based on Mozilla code use the Add-ons manager so the majority of the new features apply to them. | |||
'' If so, what is the proposal's relationship to their work? Do you depend on others' work, or vice-versa?'' | |||
Community add-ons require the add-ons manager and the features it provides in order to install into the application. | |||
'' 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? '' | |||
No | |||
== Documentation == | == Documentation == | ||
'' Do built-in Help pages need modified?'' | |||
Yes, the additional plugins UI should be documented. | |||
'' Documentation for developer.mozilla.org?'' | |||
Yes, most features require developer documentation all of which has already been completed along with an extensive rewrite of the add-ons update documentation. | |||
== Other == | == Other == | ||