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 to
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
[Bug 17042] New: Last-Event-ID is not a simple header
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17042 Summary: Last-Event-ID is not a simple header Product: WebAppsWG Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: XHR 2.0 AssignedTo: ann...@annevk.nl ReportedBy: vic99...@yandex.ru QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Server-sent-events use this header with CORS http://www.w3.org/TR/eventsource/#last-event-id -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug 17042] Last-Event-ID is not a simple header
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17042 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Anne ann...@annevk.nl 2012-05-13 10:12:25 UTC --- More importantly, it's not an author request header. -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Review of Web Application Manifest Format and Management APIs
Hi Marcos, Thanks for the thorough review, this is extremely useful! Most things seems fixable fairly easily, for those that aren't, comments inline: On 5/12/2012 4:32 PM, Marcos Caceres wrote: 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? The locales property is a dictionary, so there is no reliable way to pick the first from the list. We'd have to convert it to an array and add one more level of nesting which seemed a bit more complex compared to adding a property at the top-level. 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? Yes, all HTTP responses are honored, as long as the redirects are within the same origin, since it's the origin that identifies the app. The UA should enforce this policy, we should add some language to that effect. 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? If we use HTML icons, app stores will have to load the app's home page in the background in order to extract the icon to display on their storefront. Since they have to fetch manifests when a developer submits their app to the store anyway, it seemed useful to include icons. It also helps user agents display icons for apps, in an app dashboard, for example, without having to load a HTML pages in the background. Icons must be square. Why? and what if they are not square? Seems like a fairly platform specific restriction? Yes, this is a fairly whimsical restriction, when we were trying to get some consistency. There is no important reason they should be, I'll remove it. 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 *? Language-Tag, correct. * is not allowed, and the manifest will be rejected as invalid. If you want to apply a set of values for any language, just skip the locales property entirely. 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? By the author. What this means is that locales, installs_allowed_from and default are invalid properties inside any object in the locales top-level property. If any of those three is found, the manifest is rejected as invalid. 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? We have two options here. In our current implementation we simply ignore the locales property in this case and only use the top-level name and description. The other option is to reject the manifest as invalid. I have no strong feelings for one over the other. 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? I'm not sure what the question means, but origins are essentially a combination of [protocol]://[hostname]:[port]. Whenever an install is triggered, the UA must check if the origin of the page triggering the install is present in this array. * is a valid value for installs_allowed_from, in which case the UA may skip this check. 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? These values do not interfere with runtime detection via media queries. The use case for these values is two-fold: - An app store may prevent the user from installing an app on a device which doesn't meet this criteria - A UA may prevent the user from launching an app on a device which doesn't meet this criteria The primary goal in both cases is to let the developer declare what screen sizes their app is known to work correctly. 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). Examples include touch,
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
