[w3c/IndexedDB] Shared databases and stores (and more robust schemas) (#75)

## Introduction

It would be hard to overestimate the benefits that application-agnostic file systems have brought, both with healthy competition spurring on improved apps, and users not being stuck with their data locked away in a data silo.

Especially if shared file systems are not going to see the light of day, I would like to see choice be brought back to users after the open web has now, in effect, paradoxically removed this control away from users. Just because some progressive sites allow you to export their data, this is not a substitute for the ability to effortlessly switch between applications for the same data.

This proposal goes beyond the idea of cross-origin database requests as these still require a particular site to act as a privileged go-between.

I'd like to see the ability for sites to create and modify databases and stores into a shared space potentially available to all websites.

For privacy/security/UX reasons, there would be one browser UI component for whitelisting sites to create or gain access to shared stores as one was visiting the sites, but the main browser UI would be a kind of "web desktop" where all priorly approved shared stores were displayed.

I would even hope that browsers would even consider opening ALL local databases for origin-agnostic reading or editing since the large amount of storage in IndexedDB should not be used for housing authentication tokens or other site-sensitive details but data owned by the user (and even an app for housing your passwords should not be the only one to continue having access to your data, giving you the choice to move to another such app).

## Addressing privacy/security/notification-fatigue concerns

Since it could become a nightmare to have sites constantly asking to serve as a shared storage type handler in addition to the privacy/security risks of such ready access to shared data, the idea would be for sites to advertise that they can support read-only, read-write, or create-read-write access to certain shared formats, and the only browser UI that would expose this to the user would be a button to indicate that the site has shared storage support for which the user could grant the site access (and showing the button visibly different or absent when a site was not advertising any shared format support).

If a shared store of the name/type and schema requested by the site had not yet been created, the first create-read-write privilege-supporting site to have the button clicked would gain access (and with storage limits) toward creating the shared store. (Requiring a schema would be important to ensure that sites would not clash with the same name but different data types.)

Since the origin-agnostic access could be compromised if the origin site (or current default site) could continually make upgrades to the format, there should, I think, be no upgrade access for these stores (at least not unless "upgrade" access were a separate privilege). A site already with access that wanted to upgrade would need to migrate the data to a non-shared store or wait for another button click by the user to gain the user's permission for migrating to a new shared store, and such a migration would not remove the old shared store data.

If the user later visited another site which advertised support and they clicked the shared privilege granting button, there could perhaps be an option to immediately change to this new site's default, or, the browser could opt to require the user to right-click the shared store in the "web-desktop" to change its "Open with..." behavior (but all button-clicked sites would show up there as options).

There is still the concern about privacy/security for malicious sites, whether those which sought to plant their flag with a well-known shared store before other sites had a chance or which were approved later, but this is the price we have on the desktop too when installing apps that can be used as read/write handlers for our files.

But the manner described above should not amplify the means for malicious behavior since a site cannot gain access to this shared data by harassing the user with doorhanger notifications. As with the desktop, access would only occur at their initiation.

## Web-desktop UI

The browser could expose a UI "web desktop" to users for navigating through all shared databases/stores in some file-system-like interface. But since we wouldn't want spam sites polluting the user's web-desktop, mentioning the names of various products, etc., the UI could perhaps be purely indexed by site origin. However, to prevent sites from muscling attention by setting up many domains, the site wouldn't even be listed unless a user whitelisted a site--not at the initiation of the site like doorhanger notifications, but with the above-mentioned button within the browser UI if the site had offered itself for handling shared storage.

While developers could perhaps be given access to see a JSON serialization of a given store to know what was in it without opening it in a particular site, the default UI for regular users would first show a list of origin sites and if one drills down into a particular site, one could then choose to view or edit a particular database or store (handled by default by the originating site). (Or if one is already visiting a site with a store in the browser, it would provide a button to "View/edit this site's (shared) data".)

If the user right-clicked a particular database/store on the web-desktop, it would have a context menu item to open the db/store with other sites, mentioning that X, Y, and Z sites have also previously requested and been granted potential access (read-only or readwrite) to this particular database/store and that you could choose to open with their site instead (with some warning about privacy/security of the shared information).

The UI could also allow the user to move the database/store out of the site-indexed section and give it a name they can remember and within any folders they wanted to set up, but such a move would be more like a symlink, not granting even the origin site any additional privileges except to continue to be able to read and/or modify the store data (the file name or path itself would be opaque to the origin site).

(Ideally, this UI for local database storage could be integrated with views on other remotely hosted data files such as bookmarked JSON files (if served with a specific content type or with an accompanying JSON schema indicating content types) that could be viewed in any content-type handler viewer/editor (even allowing, if the site supported and gave access, for a PUT back to the site).)

The browser could ideally, moreover, allow users to highlight selections during their browsing and use a context menu to add the content into chosen shared stores, being sensitive to content type (e.g., if highlighting formatted text, one could shuttle the data to a preexisting shared store which supported HTML or to one which supported plain text).

# MIME types

Besides allowing for custom formats--a MUST in my opinion--shared stores could also designate themselves as adhering to a particular MIME type and/or JSON Schema (which could also indicate MIME types for subobjects, via the JSON Hyper Schema). This addition of validation requirements could help prevent corruption and promote interoperability of data. And if sites had offered themselves as handlers of the MIME or schema type, the UI could, also via context menu or such, allow one to designate a particular site as trusted for opening such well-known types, but normally the control would be granular to the particular shared database/store.

Aliases could be added to the web-desktop so that as long as the schema defined a MIME type for a given store or object, one could treat those particular objects like individual files--directly editable in other apps.

# Conclusion

The main idea here is to return control of the user's data to the user. Not to let sites make black boxes even out of data they store locally or as remote files. While it would be up to sites (if not browsers) to decide whether shared storage was used or not, I think it would become compelling for them as this ability became employed for any given data format and as users came to recognize the benefits to them of such choice and ownership.


---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/IndexedDB/issues/75