The current policy of blocking all access to IndexedDB from third-party iframes puts excessive limits on composability of web apps. Denying access by default is fine, as long as there is a way for the user to add exceptions for third-party domains that they trust. Related: #595307

Sanboxed iframes with allow-same-origin, specifically, should be allowed or an alternative standard mechanism proposed. the disadvantage of the later is that the former is per spec and implemented elsewhere

This restriction is also causing my team (Orion) problems as we use iframes to let third parties contribute functionality back to our browser-based IDE. In particular this prevents our plugin authors from providing some basic offline support on FF only. We're using sandboxed iframes and could also do something on the iframe side if some sort of trust handshake was needed.

Having an option in about:permissions to control this would be nice.

I would welcome unification of site-specific permissions and third-party permissions across all forms of local storage. The current site-specific permissions are a mess, and it's very confusing for developers to have cookie and indexdb requests treated differently. Jonas, what do you think?

Agreed! Would you be able to work on this, or know of anyone who would? If so we could get together an come up with a comprehensive design.

Ok, good :) I wouldn't be able to work on this anytime soon, but we should come up with a plan anyway -- I may be able to recruit someone who has capacity.

In the short-term, can we enable indexeddb in third-party iframes when third-party cookies are enabled?

See comment above.

Jonas owns indexdb.

I don't actually. Ben Turner does these days. But yes, I agree that we should enable IndexedDB in cross-origin iframes when third-party cookies are enabled.

We're all in basic agreement that all forms of temporary storage should behave the same as cookies. ack is going to take a look here.

To clarify, we want allow IndexedDB for a fist-party domain even when cookies are disabled?

Added a check for cookie permissions when testing third-partyness. Check is essentially the same as the one for third-party cookies. (Ignore the whitespace changes.)

The changes to CookieServiceChild are trivial, but the patch seems to work. Not sure what needs to be done there (WIP).

Comment on attachment 8472295 [details] [diff] [review] idb-third-party-iframes.patch Review of attachment 8472295 [details] [diff] [review]: ----------------------------------------------------------------- ::: netwerk/cookie/CookieServiceChild.cpp @@ +213,5 @@ > +CookieServiceChild::CheckCookiesAllowed(nsIURI *aHostURI, > + nsIChannel *aChannel, > + bool *result) > +{ > + return NS_OK; This doesn't seem right. Note that FirefoxOS uses child processes a lot and we want to make sure that this bug is fixed there too. ::: netwerk/cookie/nsCookieService.cpp @@ +1638,5 @@ > > NS_IMETHODIMP > +nsCookieService::CheckCookiesAllowed(nsIURI *aHostURI, > + nsIChannel *aChannel, > + bool *result) Someone other than me needs to look at this.

I think that if cookies are completely disabled, we should also disable IndexedDB. Eventually we should enable IndexedDB in the persistent storage area even when cookies are disabled, but let's not worry about that for now.

Comment on attachment 8472295 [details] [diff] [review] idb-third-party-iframes.patch Review of attachment 8472295 [details] [diff] [review]: ----------------------------------------------------------------- This looks generally fine, but I agree with sicking that the child process impl has to work too. Also, your editor has made this patch hard to follow with all the unrelated whitespace changes. You'll want to revert those before getting a full review. ::: dom/base/nsGlobalWindow.cpp @@ +10639,5 @@ > bool isThirdParty; > aError = thirdPartyUtil->IsThirdPartyWindow(this, nullptr, > &isThirdParty); > + > + if (isThirdParty) { You're not checking aError.Failed() here, 'isThirdParty' could be uninitialized. @@ +10644,5 @@ > + if (!codebaseURI) { > + // Document's principal is not a codebase (may be system), so > + // can't set cookies > + > + aError.Throw(NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR); Previously we didn't throw but just made the return value null. I'd keep that approach. @@ +10648,5 @@ > + aError.Throw(NS_ERROR_DOM_INDEXEDDB_UNKNOWN_ERR); > + return nullptr; > + } > + > + // not having a cookie service isn't an error Really? In what cases would we not have a cookie service? @@ +10650,5 @@ > + } > + > + // not having a cookie service isn't an error > + nsCOMPtr<nsICookieService> service = do_GetService(NS_COOKIESERVICE_CONTRACTID); > + nsIURI* documentURI = GetDocument()->GetDocumentURI(); What happens if documentURI is null? ::: netwerk/cookie/nsCookieService.cpp @@ +1638,5 @@ > > NS_IMETHODIMP > +nsCookieService::CheckCookiesAllowed(nsIURI *aHostURI, > + nsIChannel *aChannel, > + bool *result) I'd suggest someone in network, jduell or jdm perhaps

Removed whitespace changes from patch.

Pretty sure Alan has moved on.

Still interested in seeing this fixed, but I no longer have time to do the work.