Confirmed users
98
edits
CloudServices/Sync/FAQ: Difference between revisions
m
fix typos
m (fix typos) |
|||
| Line 1: | Line 1: | ||
===When do syncs occur?=== | ===When do syncs occur?=== | ||
* Sync | * Sync uses a timer for regularly scheduled syncs. The time between syncs varies in some conditions (eg, it is increased when the device is idle) but in general, a single-device account syncs once per hour, where multi-device accounts sync once every 10 minutes. | ||
* In addition, Sync maintains a | * In addition, Sync maintains a "score" and syncs when reaches a threshold, with different types of data contributing a different score. For example, a bookmark, password and addon change causes a large score increment, so a Sync will start on every bookmark, password or addon change. However, new history and tab entries cause a smaller increment so a Sync is not performed every time the user visits a new page. | ||
* Syncs always happen immediately when the user presses the “Sync Now” button in the hamburger menu. | * Syncs always happen immediately when the user presses the “Sync Now” button in the hamburger menu. | ||
'''Server states''' | '''Server states''' | ||
* Server can send status codes (503) to backoff | * Server can send status codes (503) to "backoff" the Sync interval to a server-specified value in the unlikely event of infrastructure issues affecting the service. | ||
===How much data syncs?=== | ===How much data syncs?=== | ||
| Line 12: | Line 12: | ||
'''Subsequent Syncs:''' | '''Subsequent Syncs:''' | ||
* Sync stores the “last modified” timestamp sent by the server, and only fetches new items the server reports has changed since that timestamp. Thus, it is not uncommon for a Sync to ask the server for new items and be told there are | * Sync stores the “last modified” timestamp sent by the server, and only fetches new items the server reports has changed since that timestamp. Thus, it is not uncommon for a Sync to ask the server for new items and be told there are none. | ||
* The client also keeps track of which items have changed locally since the last Sync (eg, new bookmarks, new history visits, etc) and uploads these entries to the server. | * The client also keeps track of which items have changed locally since the last Sync (eg, new bookmarks, new history visits, etc) and uploads these entries to the server. | ||
| Line 38: | Line 38: | ||
Note that work is underway to try and reduce these bad scenarios: | Note that work is underway to try and reduce these bad scenarios: | ||
* We are considering giving users the choice of using a slightly different encryption scheme that will not lose all their data in the case of a password reset in exchange for slightly less security of their data (ie, mozilla will then hold a key capable of decrypting their data). The big challenge here is around UX - how to we succinctly explain the tradeoffs and offer that choice so the user can make an informed choice? | * We are considering giving users the choice of using a slightly different encryption scheme that will not lose all their data in the case of a password reset in exchange for slightly less security of their data (ie, mozilla will then hold a key capable of decrypting their data). The big challenge here is around UX - how to we succinctly explain the tradeoffs and offer that choice so the user can make an informed choice? | ||
* We are working on the server infrastructure | * We are working on the server infrastructure so the failure of a single Sync server will not lose the data - so the data is carried across to the new Sync server for that user. | ||
===When will client upload or fetch all data?=== | ===When will client upload or fetch all data?=== | ||
| Line 45: | Line 45: | ||
What are known situations where a client could corrupt data? | What are known situations where a client could corrupt data? | ||
The main cause of “corruption” is when a change made locally on a device is not uploaded to the server. Depending in the data, the perceived level of corruption differs. | The main cause of “corruption” is when a change made locally on a device is not uploaded to the server. Depending in the data, the perceived level of corruption differs. | ||
* For most data, this just appears to the user as though Sync hasn’t got the complete data - for example, a history entry or password may not appear on all devices. In general, the user | * For most data, this just appears to the user as though Sync hasn’t got the complete data - for example, a history entry or password may not appear on all devices. In general, the user perceives the data as “missing” rather than “corrupt” | ||
* For bookmarks in particular, the issue is more complex - for example, if a single item for a bookmark folder is missing but the bookmarks within that folder do exist, Sync can’t reliably replicate the bookmarks tree. In general it will then | * For bookmarks in particular, the issue is more complex - for example, if a single item for a bookmark folder is missing but the bookmarks within that folder do exist, Sync can’t reliably replicate the bookmarks tree. In general it will then place these child bookmarks in the “unfiled bookmarks” folder. The user will often perceive this as real corruption as not only are items missing, but the tree structure for items that do exist is wrong. | ||
Unfortunately there are a number of cases where Sync will fail to detect a local change, and thus will not upload that change to the server. These include: | Unfortunately there are a number of cases where Sync will fail to detect a local change, and thus will not upload that change to the server. These include: | ||