Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs
On 05/27/2012 12:53 PM, Scott Wilson wrote: On 27 May 2012, at 17:49, Anant Narayanan wrote: On 05/27/2012 05:11 AM, Marcos Caceres wrote: Sure, but doesn't that lead to the original complaint that certain developers don't want their application to install at all for PR reasons? In combination with installs_allowed_from, some apps can choose to publish only on certain stores with which they have an agreement that users won't be allowed to install apps on devices they weren't designed for. Sure, it would be easy to bypass this since there is no UA enforcement, but this would be limited to a fairly small technical crowd. Two objections: - If its metadata intended for web app *stores* wouldn't it make more sense as part of the metadata for store submission, rather than an API for browser-type UAs? (Once more I'm CCing the web app stores CG...) I think it is useful for UAs to have this information. Even if we don't make it mandatory for UAs to enforce the size restrictions in the spec, some might choose to. - If its easy to bypass, why bother with it? (I once wrote a greasemonkey script that let the Chrome Store work on Firefox :) A large majority of users will never bother bypassing the restriction, either due to lack of skill or time. Even if UAs did enforce it, it would be possible to bypass (in Firefox at-least, via an add-on). I don't anticipate that to be a huge issue, as long as we cover 90% or more users having a good experience for apps on any device. -Anant
Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs
On 05/27/2012 01:35 AM, Marcos Caceres wrote: On 26 May 2012, at 18:32, Anant Narayananan...@mozilla.com wrote: The intent for the screen_size parameters is not to let the developer enforce a particular screen size or resolution, but rather specify the *minimum* width and height required by the app. This means that on a screen below the specified size, the app will not function at all. To make this more clear, maybe call this min_screen_size. Well, we haven't received this request from developers explicitly yet, but one can imagine a situation in which a developer makes an app only for mobile phones (Instagram?) and doesn't want users to use it on desktops. Even though it'll technically work, it might look ugly due to scaling. In this case, we'll need a max_screen_size. I will also note that it is upto the app store to interpret this field however they'd like. If they do not want to disallow installs on devices that don't meet the developer-specified criteria, that's fine. However, we should still convey this information from the developer to the store via the manifest. At install time or when I am browsing apps, how does a server know my screen resolution? Or is this restriction imposed on by the user agent? The same way an app would find out, by feature sniffing. The app store is also presumably a web page or a native store, in either case, it should be able to know the characteristics of the current device using standard techniques. It is unrealistic to assume that all app developers will make a responsive design for all possible screen sizes. The tools aren't great and it costs time and money. We added this field after we received a request from the developer of a popular game that only worked on desktops, but not mobile phones (due to size). They wanted to make sure users weren't able to install them in places the app wasn't designed for and get a bad impression of the company. I think this is really important. I think that's fine, but as Scott pointed pointed out, user agents have a history of allowing users to bypass these kinds of restrictions (or users hack around them). I think this field can only really serve as a warning that the app might not work as expected. Serving as a warning is sufficient, I agree that we will always have some % of users ignore the warning and install it anyway. -Anant
Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs
On 05/27/2012 05:11 AM, Marcos Caceres wrote: On 27/05/2012 12:36, SULLIVAN, BRYAN L wrote: Re At install time or when I am browsing apps, how does a server know my screen resolution? Or is this restriction imposed on by the user agent?: When browsing apps, the server can easily access the screen and window DOM attributes. Right, but that requires some communication that is implicit in the spec. I'm trying to figure out what data is leaving my device and going to the server, and why (i.e., what is the expected life cycle model). There is all sorts of things that are implied going on behind the scenes that this spec eludes to (e.g., installation management/sync across devices), and it's good to get a sense of how it all comes together. If it's not clear in the spec, then I have a hard time seeing how multiple user agents will be able behave in an interoperable manner. There is no extra data leaving your device. When you visit a store it will probe for your current device capabilities, and the store, at its discretion, can decide whether or not to let the user install an app. There is no enforcement by the User-Agent at install time. Synchronization is an interesting problem that we haven't fully tackled head-on yet. So we might need to add some UA enforcement at sync time as opposed to install time. When installing apps, the installer (browser, app manager, etc) can provide a warning to the user that the app is designed for use on larger screens, and may not work properly on this device. Sure, but doesn't that lead to the original complaint that certain developers don't want their application to install at all for PR reasons? In combination with installs_allowed_from, some apps can choose to publish only on certain stores with which they have an agreement that users won't be allowed to install apps on devices they weren't designed for. Sure, it would be easy to bypass this since there is no UA enforcement, but this would be limited to a fairly small technical crowd. -Anant
Re: [manifest] Parsing origins, was Re: Review of Web Application Manifest Format and Management APIs
On 05/25/2012 11:11 PM, Adam Barth wrote: On Fri, May 25, 2012 at 7:39 AM, Marcos Caceresw...@marcosc.com wrote: On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote: 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. By parsing I mean which ones win, which ones get discarded, what happens to invalid ones, are they resolved already, etc. in the following: installs_allowed_from: [http://foo/ , bar://, 22, https://foo/bar/#*;, http://foo:80/;, wee!!!, http://baz/hello there!, http://baz/hello%20there!;] And so on. So, all the error handling stuff. Or is a single error fatal? I seem to have missed the context for this thread, but typically origins are not parsed. They're compared character-by-character to see if they're identical. If you have a URL, you can find its origin and then serialize it to ASCII or Unicode if you want to compare it with another origin. Ah we could certainly do this, but in our current implementation a single error is fatal. I do like the idea of not making sure that the origins are valid, especially for installs_allowed_from. -Anant
Re: [manifest] screen sizes, Re: Review of Web Application Manifest Format and Management APIs
On 05/25/2012 09:25 AM, Marcos Caceres wrote: On Friday, May 25, 2012 at 4:34 PM, SULLIVAN, BRYAN L wrote: Marcos, Re I thought we had stopped the whole designing for particular screen sizes, etc. a long time ago., that may be the still-closely-held goal, but the reality is that designing for multiple screen sizes (and pixel densities) is still far from simple. Even with all the tools that have been developed in CSS and Media Queries. So if developers want to claim that they have focused their design on specific form factors (and presumably tested it thoroughly on them), this seems like a good thing as it allows them to be more certain that their apps won't be distributed to users of devices on which they won't work well (which will negatively impact the developer's reputation, use of the app, appstore etc), or if distributed to such users, will be clearly identified as not being designed for those devices. Like many of the things we wanted to do in widget manifest structures in BONDI and WAC, if these get pulled from the plan the only fallback is developer ecosystem-specific app metadata, which in the end evaporates with the developer ecosystems, or never achieves widespread use or interoperability. So the problem is not solved for developers by leaving these things out of standards, where there is a strong use case. Still sounds to me like Made forinsert everyone's favorite 90's browser here, and best viewed at 800x600 … and look how well that turned out. Even if we don't focus on mobile devices, it seems like a silly requirement as I can just adjust my browser window to whatever size I want (there is no reason to believe I won't be able to do that on future mobile devices). I.e., screen size and application display area are not the same thing and this metadata attribute seems to assume so. The intent for the screen_size parameters is not to let the developer enforce a particular screen size or resolution, but rather specify the *minimum* width and height required by the app. This means that on a screen below the specified size, the app will not function at all. I will also note that it is upto the app store to interpret this field however they'd like. If they do not want to disallow installs on devices that don't meet the developer-specified criteria, that's fine. However, we should still convey this information from the developer to the store via the manifest. It is unrealistic to assume that all app developers will make a responsive design for all possible screen sizes. The tools aren't great and it costs time and money. We added this field after we received a request from the developer of a popular game that only worked on desktops, but not mobile phones (due to size). They wanted to make sure users weren't able to install them in places the app wasn't designed for and get a bad impression of the company. I think this is really important. -Anant
Re: [manifest] features Re: Review of Web Application Manifest Format and Management APIs
On 05/25/2012 07:54 AM, Marcos Caceres wrote: On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote: 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, webgl, indexeddb. You're right that it's possible to use this for proprietary extensions; but there are use cases for standard web features. The idea is to let the store and runtime have some control over not allowing the user to purchase/install/launch an app that is known not to work on their current device. For instance, if I am browsing for apps on my phone that doesn't support WebGL, the Mozilla App Marketplace won't let me install any apps that have that feature listed in required_features. Likewise, the runtime may prevent launching apps that are known to be incompatible with the current UA, quire similar to screen_size. I think this will quickly become unmanageable. It means you need to take the current web as it is today, freeze it, and then start hiding all future functionality that can only be enabled through this list (and the list of things you need to enable grows forever or you end up having to enable unexpected things, which then may cause security issues that the developer was not expecting). Hence, features like this should only be used for things that are sure not to be part of the Web Platform. This also goes against the trend of responsive design: it means that I can't make an app that both uses WebGL and falls back to legacy tech because the store will refuse to install it on my non-webGL-phone. So as a developer, I would need to release two versions of the same app. That is not the intent of the field. The required prefix indicates that these are *mandatory* features without which the application will not function at all. A camera app is no good without camera access, responsive design does not help. In your example, if an app is able to fall back to legacy tech, then the developer is expected /not/ to list WebGL in this field, since it is not mandatory. -Anant
Re: [manifest] asynchronous calls, Re: Review of Web Application Manifest Format and Management APIs
On 05/25/2012 08:04 AM, Marcos Caceres wrote: On Sunday, May 13, 2012 at 5:47 PM, Anant Narayanan wrote: This is also an asynchronous call, and will be used by apps to retrieve their own AppObject. This is useful when an app wants to retrieve the receipt for their app (that was set by the app store when install() was called), and verify, for example, that the current user has paid for their app. I'm still not sure why these are asynchronous? Is what apps are installed retrieved from a remote server or something? If you are just checking a small list of installed things on the user's device, then I don't see why you would not just have an installed attribute? Like: myApps = navigator.apps.installed; Otherwise, it seems like a lot of work just to get a list of things that are already installed on my system? Getting the list of things installed on your system will involve disk I/O and sometimes even network I/O (we do so sometimes with our app sync implementation). Even without considering network, disk I/O is still a big issue. Even if there's a small list of 50 apps, it would still have to be stored somewhere persistent and retrieved, which can take more than 100ms and we don't want to block the UI thread. -Anant
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
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
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: 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
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
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
