Move Application.uninstall() to ApplicationManagement

[mounirlamouri]

For security and UI reasons, uninstall() might need to be under ApplicationManagement.

The UI reasons are about how to handle an application uninstalling itself.
The security reasons are that an application that is powned would be able to uninstall various other applications if it can access it application object.

ApplicationManagement being behind a permission and should be used for management applications, we could expect this to be less of an issue there.

[jmajnert]

Both reasons seem valid to me, so I support this solution.

As for the security reason - it also applies to ApplicationRegistry.install(). A malicious application could potentially install many other malicious apps. Maybe it too should be moved to the ApplicationManagement interface? Or we could at least specify when an application is not allowed to install other applications (in other words, when does the condition from point 1 of the install() algorithm [1] apply?)

[1]http://runtime.sysapps.org/#widl-ApplicationRegistry-install-DOMRequest-DOMString-manifestUrl-Object-parameters

[mounirlamouri]

We expect the installation request to be started by any web page and the UA should provide the security measures (doorhanger for example) to make sure the user accepted the installation. I do not know if we should be more precise than that but this is out of scope from this bug. If you think we should be more precise, could you open another issue?

[jmajnert]

What you're saying seems a bit inconsistent to me. You expect the UA to get user's permission to install an app, so it's ok to allow any webpage install any application. On the other hand you are afraid that a powned app might want to uninstall other applications, so you don't expect the UA to get user's permission for uninstalling?

How is uninstalling different that installing in this context?

[mounirlamouri]

I'm not a security guy but from the top of my head, I think that installing something without user consent as way less impact that uninstalling. If you uninstall all my applications, you will erase all the data that was owned by those applications. If you install new applications, they will unlikely do any harm because of the security model: if they are not privileged, they will not have access to sensitive APIs and if they are privileged, there is a chain of trust that should guarantee that they will not be harmful.

[jmajnert]

I'm wondering if it wouldn't be better to have 2 methods for installing applicaitons:

1. ApplicationManagement.install() - for use by privileged applications to install any other application
2. ApplicationRegistry.installSelf() - for any webpage to be able to install itself as a system application. This method would take no parameters and only install the application if the webpage declared the path to manifest file in markup, like is being proposed in Associate a web app with a manifest w3c/manifest#17

This way we would put install/uninstall/update functionality into a consistent privileged "management" interface and still allow webpages to install themselves.

[marcoscaceres]

I'm wondering if it wouldn't be better to have 2 methods for installing applicaitons:

1. ApplicationManagement.install() - for use by privileged applications to install any other application

FWIW, this seems useful.

1. ApplicationRegistry.installSelf() - for any webpage to be able to install itself as a system application. This method would take no parameters and only install the application if the webpage declared the path to manifest file in markup, like is being proposed in Associate a web app with a manifest w3c/manifest#17 (Associate a web app with a manifest w3c/manifest#17)
   This way we would put install/uninstall/update functionality into a consistent privileged "management" interface and still allow webpages to install themselves.

I personally don't like this dependency on JS. I think applications should only declare themselves as installable (through markup), and the UA provide the UI to do the installation. If the declarative means is supported, I personally can't see a strong reason for there being an install() method to be provided to web regular apps.

[jmajnert]

@marcoscaceres I think it could be useful if the webpage wanted to customise the installation experience. Of course calling installSelf() would only bring up the UA's installation dialog.

[marcoscaceres]

In what way would you envision it customising the experience given the information currently provided by the API?

This is how I think installation and launching would be done (without the hosted application itself ever needing the launch() or install() parts of the API):

Scenario 1 - App Store.

