Closed Bug 756644 (app-data-jars) Opened 8 years ago Closed Last year

Implement "data jars" for data stored in B2G-apps

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set

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.
blocking-kilimanjaro: --- → ?
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>)
No longer depends on: 756645, 756648, 756717, 754141
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.
> No longer depends on: 756645, 756648, 756717, 754141

Did you mean to clear the dependencies?
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.
Depends on: 758258
Not blocking on meta bugs - marking all dependencies as blocking.
blocking-kilimanjaro: ? → -
Jonas, if specific dependents do *not* actually block, let me know or flip the flag on the bug back to ?.
Alias: app-data-jars
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 :).
(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
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.
Depends on: 774957
Depends on: 775377
Depends on: 775713
Depends on: 769583
Depends on: 775796
Depends on: 775815
Depends on: 775817
Depends on: 775822
Depends on: 775824
Depends on: 775829
Depends on: 777072
OS: Mac OS X → All
Hardware: x86 → All
Depends on: 786293
Depends on: 792171
Keywords: meta
Mass closing as we are no longer working on b2g/firefox os.
Status: NEW → RESOLVED
Closed: Last year
Resolution: --- → WONTFIX
Mass closing as we are no longer working on b2g/firefox os.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.