User Services/Meta
Contents
Context
Given that Firefox Account is a multi-service account system, and the set of services will grow and change over time, we need a small service to manage the set of service descriptors and allow clients to make and describe their choices.
That service is the meta service.
This is one of two privileged services — privileged meaning "directly known to the client" — the other being device management itself (which will likely be simply a role of the account system).
The locators for the account server and the meta server are the two pieces of base configuration required to connect to an existing Account/Sync constellation.
Outline
The meta service is a standalone service with the same availability and durability requirements as the account service. It exposes a simple API for managing three domain entities:
- Device descriptions.
- Service descriptions.
- Device-service elections.
That is, by talking to the service description system, armed with canonical knowledge of connected devices (via device management, which is the source of truth for active/inactive etc.), it's possible to discover:
- The protocol (and feature) capabilities of those connected devices.
- The services known to implement those protocols.
- Which services are in use by which connected devices.
Note that this service is 'not' responsible for storing service-specific data: no last-sync timestamps, no preferences for days of history, etc. The general rule of thumb is that if it changes infrequently and is useful for selecting an endpoint it lives here; if it describes the operation of a particular service it lives near that service; and if it's intimately linked to the lifecycle of sessions, then it lives in the device manager.
This data is used to select, present, and sometimes seamlessly transition between services.
A service descriptor is the third piece of information needed to set up Sync (or other identity-attached services). Clients can ship with descriptors, or be provided with them by provisioning or from the web (e.g., as with the social providers). Via interaction with the meta server, service descriptors are shared between clients.
Flow
[Auth with FxA] => (client IDs) [Query SD server] => (services and elections) [Decide on service and user elections] [Update SD server] [Connect to individual services]
Categories, protocols, services, and features
One can imagine a taxonomy like this:
"Data synchronization"
Firefox Sync 1.1
Mozilla's Firefox Sync 1.1 service
JoeCorp's Firefox Sync 1.1 service
Firefox Sync 3.0
Mozilla's Firefox Sync 3.0 service
— supersedes Mozilla's Firefox Sync 1.1 service
"Reading list"
Pocket Share 1.0
Pocket's hosted sharing service
That is: a category of related protocols that achieve a stated goal; a set of defined protocols that services (and clients) implement; and then concrete endpoints that expose that protocol.
The assumption is that services which implement a particular protocol are — to a point — interchangeable; more accurately, that any decision to use one provider over another is a personal or policy decision, not technical.
Clients are the other half of this. Shipping clients support a certain set of protocols — a set which might be extended by add-ons or future releases. They use those protocols to synchronize certain data types; for example, Sync 1.1 ships with engines for bookmarks, forms, history, etc.
Protocol selection
In short: choose the best protocol and service within the desired category, where "best" means:
- The most features you need
- The best overlap with your other devices
- Not superseded by another protocol/service.
Typically this will be a trivial decision: there will be one or two services, one or two protocols, and a limited feature set. Beyond that most services are likely to be disjoint sets, so I'm not concerned about intractible set cover problems and awkward heuristics.
Election
Note that a compromised meta server could amend any client's elections, causing other clients (or the client itself!) to upload data in a way that would surprise the user.
As such, clients should confirm suggestions with the user prior to acting.
Protocol transition
- Supersedes
- Cost to transition
- Transition itself has a cost: no flip-flopping (though directional "upgrade arrows" should prevent this anyway)
- Distinction between one-shot and persistent, and between cleartext and encrypted
- Easy to switch to a new Pocket API; less so for encrypted profile data.
- Unsupported devices
- Unsupported features
- Reupload
- Re-encryption
Service descriptions
Straight to the JSON:
{"id": "daecb5b2-8235-479f-91ca-09447d4bb339", — Or a URL?
"v": 1, — Descriptors can 'mutate' by bumping versions.
"name": "Mozilla Sync 1.1",
"provides": "org.mozilla.sync.1.1",
"url": "https://auth.services.mozilla.com/", — Protocol-specific.
"pp": "https://services.mozilla.com/privacy-policy/", — We'd like these included in the digest, so not metadata.
"tos": "https://services.mozilla.com/tos/",
"supersedes": [],
"digest": "...", "owner": "...", — Some mechanism for verifying and protecting service descriptions.
"metadata": "http://services.mozilla.com/sync-1.1/meta", — Support URL, icon bundles, descriptive text; clients can cache.
}
Device descriptions and elections
Note that this augments the basic device info from the account service.
{"id": ..., — Stable identifier.
"protocols": {
"org.mozilla.sync.1.1": ["bookmarks", "adblockplus"],
"org.mozilla.sync.3.0": ["bookmarks", "readinglist"],
},
"elections": {
"org.mozilla.sync.1.1": {
"service": "daecb5b2-8235-479f-91ca-09447d4bb339", — Foreign key!
"features": ["bookmarks"], — Protocol-specific; can be ignored/omitted.
}
"org.mozilla.sync.3.0": ...
}
}
Note also that this assumes that each device can elect its own datatypes — that is, each can sync a different set of data to a different service. Different user experiences can be layered on this; each device knows the other devices' elections, and can mirror them accordingly.
Protocol description
TBD
