There is no way to store local data in cross-origin iframe

• Component: DOM
• Status: NEW ---

[Adam Lippai]

If I want to open the storage (IndexedDB or WebSQL) from an embedded iframe (the origin differs), it throws an error:
SecurityError: DOM Exception 18: IDBFactory.open() called in an invalid security context

Also the localStorage is buggy in the cross-origin usecase. It's affected by the parent domain while it shouldn't be context (parent origin) aware.

Both APIs are violating the specs and they work in the other browsers (Chrome, IE, FF).

All the storage specs require exactly one "storage space" per origin. Zero (IndexedDB and WebSQL) and multiple (localStorage has one space per parent origin) are not allowed.

[John Wilander]

For the local storage part I believe this works as intended. See:
https://bugs.webkit.org/show_bug.cgi?id=115004
http://trac.webkit.org/changeset/149326

[Adam Lippai]

In 2012 there were very few really client-side heavy apps and they had little or no shared resources. Now, more than four years later it should be reconsidered to finish the correct - but harder to implement - way.

E.g.: We want to implement a cookieless SSO (sessions) and Safari is the only browser where we have to share anything with the parent domain and do ugly redirections.

Other example: offline first websites / web apps, where you want to pass data between them (with no network interaction).

I couldn't find info on this, but I think https://bugs.webkit.org/show_bug.cgi?id=93390 was about Allowing this behavior and not defaulting to it. This piece of code wasn't revamped when the browser's  default behavior changed so it's missing at least a reconsideration.

Maybe the localStorage or this security model is Apple's sacred cow, but now there is no way to share resource - anything but cookie - in the shared iFrame. This behaviour would be acceptable only if not ALL the specs would go in the other direction. Also this will be an issue with future specs (think ServiceWorker, which is on the roadmap).

[Stefan Sechelmann]

Any advances of this topic would be greatly appreciated. At the moment we open a little pop-up and pass all data stored in indexeddb through postMessage API to the iframe. This is so ugly!

[Stefan Sechelmann]

> Also this will be an issue with future specs (think ServiceWorker, which is on the roadmap).

ServiceWorkers have arrived and the issue unfolds further: Now it is possible to store data into, e.g., IndexedDB without any partitioning applied. The whole concept of partitioning is not well-defined anymore in a ServiceWorker environment since there is no enclosing context such as in the pure iframe case. So one could easily cook up an iframe that spawns a service worker and stores data regardless of the surrounding top-level context.

[Stefan Sechelmann]

Not sure if this a bug in the current implementation of SafariTechPreview though or intended behaviour: If one closes the browser all data stored from within the ServiceWorker to IndexedDB is gone.