So when an application is running, it is running on top of what we call a web runtime
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.