W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2014

Re: [whatwg] Shared storage

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Tue, 28 Oct 2014 21:08:31 +0100
Message-ID: <CAKaEYhLxp7dXJeY5a3dZD4ng4=1J9ni++rT19H8WrTxbKAvWow@mail.gmail.com>
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.


> Thank you,
> Brett
Received on Tuesday, 28 October 2014 20:08:58 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:24 UTC