- From: Melvin Carvalho <melvincarvalho@gmail.com>
- Date: Tue, 28 Oct 2014 21:08:31 +0100
- To: Brett Zamir <brettz9@yahoo.com>
- Cc: whatwg <whatwg@whatwg.org>
On 15 February 2014 03:04, Brett Zamir <brettz9@yahoo.com> wrote: > *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. > +1 > > Thank you, > Brett > >
Received on Tuesday, 28 October 2014 20:08:58 UTC