Confirmed users
964
edits
CloudServices/Sync/FAQ: Difference between revisions
Jump to navigation
Jump to search
no edit summary
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
* 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 can send status codes (503) to backoff from fetch interval in the unlikely event of infrastructure issues affecting the service. | * Server can send status codes (503) to backoff from fetch interval in the unlikely event of infrastructure issues affecting the service. | ||
===How much data syncs?=== | ===How much data syncs?=== | ||
First Sync, or the unusual case of the user being moved to a new Sync server | '''First Sync, or the unusual case of the user being moved to a new Sync server''' | ||
* In this case we fetch all items on the server and apply them locally if they don’t already exist. After fetching all items we also look for local items that are not on the server and upload these missing items - although in the case of “history” we only upload the last 30 days of visits. | * In this case we fetch all items on the server and apply them locally if they don’t already exist. After fetching all items we also look for local items that are not on the server and upload these missing items - although in the case of “history” we only upload the last 30 days of visits. | ||
'''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 no new items. | * 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 no new items. | ||
* 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 22: | Line 23: | ||
* If the server data is lost, it will be repopulated the next time a client Syncs. | * If the server data is lost, it will be repopulated the next time a client Syncs. | ||
* If a client is lost, a new client can be connected to the Sync account and the data from the server will be pulled down. | * If a client is lost, a new client can be connected to the Sync account and the data from the server will be pulled down. | ||
Note that the server data will be lost in 2 main scenarios: | Note that the server data will be lost in 2 main scenarios: | ||
* The encryption used by Sync means that if a user’s password is reset (not simply changed), then the data on the server is unable to be decrypted. While the data isn’t actually “lost” in this case, it might as well be. | * The encryption used by Sync means that if a user’s password is reset (not simply changed), then the data on the server is unable to be decrypted. While the data isn’t actually “lost” in this case, it might as well be. | ||
| Line 37: | Line 39: | ||
* 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 to 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. | * We are working on the server infrastructure to 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?=== | |||
* Server node is moved or lost, or user reset their password such that the existing data can not be decrypted. | * Server node is moved or lost, or user reset their password such that the existing data can not be decrypted. | ||
* New device is added and will fetch all data, and upload any local data not already on the server. | * New device is added and will fetch all data, and upload any local data not already on the server. | ||
| Line 53: | Line 56: | ||
Currently client server data is merged (deleted items explicitly marked). Giving user control presents a complex decision which is difficult to explain outcomes to users. | Currently client server data is merged (deleted items explicitly marked). Giving user control presents a complex decision which is difficult to explain outcomes to users. | ||
* With sync 1.1 there were options that applied to the first Sync: | * With sync 1.1 there were options that applied to the first Sync: | ||
** Merge client data | |||
** Overwrite server data | |||
** Overwrite client data | |||
There are also preferences the user can set to adjust the timer delay and other obscure configuration options. | There are also preferences the user can set to adjust the timer delay and other obscure configuration options. | ||
===Can a user backup to a snapshot of data?=== | ===Can a user backup to a snapshot of data?=== | ||
Not currently, but this is a feature that could be added. Like some of the above, a key challenge here is UX and giving the user enough information and choice that they can make an informed decision about the implications of their choice. For example, if the user chooses to restore from a backup, are we sure they are aware the change will affect all their devices and not just the current device? Is it possible that only this local client is in a bad state, and that the copy of the data on the server is in a good state and should be reapplied to this device without impacting other devices? | Not currently, but this is a feature that could be added. Like some of the above, a key challenge here is UX and giving the user enough information and choice that they can make an informed decision about the implications of their choice. For example, if the user chooses to restore from a backup, are we sure they are aware the change will affect all their devices and not just the current device? Is it possible that only this local client is in a bad state, and that the copy of the data on the server is in a good state and should be reapplied to this device without impacting other devices? | ||