CloudServices/Sync/FAQ

When do syncs occur?

• Sync uses a timer for regularly scheduled, full syncs (except for Tabs, see below). The time between syncs varies in some conditions (e.g. it is increased when the device is idle) but in general:
  • on iOS, the period is every 15 minutes.
  • on Android, the period is every 4 hours (after an initial delay).
  • on Desktop:
    • There is an initial delay:
      • Wake from sleep: 2s after wake
      • After startup: 5 minutes
    • The period itself varies depending on the state:
      • Idle: 1 hour
      • Active: 10 minutes
      • After recently syncing something: 1.5 minutes (if we’ve synced something new, we temporarily change the sync delay from 10min -> 1.5min until we don’t have anything left to sync)
• Tabs were changed with MR 2022 to sync every 5s after a tab change. This is sometimes called “quick writing.”
• 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 add-on 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.

Server states

• 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?

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.

Subsequent Syncs:

• Sync stores the “last modified” timestamp sent by the server, and only fetches new items the server reports as 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 (e.g. new bookmarks, new history visits, etc) and uploads these entries to the server.

When can users lose data?

In general, for a user to lose all their Sync data, two events must happen at the same time:

• The copy of the data on the server is lost
• The copy of the data on each of their devices is lost

If either of these events happens by itself, Sync will generally recover correctly:

• 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.

Note that the server data will be lost in two 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 user unchecks all of the Sync options or deletes their account - both actions trigger the server to delete that user’s data.

While the above considerations mean that in most cases Sync will recover from either a client or server loss, actual data loss can occur in these edge cases: 1. Single device users who have “lost” their only existing device and reset their password - in this case the data is lost on the server and the only device with a copy of the data no longer exists. 2. As above, but for multi-device users who have lost all their existing devices.

As a first sync can often take a long time to complete, we believe that some users will also perceive their data as being lost after reconnecting their device but before Sync has downloaded it all down to the new device.

Can’t Mozilla just save my password on their server so I can’t ever lose data?

Not without compromising the security model. Inherent in the security model is that Mozilla never sees or stores your password on our servers. This means we cannot (even if we wanted to) read your synced data stored on our servers. That data is encrypted before it leaves your device, and decryptable only by your device.

When will client upload or fetch all data?

• 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.

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.

• 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 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:

• User adds/removes item before sync has initialized at startup.
• User makes changes during a sync.
• Client network interrupted during upload of data meaning only partial data is on the server. While this is likely to be fixed by the next Sync of this client, there is a possibility other devices will Sync in the meantime and apply this partial data.

Can a client control Sync policies?

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.

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?