-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Grant access to other origins #60
Comments
IMHO, we should demonstrate that |
Agree about doing Foreign Fetch first. And if performance still is a problem we could add an API to "pre can" foreign-fetch responses for given URL requests. |
As a simpler beginning to #75, might this foreign access include a shared database type which is agnostic as to origin (like |
To address the privacy/security concerns of apps snooping or vandalizing shared storage at will (while avoiding the full complexity of my earlier proposal), a simple implementation beginning could be to forego permitting doorhanger requests for access (which might itself lead to some degree of abuse) and simply require a site to be whitelisted within preferences in order to gain any access to shared storage, optionally requiring access be designated only for a particular database (though ideally with an optionally higher privilege allowing arbitrary access of shared storage databases as well as enumeration of database names on shared storage (on top of #31)). Readonly access support be added later and to avoid interoperability problems, upgrade transactions could be prevented beyond the first version (a site needing to start over with their shared format could bake a version (as well as optional namespacing) into the database name itself and require users to whitelist the new database to do any migration of content, ensuring interoperability continues to be maintained with other sites still expecting the old format until such time as they may support the new version of the format). Progressively-minded (and self-interested) sites that provided an option to their users for such shared storage would help the user avoid the need to continually export and import their data in order to gain the freedom to choose between multiple sites for reading/altering their data (assuming a site even feels pressure nowadays to allow for this) without any site being a sole gate-keeper of the user's data. The benefits of full user control (of which apps are allowed to access which data) inherent in the typical desktop file system along with the benefits of the web in expanded choices and live updated software, as well as the absence of the dangers of executable installation would thus be joined together. Other features could be added such as limiting access of sites to a one-time, per-database basis, e.g., granting a word processor permission to only edit one requested database file and not all previously opened ones (making the proposed urlification feature, #57 , more meaningful, as the same URL could be used to view in whatever app was designated as the default). |
TPAC 2019 Web Apps Indexed DB triage notes: We think doing this as part of Storage Buckets makes the most sense. |
Currently this requires opening an iframe and proxying all data access (hence, perf issue)
One approach would be to make IDBDatabase connection objects Transferable; then they could be passed between cooperating frames via postMessage()
Imported from https://www.w3.org/2008/webapps/wiki/IndexedDatabaseFeatures
The text was updated successfully, but these errors were encountered: