Re: [runtime] Privileged Applications Extensions spec proposal

On Wed, Jun 26, 2013 at 10:37 PM, Kostiainen, Anssi <
anssi.kostiainen@intel.com> wrote:

> On Jun 25, 2013, at 10:52 AM, Janusz Majnert <j.majnert@samsung.com>
> wrote:
>
> >> And if we'd add a change event handler for it an app developer would
> not need to poll the attribute. I added a note to the PR [2] we may want to
> move updateState to ApplicationManagement and should consider adding an
> event handler for it.
> >>
> >> All - do you have concerns with the updateState attribute and
> associated event handler (or an equivalent based on Promises) being exposed
> to privileged apps only?
> >
> > I have nothing against moving updateState into ApplicationManagement,
> but if we do, I think downloadSize and downloadUpdate() should be moved as
> well.
>
> Janusz - thanks for your comments.
>
> Re downloadSize and downloadUpdate(): I tend to agree. If only a
> privileged app is able to invoke applyUpdate() to update the app, it seems
> knowing the size of the update or being able to download the update should
> require the same privileges.
>

downloadSize and downloadUpdate() is needed to build a update-UI. I.e. it's
needed if a store wants to put an "update now" button in the store if it
detects that the app the user is viewing is installed but out-of-date. Or
if an app wants to put a "I'm out of date, click here to update me" banner
at the top of itself when it detects that it's out-of-date. In both cases
you might want to show the user the update size so that the user can make a
decision if he/she wants to download the update.

However applyUpdate() is something that probably possibly shouldn't exist
at all (other than internally in the runtime implementation). At least in
FirefoxOS we haven't implemented support for having multiple versions of an
app installed at the same time. Because of that it's important that an
update isn't applied as long as the app is running. And so applyUpdate() is
important that it's only called when it's guaranteed that the app isn't
running. Something which can't be guaranteed as long as the applyUpdate()
function is exposed.

So I propose we simply remove this function.


>
> In addition, downloading an update may cost the user money (data transfer
> charges e.g. while roaming or on an expensive network) and consume system
> resources (e.g. CPU cycles, storage space). At least user consent should be
> obtained. The downloadSize attribute is probably less harmful, but still
> may be a better fit into the ApplicationManagement, if there are no use
> cases for it other than finding out the size of the update ahead of its
> download.
>

The App API was designed such that the only actors which are able to get a
references to an App object are ones that should be able to update the app.

I think that part of the security model is that installed apps should be
able to use system resources (CPU, storage space, network bandwidth, etc)
without having to ask the user for permission. There are simply too many
good use cases for installed apps to use system resources and users
generally expect them to be able to, that prompting each time it happens
will be too annoying and will lessen the value of other, more important,
prompts (like security prompts).

Rather than constantly asking for permission, the OS is expected to be able
to surface information to the user about each apps resource usage. The user
can always uninstall an app that uses too much system resources to reclaim
those resources.

Bandwidth usage that has cost money unfortunately can't be reclaimed. But I
still think that prompting users here will be too high of a burden on the
user.

/ Jonas