1. user navigates to apps store (either through a web browser or an app store application), browses a bunch of apps (screenshots, etc).
2. User clicks, "buy" or "install".
3. manifest data is gotten by the UA and app is installed in the background (app doesn't actually get run!).
4. User continues browsing/shopping for other apps while installation is happening in the background.
5. Once the user finishes shopping, she either access a list of purchased apps (and launches the app from there) or drops to the home screen to open the app.

Scenario 2. user installs bar.com

1. user visits bar.com through the Web browser
2. bar.com serves the home page along with the HTML attribute pointing to the manifest.
3. The UA informs the user that the app is installable.
4. The user either accepts or ignores the install information bar or dialog or marker (or whatever UX the AU provides).
5. If the user installs the app, the UA d/ls it in the background (or schedules it for d/l later, if it's too big to install right now as it requires WIFI - app is over 100MB). While the app downloads, the UA shows the installation progress. The user continues to use the web apps as normal.
6. As the app is installed - the UA offers the user the option to open the app. User declines, she continues using the Web browser as normal.
7. A day later, the user powers up their device and finds the app installed on their home screen. She clicks the icon and the app is launched independently of the Web browser.
8. The day after, the user goes to bar.com. The UA knows already that the user installed the bar.com app, so asks the user: "Hey! you have bar.com app installed. You want me to open it for you?".

Scenario 3. User subscribes to Website foo.com.

1. User visits website foo.com - registers and logs in.
2. Having logged in, website foo.com tells user that they can "buy/subscribe" to this app's services.
3. User buys the app/service through paypal or whatever.
4. Website knows this user bought this app, so makes the install attribute available declaratively.
5. The UA informs the user that the app is installable.
6. The user installs the app (through the browser). But continues using the browser as normal (switches tabs, go to gmail, whatever).
7. Later, the user drops back to their home screen. The app icon is there.
8. The user clicks the app icon, the app pops up: they log in. They use the app as normal.

[marcoscaceres]

I think all that hosted web apps may need to know is:

1. Am I running as an installed app? yes/no.
2. What is my localized install name? and possibly a few other little things from the manifest.

Applications management/launching should should be handled by the UA.

[draggett]

On 25/04/13 10:30, Marcos Caceres wrote:

I think all that hosted web apps may need to know is:

1. Am I running as an installed app? yes/no.
2. What is my localized install name? and possibly a few other little
   things from the manifest.

Do apps have read access to their manifest?

Presumably, apps don't have write access to their manifest?

My assumption is that if apps need changes to the manifest, this is
essentially the same as updating the app.

Dave Raggett dsr@w3.org http://www.w3.org/People/Raggett

[marcoscaceres]

Do apps have read access to their manifest?

Yes. They can XHR it. Elsewhere, we are trying to find out exactly which things from the manifest should be exposed to an installed app (e.g., the localized name). Currently don't have a bug for this, but it's something @mounirlamouri have been discussing in IRC.

Presumably, apps don't have write access to their manifest?

Correct.

My assumption is that if apps need changes to the manifest, this is
essentially the same as updating the app.

This is also the assumption that the runtime spec makes... this assumption can have really bad consequences for packaged apps. If a developer fixes a typo in a description, the UA might download the corresponding packaged app again potentially costing the user a lot of money.

Also, hosted web apps don't have "versions". All their files are online (and some a cached with appcache).

[jmajnert]

@marcoscaceres

1. Website knows this user bought this app, so makes the install attribute available declaratively.

I guess this is what I wanted to achieve with installSelf(). As you pointed out this is already doable.

@mounirlamouri Could you please tell us what use cases you foresee that are not covered if we move the install/uninstall into ApplicationManagement interface?

[mounirlamouri]

uninstall() will move to ApplicationManagement.

Regarding install() there is also the case of having any website being able to behave like a store. We shouldn't require special privileges for that to happen and having a .install() method is a solution to make that happen.

[jmajnert]

uninstall() will move to ApplicationManagement.

Agreed.

Regarding install() there is also the case of having any website being able to behave like a store. We shouldn't require special privileges for that to happen and having a .install() method is a solution to make that happen.

Could you please provide a use where this is not doable using the declarative approach?
What I mean is that when the user visits the "store" website and decides to install one of the apps, the store website can navigate them to the relevant application's document, which in turn declares the path to the manifest. The UA takes it from there...