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
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
Risks
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
Risks
HTML5 Client
People
| Developer Lead
|
Ian Bicking (ianbicking
|
| Additional Engineers
|
TBD
|
Requirements
<<not defined yet>>
Risks
- BrowserID key wrapping not implemented
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.
Risks
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.
Risks
Security Assessments
- Threat/security analysis (yvan)