Question about storage.sync


(CR) #1

On MozillaWiki, it said that Mozilla does not provide any guarantees about the uptime, performance, and data retention of sync storage. This got me thinking, do I need to provide fallback for the sync storage?

If the API doesn’t provide this, there may be a lot to consider (if the service is down, if user disabled sync, sync to local storage if using it for backup, resync previously failed sync data, etc), therefore I would like to know about it before implementing sync.


(Niklas Gollenstede) #2

The main use case of this API is to store preferences about your extension and allow the user to sync them to different profiles. You can [only] store up to 100KB of data using this API.

And sync means that, sooner or later, if the user wants to, every dynced device should have the same set of key-value settings.

Any other form of “persistent” storage the browser can offer could also be cleared by the user or otherwise be lost at any time.

I don’t know what you want to save. If it is just some preferences, the above should be fine. If it is a password database, none of the browsers storages will do.

Assuming that the user actually has multiple devices, you could periodically store snapshots of the synced state to e.g. the indexedDB on each device, and offer a UI to restore those.


(CR) #3

Thanks, I was hoping that the storage.sync API already provided a local storage fallback by itself, but it doesn’t seems to behave that way.

I understand that storing sensitive private information on storage API is discouraged since it is stored in plain text.

I guess that’s the best and easiest option: make the sync storage optional and be used only if the user choose to do so.


(Niklas Gollenstede) #4

Not sure what you mean by “local fallback”, but if the user is not signed in, the data is simply stored locally.

storing sensitive private information on storage API is discouraged since it is stored in plain text

I’m fairly certain that the data gets encrypted in the browser, is transmitted and stored encrypted and is only decrypted in the browser again. Not even Mozilla can read it on their servers. You still wouldn’t want to save passwords in it because it rests on the local computer without encryption (maybe unless you set a master password in Firefox).

If it is a password database, none of the browsers storages will do.

I said that because with information that important, you also would not want to loose the data (as in, have no access yourself).

I guess that’s the best and easiest option: make the sync storage optional and be used only if the user choose to do so.

Again, it really depends on what you store, but in general I disagree. For most settings it’s fine to just dump them into storage.sync.


(CR) #5

This is what I want to know, so I have created some extensions with its options saved on storage.local. Can I just change all “storage.local” lines to “storage.sync” in my code and will it just run without any adjustment?

If not, what do I need to do to migrate the storage to sync? Considering storage syncing is a complex problem. And what I meant about complexity problem, I’m referring to this post: https://discourse.mozilla.org/t/diary-so-when-do-you-sync-and-what-are-the-implications/25409. Of course, this may already be handled by the API and I may be over-thinking about it :smile:


(Niklas Gollenstede) #6

Whether, from a UX perspective, it is a good idea to sync your data or not, is up to you to decide.
If you do decide to sync, you pretty much have to "just change all storage.local lines to storage.sync", and copy the old data over to the sync storage.
The second part can be a bit tricky, because you’d only want to do that exactly once.
I guess this might help:


(CR) #7

Thanks! That is exactly what I need.