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: http://dvcs.w3.org/hg/app-manifest/raw-file/tip/index.html We'd like to propose using that draft as the basis for a FPWD on this topic. I look forward to your feedback! FAQs -- 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 list: 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! Regards, -Anant [1] https://mozilla.org/apps/ [2] https://www.w3.org/TR/widgets/ [3] https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/9482dcd34fa8c1a4 [4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html
Re: App Manifest API Proposal
Hi Anant, Great to see Moz pushing this forwards - and welcome to the WG!:) I'm excited to see this proposal and I'm looking forward to working with you on it as part of the WG. On Saturday, 12 May 2012 at 19:02, Anant Narayanan wrote: 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; Renaming the W3C widget spec would take about seconds :) No one is married to the name as we all know the name widgets is stupid (who would have figured stupid names matter so much:)). Bikesheds aside, I think quite a few people on this list would like to see the two efforts merged. Quite a lot of investment has been made into the widgets specs by various companies here so it would be good not to throw the baby out with the bathwater (e.g., the Moz proposal uses the same element semantics in its JSON format than the W3C widgets format, the i18n models are essentially the same… and most notably, the Moz proposal sorely lacks a parsing/error recovery model, which could simply be adapted from the W3C widgets spec). the other fundamental difference is that the widget spec describes packaged apps, whereas our manifest describes hosted apps. This is not exactly true. The metadata format is consequently bound to the zip file (but the relationships are pretty weak between a config.xml and its container… some places require a file path, but those could just be swapped out with a URL or path relative to some origin). The only reason that there is a weak relationship between a config.xml and the package is because: a. HTML was supposed to handle the metadata for the app. b. There was no drive to standardise what is being proposed now 6 years ago (and slightly related, XML was still all the rage back then… and it's even so today on some platforms like Android). Another counter to the packaged/hosted app assertion is Apache Wookie's use of W3C widgets to embed widgets the Web: http://incubator.apache.org/wookie/ 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!). Yes, it is common knowledge that AppCache is a douchebag (technical term) :) Packaged apps do have their own advantages though, which we acknowledge, and are open to extending the spec to support both types of apps. So, to be honest, my concern with the current proposal is that we have regressed back a little bit compared to widgets: the current proposal is a good start, but is lacking several key things (e.g., the parsing/error handling model). I would urge the group to consider a merge between the two approaches so that the JSON format could also be used with packaged apps (and that we drop the archaic/stupid/hated word widget once and for all). Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: App Manifest API Proposal
On Sat, 12 May 2012, Anant Narayanan wrote: Q. Apps are just web pages, why bother installing them? A. This has been previously discussed on the list [4]. [4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html This has already received a reply: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0465.html 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. I don't think it makes sense to use a technical solution to a non-technical problem. 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. Desktop operating systems have demonstrated over a period of many years that this approach simply doesn't work. Users find it very difficult to understand what it means to trust an app. The Web's security model is IMHO significantly superior than any of the app security models we have seen in native operating systems, as demonstrated by the way that when malware is written to the app model it has to be dealt with by curating the application market space, whereas when malware is written to the Web model it is almost always because of errors in the design or implementation of the Web platform that, once fixed, preclude any similar attack from being performed again. The installation security model of asking the user up-front to grant trust just doesn't work because users don't understand the question, and the installation security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn't scale. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: App Manifest API Proposal
On 5/12/2012 1:14 PM, Ian Hickson wrote: On Sat, 12 May 2012, Anant Narayanan wrote: 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. I don't think it makes sense to use a technical solution to a non-technical problem. The proposed spec is not the solution, but rather forms the technical basis for the actual solution which is to build an app ecosystem around web technologies. It is futile to try and educate users of how the web *really* works, and thus we must move to terminology and conventions that they already know and understand (purchase/install apps from stores). 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. Desktop operating systems have demonstrated over a period of many years that this approach simply doesn't work. Users find it very difficult to understand what it means to trust an app. The Web's security model is IMHO significantly superior than any of the app security models we have seen in native operating systems, as demonstrated by the way that when malware is written to the app model it has to be dealt with by curating the application market space, whereas when malware is written to the Web model it is almost always because of errors in the design or implementation of the Web platform that, once fixed, preclude any similar attack from being performed again. The installation security model of asking the user up-front to grant trust just doesn't work because users don't understand the question, and the installation security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn't scale. We are not suggesting that a web app be automatically given privileges simply on the virtue of being installed. Untrusted installed apps are no different from any web page in that regard. Neither are we suggesting that all permissions be asked up-front. For some APIs it makes sense to ask up front, for others, run-time is more appropriate. The real security comes from curated stores, ratings, signed apps, pro-active take-downs and many other such measures. The main point is that creating a layer of trust beyond what we have for web pages allows such privileges to be granted to a set of apps that meet certain criteria. We are discussing the security model for each type of API in detail on the dev.webapps list [1], but the general idea is to categorize every API into one of three buckets: Regular content (unauthenticated web pages and apps) Trusted content (apps authenticated by publisher) Certified content (apps vouched for by trusted 3rd party) Apps in a curated store fall in the 2nd category, whereas sensitive apps like the dialer on a phone would fall into the 3rd category because they are, for example, pre-bundled and signed. A regular web app that simply adds an install button to their page would fall in the first category. The real value to such a system is on mobile devices rather than desktops. The fact remains that most users spend less time in a browser than in an app when they are using a phone or tablet. The open web platform needs to regain some of that lost attention. Regards, -Anant [1] https://groups.google.com/group/mozilla.dev.webapps/browse_thread/thread/52d86024cbfd0da6
Re: App Manifest API Proposal
The installation security model of asking the user up-front to grant trust just doesn't work because users don't understand the question, and the installation security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn't scale. Installing an application doesn't mean up-front grant of permissions. It merely means that we offer a way to get away from a mere visit document mode to a run interactive applications mode. In our Boot 2 Gecko implementation we use the fact that the user installed a web app as a general grant of some low-risk privileges such as yep, you can use app cache and we won't bother you with quota dialogs. Beyond that, we use the regular web security model wherever possible (e.g. geolocation). The UX crowd seems to think that offering the ability to grant these permissions at install time as an option (opt-in) is good practice, so thats a good additional way to handle this. But the general principle is to stick with the web's pay-as-you-go model (doorhangers etc). I definitely agree with you that thats the better model. As for using curation, I agree that it doesn't scale if all web content needs high risk privileges that rely on curation. In practice most web apps need minimal or no privileges that can be handled with the traditional model, and very few web apps rely on curation to get access to risky privileges. Andreas -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: App Manifest API Proposal
On Saturday, 12 May 2012 at 21:14, Ian Hickson wrote: On Sat, 12 May 2012, Anant Narayanan wrote: Q. Apps are just web pages, why bother installing them? A. This has been previously discussed on the list [4]. [4] http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0464.html This has already received a reply: http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0465.html 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. I don't think it makes sense to use a technical solution to a non-technical problem. It's sometimes nice to have a curated space to find interesting apps - though I agree that this is not a technical problem, though the manifest format facilitates this to some respect *iff it fills gaps in the HTML spec with regards to metadata* (or maybe some API aspect, though I've not looked at those in any detail). If this warrants standardisation, I don't know… guess that is what we are trying to figure out. 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. Desktop operating systems have demonstrated over a period of many years that this approach simply doesn't work. Users find it very difficult to understand what it means to trust an app. The Web's security model is IMHO significantly superior than any of the app security models we have seen in native operating systems, as demonstrated by the way that when malware is written to the app model it has to be dealt with by curating the application market space, whereas when malware is written to the Web model it is almost always because of errors in the design or implementation of the Web platform that, once fixed, preclude any similar attack from being performed again. The installation security model of asking the user up-front to grant trust just doesn't work because users don't understand the question, and the installation security model of curating apps and trying to determine by empirical examination whether an application is trustworthy or not just doesn't scale. I agree with Ian about the above, which is why I was hopeful that feature thing is not needed in the manifest format (or the manifest format is not needed at all). Features have historically enable proprietary APIs (in Chrome extension, Opera extensions, and WAC for example), which likely won't interoperate (so features will also require standardisation). In my email I said that we (the widget-side of the Webapps WG) were hopeful that HTML would provide the needed app metadata to allow apps to be installed in some meaningful way (e.g., HTML provides icon support already, and I think Opera exploits this in speed dial - which serve a similar purpose to a installed app/visual bookmarks). So I'm left wondering, what is missing (if anything) from HTML to meet the use cases that Moz's proposed manifest and API sets out to provide? -- Marcos Caceres http://datadriven.com.au
Review of Web Application Manifest Format and Management APIs
Hi Anant, Here is a quick review of the Web Application Manifest Format and Management APIs proposal. On Saturday, 12 May 2012 at 20:37, Marcos Caceres wrote: Web Application Manifest Format and Management APIs Abstract This document specifies a JSON based format to describe installable web applications. In addition, a set of JavaScript APIs are described that allow web content to trigger installation of such applications, as well as manage them on behalf of the user. 1. App Manifest An application manifest is a JSON file describing an installable web application. Should be: An application manifest is a [HTTP] resource served with the a ...app-mainfest content type/a. It is recommended that the manifest be encoded as UTF-8. This JSON file consists of a top-level object and several properties. Should be: The manifest consists of… Probably best not to speak of files as these are coming from the server (and might be completely auto generated). 1.2 Properties Mandatory Properties name: The name of the web application in the default locale. Maximum length is 128 characters. It's not clear why would this be limited to 128 characters? Also, what happens if the size is exceeded? description: A short description of the web application in the default locale. Maximum length is 1024 characters. As above. default_locale: [Mandatory only if locales property is set]. The locale of the top-level name and description. Why not just take the first locale encountered? Optional Properties launch_path: The path within the web application's origin that is loaded when the application is launched What happens if the path redirects? Are HTTP responses honoured? icons: A map of icon sizes to URIs of the icons (which may be absolute or data URIs). Why not just use HTML's icons? Icons must be square. Why? and what if they are not square? Seems like a fairly platform specific restriction? developer: Information about the developer of the application, suitable for display. name: The name of the developer. url: A URL pointing to the developer's website locales: A map of locale specific overrides of data contained in the manifest. Each locale key is keyed on a locale tag [RFC4646], and contains a sparse representation of the manifest. I think you mean a Language-Tag? What happens if it's not a language tag? What happens if it's a *? Any field in the locales property will override the corresponding property in the manifest. The locales, installs_allowed_from, and default_locale CANNOT be overridden. By the author or by the runtime? If the locales property is set, the default_locale must also be set. What happens if it's not set? What happens if only locale data is set? installs_allowed_from: An array of origins that are allowed to trigger installation of this application. This field allows the developer to restrict installation of their application to specific sites. If the value is omitted, installs are allowed from any site. How are origins parsed? version: A string that represents the version of this manifest. The User-Agent does not interpret this value in any way and is opqaue to everyone Typo: opqaue opaque but the application itself. The field is provided to help the developer deal with various update cases, which will be discussed in following sections. This was not discussed. screen_size: This object may contain the min_height and min_width properties that describe the minimum height and width (in pixels) the application needs in order to render correctly. Interpretation of these values is left up to the runtime and/or app store. How does this play with CSS and media queries in particular? What's the use case? required_features: This array consists of a set of values that describes the mandatory features the application needs in order to run correctly. A full list of valid values is TBD. Interested to see what could be listed here… this is the area of greatest interop concern, IMO (hopefully it won't be needed at all, as it's only really useful on extension/proprietary platforms). orientation: This value defines the orientation at which the application will initially start. Can be one of portrait, landscape, portrait-secondary or landscape-secondary. Could this be handled on a per page basis using CSS device adaption? http://dev.w3.org/csswg/css-device-adapt/#the-lsquoorientationrsquo-descriptor The options suffixed with -secondary imply a 180 degree rotation from the options without the suffix, for instance, holding the phone upside down (but still in a manner where width height), implies the portrait-secondary orientation. If this field had a valid value, the runtime will not change the orientation of the view rendering the application even if the device is turned. fullscreen: This value is set to true or false to describe whether the
