W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

RE: App Manifest & API Proposal

From: SULLIVAN, BRYAN L <bs3131@att.com>
Date: Sun, 13 May 2012 08:11:12 +0000
To: Anant Narayanan <anant@mozilla.com>, public-webapps <public-webapps@w3.org>
Message-ID: <59A39E87EA9F964A836299497B686C350FEB9D91@WABOTH9MSGUSR8D.ITServices.sbc.com>
Hi Anant,

Thanks for the proposal. It's good to see this moving forward, following the workshop we had last year after TPAC. 

Some initial comments:

1) Re "version: A string that represents the version of this manifest. The User-Agent does not interpret this value in any way and is opaque to everyone but the application itself.": it's also likely that the "privileged caller" may also need to interpret this, as one key use case for the a privileged caller is an appstore client.

2) How do you propose that the manifest information be trusted, through signature on the JSON file?

3) Re softening of the requirement "There must only be one application per origin.": you will likely need an App ID field (a URI), for which there should be only one installation at a time (otherwise per the manifest trust above, an untrusted app could pose as another app).

4) For which of the attributes, instead of being in a manifest, could we achieve the same purpose with HEAD section elements in the start page of the app? I guess this question comes down to what is the inherent value of a manifest, and also how can we get similar value for these attributes on normal Web pages (with no manifest).

Bryan Sullivan 

-----Original Message-----
From: Anant Narayanan [mailto:anant@mozilla.com] 
Sent: Saturday, May 12, 2012 11:02 AM
To: public-webapps
Subject: App Manifest & API Proposal

Hi everyone,

I recently joined the webapps working group and I'd like to introduce 
myself! I work at Mozilla and for the past year or so have been working 
on our Apps initiative [1]. Our goal has been to make it very easy for 
developers to build apps using web technologies that can go above and 
beyond what one might achieve using "native" SDKs on platforms like iOS 
and Android. We're also trying to make it really easy for users to find 
and acquire these apps, and use them on any device they happen to own 
regardless of platform.

As part of this work we have devised a simple JSON based manifest format 
to describe an installable web app, in addition to a few DOM APIs to 
install and manage these apps. We have a working implementation of the 
entire system in our latest Nightly builds.

The manifest and corresponding APIs are described in an early draft at:

We'd like to propose using that draft as the basis for a FPWD on this 
topic. I look forward to your feedback!

There are a few questions I anticipate in advance, which I will try to 
answer here, but we can definitely go in more depth as necessary on the 

Q. Why not simply reuse the widgets spec [2]?

A. Aside from naming (we're talking about apps, the word "widget" seems 
to imply an artificial limitation), and replacing XML with JSON; the 
other fundamental difference is that the widget spec describes packaged 
apps, whereas our manifest describes hosted apps.

We think hosted apps have several interesting and unique web-like 
properties that are worth retaining. Hosted apps can be made to work 
offline just as well as packaged apps with AppCache (which is in need of 
some improvement, but can be made to work!). Packaged apps do have their 
own advantages though, which we acknowledge, and are open to extending 
the spec to support both types of apps.

Q. Why is the DOM API in the same spec as the manifest?

A. One success condition for us would be standardize the DOM APIs so 
that users will be able to visit any app marketplace that publishes web 
apps conforming to the manifest spec in any browser and be able to 
install and use them.

We understand there might be other platforms on which a JS API may not 
be feasible (for eg: A Java API to install and manage these apps is 
equally important), but that shouldn't preclude us from standardizing 
the DOM API in browsers. The manifest and the API go hand-in-hand, as we 
think each of them is dramatically less useful without the other.

Q. Why only one app per origin?

A. We originally placed this restriction for security reasons. In 
Firefox (and most other browsers), the domain name is the primary 
security boundary - cookie jars, localStorage, XHRs are all bound to the 
domain. For supporting multiple apps per domain we would have to do some 
extra work to ensure that (potentially sensitive) permissions granted to 
one app do not leak into another app from the same domain. Additionally, 
this lets us use the origin of the domain as a globally unique 
identifier. Note that app1.example.org and app2.example.org are two 
different origins under this scheme.

That said, we've received a lot of developer feedback about the 
inconvenience of this restriction, and we are actively looking to lift 
it [3]. We cannot do this without a few other changes around permissions 
and enforcing specific UA behavior in "app mode" (as opposed to "browser 
mode"), but is something we can work towards.

Q. Apps are just web pages, why bother "installing" them?

A. This has been previously discussed on the list [4]. There are clear 
differences in perception between an app and a website for most users. 
Most web content is expected to be free, but the same content wrapped in 
an app is something people seem to be willing to pay for. Monetization 
is important to encourage a thriving web developer community.

Additionally, treating certain "installed" websites as apps gives us a 
context separate from loading pages in a browser, which allows us to 
provide privileged APIs to such trusted apps, APIs we would normally not 
give to untrusted web content.

Thanks for reading!


[1] https://mozilla.org/apps/
[2] https://www.w3.org/TR/widgets/
[4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html
Received on Sunday, 13 May 2012 08:12:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC