Closed
Bug 756644
(app-data-jars)
Opened 13 years ago
Closed 6 years ago
Implement "data jars" for data stored in B2G-apps
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
WONTFIX
blocking-kilimanjaro | - |
People
(Reporter: sicking, Unassigned)
References
Details
(Keywords: meta)
The general model for apps is that each app gets its own "cookie jar". I.e. that each app has a separate mapping for which cookies are stored for a given domain.
However apps don't just get their own set of cookies. They also get their own set of IndexedDB databases, their own set of localStorage data, their own appcache and their own set of permissions mappings.
That means that if http://www.facebook.com in firefox sets a cookie, creates an IndexedDB database, stores data in localStorage or appcache, or acquires the permission to use for example geolocation, that means that none of those things when the same page is opened in a facebook app, or in some other app which <iframe>s facebook.
On desktop we will implement this by giving each app a separate profile. However in B2G all apps run in the same profile and so we need to hack this support into gecko.
This is a tracking bug to implement this.
Reporter | ||
Updated•13 years ago
|
blocking-kilimanjaro: --- → ?
Reporter | ||
Comment 1•13 years ago
|
||
In order to indicate which "jar" a specific page should go into we could add the ability to nsIPrincipal to store a opaque "data-jar" identifier. In case of normal apps we would use the app-cache URL as this unique identifier. (For trusted apps it might be an additional boolean for signed resources. For browser apps we might add something to distinguish urls loaded in the app itself from urls loaded in a <iframe mozbrowser>)
Comment 2•13 years ago
|
||
I've been thinking about how we decide when to attach an existing data jar to a new iframe mozapp/mozbrowser. Here's how I think it should work:
* For mozapp, just use the app-cache URL, or manifest URL, or some unique unchanging identifier, to choose the app's data jar.
* For mozbrowser, it's more complicated. The tabs in a multi-tabbed browser need to share data jars.
So what I think we do is walk up the iframe hierarchy until we find a mozapp. Every time we see a mozbrowser or a mozapp, we record its owner origin or app-cache URL, respectively. For example, if we had
<iframe mozapp app-cache-url="http://windowmanager.com">
<iframe mozapp app-cache-url="http://app.com">
<iframe mozbrowser src="http://browser.com">
<iframe mozbrowser src="http://google.com">
then the list we'd generate for the innermost mozbrowser is [(APP, "http://app.com"), (BROWSER, "http://browser.com")].
All mozbrowser instances which share that same list (i.e., all mozbrowser siblings in the mozapp/mozbrowser tree) share a data jar. And anytime that same list of parents creates a new mozbrowser, it'll get this same data jar.
Note that we never look above the first app we see in the hierarchy. I *think* this is the right thing to do, because it means that I can switch out window manager apps without losing data. And hopefully we have a lot of trust in any app which has permission to create mozapp frames.
Comment 3•13 years ago
|
||
> No longer depends on: 756645, 756648, 756717, 754141
Did you mean to clear the dependencies?
Reporter | ||
Updated•13 years ago
|
Comment 4•13 years ago
|
||
Generally, that seems a good idea but I was wondering if "app-cache-url" is something you propose to add or something that is already here. I think we could simply use the mozapp attribute value instead which is how the window know the contained app (see bug 754141). The mozapp attribute should contain the manifest url.
Comment 5•13 years ago
|
||
Not blocking on meta bugs - marking all dependencies as blocking.
blocking-kilimanjaro: ? → -
Comment 6•13 years ago
|
||
Jonas, if specific dependents do *not* actually block, let me know or flip the flag on the bug back to ?.
Updated•13 years ago
|
Alias: app-data-jars
Updated•12 years ago
|
Blocks: basecamp-security
Reporter | ||
Updated•12 years ago
|
Reporter | ||
Updated•12 years ago
|
Comment 7•12 years ago
|
||
Will this functionality be available for Firefox desktop?
It seems like it would help bug 511933 (and I could remove some hacks from an extension :).
Comment 8•12 years ago
|
||
(In reply to Jeferson Hultmann from comment #7)
> Will this functionality be available for Firefox desktop?
>
> It seems like it would help bug 511933 (and I could remove some hacks from
> an extension :).
There's definitely a desire to do something along these lines for desktop - for example, see https://wiki.mozilla.org/Privacy/Features/Multiple_Cookie_Jars
Reporter | ||
Comment 9•12 years ago
|
||
None of that work will happen in this bug though. The scope of this bug is huge as it is so I'd rather keep it to just the infrastructure needed in the core. Not any of the work needed to hook up data jars to the various front-ends, like Firefox.
Updated•12 years ago
|
OS: Mac OS X → All
Hardware: x86 → All
Comment 10•6 years ago
|
||
Mass closing as we are no longer working on b2g/firefox os.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Comment 11•6 years ago
|
||
Mass closing as we are no longer working on b2g/firefox os.
Assignee | ||
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•