CloudServices/FirefoxMobileServices
|
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. |
Contents
Overview
This project proposal is to provide a way for Mozilla Cloud Services to have an established way to push new services out (without bogging down FxOS releases) to increase the service-based capabilities of FxOS for app developers and address urgent security holes that may occur. It could be considered similar in spirit to Google Mobile Services on Android (except everything including the server-side service components are completely open-sourced).
The initial focus will be on creating the FMS API's for FxOS which can integrate with the Preferences panel, and a small set of Javascript modules and framework for running them in on Firefox OS. At a later point a similar component with inter-process communication for Android should be created to expose similar functionality to web applications installed on Android devices.
Background
Currently Mozilla Cloud Services has landed the client-side code for projects such as Sync by integrating client-side code in the main code- base (Firefox, Fennec, etc). If/when security problems or exploits were found requiring an urgent fix Mozilla would issue a 'chem spill' emergency release of the project. This is a feasible approach (though labor intensive as it requires a complete release of the project) because Mozilla controls the release and distribution of Firefox for desktop and mobile devices. This approach is not viable for client-side services in Firefox OS because OEM's control the phone updates, not Mozilla or the users.
An additional constraint is that Cloud Services has plans to increase the service-based feature-set of Firefox OS (to attempt to match parity on some level with iOS/Android) which requires a much shorter release cycle than Firefox OS currently has. Being able to deploy new API's and update existing ones for new services quickly is important.
The two first projects at Cloud Services that added such code on the Firefox OS platform are SimplePush and Firefox Account
We're expecting that more projects (Presence) will do the same in the future, and this wiki page describes the biggest problems that were encountered and how we can make this integration work faster & easier for every one.
Features
Several features that are needed for client-side components that include a Mozilla Cloud Service:
- A new app in Gaia for Cloud Services preferences/settings
- Provide a Javascript DOM API namespace available to applications for Mozilla Cloud Services
- Run a background service (SimplePush has an agent that holds open a connection)
- Spawn a FxOS application (Push wakes applications to process notifications)
Use Cases
Note: Cloud Service Channel refers to a hypothetical future channel between devices and Mozilla/Telco's/etc. that multiple Cloud Services can use in addition to SimplePush.
Simple Push
XXX Existing implementation in xpcoms within gecko
see https://bugzilla.mozilla.org/show_bug.cgi?id=822712
Firefox Account Service
- DOM API's to get auth tokens
Presence Service
- Background service that runs with the Cloud Service Channel
- Sends/receives data over the Cloud Service Channel
- DOM API's to register for LiveNotification events
Loop (old Talkilla)
- Ability to see if friends want to receive calls
- Ability to send Tokbox tokens through LiveNotifications to avoid storage of tokens in cloud storage
Firefox OS Integration
Adding features in Firefox OS can be done at several levels:
- by creating an open web app at one of the 3 permission level: normal, privileged and certified
- by extending Firefox OS at a lower level : Gecko, Gaia
The first solution offers a lot of advantages:
- updates are very easy
- applications can interact with most of the system using Web API
- we're coding in pure HTML5/Javascript
There are some pitfalls however:
- limited control when the application is in the background, which is the case for headless features
- security restrictions. For example we can't load another app's UI
- some restrictions in what can be done in sandboxed child processes (XXX elaborate)
The other option --extending the system at lower level-- has a few advantages:
- there are no restrictions whatsoever in what can be done
- the code is part of the B2G process, and is not treated like web apps. For example, it can be running in the background without fearing oomkiller
But the pitfalls are quite important:
- the feature becomes part of B2G and must follow its release lifecycle, and fast iterations become impossible: once it's part of the system it's there forever. What if we need to push a security patch asap for Firefox Account ?
- developing in the core is very hard for people outside the FFOS team because it's a moving target. It involves a lot of boiler plate code and knowledge, and is not about coding the web anymore (xpcom anyone? JSM?)
Proposal: Firefox Mobile Services
We are proposing several parts that will be added to Firefox OS to ease development of client-side components that talk to Mozilla Cloud Services.
1. A 'Cloud Services' app (that will land in Gaia) to allow a user to manage Cloud Service settings such as their Firefox Account, Push Notifications, Presence, and/or any upcoming client-side settings needed for a Cloud Service.
2. A background 'Services Thread', launched in the parent process that will manage the Service Channel, do Push/Presence handling, etc.
3. A single location with the 'Services Thread' component for specifying DOM API's used to interact with Mozilla Cloud Services.
Ideally these three parts can be tied together at some point and updated independently of Firefox OS, though for an initial version that's probably not reasonable as it would require substantially more engineering to bridge the DOM API to a new separate gecko Service Process, and a separate process consumes drastically more memory on the device than a Service Thread would.
Detailed Description
Background Service Thread / DOM API's
This component is developed as a separate core JSM in b2g as a Service Thread. New DOM API's backed by Mozilla Cloud Services are added here. This service thread is launched from the parent process event loop and handles the Service Channel for the Push/Presence services and other Cloud Services that need to communicate over a single channel.
Development for client-side components to Cloud Services is done here to unify all Cloud Service components in a single place. A secondary goal is that it may be easier to initially land changes in a component we own, that is reviewed all at once later before FxOS releases (slight inefficiencies in our thread would not hold up the main event loop).
Cloud Services App
This component is developed in Gaia, and handles all the preferences for Cloud Services such as Firefox Accounts, Push Notifications, Presence, etc. It uses privileged DOM API's to change the Cloud Service settings that may need to trigger the Service Thread do work (indicating a user is offline, etc).
Once complete, Mozilla Cloud Services would be the owner of this component and should be able to land code without increasing the burden on existing B2G module owners.
Projects
Open Questions
Should Cloud Service DOM API's be standardized?
This question should likely be handled at a higher level than this project.
At the moment though, features are landing in FxOS with moz* vendor prefixes (mozPush, mozId, etc). To quickly increase cloud service feature parity with Android/iOS it seems likely that we will need to build more compelling services that we will deploy before pushing them through a standards track.
How can a separate update cycle be handled?
Right now, we have the capability to issue special 'chem spill' releases of Firefox on the Desktop and Firefox for Android (Fennec). For FxOS releases, our OEM partners need to push out new releases. There's nothing to indicate that they wouldn't quickly push out a release if we indicated it was urgent, but this process could increase in complexity later.
There's two compelling reasons that a Cloud Services component may be more likely to have urgent issues than Firefox OS as a whole (which is running the gecko engine that also has security holes found):
- The services we're deploying are brand new, some deploying new uses of crypto that have not seen as many attempts to hack them as existing browser components
- It's possible that a client-side component could cause unforseen non-security related issues at scale.
An example of the second case would be a type of DDoS that was seen with Firefox Sync on the Desktop. A bug in the retry logic in the client coupled with losing several Sync service nodes caused massive load similar to a DDoS on Mozilla Services as clients failed to properly back-off on their retries. This made it substantially harder to restore service availability.
What about parity with the desktop browser?
The mobile world thus far is defined by the dominant players, Android, iOS, and to an extent WindowsPhone. The companies behind them have been adding compelling cloud-based services to their native environments. While some client-side portions could be standardized (like Push), features like Firefox Accounts, Firefox Sync are not and would be unlikely to be implemented in Safari/Chrome as they're seen as a competitors service.
To create compelling features for FxOS, we're focusing first on how to enable that. The final answer will need to be determined by major stake-holders as with the standardization question.
References
Dump of useful links
