If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

webapps-manage is certified applications only and prevent third party homescreen

RESOLVED FIXED

Status

()

Core
DOM: Apps
P1
normal
RESOLVED FIXED
4 years ago
2 years ago

People

(Reporter: vingtetun, Assigned: tedders1)

Tracking

(Depends on: 1 bug, Blocks: 4 bugs)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

(Whiteboard: [systemsfe])

Attachments

(2 attachments)

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

4 years ago
Component: DOM: Device Interfaces → DOM: Apps
See Also: → bug 745046
blocking-b2g: --- → koi?
I don't really think it is a koi?. Sorry for the noise.
blocking-b2g: koi? → ---
Depends on: 912340
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.
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.
(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

4 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

4 years ago
Flags: sec-review?(ptheriault)
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...)
Blocks: 934289
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.
> 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.
See Also: → bug 914587
Assignee: nobody → fabrice
Whiteboard: [systemsfe]
Created attachment 8364101 [details] [diff] [review]
apps-icons-blobs.patch

Here's my current wip. Changes needed are to make gecko responsible for getting the icons and returning blob urls.
Created attachment 8364288 [details] [diff] [review]
Alternate permission for crossload

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)
I'd like to avoid using new permissions if possible... what we really need is CORS support for packaged apps!
Flags: needinfo?(fabrice)
(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.
(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).
blocking-b2g: --- → backlog
This is needed for replaceable homescreen.
blocking-b2g: backlog → 1.5+
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.
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 :))
Blocks: 988401
Antonio, do you have objections to the recommendations in comment 17?
Flags: needinfo?(amac)
Nope, that looks great to me!
Flags: needinfo?(amac)
(Assignee)

Updated

4 years ago
Assignee: fabrice → tclancy
Ted, please also have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=972076#c10
Blocks: 987753
Blocks: 989848
No longer blocks: 988401
Blocks: 994858
No longer blocks: 989848
Blocks: 993266
(Assignee)

Updated

4 years ago
Whiteboard: [systemsfe] → [systemsfe][p=8]

Updated

4 years ago
Blocks: 980768
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)
Target Milestone: --- → 1.4 S6 (25apr)
No, I was thinking that "homescreen-webapps-manage" would give permission to use mgmt.getAll().
Flags: needinfo?(jonas)
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
(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.
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

4 years ago
I'm going to split this bugzilla ticket into three new tickets, based on the tasks listed in Comment 17.
(Assignee)

Updated

4 years ago
Blocks: 1000305
(Assignee)

Updated

4 years ago
Blocks: 1000313
(Assignee)

Updated

4 years ago
Blocks: 1000315
(Assignee)

Comment 28

4 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

4 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.
Target Milestone: 1.4 S6 (25apr) → 2.0 S1 (9may)
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

3 years ago
Blocks: 1002336
feature-b2g: --- → 2.0
Target Milestone: 2.0 S1 (9may) → 2.0 S2 (23may)
Target Milestone: 2.0 S2 (23may) → 2.0 S3 (6june)
feature-b2g: 2.0 → 2.1
Target Milestone: 2.0 S3 (6june) → 2.0 S4 (20june)
Target Milestone: 2.0 S4 (20june) → 2.0 S5 (4july)
Target Milestone: 2.0 S5 (4july) → 2.0 S6 (18july)
Target Milestone: 2.0 S6 (18july) → 2.1 S1 (1aug)
(Assignee)

Updated

3 years ago
No longer blocks: 1000305, 1000313, 1000315
Depends on: 1000305, 1000313, 1000315
(Assignee)

Updated

3 years ago
Blocks: 1042797
(Assignee)

Updated

3 years ago
No longer blocks: 1042797
Depends on: 1042797
(Assignee)

Updated

3 years ago
No longer depends on: 1042797
(Assignee)

Updated

3 years ago
Depends on: 1042807
(Assignee)

Updated

3 years ago
No longer depends on: 1042807
Target Milestone: 2.1 S1 (1aug) → 2.1 S2 (15aug)
feature-b2g: 2.1 → ---
Target Milestone: 2.1 S2 (15aug) → ---
Priority: -- → P1
(Assignee)

Updated

3 years ago
Depends on: 1092726
Depends on: 1110606
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

3 years ago
Yeah, now that bug 1000313 and bug 1000305 are both done, this bug isn't needed anymore.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog

Updated

2 years ago
Blocks: 1187806

Updated

2 years ago
No longer blocks: 1187806
You need to log in before you can comment on or make changes to this bug.