User:Mconnor/BIDSync(s): Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 10: Line 10:
* 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
* 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


== Client Work ==
== Desktop Client ==


=== Desktop Client ===
=== BrowserID Support ===
==== People ====
==== People ====


{{ServicesProjectPeople
{{ServicesProjectPeople
|devLead=Gregory Szorc (gps)
|devLead=Gregory Szorc (gps)
|engineers=Anant (AppSync specifics)
|engineers=
}}
}}


Line 24: Line 24:
* Hook key storage into BrowserID key wrapping/unwrapping
* Hook key storage into BrowserID key wrapping/unwrapping
* Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials.
* Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials.
* Define and document app-neutral data format for Apps metadata (shared with Android Client)
 
==== Risks ====
* UX portions are blocked on Product/UX coherency
* BrowserID key wrapping is not implemented
 
=== App Sync integration ===
 
==== People ====
 
{{ServicesProjectPeople
|devLead=Anant N (anant)
|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  
* Write a Sync engine for Apps using the shared data format  


==== Risks ====
==== Risks ====
* UX portions are blocked on Product definitions
* BrowserID key wrapping not implemented


=== Android Client ===
== Android Client ==
=== BrowserID Support ===
==== People ====
==== People ====


Line 40: Line 55:


==== Requirements ====
==== Requirements ====
* Implement support for the v2.0 protocol based on BrowserID
* Implement support for the v2.0 protocol based on BrowserID
* Hook key storage into BrowserID key wrapping/unwrapping
* Hook key storage into BrowserID key wrapping/unwrapping
* Implement support for revised UX based on BrowserID login/account creation/migration from existing Sync credentials.
* 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 ====
{{ServicesProjectPeople
|devLead=Harald Kirschner (digitarald)
|engineers=
}}
==== Requirements ====
* Define and document app-neutral data format for Apps metadata (shared with Desktop Client)
* Define and document app-neutral data format for Apps metadata (shared with Desktop Client)
* Write a Sync engine for Apps using the shared data format  
* 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 ====
==== Risks ====


* UX portions are blocked on Product definitions
* BrowserID key wrapping not implemented


=== HTML5 Client ===
=== HTML5 Client ===

Revision as of 23:54, 26 January 2012

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)