[Webkit-unassigned] [Bug 231879] No IndexedDB persisted for iframe on different subdomain / port

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=231879

--- Comment #10 from Sihui Liu <sihui_liu at apple.com> ---
(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 :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211020/b5bdebc6/attachment-0001.htm>