W3C home > Mailing lists > Public > www-tag@w3.org > February 2012

Re: Installing web apps

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 1 Feb 2012 11:23:42 -0800
Message-ID: <CA+c2ei-WjuwEZZ61RsQgCv_vFpMB2xTmLf4B5Tx2KPNS5BWKZg@mail.gmail.com>
To: Tim Berners-Lee <timbl@w3.org>
Cc: Ian Hickson <ian@hixie.ch>, public-webapps@w3.org, Thomas Roessler <tlr@w3.org>, "Michael(tm) Smith" <mike@w3.org>, TAG List <www-tag@w3.org>
On Wed, Feb 1, 2012 at 8:42 AM, Tim Berners-Lee <timbl@w3.org> wrote:
>
> On 2012-01 -20, at 14:32, Ian Hickson wrote
> in http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/0238.html :
>
> On Fri, 20 Jan 2012, Tim Berners-Lee wrote:
> [...]
>
> There of course places where XHR is used and there is no
>
> cross-sitescripting security needed
>
>
> 1)  in a browser extension
>
> 2)  in node.js code trusted apps
>
>
> These aren't the Web, so they're probably out of scope of the CORS and XHR
> specs, but Anne can comment if he disagrees. :-)
>
>
> 3)  in web apps when web apps can, in I hope the near future, be
>
> installed, and flagged as trusted code
>
>
> Personally I think the idea of "installing" a Web app is anathema.
>
>
> You may, but others have a need for it.
>
> The open web platform is a strong contender
> for apps which you write once run anywhere
> and end up being a better alternative, or quietly
> moving out, native apps on all kids of device.
>
> These apps have got to be able to completely
> act as agents trusted by the user, like for example
>
> - a web browser
> - a calendar client
> - an IMAP client
>
> and so on, none of these can you currently write
> as a web app, because of CORS.

Nit: It's not CORS that is getting in your way. It's the web's default
same-origin-policy. CORS simply relaxes the s-o-p so it's strictly
helping you here.

But yes, we'll need a way to relax the same-origin-policy even in
cases when the target site wasn't built with the web security model in
mind.

> As a user when I install an app, I want to be able to give
> it access to a selection of:
>
> - Program storage, to a limit
> - Whether it is permanently available or downloaded or cached for a while
> - Access to RAM at runtime, to a limit
> - Access to the net, maybe to a bandwidth limit
> - CPU time when in background, to a limit
> - Ability to access anything on the web
> - Access to its own local storage up to a given limit
> - Access to shared local storage up to a given limit
> - Access to my location, as we currently allow an origin;
> - Access video and still camera, and sound
> - Access to other sensors such as temp, accelerometer, etc
>
> I want to be able to se where all my resources (including CPU, RAM, 'disk')
>  on my laptop or tablet or phone
> are being used up, just like I do with music and movies.
>
> I want maybe a couple of default profiles for all the above.
>
> (I'll want to sync its local and shared data storage between  all my devices
> too)
>
> If I can't give power to apps, then the web app platform cannot compete with
> native apps.
>
> I don't want the value of these setting to be the origin domain name of the
> script of the app,
> as that is too high a granularity.
>
> Note that when people talk about installation, they often immediately
> discuss
> packaging and manifest formats, which will need to be defined, and for which
> we might have more than one, but is not the crux of the issue -- the crux is
> allowing it access to precious and/or sensitive resources.

For what it's worth, we're working on a lot of these aspects at
mozilla as part of our Open Web Apps effort.

There are obviously a lot of subtle issues and tricky edge cases to
get right. For example while we want it to be "safe" to install any
web app, we also want to enable installed web apps to have elevated
privileges when we can establish that there's some sort of trust
relationship which ensures that the apps won't do anything harmful.

Some of the things that I've been arguing that we can grant installed
apps automatically are:

1. Use of system resources (CPU, disk space, network bandwidth, etc).
2. Ability to "annoy" the user, i.e. things like popups or replacing
the context menu.
3. Ability to finger print the user. This will allow access to things
like the users custom spellcheck dictionary.

The last one is the most controversial and something I haven't been
fully convinced of yet. It's more than likely something that won't be
an absolute.

I'm personally not a big fan of having strict limit for system
resources as that tends to make development hard and the limits will
either be fairly arbitrary or a pain for the user to constantly
manage. A better path is to enable the user to see how much system
resources a given app uses. This way the user can choose to uninstall
the app, or power users could choose to manually manage limits.

Other problems with giving installed web apps elevated privileges is
how do we explain this to the user such that they make a safe informed
decision. For example asking the user "Do you want to allow this app
to connect to the internet" sounds innocent enough, but the user
probably doesn't realize that this means that the app can read data
from inside corporate firewalls.

This isn't to say that we shouldn't allow these things. It just will
take a lot of design work, experimenting and iterating to get it
right.

/ Jonas
Received on Wednesday, 1 February 2012 19:24:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:45 GMT