Firefox OS Data Sync
Firefox Cloud
|
THIS PAGE IS A WORKING DRAFT | 
|
| The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page. |
Overview
At a high level, the Firefox Cloud project aims to create a service to allow the creation of rich cloud-enabled web applications that sync their data to a user chosen remote storage.
The product
The product vision is built on top of three major concepts fully aligned with Mozilla's mission.
- User choice
Firefox Cloud should offer to users the ability to decide where they want to store their data. On currently existing platforms users are tied to a specific storage: on iOS people are tied to iCloud, on Android, to Google Drive, etc. We want to give users the ability to choose the cloud storage provider they want. Ideally, we want to also be able to give them the choice to use self hosted storage like ownCloud. But this is still under discussion. Mozilla might also provide cloud storage space for users as one of these choices, but this is also still to be decided.
- User privacy
In order to ensure that the data that the user sends to the cloud is protected and no one else other than the user can read it, the Firefox Cloud client solution should allow users to opt-in to encrypt the data on the client side and store it encrypted on the selected cloud storage provider. Not even Mozilla should be able to read this data or store it unencrypted. All the encryption and decryption should happen on the client side.
- User identity
We want to use Firefox Accounts as the authentication mechanism for this service. Once the user links their chosen cloud storage provider credentials to her Firefox Cloud account, all that she needs to do to authenticate herself from new devices accessing her Firefox Cloud account is her Firefox Accounts credentials.
Use cases
Messaging application
Alice uses her Messaging app to send and receive SMS, MMS and IM. She accesses this application from her Firefox OS tablet, her desktop browser and her Android phone. She can see and manage the history and content of the messages sent and received from any of these devices. She can continue writing an IM that she started typing on her Android phone on her desktop browser app.
Media files
Bob uses his Music app to listen to music and audio files. He keeps a library with his preferred titles. He adds new songs from his desktop browser. When he uses his Firefox OS device, he can listen to these new songs if he is online. He can also choose to download them so he can play them offline.
Backup
Alice purchases a new Firefox OS phone (\o/). She already owns a Firefox OS tablet and she wants to have the same experience and data in both devices. She enters her Firefox Accounts credentials while configuring her new device. Her new device installs all the applications that she has on her tablet, the homescreen wallpaper, the passcode for the lockscreen, the notification sounds. When she opens the Gallery app in her new device, she is asked if she wants to access her photo collection from her new device.
File sharing
Bob wants to share a file between his desktop and his mobile phone. He accesses dummysharingservice.com, logs in with his Firefox Accounts credentials and uploads the file from his desktop. He goes to his mobile phone and logs in with the same Firefox Accounts email and downloads the file in his mobile. Now he wants to share the file with Alice. He accesses dummysharingservice.com again and uses the sharing option to send a notification about the shared file to Alice's email. Alice receives this notification and accesses the sharing service. She logs with her Firefox Accounts email and downloads the file shared by Bob.
Other use cases
- Calendar
- Notes
- Clock alarms
- Contacts
- Radio bookmarks
- Browser data (history, bookmarks, form autocomplete data, requestAutocomplete data, passwords, etc.)
- ...
The solution
Authentication
Firefox Accounts will be the authentication mechanism used by Firefox Cloud. Using Firefox Accounts should enable us to do the data encryption in the client without worrying about storing any private key or secret in the clients. We can obtain a key derived from the user's Firefox Accounts and encrypt the local data on the fly before sending it to the cloud. The authentication keys for the remote storages that the user chooses to use will be stored in the Firefox Cloud server also encrypted with a symmetric key that the client will provide on every sync request. That way if the Firefox Cloud server is compromised, the attacker won't get access to the remote storage accounts.
Documents vs Files
Service
Client
Along with the Firefox Cloud server, we will be providing a reference implementation of a Firefox Cloud client. At a high level, this client will need to address at least the following:
- Consume the Firefox Cloud server exposed HTTP API for storing and fetching data from the cloud.
- Conflict resolution.
- Authentication management.
- Encryption and decryption of data.
We would also like it to fulfill the following requirements:
- Offline first.
Ideally we should have a solution where consumers can store the data locally first and then specify that the data needs to be synchronized with a given remote endpoint. The app developer shouldn't need to know the underlying details of the sync protocol, and so instead of using the HTTP API exposed by the Firefox Cloud server, we should provide them with an abstraction to request this synchronization in the form of a JS library.
- Avoid enforcing another client storage solution.
We already have enough storage APIs in the client side at least on Firefox OS to add another one. We don't think it is a good idea to force developers to use another API for remote data synchronization. Instead, we would prefer a solution that allows developers to keep using the API of their current data source (let's say IndexedDB) for adding, editing and removing records and performing searches. While we can provide an easier abstraction of the current APIs (IndexedDB is known for being a powerful but complicated API), we should still allow developers to keep accessing and using them.
- Avoid data duplication.
One of the issues that we currently have with DataStore is that we potentially create several copies of the same data across Firefox OS. Ideally, we should not require to do the same with the solution that we choose for the client side of this system. So we should either have a solution that allow us to keep using the same data sources that we use currently but somehow adding the sync capabilities to it or a way to migrate the existing data to a new data source with already sync enabled capabilities. We will certainly need to add meta information along with the existing data that we have in our apps, but this data should have an unique source.
- It should be cross browser.
Whichever solution we find for this, it should work in all browsers. If we end up creating a JS library, we need to be sure that it works (or will work, thinking about IndexedDB support) in all the major browsers. We believe that we can avoid adding a new web API for this, but in case that we finally need to do it, it would be great if we could standardize it and avoid repeating the DataStore fiasco.
Javascript library
This is still under discussion, but the current proposal is to create a JS library that exposes a PouchDB inspired API but also gives a direct access to the underlying data source API by exposing a proxified instance of the used data source (initially limited to IndexedDB). This way the developers should be able to use the new improved API or keep using the specific data source API. This library should handle all the synchronization of data with the Firefox Cloud server, the resolution of conflicts, the migration from a currently existing database, the authentication part and the remote storage auth management, the encryption and decryption of the data in the client...