Canmove, confirm
409
edits
Changes
add info for security review
The first release will not include locales & dictionaries. follow up bugs have been filed.
|Feature ux design=;May need some for giving the user feedback when an add-on is being updated due to sync.
|Feature security review=The feature follows the same security model as other sync engines: add-on records are encrypted using the Sync Key and the IDs for each add-on are randomly generated.
The entire feature is implemented in JavaScript and runs in the chrome process - the same process as Sync.
For the initial feature drop, synchronized add-ons will be limited to:
* XPI extensions or themes
* from the same application ID as other Sync profiles
* installed in the profile directory
* installed explicitly by the user (those put in the profile directory by nefarious applications will be ignored - !addon.foreignInstall)
* installed from addons.mozilla.org
** In the implementation, the hostname is defined by a preference. the default value is *addons.mozilla.org*
Eventually, we'll want to expand to all XPI extensions and will want to handle add-ons from non-AMO URIs. But, these will be covered by separate feature(s) and security review(s).
UX has deemed it best for the feature to have no explicit UX in the browser, as Sync should be transparent. However, modification of add-ons could result in changes in browser behavior. Toolbars and buttons could appear/disappear "randomly" (corresponding with when Sync runs - which is transparent to the user). Tabs could be opened for add-ons which open tabs on install events. While these aren't security vulnerabilities, they could be perceived as such. "Why is my browser changing - was it hacked?" UX rationalizes it by saying that any add-on behavior must have been triggered by user behavior somewhere. This is true. However, a user might be surprised to see add-ons magically being changed upon (transparent) upgrade to Firefox X. Upon add-on modification, about:addons should reflect the change immediately.
If a user's Sync server credentials (but not the Sync Key) are compromised, the server records would reveal the last modified time of individual add-on records. Without access to a Firefox profile, it would be unknown which add-on each record corresponded to. This data leakage is minor and is on par with other leakages currently in the Sync service.
Sync transmits each add-ons ID between devices. The add-on ID is looked up on addons.mozilla.org. Assuming it is found, Firefox will download the extensions or theme from addons.mozilla.org and install it. The installation process uses existing AddonManager APIs. This will result in more requests to addons.mozilla.org. However, such requests shouldn't be traceable back to Sync. We (theoretically) already trust the privacy model of addons.mozilla.org, so even if data is leaked, it should be no big deal.
This is the first component of Sync which will indirectly communicate with a non-Sync server (addons.mozilla.org). Sync will be talking with it via the AddonRepository JS APIs. Sync assumes those APIs are doing the proper things to secure against MITM attacks, etc.
}}
{{FeatureInfo
