*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
