756644 - (app-data-jars) Implement "data jars" for data stored in B2G-apps

Status: RESOLVED WONTFIX

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

Description

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

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.

Comment 1

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

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

[Justin Lebar (not reading bugmail)]

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

[Justin Lebar (not reading bugmail)]

> No longer depends on: 756645, 756648, 756717, 754141

Did you mean to clear the dependencies?

Comment 4

[Mounir Lamouri (:mounir)]

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

[Dietrich Ayala (:dietrich)]

Not blocking on meta bugs - marking all dependencies as blocking.

Comment 6

[Dietrich Ayala (:dietrich)]

Jonas, if specific dependents do *not* actually block, let me know or flip the flag on the bug back to ?.

Comment 7

[Jeferson Hultmann]

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

[Ian Melven :imelven]

(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

Comment 9

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

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.

Comment 10

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.