dwitte@gmail.com Reporter
	Description • 14 years ago

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.

	dwitte@gmail.com Reporter
	Comment 1 • 14 years ago

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

	Benjamin Smedberg
	Comment 2 • 14 years ago

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.

	dwitte@gmail.com Reporter
	Comment 3 • 14 years ago

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

	dwitte@gmail.com Reporter
	Comment 4 • 14 years ago

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

	dwitte@gmail.com Reporter
	Comment 5 • 14 years ago

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.

	Shawn Wilsher :sdwilsh
	Comment 6 • 14 years ago

(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.

	dwitte@gmail.com Reporter
	Comment 7 • 14 years ago

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.

	dwitte@gmail.com Reporter
	Comment 9 • 14 years ago

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

r-, please attach in text/plain.

	dwitte@gmail.com Reporter
	Comment 10 • 14 years ago

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

r=dwitte

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 11 • 14 years ago

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.

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 12 • 14 years ago

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.

	Ben Turner (not reading bugmail, use the needinfo flag!)
	Comment 13 • 14 years ago

http://hg.mozilla.org/mozilla-central/rev/9b05e0e4cf04

	Eric Shepherd [:sheppy]
	Comment 14 • 13 years ago

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.

	jonnew
	Comment 15 • 13 years ago

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.

	Amit Ambardekar
	Comment 16 • 13 years ago

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.

	gene.vayngrib
	Comment 17 • 11 years ago

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.

	gene.vayngrib
	Comment 18 • 11 years ago

(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.

	Mark Hammond [:markh] [:mhammond]
	Comment 19 • 11 years ago

(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?

	Johnny Stenback (:jst)
	Comment 20 • 11 years ago

bent should be able to provide an explanation here!

	Ben Turner (not reading bugmail, use the needinfo flag!)
	Comment 21 • 11 years ago

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.

	Mark Hammond [:markh] [:mhammond]
	Comment 22 • 11 years ago

(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.

	Brian Kardell
	Comment 23 • 11 years ago

(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?

	brunoais
	Comment 24 • 10 years ago

> 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.

	brunoais
	Comment 25 • 9 years ago

Any updates?

	Ben Turner (not reading bugmail, use the needinfo flag!)
	Comment 26 • 9 years ago

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

	(no longer active)
	Comment 27 • 9 years ago

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.

	(no longer active)
	Comment 28 • 9 years ago

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

	Chris Mills [:cmills]
	Comment 29 • 9 years ago

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.