[whatwg] Shared storage

[Brett Zamir]

*The opportunity and current obstacles*

The desktop PC thankfully evolved into allowing third-party software 
which could create and edit files shareable by other third-party 
software which would have the same rights to do the same. The importance 
of this can hardly be overestimated.

Yet today, on the web, there appears to be no standard way to create 
content in such an agnostic manner whereby users have full, built-in, 
locally-controlled portability of their data.

*Workarounds*

Sure, there is postMessage or CORS requests which can be used to allow 
one site to be the arbiter of this data.

And one could conceivably create a shared data store built upon even 
postMessage alone, even one which can work fully offline through cache 
manifests and localStorage or IndexedDB (I have begun some work on this 
concept at https://gist.github.com/brettz9/8876920 ), but this can only 
work if:

1. A site or set of domains is trusted to host the shared content.
2. Instead of being built into the browser, it requires that the shared 
storage site be visited at least one time.

*Proposal*

1. Add support for sharedStorage (similar to globalStorage but requiring 
approval), SharedIndexedDB, and SharedFileWriter/SharedFileSystem which, 
when used, would cause the browser to prompt the user to require user 
approval whenever storing or retrieving from such data stores (with an 
option to remember the choice for a particular site/domain), informing 
users of potential risks depending on how the data might be used, and 
potentially allowing them to view, on the spot, the specific data that 
was being stored.

Optional API methods could deter XSS by doing selective escaping, but 
the potential for abuse should not be used as an excuse for preventing 
arbitrary shared storage, since again, it is worked well on the desktop, 
despite risks there, and as works with postMessage despite it also 
having risks.

2. Add support for corresponding ReadonlyShared storage mechanisms, 
namespaced by the origin site of the data. A site, http://example.com 
might add such shared storage under "example.com" which 
http://some-other-site.example could retrieve but not alter or delete 
(unless perhaps a grave warning were given to users about the fact that 
this was not the same domain). This would have the benefit above 
postMessage in that if the origin site goes down, third party sites 
would still be able to have access to the data.

3. Encourage browsers to allow direct editing of this stored data in a 
human-readable manner (with files at least being ideally directly 
viewable from the OS desktop).

I proposed something similar earlier, and received a reply about doing 
this through shared workers, but as I understood it, I did not like that 
possibility because:

     a. it would limit the neutrality of the storage, creating one site 
as an unchallengeable arbiter of the data
     b. it would increase complexity for developers
     c. it would presumably depend on the setting of CORS directives to 
distinguish it from same-domain shared workers.

While https://wiki.mozilla.org/WebAPI/DeviceStorageAPI appears to meet a 
subset of these needs, it does not meet all.

Thank you,
Brett