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

An exploration into some use cases...

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

Bugs for porting this over can hang off 1220494:

Full Query

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.