User:Mconnor/BIDSync(s)

Project Summary

Sync is moving to use BrowserID. The Apps product also needs Sync, and introduces a hard requirement for access to data from HTML5 web apps. This is a joint project to build out a shared platform, based on the current Firefox Sync implementations and APIs.

High level concepts

• We will use BrowserID+OAuth for authentication to service endpoints.
  • This includes a token/service discovery service that points clients to resources
• BrowserID will provide a key wrapping service that will allow the Sync Key to be stored, safely, alongside of the Sync data.
• AppSync will be in most ways, just another Sync engine, but the data will be stored in a durable form, as a HA (three nines?) cluster with backups, and a to-be-defined target for durability/geo-redundancy
• We will not include backwards compatibility with v1.1 users. This is a flag day, plain and simple.

Key Personnel

Engineering
Server	Toby Elliott
Desktop Firefox	Gregory Szorc
Android Firefox	Richard Newman
HTML5 Client (Apps)	Ian Bicking
Products
Identity	Dan Mills
Apps	Ragavan Srinivasan
Management Contacts
Services	Mike Connor
Apps	Bill Walker
Services Ops	Jeff Vier

Desktop Client

BrowserID Support

People

Developer Lead	Gregory Szorc (gps)
Additional Engineers

Requirements

• Implement support for the v2.0 protocol based on BrowserID
• Hook key storage into BrowserID key wrapping/unwrapping
• Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials.

Risks

• UX portions are blocked on Product/UX coherency
• BrowserID key wrapping is not implemented

App Sync integration

People

Developer Lead	Anant N (anant)
Additional Engineers

Requirements

• Define and document app-neutral data format for Apps metadata (shared with Android/HTML5 implementations)
• Write a Sync engine for Apps using the shared data format

Android Client

BrowserID Support

People

Developer Lead	Richard Newman (rnewman)
Additional Engineers	Harald Kirschner (digitarald), Chenxia Liu (liuche)

Requirements

• Implement support for the v2.0 protocol based on BrowserID
• Hook key storage into BrowserID key wrapping/unwrapping
• Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials.

Risks

• UX portions are blocked on Product/UX coherency
• BrowserID key wrapping is not implemented

App Sync integration

People

Developer Lead	Harald Kirschner (digitarald)
Additional Engineers

Requirements

• Define and document app-neutral data format for Apps metadata (shared with Desktop Client)
• Create an Android content provider for access to Apps local store
• Write a Sync repository for Apps using the shared data format and the content provider

HTML5 Client

People

Developer Lead	Ian Bicking (ianbicking
Additional Engineers	TBD

Requirements

• Identify what requirements the HTML client has for the server
• Implement/adapt sync client
• Develop testing routine across supported clients/browsers

Risks

• BrowserID key wrapping not implemented.
• We need an app serialization format to move forward on the implementation.
• HTML clients have more restricted cross-origin requirements; facilitating this kind of access requires server support, maybe a proxy.
• HTML clients might not support crypto efficiently (still not sure if we're doing crypto or not).

Server Work

BrowserID key wrapping and master key storage

People

Developer Lead	Ben Adida (benadida)
Additional Engineers	TBD

Requirements

• Provide an API for BrowserID consumers to have a key bundle wrapped/unwrapped using a master key
• Store master key with BrowserID provider

Risks

• crypto is hard
• work not yet started

Discovery Service

People

Developer Lead	Tarek Ziade (tarek)
Additional Engineers	Alexis Metaireau (alexis)

Requirements

• Provide a file that represents an entry point into a Sagrada system. Can be static.

Risks

• File format needs defining. It's not going to be complex, though.

Token Server

People

Developer Lead	Tarek Ziade (tarek)
Additional Engineers	Alexis Metaireau (alexis)

Requirements

• Define flow for retrieving and converting tokens to be used in other Sagrada apps
• Implement HA, scalable server with entrypoint for each service
• Do node-assignment to large-scale installations to distribute users across the instance

Risks

• High-volume crypto at scale is tricky

Storage API v2.0

People

Developer Lead	Ryan Kelly (rfkelly)
Additional Engineers	Tarek Ziade (tarek) (as consultant on current system)

Requirements

• Support consumption of Sagrada tokens as primary method of authentication
• Use Sagrada metadata tokens to identify backend storage location
• Document and implement changes to 2.0 API (almost all unused feature removal)
• Take the clean-room opportunity to fix some long-standing database problems

Risks

• Because users will reupload all their stuff, FF launch day is likely to be a heavy, heavy data day.

Metrics (metlog)

People

Developer Lead	Rob Miller (RaFromBRC)
Additional Engineers	Victor Ng (vng)

Requirements

• Produce internal library for centralized logging
• Process incoming logging data along entire pipeline to final storage location(s)
• Some initial graph interpretations of incoming data

Risks

• While this is nice to have and probably achievable, it is not strictly a blocker to BID sync

Token Processing Library

People

Developer Lead	Ryan Kelly (rfkelly)
Additional Engineers	Tarek Ziade (tarek)

Requirements

• Abstract out the code that turns a Sagrada token into a userid and some additional metadata into a library that all Sagrada services can use.

Durable Node Cluster

People

Developer Lead	Richard Soderberg (atoll)
Additional Engineers	Pete Fritchman (petef)

Requirements

• Operational deployment of v2.0 webheads, talking to a Replicated MySQL cluster with backups
• Durability of data is a requirement. HA requirement is similar to sync.

Security Assessments

• Threat/security analysis (yvan)