Bug 183517
| Summary: | Feature Request: Include IndexedDB into Storage Access API | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Stefan Sechelmann <stefan> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | beidson, bfulgham, dbates, webkit-bug-importer, wilander, youennf |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: |
https://bugs.webkit.org/show_bug.cgi?id=175759 https://bugs.webkit.org/show_bug.cgi?id=168631 |
||
Stefan Sechelmann
We develop a web app that handles sensitive user date. We have a security mechanism in place that is based on origin separation between frontend (top-level context) and data storage (iframe on a different origin via postMessage api). Currently we support Chrome and Firefox which allow for 3rd party storage access.
We respect the policy of the WebKit team to protect the privacy of the user and prevent tracking by employing partitioning on all 3rd party storage systems. At the same time this is a blocker for us when implementing our system for Safari on Mac and iOS. The Storage Access API (https://github.com/whatwg/html/issues/3338) seems like the right idea if applied to all storage types, i.e., Cookies, LocalStorage, and IndexedDB.
As the discussion points in the direction of having no user interaction to grant the permission I wanted to stress that we are in favour of a system that goes along the lines of other permissions like camera or microphones, i.e., the user is prompted for consent via browser UI and the choice is persisted across browser sessions.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Brady Eidson
I'm *pretty sure* the plan is for StorageAccess to cover literally every local storage type eventually.
I'll let John comment, though.
Brady Eidson
(In reply to Brady Eidson from comment #1)
> I'm *pretty sure* the plan is for StorageAccess to cover literally every
> local storage type eventually.
Yah, I see in the issues thread Maciej asked you file this bug and then you did.
Again, cookies being the primary and "automatic" tracking vector is why v1 focused on them, but there are plans to cover the whole platform.
John Wilander
Brady is correct — Storage Access API is intended to cover all partitioned storage. We just need to get adoption of v1 and get feedback on it.
We already got an important enhancement request in how the API plays together with the popup blocker.
I imagine something similar might go for when a cross-origin iframe tries to navigate the top frame. There's movement in that space right now. We don't want to end up with well-behaved third-parties having to convince first-parties to execute their JavaScript in the first-party context to be able to navigate the user to a login page. And we want the embedding page to have appropriate control through iframe sandbox tokens.
Stefan Sechelmann
Ok, so then we may use this thread to gather ideas on how to extend the API to include IndexedDB. I mean there are a few questions that immediately come to my mind:
* What happens to database instances that are already active when the a storage access request resolves?
* If service workers are affected by partitioning too, what happens to the database connections that are active within a service worker?
* What is going on if there is more that one tab, is there some kind of event that makes other tabs aware of the change?
Greetings
Stefan
youenn fablet
> * What happens to database instances that are already active when the a
> storage access request resolves?
> * If service workers are affected by partitioning too, what happens to the
> database connections that are active within a service worker?
Note that a service worker may be used to keep some state.
It might make sense to change the controlling service worker of such an iframe when using the storage access API.
Radar WebKit Bug Importer
<rdar://problem/81812694>