Last Comment Bug 595307 - IndexedDB: third-party checks
: IndexedDB: third-party checks
Status: RESOLVED FIXED
[softblocker][indexeddb]
: dev-doc-complete, privacy
Product: Core
Classification: Components
Component: DOM: IndexedDB (show other bugs)
: unspecified
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Michael Layzell [:mystor]
:
Mentors:
Depends on: 595305
Blocks: 912202 IndexedDB
  Show dependency treegraph
 
Reported: 2010-09-10 13:26 PDT by dwitte@gmail.com
Modified: 2015-12-01 02:04 PST (History)
29 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
betaN+


Attachments
Patch, v1 (7.29 KB, patch)
2010-12-16 16:27 PST, Ben Turner (not reading bugmail, use the needinfo flag!)
dwitte: review+
jonas: review+
Details | Diff | Review

Description dwitte@gmail.com 2010-09-10 13:26:00 PDT
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.
Comment 1 dwitte@gmail.com 2010-09-13 10:50:10 PDT
This should block final (maybe betaN) so we get our story straight before we ship IndexedDB!
Comment 2 Benjamin Smedberg [:bsmedberg] 2010-09-14 13:33:48 PDT
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.
Comment 3 dwitte@gmail.com 2010-09-14 13:38:01 PDT
There was an email thread about this, which has the rationale. For expediency, I'll just pastebin it. Momentarily!
Comment 4 dwitte@gmail.com 2010-09-14 13:40:48 PDT
And here it is (initial message first): http://pastebin.mozilla.org/789127
Comment 5 dwitte@gmail.com 2010-09-14 13:41:50 PDT
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.
Comment 6 Shawn Wilsher :sdwilsh 2010-09-16 09:14:29 PDT
(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.
Comment 7 dwitte@gmail.com 2010-09-16 09:24:47 PDT
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 8 Ben Turner (not reading bugmail, use the needinfo flag!) 2010-12-16 16:27:39 PST
Created attachment 498253 [details] [diff] [review]
Patch, v1
Comment 9 dwitte@gmail.com 2010-12-16 16:39:37 PST
Comment on attachment 498253 [details] [diff] [review]
Patch, v1

r-, please attach in text/plain.
Comment 10 dwitte@gmail.com 2010-12-16 16:41:40 PST
Comment on attachment 498253 [details] [diff] [review]
Patch, v1

r=dwitte
Comment 11 Jonas Sicking (:sicking) 2010-12-17 17:46:44 PST
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 12 Jonas Sicking (:sicking) 2011-01-06 17:05:23 PST
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.
Comment 13 Ben Turner (not reading bugmail, use the needinfo flag!) 2011-01-07 00:49:35 PST
http://hg.mozilla.org/mozilla-central/rev/9b05e0e4cf04
Comment 14 Eric Shepherd [:sheppy] 2011-02-17 07:06:21 PST
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.
Comment 15 jonnew 2011-08-12 10:47:47 PDT
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.
Comment 16 Amit Ambardekar 2012-01-06 15:01:48 PST
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.
Comment 17 gene.vayngrib 2013-06-27 08:54:31 PDT
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.
Comment 18 gene.vayngrib 2013-06-27 14:49:30 PDT
(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.
Comment 19 Mark Hammond [:markh] 2013-07-24 19:47:38 PDT
(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?
Comment 20 Johnny Stenback (:jst, jst@mozilla.com) 2013-07-24 21:01:19 PDT
bent should be able to provide an explanation here!
Comment 21 Ben Turner (not reading bugmail, use the needinfo flag!) 2013-07-25 13:23:24 PDT
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.
Comment 22 Mark Hammond [:markh] 2013-07-25 18:12:46 PDT
(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.
Comment 23 Brian Kardell 2013-08-25 18:15:44 PDT
(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?
Comment 24 brunoais 2014-11-04 11:27:51 PST
> 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.
Comment 25 brunoais 2015-03-30 04:08:30 PDT
Any updates?
Comment 26 Ben Turner (not reading bugmail, use the needinfo flag!) 2015-07-05 11:13:32 PDT
I think ehsan is going to be driving the unification of storage behavior with respect to the third-party prefs.
Comment 27 :Ehsan Akhgari (busy, don't ask for review please) 2015-07-06 12:58:36 PDT
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.
Comment 28 :Ehsan Akhgari (busy, don't ask for review please) 2015-07-06 12:59:03 PDT
Oops, that should have read "lastest plans are..."
Comment 29 Chris Mills (Mozilla, MDN editor) [:cmills] 2015-12-01 02:04:33 PST
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.

Note You need to log in before you can comment on or make changes to this bug.