Firefox/RemoteSettings

Firefox Remote Settings

Remote Settings is a Mozilla service that makes it easy to manage evergreen settings data in Firefox. Firefox/Kinto is used for syncing of data. A simple API is available in Firefox for accessing the synchronized data.

Key Features

• Admin UI (generated from data schema)
• Data history
• Preview data (QA)
• Sign-off (review)
• File attachments
• Email notifications
• Content signature (Autograph integration)
• Single endpoint for polling for changes
• Client synchronization (diff based, local db)
• Client-side target filtering (JEXL a-la Normandy)
• Client Telemetry
• Robust protocol (retry, precondition headers, backoff, …)

const { RemoteSettings } = ChromeUtils.import("resource://services-settings/remote-settings.js", {});

RemoteSettings("my-collection")
  .on("sync", (e) => {
    // e.data.current = [ Record, Record, ... ]
  });

Resources

• Tutorials, screencasts and FAQ
• API client docs (How to use RemoteSettings in Gecko)
• OPs and staff documentation (How to create new collections etc.)
• List of Firefox features powered by RemoteSettings
• RemoteSettings server bugs list
• RemoteSettings client bugs list
• Project milestones

RemoteSettings DevTools

An addon is available to diagnose remote settings synchronization and state. See https://github.com/mozilla/remote-settings-devtools

From AMO to Kinto

Blocklists used to be managed via the addons server.

Now, the blocklist XML is generated on the Kinto server and a lambda pulls the JSON and generates the Web pages shown at https://blocked.cdn.mozilla.net

Source code: https://github.com/mozilla-services/amo2kinto/

Transition from XML to RemoteSettings

Currently the blocklist system relies on a big XML file that is downloaded every day. It contains block entries for certificates to be revoked, addons and plugins to be disabled, and gfx environments that cause problems or crashes.

Firefox (and derivatives like Thunderbird, Seamonkey, ...) downloads it on an URL that contains client information (eg. https://blocklist.addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/44.0a1/)

• phase 1: DONE: Both mechanisms run in parallel but only the legacy one will be used.
• phase 2: DONE: The source of truth for blocklist is Kinto but produces the same XML as the legacy one.
• phase 3: DONE: The nsBlocklistService should become asynchronous in order to be able to fetch info from remote settings local database
• phase 4: Eventually, blocking mechanism will rely on RemoteSettings entirely and the old XML client will be decommissioned.