- From: Brett Zamir <brettz9@yahoo.com>
- Date: Sat, 15 Feb 2014 10:04:05 +0800
- To: whatwg <whatwg@whatwg.org>
*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
Received on Saturday, 15 February 2014 02:04:47 UTC