Firefox OS Data Sync: Difference between revisions

Add initial notes from our roadmap brainstorm (we can update this as ideas consolidate)
(→‎For Browser/System data: Remove remark about work to be done.)
(Add initial notes from our roadmap brainstorm (we can update this as ideas consolidate))
Line 132: Line 132:
* Outlook for Contacts. We are currently importing contacts only.
* Outlook for Contacts. We are currently importing contacts only.
* CardDav for Contacts. One of the most wanted features (269 votes so far). Check [https://bugzilla.mozilla.org/show_bug.cgi?id=859306 bug 859306].
* CardDav for Contacts. One of the most wanted features (269 votes so far). Check [https://bugzilla.mozilla.org/show_bug.cgi?id=859306 bug 859306].
= Roadmap brainstorm (subject to change) =
== Before 2.5 RA ==
=== Firefox Sync on 2.5 ===
We plan to implement readonly bookmarks and history synchronization. We will be enabling Sync on master for phone foxfooders after the 2.5 branch is created.
== After 2.5 RA ==
=== Finish Firefox Sync ===
The next logical step is to finish the work that we started with Firefox Sync in a way that Firefox OS can catch up with other Firefox Sync clients (Desktop, Android and iOS). So we need to work on exporting data from the collections that we already have implemented (bookmarks and history) and work on importing/exporting from the collections that it still doesn't have (passwords, add-ons, tabs, preferences, forms, clients). Some of these may not make sense on Firefox OS though.
Also for bookmarks, we still need to define and implement an UI to display the synchronized bookmarks on the phone.
Finally, we need to allow the creation of new Sync users from Firefox OS. This involves generating the 'crypto/keys' object containing a new bulk key bundle, encrypt it with 'kB' on the client and uploading it to the server.
=== SyncEngine shared library ===
Right now, the sync engine lives only inside the Sync app that we added for synchronizing bookmarks and history. This works fine as long as the data source to be synchronized is accessible outside of the owner app (via DataStore for example). But it makes it impossible to synchronize an app's data that is not exposed outside of the owner app. Also, having the Sync app managing the synchronization of any kind of data doesn't really scale very well and causes potentially unnecessary data duplication. It makes more sense that each app handles the synchronization of its own data. So in order to allow the addition of new collections (not only existing Firefox Sync collections, but also any other type of collection like contacts, call log or settings data) from any application we need to package the logic of the sync engine in the form of a shared library that can be used by any Gaia application.
=== Sync collection extension mechanism ===
Apart from creating this shared library to ease the synchronization process from other apps, we also want to create a way for apps to register themselves in the Firefox Sync machinery. This is, to be able to add their collections to be listed within the Settings UI and to register themselves to be waken up periodically by the sync scheduler that lives in the System app.
=== CryptoKey and CryptoKey Discovery API ===
We want to implement a model where initially the SyncEngine library would use Kinto.js and Syncto to retrieve crypto/keys, pass this encrypted blob to Gecko, and get back a set of non-extractable CryptoKey objects, with which it can decrypt the data from other collections. The communication between Sync app <-> System app <-> Gecko can initially be done via IAC + chrome/content events. However, that's not possible on Firefox Desktop. And we need to be able to decrypt the data that we send from FxOS on Desktop and viceversa so that the same data can be accessed on Desktop and on Firefox OS. For that we need the CryptoKey Discovery API implemented on Gecko, so we can provision kB on Firefox Desktop and expose it to a certain set of associated origins. With that, we would still not have a cross browser solution, so we would need other browser vendors to implement the same API, and have an inter-browser solution for moving the private key between one browser silo and another. Sync used to do something similar between Firefox Desktop and Android where one showed the user a string (or QR code maybe) that needed to be entered in the other.
=== Push notifications in Kinto ===
Because we want to avoid unnecessary battery and network consumption by polling constantly from the device but we still want the data to be synchronized as soon as possible, we want to add push notifications to Kinto. This way, when something changes in a remote collection, the server will send every client of this collection a notification about this change so it can update itself accordingly.
=== Firefox Accounts improvements on Firefox OS ===
This is not entirely part of sync, but it is quite related. We are using Firefox Accounts as our identity mechanism. Firefox OS the only platform that still uses BrowserId assertions while other platforms are using the OAuth flow instead. This forces Relying Parties that want to benefit from the SSO system that we have on FxOS to use the non-standard mozId API. It also forces every server side part that we want to create for syncing to support both BrowserId assertions (if we want to sync from FxOS) and OAuth tokens (if we want to sync from Desktop). We aim to move to OAuth as soon as possible.


= Related work =
= Related work =