canmove, Confirmed users
409
edits
Services/Sync/Addon Sync: Difference between revisions
FAQ on limiting to AMO
(replace content with feature overview) |
(FAQ on limiting to AMO) |
||
| Line 46: | Line 46: | ||
We explored adding UI in the browser to alert users to the existence of add-on sync. However, this didn't make the cut for Firefox 11. Perhaps you will see it in a future Firefox release. | We explored adding UI in the browser to alert users to the existence of add-on sync. However, this didn't make the cut for Firefox 11. Perhaps you will see it in a future Firefox release. | ||
===Why is Functionality Limited to Add-ons from addons.mozilla.org?=== | |||
First, this is only the default behavior. The *services.sync.addons.trustedSourceHostnames* preference can be modified to allow other trusted hostnames. (This behavior may change - see {{bug|712834}}). | |||
There are 2 main reasons for this: security/privacy and ease of implementation. | |||
It is important that Sync not be used as a delivery vehicle to carry out malicious attacks against the browser. Add-on sync is the first time a synchronized entity could really do harm if left unchecked. For example, an attacker could install a malicious add-on on a Sync-connected device and this add-on could propagate automatically to other Sync-connected devices, compromising them as well. Sync is designed with user security and data privacy in mind and it should be pretty obvious that we don't want to undermine them. | |||
Allowing arbitrary/untrusted add-ons to be synchronized would undermine the security of Sync and would allow Sync to be used as a delivery vehicle for bad. | |||
Since all add-ons on addons.mozilla.org are reviewed prior to being published, there is trust that add-ons hosted there are not malicious and safe to install (providing the user has consented, of course). Technically, addons.mozilla.could could be used to distribute malicious extensions via Sync. But, there are procedures in place to ensure that malicious add-ons don't exist on addons.mozilla.org, so we ignore this possibility. | |||
The second reason is ease of implementation. We eventually want to *support* syncing of **any** add-on. However, there are technical challenges in our way: | |||
* Data storage - Add-ons can be quite large, possibly more than you are allowed to store in Sync's servers. The additional storage of add-on data could also use up a lot more space on Sync's servers, causing the cost of operation of this (free) service to go up (the problem is compounded by the fact that data is encrypted on the client, so we can't de-dupe identical add-ons on the server). | |||
* Versioning - How do you handle different add-on versions? One version may not be compatible on all devices because the devices are running different Firefox versions. How do you handle that? | |||
* Remote access to add-on data - Say you store the add-on's install URI instead of the actual add-on data. This circumvents issues with storage of large add-on data. But, what happens when that URI isn't accessible on another device? Should Sync try again later? How long should it keep trying before it gives up? What happens if it fails? | |||
Trust us, these are hard problems. We decided it was best to focus on a subset of the add-on sync space that didn't have these concerns for the initial launch. And, as it turns out, add-on sync is hard enough, even with the limited functionality. We know people want these features, so we'll try to support more features in future Firefox releases. | |||