W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2012

Re: App Manifest & API Proposal

From: Marcos Caceres <w3c@marcosc.com>
Date: Sat, 12 May 2012 22:57:18 +0100
To: Anant Narayanan <anant@mozilla.com>, Ian Hickson <ian@hixie.ch>
Cc: public-webapps <public-webapps@w3.org>
Message-ID: <D491B42D54F74492A4AB14D50DE6194C@marcosc.com>

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
Received on Saturday, 12 May 2012 21:57:48 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:40 UTC