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:[email protected]] 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 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
