Re: App Manifest API Proposal
On 5/13/12 2:17 PM, SULLIVAN, BRYAN L wrote: For (1) we can expect a text change, right? Yes, I will make them as soon as I able to. For (2), If the app manifest if obtained over non-secure HTTP, it is subject to modification. If the app is delivered over non-secure HTTP, even more can be modified. So is the plan to provide some kind of user warning when the manifest and/or app (including assets from the same origin) are delivered via non-secure HTTP (in the absence of a manifest signature)? And even if a manifest signature is provided how does it ensure protection of the assets (e.g. JS, CSS, and HTML) if they are delivered over non-secure HTTP? Does HTTPS need to be enforced, and cert domain validation as well? We've previously discussed enforcing serving manifests over HTTPS, but it may not be appropriate to put this into the spec itself. Different user agents may choose to do different things, ranging from disallowing installs over HTTP or warning the user before proceeding. Regards, -Anant
Re: App Manifest API Proposal
On Monday, 14 May 2012 at 17:44, Anant Narayanan wrote: We've previously discussed enforcing serving manifests over HTTPS, but it may not be appropriate to put this into the spec itself. Different user agents may choose to do different things, ranging from disallowing installs over HTTP or warning the user before proceeding. I agree - trying to enface this in the spec would be unhelpful. Would make, for instance, testing really annoying because devs would need to shell out a bunch of money for a static IP and an SSL cert. -- Marcos Caceres http://datadriven.com.au
Re: App Manifest API Proposal
Hi Scott, Thanks for your comments, more inline. On 5/13/12 12:06 PM, Scott Wilson wrote: On 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), To be fair, you can call your implementation anything you want even if it implements the Widget specs. Maybe we could rename the Widget specs Widgets, Apps, Gadgets or Whatever specs. If you really, really hate the word that much you could decide to call the TWI widget object app instead in your own documentation, and just silently convert window.widget to window.app whenever you come across it. To reciprocate, I could add a line somewhere in Apache Wookie and Apache Cordova that does the exact opposite. Interoperability FTW! I'm trying to understand how building on the widget spec would work in practice. I'm not opposed to it on principle, but we (Mozilla) have chosen not to implement the widget spec in the past, but we have already implemented the JSON manifest and API spec. If we rework this proposal as an extension to the widget spec, does it mean we will have to implement the entirety of the widget spec too? Essentially, I'd like to make both spec independently implementable, even if we chose to extend some objects defined in the widget spec. and replacing XML with JSON; No objections to representing the manifest in JSON either. Would a serialization of The Widget Interface as a JSON manifest file obviate the need for defining basically the same metadata in a different spec? We can then just focus on the things that definitely aren't part of existing specs, such as the security model, installation events, and default orientation, all of which look like interesting extensions. Rich Tibbett from Opera did precisely that, you can see a mapping here: http://people.opera.com/richt/release/specs/manifests/widgets_to_app_manifest.html It looks good to me in general, but I'm a little wary of committing to all fields that are valid keys in the XML schema. Is there a way we can take a subset instead? the other fundamental difference is that the widget spec describes packaged apps, whereas our manifest describes hosted apps. Widgets is also used for hosted as well as packaged apps e.g. Apache Wookie + Apache Rave... Ah, that's really good to know; I hadn't come across a widget that was hosted before, but looks like it is possible. 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!). Which are the bits of this proposal that are important for this and which aren't found in Widgets? Can we add those to the existing specs to fill any gaps? The manifests in the proposal don't have an id field, because an app is simply identified by the domain from which the manifest for it was fetched. This is the key difference, but I'll have to look deeper at the Widget spec to see if there are any more. Packaged apps do have their own advantages though, which we acknowledge, and are open to extending the spec to support both types of apps. Hmm, that does kind of negate the previous point... but moving on..! We don't support packaged apps yet, either in the specification or the implementation. If possible we'd like to go hosted + appcache as far as we can. I mentioned this because I don't want packaged apps to be a reason for this spec to be rejected. I'm very positive about this proposal and would love to see it merged into Widgets:PC TWI, with perhaps a separate spec on web app/widget installation including the work Mozilla has done on installation APIs and events. I'm glad you like the proposal! However, I would really like to see the API and manifest in the same document, because, as I mentioned earlier, at-least in the context of browsers they are dependent on each other. What does it mean for a browser to only implement the manifest spec but not the installation API (or vice-versa)? On the other hand, there might be other User-Agents that won't have the installation API though, because they don't have a DOM or support JavaScript; in which case we could seperate them but write additional text that recommends implementing both for environments that have a DOM. I'm not sure if that's in scope for the working group. I'd be interested in implementing those in Apache Wookie, Apache Rave and related projects and initiatives that build on them, as web app installation and app store APIs are something thats come up in quite a few implementations and it would be great to have a spec for that. Just don't tie it to another competing manifest format, please! The current widget spec doesn't allow for a JSON representation. We will have to come up with a
Re: App Manifest API Proposal
On 5/14/12 10:47 AM, Mounir Lamouri wrote: I don't think we can justify the choice of one app per origin just because it's how browsers work nowadays regarding security and permissions. This is an implementation detail and we shouldn't write specs based on implementation details. And that might be true only for some browsers and not for others. Agree wholeheartedly! In addition, how permissions are currently handled already have serious limitations which would make the app security model hard to implement if we stick to a simple origin definition. For example, if I go to foo.example.com from APP1 (because APP1 is from that origin or because I'm browsing that website from that app) and then I go to foo.example.com from APP2, should permissions given when I was using APP1 given to APP2? I don't think we should. Concretely that means that a website accessed from it's dedicated app and the same website browsed from a browser app would have the same permissions or that a website browsed from browser foo and the same website browsed from browser bar would also have the same permissions. I don't understand this scenario fully, permissions given to an app are tied to its origin and cannot be extended to any other domain, irrespective of whether that domain was accessed via the app (an iframe or something else). We do not allow an app to navigate outside its origin at the top-level window. IMO, the manifest URL should be the unique identifier for an application so we should not restricts applications per origin and the security model should consider that permissions where given to a specific origin inside a specific application. I'm not sure how this would work. Not only do we have to isolate API permissions between two apps from the same domain, but also other things like cookie jars, localStorage, indexedDB, XHR, and so on. How will you enforce App1 from being unable to XHR to App2 even though they're both from the same domain? In particular, how do you know what pages from a given domain belong to which app? One possibility is to allow suffixes: (example.org/app1, example.org/app2), but the manifest URL by itself is insufficient. -Anant
Re: App Manifest API Proposal
On 14 May 2012, at 18:12, Anant Narayanan wrote: Hi Scott, Thanks for your comments, more inline. On 5/13/12 12:06 PM, Scott Wilson wrote: On 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), To be fair, you can call your implementation anything you want even if it implements the Widget specs. Maybe we could rename the Widget specs Widgets, Apps, Gadgets or Whatever specs. If you really, really hate the word that much you could decide to call the TWI widget object app instead in your own documentation, and just silently convert window.widget to window.app whenever you come across it. To reciprocate, I could add a line somewhere in Apache Wookie and Apache Cordova that does the exact opposite. Interoperability FTW! I'm trying to understand how building on the widget spec would work in practice. I'm not opposed to it on principle, but we (Mozilla) have chosen not to implement the widget spec in the past, but we have already implemented the JSON manifest and API spec. If we rework this proposal as an extension to the widget spec, does it mean we will have to implement the entirety of the widget spec too? Entirety of the widget spec isn't much - you've done most of it already. If you mean would you have to support an XML manifest, or support packaged apps as well as naked manifests? No, I can't see a reason you would. Comparing TWI with the proposal, the only things in TWI that are additional are shortName, authorEmail, and preferences. Preferences may not make sense for Mozilla's implementation - if so, don't use them, or autowire into WebStorage. Essentially, I'd like to make both spec independently implementable, even if we chose to extend some objects defined in the widget spec. and replacing XML with JSON; No objections to representing the manifest in JSON either. Would a serialization of The Widget Interface as a JSON manifest file obviate the need for defining basically the same metadata in a different spec? We can then just focus on the things that definitely aren't part of existing specs, such as the security model, installation events, and default orientation, all of which look like interesting extensions. Rich Tibbett from Opera did precisely that, you can see a mapping here: http://people.opera.com/richt/release/specs/manifests/widgets_to_app_manifest.html It looks good to me in general, but I'm a little wary of committing to all fields that are valid keys in the XML schema. Is there a way we can take a subset instead? The spec defines the set of widget metadata. If you only choose to use a subset in implementation, thats fine. Also, don't worry about the XML - I think the main point of comparison is the Widget Interface spec which already maps a subset of the XML manifest properties to JS properties that make sense in the browsing context of a running widget. So manifest properties that only really apply to a packaged widget wouldn't necessarily be used in a JSON representation for a hosted widget. the other fundamental difference is that the widget spec describes packaged apps, whereas our manifest describes hosted apps. Widgets is also used for hosted as well as packaged apps e.g. Apache Wookie + Apache Rave... Ah, that's really good to know; I hadn't come across a widget that was hosted before, but looks like it is possible. 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!). Which are the bits of this proposal that are important for this and which aren't found in Widgets? Can we add those to the existing specs to fill any gaps? The manifests in the proposal don't have an id field, because an app is simply identified by the domain from which the manifest for it was fetched. This is the key difference, but I'll have to look deeper at the Widget spec to see if there are any more. The id property is optional in widgets anyway. Packaged apps do have their own advantages though, which we acknowledge, and are open to extending the spec to support both types of apps. Hmm, that does kind of negate the previous point... but moving on..! We don't support packaged apps yet, either in the specification or the implementation. If possible we'd like to go hosted + appcache as far as we can. I mentioned this because I don't want packaged apps to be a reason for this spec to be rejected. I'm very positive about this proposal and would love to see it merged into Widgets:PC TWI, with perhaps a separate spec on web app/widget installation including the work Mozilla has done on installation APIs and events.
Re: App Manifest API Proposal
Hi Anant, On 14/05/2012 18:12, Anant Narayanan wrote: Hi Scott, Thanks for your comments, more inline. On 5/13/12 12:06 PM, Scott Wilson wrote: On 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), To be fair, you can call your implementation anything you want even if it implements the Widget specs. Maybe we could rename the Widget specs Widgets, Apps, Gadgets or Whatever specs. If you really, really hate the word that much you could decide to call the TWI widget object app instead in your own documentation, and just silently convert window.widget to window.app whenever you come across it. To reciprocate, I could add a line somewhere in Apache Wookie and Apache Cordova that does the exact opposite. Interoperability FTW! I'm trying to understand how building on the widget spec would work in practice. I'm not opposed to it on principle, but we (Mozilla) have chosen not to implement the widget spec in the past, but we have already implemented the JSON manifest and API spec. If we rework this proposal as an extension to the widget spec, does it mean we will have to implement the entirety of the widget spec too? Absolutely not: there would be no need to support the XML format. You just support a particular serialization (JSON) and not the packaging side (which is also orthogonal). But the semantics and data model remain the same across the specs where appropriate. Essentially, I'd like to make both spec independently implementable, even if we chose to extend some objects defined in the widget spec. Yes, that would be ideal. Historically, we renamed the Widget spec to Packaging and *XML Configuration* on purpose, because we've been anticipating the JSON format for a long long time (our requirement document has mentioned JSON as a target for many years [1]). We sat on it because we were waiting for Google or you guys to jump on it :) Ideal situation: JSON format should be usable by UAs that currently support XML format (if there is support for that from implementers like Opera). If you guys have new/interesting use cases, then we should keep the specs in sync. I'm happy to help keep them in synchornized. and replacing XML with JSON; No objections to representing the manifest in JSON either. Would a serialization of The Widget Interface as a JSON manifest file obviate the need for defining basically the same metadata in a different spec? We can then just focus on the things that definitely aren't part of existing specs, such as the security model, installation events, and default orientation, all of which look like interesting extensions. Rich Tibbett from Opera did precisely that, you can see a mapping here: http://people.opera.com/richt/release/specs/manifests/widgets_to_app_manifest.html It looks good to me in general, but I'm a little wary of committing to all fields that are valid keys in the XML schema. Is there a way we can take a subset instead? Absolutely! That would totally be ok. There is nothing required in the widget XML format at all. So, if you don't have a use case for something in the Widgets PC spec, then you can simply ignore it. This is by design. the other fundamental difference is that the widget spec describes packaged apps, whereas our manifest describes hosted apps. Widgets is also used for hosted as well as packaged apps e.g. Apache Wookie + Apache Rave... Ah, that's really good to know; I hadn't come across a widget that was hosted before, but looks like it is possible. There is a long legacy, dating back to the original Google Gadgets. 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!). Which are the bits of this proposal that are important for this and which aren't found in Widgets? Can we add those to the existing specs to fill any gaps? The manifests in the proposal don't have an id field, because an app is simply identified by the domain from which the manifest for it was fetched. This is the key difference, but I'll have to look deeper at the Widget spec to see if there are any more. Looking forward to seeing what you find. And remember, we are open to changes so feel free to discuss. Packaged apps do have their own advantages though, which we acknowledge, and are open to extending the spec to support both types of apps. Hmm, that does kind of negate the previous point... but moving on..! We don't support packaged apps yet, either in the specification or the implementation. If possible we'd like to go hosted + appcache as far as we can. I mentioned this because I don't want packaged apps to be a reason for this spec to be rejected. I think that is
RE: App Manifest API Proposal
At least in the widget model, the manifest (including feature elements) provides a means of disclosure to the user about the APIs that the app wants to access. Of course if one assumes that users are brainless click-happy automatons then such disclosures are useless, but at that end of the extreme the value of curated appstore services is clear, to me at least. I note that appstores are big businesses for native platform vendors also, and I assume that they support extension of that model to Webapps. There will always be a tension between the pure protection that a perfect Web security model will provide (good luck with that), and the (perhaps, sometimes misplaced) trust in a system of curation. But even in the apps come from servers camp, there is curation involved, by the Website operator (who creates links) and the user (who chooses what sites to visit). Someone has to choose. I personally do not think we can design a Web security model that eliminates all need for intelligent choices, whether supported through informed consent or by personal experience with a Website / app author. On whether the concept of installation fits into the Web model, I note that Webapp device platforms are nearing launch, which will depend upon installation of apps as they will take the place of native apps (they become the native apps). A lot of apps will still of course be transient, as server-based models still have unique valuable features. But the Web is growing beyond the browser (as with Webview API's it's already been growing for a number of years), and to do so it needs to accommodate the curator-trust model of appstores, and the metadata that enables informed user consent. Thanks, Bryan Sullivan -Original Message- From: Marcos Caceres [mailto:w...@marcosc.com] Sent: Saturday, May 12, 2012 2:57 PM To: Anant Narayanan; Ian Hickson Cc: public-webapps Subject: 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
RE: App Manifest API Proposal
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). Thanks, Bryan Sullivan -Original Message- From: Anant Narayanan [mailto:an...@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: 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
Re: App Manifest API Proposal
On 5/12/2012 2:57 PM, Marcos Caceres wrote: On Saturday, 12 May 2012 at 21:14, Ian Hickson wrote: 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? The big difference is runtime vs. install/launch time. As I noted in the other review email, we'd like to give developers, stores and UAs a little more information about any given app before they actually let the user purchase/install/launch the app. -Anant
Re: App Manifest API Proposal
Hi Sullivan, Thanks for your comments, some responses inline: On 5/13/2012 1:11 AM, SULLIVAN, BRYAN L wrote: 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. Yes, absolutely. 2) How do you propose that the manifest information be trusted, through signature on the JSON file? We haven't devised any signing scheme yet, we are only relying on manifests being served over SSL for establishing trust. I recall someone from Google saying something quote-worthy regarding this: If it's good enough for your banking, it's good enough to install some apps :) That said, we are definitely open to adding signatures. This already seems required for packaged apps for highly sensitive apps like phone dialers, as we are discovering for B2G. 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). Correct, this is one of the reasons we enforce one app per origin (posing as another app becomes very hard). Relaxing that restriction won't be trivial as we have to consider this and many other repercussions. 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). As I mentioned in another email, I'm not too worried about duplication in two places as the goals are different. The point of storing such information in the manifest is to enable various parties to make decisions about how they will handle an app before purchase/install/launch time. As you noted in your previous email, the manifest is also an appropriate place to let the developer declare what APIs they intend to use, regardless of whether the UA asks for user permission up-front or at run-time. Regards, -Anant
Re: App Manifest API Proposal
On 12 May 2012, at 19:02, Anant Narayanan wrote: 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), To be fair, you can call your implementation anything you want even if it implements the Widget specs. Maybe we could rename the Widget specs Widgets, Apps, Gadgets or Whatever specs. If you really, really hate the word that much you could decide to call the TWI widget object app instead in your own documentation, and just silently convert window.widget to window.app whenever you come across it. To reciprocate, I could add a line somewhere in Apache Wookie and Apache Cordova that does the exact opposite. Interoperability FTW! and replacing XML with JSON; No objections to representing the manifest in JSON either. Would a serialization of The Widget Interface as a JSON manifest file obviate the need for defining basically the same metadata in a different spec? We can then just focus on the things that definitely aren't part of existing specs, such as the security model, installation events, and default orientation, all of which look like interesting extensions. the other fundamental difference is that the widget spec describes packaged apps, whereas our manifest describes hosted apps. Widgets is also used for hosted as well as packaged apps e.g. Apache Wookie + Apache Rave... 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!). Which are the bits of this proposal that are important for this and which aren't found in Widgets? Can we add those to the existing specs to fill any gaps? Packaged apps do have their own advantages though, which we acknowledge, and are open to extending the spec to support both types of apps. Hmm, that does kind of negate the previous point... but moving on..! I'm very positive about this proposal and would love to see it merged into Widgets:PC TWI, with perhaps a separate spec on web app/widget installation including the work Mozilla has done on installation APIs and events. I'd be interested in implementing those in Apache Wookie, Apache Rave and related projects and initiatives that build on them, as web app installation and app store APIs are something thats come up in quite a few implementations and it would be great to have a spec for that. Just don't tie it to another competing manifest format, please! 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
Re: App Manifest API Proposal
Ok, thanks for the responses. For (1) we can expect a text change, right? For (2), If the app manifest if obtained over non-secure HTTP, it is subject to modification. If the app is delivered over non-secure HTTP, even more can be modified. So is the plan to provide some kind of user warning when the manifest and/or app (including assets from the same origin) are delivered via non-secure HTTP (in the absence of a manifest signature)? And even if a manifest signature is provided how does it ensure protection of the assets (e.g. JS, CSS, and HTML) if they are delivered over non-secure HTTP? Does HTTPS need to be enforced, and cert domain validation as well? For 3), I understand. We went through a lot of the similar issues in WAC, so maybe some of that experience will be useful in the discussion. For 4), the ability to present the user with info/options prior to downloading the app (or its root page), or to process the manifest in an app manager / AppStore client, is probably the key added value. So from that perspective, i agree that supporting similar info In a Web page markup doesn't add value in this case, and does prevent the pre-processing capability. Thanks, Bryan Sullivan On May 13, 2012, at 7:04 PM, Anant Narayanan an...@mozilla.com wrote: Hi Sullivan, Thanks for your comments, some responses inline: On 5/13/2012 1:11 AM, SULLIVAN, BRYAN L wrote: 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. Yes, absolutely. 2) How do you propose that the manifest information be trusted, through signature on the JSON file? We haven't devised any signing scheme yet, we are only relying on manifests being served over SSL for establishing trust. I recall someone from Google saying something quote-worthy regarding this: If it's good enough for your banking, it's good enough to install some apps :) That said, we are definitely open to adding signatures. This already seems required for packaged apps for highly sensitive apps like phone dialers, as we are discovering for B2G. 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). Correct, this is one of the reasons we enforce one app per origin (posing as another app becomes very hard). Relaxing that restriction won't be trivial as we have to consider this and many other repercussions. 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). As I mentioned in another email, I'm not too worried about duplication in two places as the goals are different. The point of storing such information in the manifest is to enable various parties to make decisions about how they will handle an app before purchase/install/launch time. As you noted in your previous email, the manifest is also an appropriate place to let the developer declare what APIs they intend to use, regardless of whether the UA asks for user permission up-front or at run-time. Regards, -Anant
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
