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

Re: App Manifest & API Proposal

From: Anant Narayanan <anant@mozilla.com>
Date: Sat, 12 May 2012 14:38:29 -0700
Message-ID: <4FAED855.6030602@mozilla.com>
To: Ian Hickson <ian@hixie.ch>
CC: public-webapps <public-webapps@w3.org>
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.


Received on Saturday, 12 May 2012 21:38:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:34 UTC