Extension data sync is off by default, so passwords, LocalStorage, IndexedDB, and similar data stay local. This guide explains what sync covers, the privacy trade-offs of encrypted cloud storage, when teams should enable it, and what self-hosting adds.
When you switch devices, or hand an environment to a colleague to continue operating it, the most common problem is not that you cannot log in. It is that the data inside the extensions did not come with you: login sessions have to be rebuilt, extension settings have to be configured again, and accumulated business data gets interrupted halfway through. Extension data sync is meant to bridge that gap.
The data involved is also sensitive by nature, including passwords and local storage. Before enabling sync, it is worth clarifying three things: exactly what is synchronized, where the trade-offs are, and what rules a team should set.
What types of data are synchronized
Environment-level extension data sync usually covers a fixed set of data: passwords saved in the browser, data written by websites to LocalStorage and IndexedDB, and the extension's own application data. The first two determine whether you remain signed in when opening a site, while the last determines whether an extension can keep working with its previous configuration.
Bookmarks, browsing history, and similar data that belong to the browser-account layer generally do not use this switch. They follow a different path, so do not expect them to move together with extension data. Mixing them up often leads to the familiar result: “I thought sync was enabled, but my bookmarks still did not transfer.”
Sync is disabled by default on purpose
Most environment-management tools leave extension data sync disabled by default for a privacy-first reason: when sync is off, this data stays only on the local device and is not transmitted over the network, reducing the opportunities for it to be read in transit. The choice is left to the user instead of being enabled automatically for everyone.
That default is a good fit for people who work on one fixed device. The data never leaves the machine, so exposure is minimized. Enable sync only when cross-device use or handoffs between people actually require it.
After enabling it, two steps are easy to do in the wrong order
Enabling sync itself is simple: open global settings, find the browser settings, and select the option to synchronize extension application data. The tricky part is the operating sequence.
Data is saved and synchronization is triggered only when the browser is closed normally. Do not expect live synchronization while you are still working. While the environment is running, there is no need to keep checking another device and wondering why nothing has changed.
Before the browser has been closed, do not open the same environment on another device. If both sides write at the same time, synchronization can fail and newer data may even be overwritten. Finish your work, close the browser completely, and only then check from the other device.
It is also common for these tools not to update extensions automatically. Automatic updates may bring in new permissions without you noticing, while manual updates at least give you a chance to review the permissions and privacy policy of the new version.
The privacy cost of cloud synchronization
When sync is enabled, data is sent to the cloud with end-to-end encryption and stored there in encrypted form. When sync is disabled, it is not uploaded at all. Under this model, third parties cannot read the content, but the trade-off is still clear: the data moves from “only in my hands” to “stored in someone else's data center.”
The key question is therefore not only encryption strength, but whether you can control the data lifecycle. Most tools provide an exit route: a user with super-administrator privileges can select the target environment in environment management and delete data by type through cache clearing. Before a team handoff or a change in an account's business purpose, clearing sensitive cached data is more practical than assigning blame afterward.
Should a team environment enable it
You can reduce the decision to three questions: Will this environment be used by more than one person? Will users switch devices? Does it contain sensitive accounts such as passwords, payment accounts, or admin backends?
If the answer to all three is no, leave sync off. If any answer is yes, synchronization can remove a large amount of repetitive work, but it needs shared rules rather than individual preference:
- Define in one policy which environments have sync enabled instead of leaving it to personal habits;
- Specify who is responsible for closing the browser to trigger synchronization, and avoid two people operating the same environment at the same time;
- Clear cached data before a handoff, and record the relationship between environments, accounts, and their owners;
- As the number of environments grows, use groups to separate purposes and permissions to limit who can access which environments.
In multi-account scenarios like these, PurpleMark provides the centralized management layer: environments, proxies, and account information are kept in one place; member permissions define the allowed scope of operation; and activity records make changes traceable. Whether extension data sync is enabled for an environment, and who changed it, can be checked afterward.
What self-hosted synchronization adds to your responsibilities
Some teams consider avoiding the cloud and building their own setup, with data stored in their own data center or object storage and transferred over internal links.
Self-hosting reduces dependence on a third party, but it also transfers responsibility for the entire chain to your team. How are keys generated and rotated? How are backups handled? How do you recover after data loss? Who is allowed to read the data? How will incidents be audited? Managed services usually absorb much of this work; with self-hosting, it all becomes your responsibility.
The most typical failure of a poorly designed sync system is not an attack but silent data loss: synchronization fails when it should have happened, and users notice only when it is too late. A practical decision rule is scale and staffing. If you have only a limited number of environments and no stable operations team, a managed sync switch plus encryption is usually enough. Self-hosting makes sense only when you already have internal access controls and operational capability; otherwise, you are creating another component that needs long-term maintenance.
Frequently asked questions
Will data upload immediately after sync is enabled? No. It waits until the browser is closed normally.
Will existing local data be lost if sync is disabled? No. Disabling sync only stops uploads; local data remains available, and you can continue using it if you enable sync again later.
Will the data still be there after moving to another computer? If sync is enabled, it follows the environment. If not, it remains only on the original device.
Why was the new extension version not installed automatically? This is intentional. Automatic updates are convenient, but the trade-off is that permission changes are no longer under your direct control.
