Open mounirlamouri opened 11 years ago
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?)
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?
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?
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.
I'm wondering if it wouldn't be better to have 2 methods for installing applicaitons:
This way we would put install/uninstall/update functionality into a consistent privileged "management" interface and still allow webpages to install themselves.
I'm wondering if it wouldn't be better to have 2 methods for installing applicaitons:
- ApplicationManagement.install() - for use by privileged applications to install any other application
FWIW, this seems useful.
- 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 sysapps/manifest#17 (https://github.com/sysapps/manifest/issues/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.
@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.
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.
Scenario 2. user installs bar.com
Scenario 3. User subscribes to Website foo.com.
I think all that hosted web apps may need to know is:
Applications management/launching should should be handled by the UA.
On 25/04/13 10:30, Marcos Caceres wrote:
I think all that hosted web apps may need to know is:
- Am I running as an installed app? yes/no.
- 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
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).
@marcoscaceres
- 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?
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.
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...
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...
If you allow installing with navigation like, you don't solve much security problems because users will end up on a blank page that will ask them if they want to install an application. Chances is some will say yes even if they have no idea what is happening. By using the JS API, we allow the web pages to give context (the install is triggered by a button click) so it will improve security and user experience.
@marcoscaceres gave some use cases here https://github.com/sysapps/runtime/issues/92#issuecomment-16996651 that don't have the problem you describe.
If you allow installing with navigation like, you don't solve much security problems because users will end up on a blank page that will ask them if they want to install an application.
Why would that happen? As I understand, a UA first fetches at least the headers of the document that it is navigated to? At that point the UA may decide to cancel navigation and show an installation dialog. This is similar to UA showing a download dialog when it gets navigated to a file that cannot be rendered directly. IMHO it is completely possible to give context to installation without a JS API.
I'm not sure this discussion should be continued here, as it drifted away from the issue title... but I would not want to lose the context. The installation scenarios described by @marcoscaceres here seem sufficient for our needs. The installSelf() method does not appear to be necessary, and install() should go to ApplicationManagement (together with uninstall()). In addition the specification should describe what the UA should do when it detects that a page it is loading contains the manifest link tag. Based on @marcoscaceres's description, it could be:
Is this OK for you?
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.