WebExtensions/chrome.storage.sync
Planning for implementing chrome.storage.sync for WebExtensions.
There are two components to this API: the API in Firefox and the backend storage servers. Prototype is done.
tl;dr an add-on developer can save some data related to the add-on and it is accessible to the same add-on for that user on different profiles and devices. See the Chrome docs for more.
Firefox API
- this was added in the prototype on github
- the existing code will need to be ported into mozilla-central and tested properly
- we will use Firefox Accounts for authentication of the user
What Chrome does
You can test this by getting two Chrome browsers (e.g. stable and canary) and logging into them with the same or different accounts. A simple addon is favourite-colour from webextensions-examples, just replace chrome.storage.local with chrome.storage.sync.
These are some of the questions that came up in talking about chrome.storage.sync recently. Thought I'd give Chrome a try and see what happens.
- What happens when you are offline?
- The data is saved locally.
- At some time when you go back on line it is synced up to the server.
- What happens in conflict?
- There is no conflict management on the keys as far as I can tell, it just writes over.
- If you've changed something locally and there's a different value on the server, which one wins?
- The one on the server.
- What happens if you have no account?
- The data is stored locally.
- Nothing else as far as I can tell, no error, warning, nothing.
- What happens if you have an account but are not logged in?
- See above.
- What happens when you change accounts?
- If you've got some data locally and change accounts, the change comes down from the server and wipes yours out.
Chrome does not encrypt the data so scenarios around the encryption or changing of passwords and consequences that might have are not covered.
Questions
- Is people running their own storage server a priority?
- (andym) no, but it would be nice if they could.
- (tarek) There are 2 paths
- deploy your own service and let it interact with Mozilla to verify FxA tokens.
- host everything including your own FxA infra. Michiel has worked on a series of docker images see https://github.com/michielbdejong/fxa-self-hosting
- Why Kinto over Sync?
- The Kinto server stores the data in postgres RDS instead of Sync's ad-hoc Mysql deployment. RDS comes with data replication, meaning that we have less chances to lose data for users.
- The internal Firefox Sync APIs aren't documented or stable, and are pretty hostile. There is no well-supported way for add-ons to integrate with Firefox Sync beyond just whitelisting prefs to be automatically synced.
- How long do we retain data?
- Is there a way to clear out data?
- (tarek) yes, that's a API call away with the proper permissions
- As a user can I see what data is stored by each add-on?
- Edge cases
- What happens when a user isn't logged in?
- (tarek) we store stuff locally and don't sync them
- What happens when the client goes offline?
- (tarek) the client should gracefully wait for the next chance to sync with the server. The Kinto client has built-in offline first features.
- How does it resolve when there's a conflict?
- (andym) it doesn't, it just overwrites
- What happens when a user isn't logged in?
Bugs for porting this over can hang off 1220494:
| ID | Priority | Status | Summary |
|---|---|---|---|
| 1311510 | P3 | NEW | chrome.storage.sync: performance test of production stack for chrome.storage.sync |
1 Total; 1 Open (100%); 0 Resolved (0%); 0 Verified (0%);
Storage servers
...Tarek to fill in.
The bugs for tracking the roll out are:
Timelines
- Stand up the client code, behind a feature flag, so that users have to flip it on in about:config
- Stand up the servers.
- Find some add-ons to be beta-testers.