Bug 231879 – No IndexedDB persisted for iframe on different subdomain / port

• Component: WebKit Misc.
• Status: RESOLVED INVALID

[Florian Schulz]

I've encountered a strange bug with IndexedDB that seems to be related to iframes.

I have a website running on http://localhost:1337.
That website embeds an iframe that points to http://localhost:3000

The iframe is saving to IndexedDB. The embedding page is not accessing IndexedDB at all.

The problem:
Safari shows (3!) databases: one for :3000 and two for :1337
When I restart Safari, only the one database for :3000 remains. All data is lost.

Expected:
One database for :3000 with persisted content.

[Florian Schulz]

Created attachment 441537 [details]
Multiple databases while using the app. There should only be one database for port :3000 but instead also two databases for :1337 are shown.

[Florian Schulz]

Created attachment 441538 [details]
Lost data after restarting Safari. The database containing the actual data (port 3000) is lost. An empty database for port 1337 still exists.

[Florian Schulz]

I now see that although Safari seems to be saving to a database, it never persists to disk. 

A database on the file system is only (and incorrectly) created for the embedding page, but not for the iframe

Library/Safari/Databases/___IndexedDB/v1/http_localhost_1337 (embedding page)

There is no database for the data saved to localhost:3000 :(

[Florian Schulz]

Reproduction:

The test is slightly different but shows the same problem:

There are two pages:

foo.getflourish.com embeds bar.getflourish.com

Both pages create databases and save to them.

1. Open the page https://foo.getflourish.com
2. Reload the page a couple of times to create a few entries in the database.
3. Check the web inspector to confirm that there are entries in both databases (for both domains).
4. Restart Safari.
5. Check the web inspector again.

❌ Boom: the database for "bar.getflourish.com" is gone because it was never saved to disk.

[Florian Schulz]

I’m trying to understand wether this is a bug or expected behaviour related to ITP:

What I see happening is related to "Partitioning" and "Ephemeral". But after reading about tracker prevention I don’t understand why my case (same site, different subdomains) are treated like Third-Party (?)

---

From: https://webkit.org/tracking-prevention/

> **Partitioning** is a technology to allow third-parties to use storage and stateful web features, but have those isolated per first-party website. 

> **Ephemeral.** When we say ephemeral storage, we mean the storage does not persist to disk and goes away with the application, for instance when the user quits the browser or reboots their device. 

→ This is what happens.

> **Third-party** LocalStorage and IndexedDB are partitioned per first-party website and also made ephemeral.

---

I’ve also read the article about the updates to the storage API. https://webkit.org/blog/11545/updates-to-the-storage-access-api/

I can confirm that the iframe returns "false" for document.requestStorageAccess(). I can call document.requestStorageAccess() after user interaction and then document.requestStorageAccess() returns "true". 

But if I restart Safari, we’re back at zero.

[Sihui Liu]

Hi Florian, 

This is expected behavior. Third party does not persistent IDB storage, see https://bugs.webkit.org/show_bug.cgi?id=214583.

We used to not allow IDB in third party iframe and workers at all, and decided to add it for compatibility and match the behavior with localStorage. (Note different ports will be treated as different domains.)

Also, StorageAccess API does not work with IndexedDB yet. If it's important to you, you can file a bug for requesting support (something like https://bugs.webkit.org/show_bug.cgi?id=199105) and describing your use case. Feature request can help us understand what's needed by developers, and better schedule our work.

[John Wilander]

Regarding Storage Access API, the editors of the spec from Apple and Mozilla have recently concluded that permanently partitioned non-cookie storage is probably the best way to go given that partitioned ServiceWorkers cannot be unpartitioned and can have IDB connections. However, ephemeral vs persistent is not affected by that, rather the challenge of switching between them.

[Sihui Liu]

(In reply to John Wilander from comment #7)
> Regarding Storage Access API, the editors of the spec from Apple and Mozilla
> have recently concluded that permanently partitioned non-cookie storage is
> probably the best way to go given that partitioned ServiceWorkers cannot be
> unpartitioned and can have IDB connections. However, ephemeral vs persistent
> is not affected by that, rather the challenge of switching between them.

I don't fully understand. Do you mean Storage Access API decides to not support non-cookie storage? (i.e. when requestStorageAccess() is resolved, the embedded page will only get access to first-party cookies, and other storage type will stay partitioned).

[Florian Schulz]

(In reply to Sihui Liu from comment #6)
> Hi Florian, 
> 

Thanks your for your response!

> This is expected behavior. Third party does not persistent IDB storage, see
> https://bugs.webkit.org/show_bug.cgi?id=214583.

Does that mean that the following scenarios are classified as “Third-Party”?

localhost:1234 + localhost:5678
foo.domain.com + bar.domain.com


> 
> We used to not allow IDB in third party iframe and workers at all, and
> decided to add it for compatibility and match the behavior with
> localStorage. (Note different ports will be treated as different domains.)
> 
> Also, StorageAccess API does not work with IndexedDB yet. If it's important
> to you, you can file a bug for requesting support (something like
> https://bugs.webkit.org/show_bug.cgi?id=199105) and describing your use
> case. Feature request can help us understand what's needed by developers,
> and better schedule our work.

Thanks for pointing out that StorageAccess API does not work yet for IDB. I think I have a very specific (non-tracking, non abusive) use-case which is why I was hoping it wouldn’t need any permission handling at all. I can understand why mechanisms are necessary. If my scenario indeed counts as Third-Party and I would need to use the API in the future I can describe my use case in a new post :)

[Sihui Liu]

(In reply to Florian Schulz from comment #9)
> (In reply to Sihui Liu from comment #6)
> > Hi Florian, 
> > 
> 
> Thanks your for your response!
> 
> > This is expected behavior. Third party does not persistent IDB storage, see
> > https://bugs.webkit.org/show_bug.cgi?id=214583.
> 
> Does that mean that the following scenarios are classified as “Third-Party”?
> 
> localhost:1234 + localhost:5678
> foo.domain.com + bar.domain.com

There's difference between same-site and same-origin policy; and same-origin means the same protocol, hostname and port[1].
IndexedDB uses same-origin policy[2].

[1]https://web.dev/same-site-same-origin/
[2]https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Basic_Terminology

> 
> 
> > 
> > We used to not allow IDB in third party iframe and workers at all, and
> > decided to add it for compatibility and match the behavior with
> > localStorage. (Note different ports will be treated as different domains.)
> > 
> > Also, StorageAccess API does not work with IndexedDB yet. If it's important
> > to you, you can file a bug for requesting support (something like
> > https://bugs.webkit.org/show_bug.cgi?id=199105) and describing your use
> > case. Feature request can help us understand what's needed by developers,
> > and better schedule our work.
> 
> Thanks for pointing out that StorageAccess API does not work yet for IDB. I
> think I have a very specific (non-tracking, non abusive) use-case which is
> why I was hoping it wouldn’t need any permission handling at all. I can
> understand why mechanisms are necessary. If my scenario indeed counts as
> Third-Party and I would need to use the API in the future I can describe my
> use case in a new post :)

(In reply to Florian Schulz from comment #9)
> (In reply to Sihui Liu from comment #6)
> > Hi Florian, 
> > 
> 
> Thanks your for your response!
> 
> > This is expected behavior. Third party does not persistent IDB storage, see
> > https://bugs.webkit.org/show_bug.cgi?id=214583.
> 
> Does that mean that the following scenarios are classified as “Third-Party”?
> 
> localhost:1234 + localhost:5678
> foo.domain.com + bar.domain.com
> 
> 
> > 
> > We used to not allow IDB in third party iframe and workers at all, and
> > decided to add it for compatibility and match the behavior with
> > localStorage. (Note different ports will be treated as different domains.)
> > 
> > Also, StorageAccess API does not work with IndexedDB yet. If it's important
> > to you, you can file a bug for requesting support (something like
> > https://bugs.webkit.org/show_bug.cgi?id=199105) and describing your use
> > case. Feature request can help us understand what's needed by developers,
> > and better schedule our work.
> 
> Thanks for pointing out that StorageAccess API does not work yet for IDB. I
> think I have a very specific (non-tracking, non abusive) use-case which is
> why I was hoping it wouldn’t need any permission handling at all. I can
> understand why mechanisms are necessary. If my scenario indeed counts as
> Third-Party and I would need to use the API in the future I can describe my
> use case in a new post :)

[Florian Schulz]

Thank you! I guess you can close this issue then since it’s not a bug, but intended behaviour. I will be able to work around it in my production environment, but need to find a solution for local development somehow :)