|Firefox Sync for Android|
|Release target||Fennec Native|
|Product manager||Jennifer Arguello|
|Directly Responsible Individual||Mike Connor|
|Lead engineer||Richard Newman|
|Security lead||Ian Melven|
|UX lead||Madhava Enros|
|Product marketing lead||`|
|Additional members||Chenxia Liu, Jason Voll|
- Where do we store passwords?
- What are the privacy etc. implications of using the system data stores?
- Will the mobile team decide to switch data stores?
- How do we do distribution? If it's linked to Fennec, how do we handle uninstallation, clearing data, etc.?
Stage 1: Definition
1. Feature overview
Sync for Android will run as a background service (bundled with Fennec, probably also available separately). This will provide background syncing, just as do other data sources on Android (weather, Twitter, stocks, Google contacts…).
Setup will be accessible from "Accounts & Sync" in the system preferences pane.
Synced data will be fully interoperable with Firefox on the desktop, and backwards compatible with previous versions of Fennec.
Setup will support the new flows implemented in Firefox 10 for Desktop and Mobile  to maximize user uptake.
2. Users & use cases
Sync to and from your Android device for (in priority order):
- Passwords (Q1? Still waiting for feature definition to firm up.)
- Tabs (Q1)
- Form Data (Q1)
- Prefs (Q1)
- Exposed + stable (and ideally async) APIs to local storage for synced data types as enumerated above.
- Sync must run as a background service, respecting the system sync prefs (e.g., not syncing while roaming).
- This implementation must be fully compatible with current Sync/Firefox implementations.
- When you get to the end of this setup flow, we want you to be able to hit "back" and actually end up back in Firefox.
- Any sort of revised security/setup scheme that would break compatibility with other clients.
- Any additional features beyond those currently supported on Fennec.
Stage 2: Design
5. Functional specification
6. User experience design
Here is a diagram/mockups of the Android-side setup and prefs flows: http://www.flickr.com/photos/madhava_work/6360153407/sizes/o/in/photostream/ (caution - large image)
Stage 3: Planning
7. Implementation plan
Estimated attack sequence
liuche: -- UI ---------------------- ... rnewman: -- Cryp. Rev. -- Network --- ... jvoll: -- Repositories ------------ ...
- UI is a big work item, and has lots of possible pitfalls, so get started now. Need an 'owner' for this. That's liuche.
- Repositories are standalone, follow an existing design, and have possible pitfalls. Let's get started on these, with tests if we can. jvoll is on that.
- The existing crypto code needs review and analysis from a broader perspective. That should happen before, e.g., J-PAKE tries to use it.
- After that, start working through the bits that need to be built, starting at the edge and working back.
- After some development experience, we can nail down the rest of the plan.
- Sec review Nov 18th.
- None scheduled.
Quality Assurance review
Stage 4: Development
Components, in approximate independent chunks
- Network: talking to Sync server.
- Interacts with credentials storage for username/password for Basic Auth.
- Generates and consumes records via crypto middleware (or not, for non-encrypted records).
- Extend record formats in https://github.com/mozilla-services/android-sync.
- Raises protocol-level exceptions: 401, 503 with Retry-After/X-Weave-Backoff, .... Consumed by service equivalent.
- Crypto. Consumes encrypted or decrypted records, produces the other.
- Must be heavily tested. Expect this to get detailed security review at some point.
- Raises crypto exceptions to be consumed by service.
- Interacts with credentials storage to obtain Sync Key to decrypt key bundle.
- Likely via some orchestrating component to eliminate an external dependency.
- UI: pref pane, setup wizard.
- Implement full J-PAKE flow.
- Interacts with credentials storage, of course.
- Also: triggered by service on processing of credentials errors (e.g., 401)...
- Preferences a la Google account for individual engines.
- Orchestrates repositories, crypto.
- Proceeds through state machine.
- Interaction point for Android sync infrastructure.
- Starting point: http://developer.android.com/resources/samples/SampleSyncAdapter/index.html
- Repository implementations for:
- Will involve substantial new storage work.
Stage 5: Release
10. Landing criteria
|Theme / Goal||`|
Team status notes