Re: [whatwg] Shared storage

On 28 October 2014 21:32, Nils Dagsson Moskopp <
nils@dieweltistgarnichtso.net> wrote:

> Melvin Carvalho <melvincarvalho@gmail.com> writes:
>
> > 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
>
> Stop doing this.
>

Excuse me?


>
> --
> Nils Dagsson Moskopp // erlehmann
> <http://dieweltistgarnichtso.net>
>

Received on Tuesday, 28 October 2014 20:57:48 UTC