1092726 - Remove the ability for apps to access assets from a different app

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect, P2)

Description

[Ted Clancy [:tedders1]]

+++ This bug was initially created as a clone of Bug #1000305 +++

Since Bug 1000305 will be providing a way for homescreens to access app icons, we no longer need to allow apps to access assets from other apps. This undesirable feature should be removed.

Comment 1

[Antonio Manuel Amaya Calvo (:amac)]

That undesirable feature is used extensively by the operator single variant customization. I don't think we can remove it that happily.

Comment 2

[Kevin Grandon :kgrandon]

Is this something we can decouple from the replaceable home screen effort? Can we leave certified apps with this ability, but maybe just not grant it to privileged apps initially?

Comment 3

[Ted Clancy [:tedders1]]

Attachment: new-bug-1092726-fix.patch

Comment 4

[Ted Clancy [:tedders1]]

I'll let Fabrice answer that.

Comment 5

[Antonio Manuel Amaya Calvo (:amac)]

Also this goes against what Jonas proposed at https://bugzilla.mozilla.org/show_bug.cgi?id=899994#c17, concretely:

>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.

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Any page that can use the full mozbrowser API (i.e. not the widget subset) can still effectively read the contents that iframe.

So I think anyone that has access to the "browser" permission should be able to make requests, and read responses, using the browser cookiejar of that app. And any app that has the "embed-apps" permission should be able to do so using any cookiejar.

I guess ideally we'd eventually remove that capability from webapps-manage, but I don't feel that that's particularly urgent.

Antonio: What are apps doing now that require them to read data from other apps?

Comment 7

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

And I agree with Kevin, removing this doesn't seem urgent in any way. And if the use cases are good we might not want to remove it at all.

It's already only exposed to certified apps.

So we shouldn't make this block replacable homescreens.

Comment 8

[Antonio Manuel Amaya Calvo (:amac)]

(In reply to Jonas Sicking (:sicking) from comment #6)
> 
> Antonio: What are apps doing now that require them to read data from other
> apps?

Carmen knows that code better than myself (since she wrote it), but one case that I remember is the loading of the boot up and shutting down resources. To put things in context, Single Variant is a set of features that allow a single SKU device to be used for several operators. The actual operator configuration that's applied is decided at first boot time using the SIM inserted to determine which configuration to apply.

A set of those configurations are the operator provided boot up animation, image and sound, and the equivalent shutting down sound, image and animation. The app that uses that media resources is system, but the actual media resources live on the aptly named operatorresources app. At first boot with a SIM time the correct operatorresources app is installed (the device will have several operatorresources app available up to that time, one for each possible operator that sells that particular SKU device). And system only has to know the URI of the resources it uses, since doing something like:

<img src="app://operatorresources.gaiamobile.org/startup-img.png">

currently works as expected. The actual URI is determined by a setting set by the initial configuration, but for system there's no real difference between that and

<img src="/images/startup.png">

Comment 9

[[:fabrice] Fabrice Desré]

Looks like we agree on WONTFIX for now.