We have decided to disable IndexedDB in third-party iframes. bent said he would take this if I factor the relevant code into a common service.

This should block final (maybe betaN) so we get our story straight before we ship IndexedDB!

I really don't understand this decision. It seems quite unintuitive that a feature would work when loaded at the top level but not in a framed site such as the abortive diggbar or google image results, etc. I bet this could significantly affect some apps such as widgets on the google homepage, etc. I think should be reconsidered.

There was an email thread about this, which has the rationale. For expediency, I'll just pastebin it. Momentarily!

And here it is (initial message first): http://pastebin.mozilla.org/789127

Also, I believe this was raised on the spec list for public discussion, and there wasn't much (any?) dissent, but Jonas / Shawn would know the story there.

(In reply to comment #5) > Also, I believe this was raised on the spec list for public discussion, and > there wasn't much (any?) dissent, but Jonas / Shawn would know the story there. There wasn't much talk. Google didn't want to do it, but we wanted the option as I recall. The spec text says: User agents may restrict access to the database objects to scripts originating at the domain of the top-level document of the browsing context, for instance denying access to the API for pages from other domains running in iframes.

My understanding of their position in general (i.e. for cookies, presently) is that they dislike the idea restricting third-party access, since it obviously messes with their business model. We dislike the idea too, in the sense that (with current technology) the UX sucks. Our goal is to change that. They may or may not follow suit if we do something, but we're certainly in a position to make them think about it. :) Regardless of what they do, I think there's value in us fixing this particular bug now, for the reasons already given.

Comment on attachment 498253 [details] [diff] [review] Patch, v1 r-, please attach in text/plain.

Comment on attachment 498253 [details] [diff] [review] Patch, v1 r=dwitte

Hmm.. do we really want to throw here? In general it sucks for authors to have to do feature detection using throwing if we can avoid it. Would it make sense to make mozIndexedDB return null or make the call to open fire an error event instead? The latter kind'a sucks since that means you can only do feature detection asynchronously.

Comment on attachment 498253 [details] [diff] [review] Patch, v1 Given the lack of answer I'll say r=me if you change it to return null rather than throw an error.

Can someone re-provide the explanation for why this change is needed/ The pastebin dwitte included earlier has gone away and I think our documentation for this issue needs to explain why you can't use IndexedDB in third-party frames.

I second Sheppy's comment; I'd like to read why this change was necessary. It's particularly confusing when you consider that localStorage is perfectly valid for 3rd party frames, but not IndexedDB.

Except for some UI limitation, I don't see any problem in having access to IndexedDB in iframe. Could someone update why it is not allowed when it might break many sites. Any reasoning that applies to localStorage should also apply to IndexedDB.

We have a Google Chrome packaged app that works fine, but can not port it to a Firefox Packaged app due to this change. We tested that iframe in packaged app has access to LocalStorage and appcache, but not indexeddb. Is there any kind of permissions/csp/ifrmae-sandbox rule that we can use to allow indexeddb? So far could not find any. Same app works just fine in the browser (see http:/nurs.me), but in the firefoxos packaged app we are forced to split it into the packaged app code and an unprivileged code (which runs in the iframe) and now we lost access to indexeddb. This is a complete showstopper for us, as we are trying to ship this and several other apps before firefoxos devices hit streets in July.

(In reply to gene.vayngrib from comment #17) ok, looks like we have found a non-ideal solution. We were able to get indexeddb working in iframe by making 3 changes: 1. changed type of the app to 'privileged' - unfortunately this means it will need to got through the verification process for the markteplace. "type": "privileged" 2. added special permission "permissions" : { ... browser } 3. added mozbrowser attribute to iframe > We have a Google Chrome packaged app that works fine, but can not port it to > a Firefox Packaged app due to this change. We tested that iframe in packaged > app has access to LocalStorage and appcache, but not indexeddb. Is there any > kind of permissions/csp/ifrmae-sandbox rule that we can use to allow > indexeddb? So far could not find any. Same app works just fine in the > browser (see http:/nurs.me), but in the firefoxos packaged app we are forced > to split it into the packaged app code and an unprivileged code (which runs > in the iframe) and now we lost access to indexeddb. This is a complete > showstopper for us, as we are trying to ship this and several other apps > before firefoxos devices hit streets in July.

(In reply to Eric Shepherd [:sheppy] from comment #14) > Can someone re-provide the explanation for why this change is needed/ The > pastebin dwitte included earlier has gone away and I think our documentation > for this issue needs to explain why you can't use IndexedDB in third-party > frames. This comment was made over 2 years ago. Surely someone here can add enough context so we can update the docs to reference why this discrepancy exists with chrome?

bent should be able to provide an explanation here!

Oops, sorry. This fell off my bugzilla radar. The main reason that indexedDB has never been allowed in third-party frames is that we don't want thief.com to open an iframe with my-offline-bank.com inside it and somehow get access to all of the user's sensitive data. We also don't want to enable tracking via indexedDB. When we were first implementing this we decided that we shouldn't make the same mistake that we did with localStorage and cookies. Also, relaxing the restriction (if we ever have to) is much easier than trying to enforce the restriction later. We're sorta stuck with this problem for cookies and localStorage, but we're tying to fix that nowadays anyway with this whole blocking third-party cookies initiative.

(In reply to ben turner [:bent] from comment #21) > Oops, sorry. This fell off my bugzilla radar. Great, thanks! I've updated the paragraph in https://developer.mozilla.org/en-US/docs/IndexedDB/Using_IndexedDB which pointed at this bug to read: ---8<--- It's important to note that IndexedDB doesn't work for content loaded into a frame from another site (either <frame> or <iframe>. This is a security and privacy measure and can be considered analogous the blocking of 3rd-party cookies. For more details, see bug 595307. ---8<--- specifically, I added the words "... and privacy measure and can be considered analogous the blocking of 3rd-party cookies. For more details..." which I think is OK and an improvement.

(In reply to ben turner [:bent] (needinfo? encouraged) from comment #21) > Oops, sorry. This fell off my bugzilla radar. > > The main reason that indexedDB has never been allowed in third-party frames > is that we don't want thief.com to open an iframe with my-offline-bank.com > inside it and somehow get access to all of the user's sensitive data. We > also don't want to enable tracking via indexedDB. When we were first > implementing this we decided that we shouldn't make the same mistake that we > did with localStorage and cookies. Also, relaxing the restriction (if we > ever have to) is much easier than trying to enforce the restriction later. > > We're sorta stuck with this problem for cookies and localStorage, but we're > tying to fix that nowadays anyway with this whole blocking third-party > cookies initiative. Were there talks of how it might be relaxed with certain measures?

> The main reason that indexedDB has never been allowed in third-party frames is that we don't want thief.com to open an iframe with my-offline-bank.com inside it and somehow get access to all of the user's sensitive data. I don't get it. If thief.com doesn't have access to my-offline-bank.com's DOM (includes IndexedDB), how can this change the security between thief.com and my-offline-bank.com? Besides, my-offline-bank.com can always use the X-Frame-Options header to prevent iframes completely or just from a different origin (such as thief.com). Even if they don't have access to it, how can thief.com know what has been happening in the iframe? If it is a plugin that can breach it, then it is the plugin's fault, not the browser's. Are you able to show me an example where thief.com can get information it shouldn't be able to get that can be used to track the user's interaction with my-offline-bank.com? Sincerely... I can't.

Any updates?

I think ehsan is going to be driving the unification of storage behavior with respect to the third-party prefs.

AFAIK the latest prefs are to tie all different ways of using storage in third-party iframes to the existing pref governing whether cookies can be saved in third-party iframes, so that if the user has set that pref, none of the storage APIs work in third-party iframes, and if not, they all work. I am not aware of anyone who is signed up to do the implementation work yet though.

Oops, that should have read "lastest plans are..."

This was documented at https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security I added some details on how FxOS apps can allow iframe access to IDB.