Skip to content
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

Closed
inexorabletash opened this issue Oct 8, 2015 · 5 comments
Closed

Grant access to other origins #60

inexorabletash opened this issue Oct 8, 2015 · 5 comments
Labels
feature request storage buckets Handle this with Storage Buckets instead?

Comments

@inexorabletash
Copy link
Member

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

@inexorabletash
Copy link
Member Author

IMHO, we should demonstrate that navigator.connect and/or Foreign Fetch (with a REST-style API) are insufficient before we tackle this.

@sicking
Copy link
Contributor

sicking commented Oct 8, 2015

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.

@inexorabletash inexorabletash changed the title Grant access to other domains Grant access to other origins Apr 1, 2016
@brettz9
Copy link
Contributor

brettz9 commented Feb 23, 2017

As a simpler beginning to #75, might this foreign access include a shared database type which is agnostic as to origin (like globalStorage had been)?

@brettz9
Copy link
Contributor

brettz9 commented Feb 24, 2017

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).

@inexorabletash inexorabletash added the storage buckets Handle this with Storage Buckets instead? label Sep 20, 2019
@inexorabletash
Copy link
Member Author

TPAC 2019 Web Apps Indexed DB triage notes:

We think doing this as part of Storage Buckets makes the most sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request storage buckets Handle this with Storage Buckets instead?
Projects
None yet
Development

No branches or pull requests

3 participants