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

RESOLVED WONTFIX

Status

P2
normal
RESOLVED WONTFIX
4 years ago
11 months ago

People

(Reporter: tedders1, Assigned: tedders1)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [systemsfe][p=2])

Attachments

(1 attachment)

(Assignee)

Description

4 years ago
+++ 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.
That undesirable feature is used extensively by the operator single variant customization. I don't think we can remove it that happily.
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?
Flags: needinfo?(tclancy)
Flags: needinfo?(fabrice)
(Assignee)

Comment 3

4 years ago
Created attachment 8515656 [details] [diff] [review]
new-bug-1092726-fix.patch
(Assignee)

Updated

4 years ago
Assignee: nobody → tclancy
Flags: needinfo?(tclancy)
(Assignee)

Comment 4

4 years ago
I'll let Fabrice answer that.
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.
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?
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.
(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">
Looks like we agree on WONTFIX for now.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(fabrice)
Resolution: --- → WONTFIX

Updated

3 years ago
Blocks: 1187806

Updated

3 years ago
No longer blocks: 1187806

Updated

11 months ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.