The web runtime is a set of client-side code that includes the same JavaScript, CSS and

HTML engines on all of our platforms

it provides access to the device using the security model we discussed earlier

as much as appropriate it gives a native application experience

on all of the platforms where it is available

and finally it provides access to the cloud-based backup service for application receipts and

application management

A web runtime is not a browser. It has no browser chrome, no browser history, none of

those browser features

that would distract from the application experience

We are currently focusing our web runtime efforts on the Firefox OS Boot-to-Gecko project

and on the Android platform where we have a runtime based on Gecko and

mobile Firefox. We are working on the web runtime for desktop platforms

as a way to support developers for those mobile devices

Now let's see how the data flows between these different participants in the ecosystem.

To discover and purchase an app

the user takes their device and visits

the Firefox Marketplace, where they will authenticate themselves using Mozilla Persona

this will create a session on the Firefox Marketplace and the user will discover applications

of interest to them

Upon hitting the purchase button, Firefox Marketplace will initiate a session with our

payment provider

the user will identify themselves for purposes of payment, and a receipt will be generated

and signed.

At this moment, the receipt will be installed on the device along with either the manifest

or the package

Let's see how a web application is installed from a manifest.

Upon receiving an invocation of the install API, the device retrieves the manifest from

the app's backend server

and installs it locally. At this point,

the receipt is backed up to the Apps in the Cloud service and the application is ready

to run. It's as simple as that.

In the case of installing a privileged app, the device will retrieve a package from

the Firefox Marketplace containing all of the signed and reviewed code resources for

the application

and those will be installed on the device. And again,

the receipt will be backed up to Apps in the Cloud.

Once either the package or the manifest is installed on the device, the application is

ready to launch

At launchtime, we may check to see if the receipt is expired, and if it is, retrieve

a new one

Following this, the application will send the receipt to its backend

where it will be verified. This will create a session

for the user and they will have access to protected content

or other resources that the app wants to protect.

The application can run knowing that the user is a valid user

of the application with a valid receipt.

While the application is running, the user may participate in an in-app payment

using a flow very similar to the paid app flow we looked at a minute ago

The payment provider will create an iframe which will invoke a flow which will allow

the user

to identify themselves for purposes of payment and choose a payment method

Following this, an acknowledgement will be sent to the app's backend so that it can provide

the protected content

to the user.

Web apps can be updated in two different ways. If an app is hosted by a developer

Then the update is simply a matter of retrieving updated content from the app's backend

and updating the app cache for offline experience.

To update a privileged app, the device will retrieve a new package from the Firefox Marketplace.

and replace the existing package. The device will conduct periodic requests to check whether

an updated package is available.

In order to manage applications across devices and across app stores,

the user begins by using Mozilla Persona.

This authentication allows the user to synchronize the local copy of receipts on their device

with the receipts stored in the apps in the cloud server,

giving them access to receipts for apps they might have purchased at other times on other

devices.

The user experience allows them to control

which apps are installed on which devices, so they don't end up with everything everywhere.

So we've seen the value we provide to users and developers, and we've seen the systems

and concepts

that make up the ecosystem and how data flows between them

As we go from these data flows to our implementation,

we start to see the various design pressures in any engineering project and how they interact

with one another. What we bring as values to this engineering effort

is a goal of creating loose coupling between systems so they are not intimately tied with

one another and brittle

We are also embracing open standards as we always do at Mozilla, to create open versions

of

all these APIs, for folks inside and outside Mozilla

and we are always focusing on user sovereignty, giving users control of the applications,

and where and when

information about them is kept, and allowing them as much flexibility as possible.

In the coming year, the architecture that I've described will face a number of different

challenges I'd like to outline

just a few of them. Analytics will be one.

We have a goal of providing to developers detailed information about who is using their

app, how often, when and where.

This will be a differentiator from many other app ecosystems where this information is hard

to come by.

However it is very important for us to protect user's privacy and not reveal

any personally identifiable information, while providing these for analytics.

So we have an engineering challenge ahead to find a way to balance those two priorities

We have a large challenge coming in the area of linkages across applications.

We are intent on isolating applications one from another by creating separate profiles

or separate cookie jars, so that applications cannot

share information. However, we run the risk

of creating problems for applications that do expect

cookies to be made available to a service like Facebook Connect.

or a shopping cart or a game leaderboard.

So we will need to find a way to balance the goal of protecting applications from one another

but yet providing access to shared services that all applications expect.

One challenge we faced this year is trying to provide access to sensitive device APIs

for an application,

while protecting users from malware and other bad guys on the Net.

and I'm happy to say that this problem we have solved through the security model and

the permissions that we discussed earlier.

And it's successes like these that make me optimistic

that we'll solve the other challenges I've outlined in this talk.

For more information abou the Apps ecosystem, there are several documents you can refer

to online. One is the specification of the app manifest.

One is the documentation at MDN for the navigator.mozapps API. Also on our wiki is the write-up of the

App security model.

And at MDN the documentation of the Packaging specification for Apps.

That's it. Thanks alot.