Closed
Bug 899994
Opened 11 years ago
Closed 9 years ago
webapps-manage is certified applications only and prevent third party homescreen
Categories
(Core Graveyard :: DOM: Apps, defect, P1)
Core Graveyard
DOM: Apps
Tracking
(tracking-b2g:backlog)
RESOLVED
FIXED
tracking-b2g | backlog |
People
(Reporter: vingtetun, Assigned: tedders1)
References
Details
(Whiteboard: [systemsfe])
Attachments
(2 files)
18.42 KB,
patch
|
Details | Diff | Splinter Review | |
2.18 KB,
patch
|
Details | Diff | Splinter Review |
The webapps-manage permissions is for certified application only. As a result a third party developer can not write an homescreen application. I'm not sure how to handle that. A stupid idea that comes to mind would be to convert mozapps into a datastore in order to expose it to third party homescreen for both the list of apps and the list of icons. About uninstalling? I'm not sure - maybe the homescreen can only contains shortcuts but can open a management interface that comes from the system app that let user control their installed apps. Very androish though.
Updated•11 years ago
|
Component: DOM: Device Interfaces → DOM: Apps
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → koi?
Reporter | ||
Comment 1•11 years ago
|
||
I don't really think it is a koi?. Sorry for the noise.
blocking-b2g: koi? → ---
Comment 2•11 years ago
|
||
Couldn't we allow privileged apps to use the webapps-manage permission? We could create a new permission for certified apps that need to access other apps' packages (which apps need that at the moment?), splitting the webapps-manage permission. We could make the webapps-manage permission a prompt-only permission, so that the users will always decide if they actually want to remove an application, for example.
Comment 3•11 years ago
|
||
Homescreens are the only apps I know of that need to access other app's packages, to display the icons. In my view, this is the only reason that prevent us from making that a privileged permission. Prompting is already there at install time; adding some at uninstall and when clearing data makes sense and is done by gaia but not enforced by the platform. I'd like to not add yet another different permission just for that, there should be a better solution there... What about adding a call on the mgmt object that would be: DOMRequest<Blob> getAppIcon(app, iconURL) iconURL will have to be a valid icon url for this app. The Blob will be tied to the window of the caller, so you could call URL.createObjectURL() and URL.revokeObjectURL() on it.
Comment 4•11 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #3) > Homescreens are the only apps I know of that need to access other app's > packages, to display the icons. In my view, this is the only reason that > prevent us from making that a privileged permission. > > Prompting is already there at install time; adding some at uninstall and > when clearing data makes sense and is done by gaia but not enforced by the > platform. > > I'd like to not add yet another different permission just for that, there > should be a better solution there... What about adding a call on the mgmt > object that would be: > > DOMRequest<Blob> getAppIcon(app, iconURL) > > iconURL will have to be a valid icon url for this app. The Blob will be tied > to the window of the caller, so you could call URL.createObjectURL() and > URL.revokeObjectURL() on it. I didn't know which apps needed to access the package, if getting the icon was the only use case than this seems absolutely reasonable!
Comment 5•11 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #3) > Homescreens are the only apps I know of that need to access other app's > packages, to display the icons. In my view, this is the only reason that > prevent us from making that a privileged permission. The Gaia Settings app also needs access to app icons. > > Prompting is already there at install time; adding some at uninstall and > when clearing data makes sense and is done by gaia but not enforced by the > platform. > > I'd like to not add yet another different permission just for that, there > should be a better solution there... What about adding a call on the mgmt > object that would be: > > DOMRequest<Blob> getAppIcon(app, iconURL) > > iconURL will have to be a valid icon url for this app. The Blob will be tied > to the window of the caller, so you could call URL.createObjectURL() and > URL.revokeObjectURL() on it. This sounds like a good solution to me.
Updated•11 years ago
|
Flags: sec-review?(ptheriault)
Comment 6•11 years ago
|
||
Note the webapps-manage permission privileged also allows management of updates. App.checkForUpdate/.download doesn't worry me too much, but mgmt.applyDownload does. (Could a homescreen update an app without user interaction?) Can we introduce so that privileged apps can only access: navigator.mozAppp.getAll() navigator.mozApp.onInstall navigator.mozApp.onuninstall This is all of the API that our homescreen access, and the update stuff doesn't seem relevant to the 3rd party app use case to me. That is, add 'check is certified' checks in webapp.jsm (parent, not webapps.js) to limit the following function to certified apps only: navigator.mozApp.applyDownload navigator.mozApp.getNotInstalled (this doesnt seem to do anything different to getAll on b2g, but seems safer not to allow) Apart from that I am *mostly* ok with this. My main other concern is that somehow we need to communicate to the user that the homescreen has control over all of your apps. Potential mitigating controls to this may be: - warning text in the settings page where you choose a new homescreen - marketplace changes to flag apps which request the homescreen role & homescreen permission - change the marketplace review process to account for this higher risk API (e.g. we need to reject apps that request this permission, but don't use it securely, or are not clearly homescreens to the user...)
Updated•11 years ago
|
Blocks: ExposeAPIs
Comment 7•11 years ago
|
||
Removing the sec-review flag assuming the controls in the previous comment are implemented. Please sec-review? me again once implemented
Flags: sec-review?(ptheriault)
(In reply to Fabrice Desré [:fabrice] from comment #3) > Prompting is already there at install time; adding some at uninstall and > when clearing data makes sense and is done by gaia but not enforced by the > platform. I'm fine with simply prompting at uninstall and clearing data, and not relying on yet another prompted permission. However we should still restrict the ability to call uninstall() to the homescreen app (and apps that has super-special-mega-powers like the settings app). I.e. I'm fine with granting any app with role=homescreen implicit webapps-manage permission. Though it wouldn't hurt to still enumerate the permission in the manifest still seems like a good idea? > I'd like to not add yet another different permission just for that, there > should be a better solution there... What about adding a call on the mgmt > object that would be: > > DOMRequest<Blob> getAppIcon(app, iconURL) > > iconURL will have to be a valid icon url for this app. The Blob will be tied > to the window of the caller, so you could call URL.createObjectURL() and > URL.revokeObjectURL() on it. Sounds good to me.
I don't think getNotInstalled does anything at all any more. We should just remove it. We can certainly move applyUpdate() to somewhere other than the mgmt object. I agree there's no reason to expose that to any apps other than the system app.
Comment 10•11 years ago
|
||
> I'm fine with simply prompting at uninstall and clearing data, and not > relying on yet another prompted permission. > > However we should still restrict the ability to call uninstall() to the > homescreen app (and apps that has super-special-mega-powers like the > settings app). Just so I am clear here - do you mean, "only the app which is currently set as the active homescreen can call uninstall"? That sounds good to me, but I am not sure that is what you mean. > > I.e. I'm fine with granting any app with role=homescreen implicit > webapps-manage permission. Though it wouldn't hurt to still enumerate the > permission in the manifest still seems like a good idea? Confusing roles with permissions seems like adding unnecessary complexity which could potentially lead to security issues. - AFAIK any app can declare any role in the manifest - roles don't have any of the security controls around them that permissions have (i.e. enforced per app type, revoked on uninstall, checkable inside gecko etc. I would prefer that if an wants to be a homescreen, it needs to declare both the homescreen role, and then separately ask for the webapps-manage permission as per normal. To me roles are a gaia construction that is only used for UI purposes (i.e. an app indicating which roles it can perform). Access to APIs should always be controlled by permissions, imho. > > > I'd like to not add yet another different permission just for that, there > > should be a better solution there... What about adding a call on the mgmt > > object that would be: > > > > DOMRequest<Blob> getAppIcon(app, iconURL) > > > > iconURL will have to be a valid icon url for this app. The Blob will be tied > > to the window of the caller, so you could call URL.createObjectURL() and > > URL.revokeObjectURL() on it. > > Sounds good to me.
Updated•11 years ago
|
Assignee: nobody → fabrice
Updated•10 years ago
|
Whiteboard: [systemsfe]
Comment 11•10 years ago
|
||
Here's my current wip. Changes needed are to make gecko responsible for getting the icons and returning blob urls.
Comment 12•10 years ago
|
||
I don't like the idea of removing the possibility to crossload resources completely. For a current use case that requires (or makes it a way better solution) using this, you can check bug 923443. That bug requires the startup animation and images (and sounds next) to be decided at run time based on the first useable SIM that's inserted on the phone (allowing the same physical phone to be sold under several different operator brands). Allowing controlled crossloads lets us use a solution where the resources are installed as a different app, and used from the system app, and that allows us to install *just* the resources we're going to actually use (based on the SIM). Not allowing this would require... either including several versions of the system app with the phone, or having a bloated system app that includes the resources for all the possible operators that phone can be branded as. This patch just shows the changes needed to add the new permission (all the other changes on webapp-manage, to restrict what can be done and to allow the loading only of the icons would still be needed, of course) so we don't remove that possibility.
Flags: needinfo?(ptheriault)
Flags: needinfo?(fabrice)
Comment 13•10 years ago
|
||
I'd like to avoid using new permissions if possible... what we really need is CORS support for packaged apps!
Flags: needinfo?(fabrice)
Comment 14•10 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #13) > I'd like to avoid using new permissions if possible... Why? If anything, I see adding new permissions (actually, splitting existing permissions into several) like a good thing. When the initial permission set was defined, some of the APIs had a very range set of abilities, and the permission classification (certified, privileged, everyone) was correctly assigned based on the higher level of risk of any of those abilities. But whenever we can, I think we should refine down the permissions, splitting the API capabilities by risk level, and granting lower trust level apps more functionality (and making them inclusive, obviously). More functionality open to more app types equals more apps developed (hopefully :P) and that's a good thing. That's what was done with mobileconnection when it was split into mobileconnection/mobilenetwork for example. > what we really need is CORS support for packaged apps! Hmm... We could implement something similar to web-server-wide CORS I guess, but this isn't really CORS. This is simple linking: 1. <img src="app://otherapp/resource/img.jpg"> => No CORS 2. XMLHttpRequest.open(GET, "app://otherapp/resource/img.jpg") => CORS And so it wouldn't really help with 1 (which is as webbie as you can get :)). Actually... there's something CORS-like that I would love to do, which is controlling the resource load from the linked-to app instead of checking the permission from the linking-from app. That is, instead of having a permission that gives us access to any resource in any app, allow the receiving app to specify which apps can load resources from it. Something like: linkAllowedFrom: ['app://*.gaiamobile.org', 'https://*.mozilla.org'] on the manifest (where the default value is the current one of not allowing any loads). After all, is the receiving app the one that knows how secret it resources must be.
Comment 15•10 years ago
|
||
(In reply to Antonio Manuel Amaya Calvo (:amac) from comment #14) > Actually... there's something CORS-like that I would love to do, which is > controlling the resource load from the linked-to app instead of checking the > permission from the linking-from app. What you describe is a lot like CORS, isn't it? I mean the Same Origin Policy already provides some good protection and I find it desirable to have something web-like in place, that fits to what developers expect to work. Basically: Inclusion yes, reading no (like with JSON/JS/JPG files from other domains - you can include them, but you can't read their content if it's from a different origin, i.e. app).
Updated•10 years ago
|
blocking-b2g: --- → backlog
Here's my recommendations: 1. Add a new API: DOMRequest<Blob> getAppIcon(app, size). The 'size' argument is the size of the image that the homescreen app intends to display. Note that icon syntax is getting pretty hairy, so it's good if we don't need to require every homescreen app to implement this. http://w3c.github.io/manifest/#icons-member 2. Add a new "homescreen-webapps-manage" permission. This permission gives access to calling uninstall() and getAppIcon. But the app is only allowed to use either of these if it's the currently selected homescreen app. 3. When uninstall() is called, the platform should put up a prompt. We should then remove the prompt that (if I understand correctly) the current homescreen app implements itself. So the webapps-manage permission will still have all the same privileges that it currently has. Including the ability to load arbitrary resources from any app. I don't think that CORS for packaged apps really works since packaged apps still don't have a "real" origin. And even if they did I don't think developers should need to add CORS support to their servers in order get their icons displaying correctly. The fact that we use a webapp to display icons should not be their concern.
Comment 18•10 years ago
|
||
It seems the recommendation is aligned to what Fabrice said in comment 3, which makes a lot of sense to me. (I just wonder what would happen if the manifest refers to something else than an icon :))
Comment 19•10 years ago
|
||
Antonio, do you have objections to the recommendations in comment 17?
Flags: needinfo?(amac)
Assignee | ||
Updated•10 years ago
|
Assignee: fabrice → tclancy
Reporter | ||
Comment 21•10 years ago
|
||
Ted, please also have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=972076#c10
Updated•10 years ago
|
Updated•10 years ago
|
Blocks: homescreen-apps
Updated•10 years ago
|
No longer blocks: vertical-homescreen
Assignee | ||
Updated•10 years ago
|
Whiteboard: [systemsfe] → [systemsfe][p=8]
Comment 22•10 years ago
|
||
Jonas I assume you proposal is contingent on Homescreen providing apps as a data store to other apps, ie as described in comment 0? (since 3rd party homescreens won't have mozApps.getAll()) To be clear: what is the plan for 3rd party homescreens to get a list of apps?
Flags: needinfo?(ptheriault) → needinfo?(jonas)
Updated•10 years ago
|
Target Milestone: --- → 1.4 S6 (25apr)
No, I was thinking that "homescreen-webapps-manage" would give permission to use mgmt.getAll().
Flags: needinfo?(jonas)
Comment 24•10 years ago
|
||
So I also assume we will also need to allow homescreens to listen to the oninstall events so they can create icons. It seems to follow that we allow listening to onuninstall too. (though homescreens could also watch the request.result returned from mgmt.uninstall but I can think of a risk ). So to summarize the plan, including the above for my benefit: We will create a new permission for 3rd party homescreens called 'homescreen-webapps-manage' which will allow: Apps.mgmt.getAll() Apps.mgmt.uninstall() Apps.mgmt.addEventListener() Apps.mgmt.removeEventListener() Apps.mgmt.oninstall (get/set) Apps.mgmt.onuninstall (get/set) Apps.mgmt.getAppIcon() - new API which provides the icon for a given app _homescreen-webapps-manage_ will not grant access to any other _webapps-manage_ privileges. For reference, _homescreen-webapps-manage_ will not grant access to: - Other Apps.mgmt APIs not listed above - the ability to read resources in other apps (ie [1]) - devicestorage:apps access We will add code to gecko & system app to prompt the user when mgmt.uninstall() is called, and remove this from the current homescreen and the settings app too I think, since you can uninstall from there too [2] Does that cover everything? [1] http://mxr.mozilla.org/mozilla-central/source/caps/src/nsScriptSecurityManager.cpp#711 [2] https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/apps.js#L346
Comment 25•10 years ago
|
||
(In reply to Paul Theriault [:pauljt] from comment #24) > - the ability to read resources in other apps (ie [1]) I think we can remove that, the only use case was getting the icons for homescreens.
Comment 26•10 years ago
|
||
Having 'homescreen-' in the name of the permission seems wrong to me. Surely there are other privileged apps besides homescreens which might make use of this permission. I would like to see us leave the name along and just grant access to the allowed methods. If that is not possible, something like "privileged-webapps-manage" makes more sense to me.
Assignee | ||
Comment 27•10 years ago
|
||
I'm going to split this bugzilla ticket into three new tickets, based on the tasks listed in Comment 17.
Assignee | ||
Comment 28•10 years ago
|
||
Okay, the new getAppIcon() API function will be implemented in Bug 1000305. The homescreen-webapps-manage permission will be implemented in Bug 1000313. Prompting the user when uninstall() is called will be implemented in Bug 1000315. (Woo, 7-digit bug numbers!) If you have any comments specific to one of those issues, leave it under the relevant ticket, rather than here.
Assignee | ||
Updated•10 years ago
|
Whiteboard: [systemsfe][p=8] → [systemsfe]
(In reply to Paul Theriault [:pauljt] from comment #24) > Does that cover everything? Sounds good to me. We should make sure to enforce the various limitations in the parent process of course. And if we indeed no longer need the ability to read from other packages, then I'm happy to see that capability removed. Though we should do that as a separate bug.
Updated•10 years ago
|
Target Milestone: 1.4 S6 (25apr) → 2.0 S1 (9may)
Comment 30•10 years ago
|
||
This shouldn't block - this is a feature, which is something we won't block on unless we're past FL & we're planning to still land the feature.
blocking-b2g: 2.0+ → backlog
Updated•10 years ago
|
feature-b2g: --- → 2.0
Updated•10 years ago
|
Target Milestone: 2.0 S1 (9may) → 2.0 S2 (23may)
Updated•10 years ago
|
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
Updated•10 years ago
|
feature-b2g: 2.0 → 2.1
Updated•10 years ago
|
Target Milestone: 2.0 S3 (6june) → 2.0 S4 (20june)
Updated•10 years ago
|
Target Milestone: 2.0 S4 (20june) → 2.0 S5 (4july)
Updated•10 years ago
|
Target Milestone: 2.0 S5 (4july) → 2.0 S6 (18july)
Updated•10 years ago
|
Target Milestone: 2.0 S6 (18july) → 2.1 S1 (1aug)
Assignee | ||
Updated•10 years ago
|
Assignee | ||
Updated•10 years ago
|
Updated•10 years ago
|
Target Milestone: 2.1 S1 (1aug) → 2.1 S2 (15aug)
Updated•10 years ago
|
feature-b2g: 2.1 → ---
Target Milestone: 2.1 S2 (15aug) → ---
Updated•10 years ago
|
Priority: -- → P1
Now that bug 1000313 has been fixed, this bug is no longer needed, right? Keeping in mind that bug 994858 is the general tracker for "replacable homescreen".
Assignee | ||
Comment 32•9 years ago
|
||
Yeah, now that bug 1000313 and bug 1000305 are both done, this bug isn't needed anymore.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Updated•9 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Updated•9 years ago
|
Blocks: TV_FxOS2.5
Updated•9 years ago
|
No longer blocks: TV_FxOS2.5
Updated•7 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•