[whatwg] localStorage feedback

On Mon, Oct 12, 2009 at 7:07 PM, Ian Hickson <ian at hixie.ch> wrote:
...

> > the problem here is that localStorage is a pile of global variables.
> > we are trying to give people global variables without giving them tools
> > to synchronize access to them.  the claim i've heard is that developers
> > are not savy enough to use those tools properly.  i agree that
> > developers tend to use tools without fully understanding them.  ok, but
> > then why are we giving them global variables?
>
> The global variables have implicit locks such that you can build the tools
> for explicit locking on top of them:
>
>   // run this first, in one script block
>   var id = localStorage['last-id'] + 1;
>   localStorage['last-id'] = id;
>   localStorage['email-ready-' + id] = "0"; // "begin"
>
>   // these can run each in separate script blocks as desired
>   localStorage['email-subject-' + id] = subject;
>   localStorage['email-from-' + id] = from;
>   localStorage['email-to-' + id] = to;
>   localStorage['email-body-' + id] = body;
>
>   // run this last
>   localStorage['email-ready-' + id] = "1"; // "commit"
>
>
Dividing up work like this into separate SCRIPT elements to scope the
locking seems really awkward to me.



>
> On Thu, 24 Sep 2009, Darin Fisher wrote:
> >
> > The current API exposes race conditions to the web.  The implicit
> > dropping of the storage lock is that.  In Chrome, we'll have to drop an
> > existing lock whenever a new lock is acquired.  That can happen due to a
> > variety of really odd cases (usually related to nested loops or nested
> > JS execution), which will be difficult for developers to predict,
> > especially if they are relying on third-party JS libraries.
> >
> > This issue seems to be discounted for reasons I do not understand.
>
> You can only lose the lock in very specific conditions. Those conditions
> are rarely going to interact with code that actually does storage work in
> a way that relies on the lock:
>
>  - changing document.domain
>  - history.back(), .forward(), .go(n)
>  - invoking a plugin
>  - alert(), confirm(), prompt(), print()
>  - showModalDialog()
>  - yieldForStorageUpdates()
>
> I discussed this in more detail here:
>
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023059.html
>
>
You are right that the conditions are specific, but I don't know that that
is the
exhaustive list.  Rather than defining unlock points, I would implement
implicit
unlocking by having any nested attempt to acquire a lock cause the existing
lock
to be dropped.  Nesting can happen in the cases you mention, but depending
on
the UA, it may happen for other reasons too.

This combined with the fact that most people use JS libraries means that the
coder is not going to have an easy time knowing when these specific
conditions
are met.  I don't think defining a set of allowed unlock points is
sufficient to make
this API not be a minefield for users.

For example, a JS library might evolve to use flash for something small
(like
storage or sound) that it previously didn't use when I first developed my
code.
Voila, now my storage lock is released out from under me.

At this point, I'm not favoring implementing the storage mutex in Chrome.  I
don't think we will have it in our initial implementation of LocalStorage.
 I think
web developers that care will have to find another way to manage locking,
like
using a Web Database transaction or coordinating with a Shared Worker.

Sorry to be a grump about this, but a cross-process lock that lasts until JS
returns is just going to slow down the web.  It is a really bad idea for
that
reason.

-Darin



> On Tue, 8 Sep 2009, Chris Jones wrote:
> >
> > Can those in the first camp explain why "mutex" semantics is better than
> > "transaction" semantics?  And why it's desirable to have one DB spec
> > specify "transaction" semantics (Web Database) and a second specify
> > "mutex" semantics (localStorage)?
>
> I don't think it's desirable. It's just what we have, though an accident
> of history.
>
>
> Where we're at: localStorage can't really change. It is what it is.
>
> We have a better proposal, Web Database, but not everybody wants to
> implement it.
>
> To move forward, I would recommend that someone come up with a storage
> proposal with the following characteristics:
>
>  * All major browsers vendors are willing to implement it.
>  * Compatible with workers.
>  * Doesn't have any race conditions.
>  * Doesn't involve a cross-process mutex that blocks interaction.
>  * Stores structured data.
>  * Can be queried in arbitrary ways.
>  * Doesn't expose authors to locking primitives.
>
> Then we can replace Web Database with it and we can move on.
>
> I suggest that the right venue for this discussion would be the W3C Web
> Apps group, at public-webapps at w3.org.
>
>
> On Wed, 9 Sep 2009, Darin Fisher wrote:
> >
> > What about navigating an iframe to a reference fragment, which could
> > trigger a scroll event?  The scrolling has to be done synchronously for
> > compat with the web.
>
> You can only do that with same-domain pages, as far as I can tell.
>
> (Does that really have to be synchronous? Right now we don't define the
> 'scroll' event anywhere. What are the semantics it needs?)
>
>
> On Mon, 31 Aug 2009, James Graham wrote:
> > Quoting Ian Hickson <ian at hixie.ch>:
> > >
> > > We can't treat cookies and persistent storage differently, because
> > > otherwise we'll expose users to cookie resurrection attacks.
> > > Maintaining the user's expectations of privacy is critical.
> >
> > I think the paragraph under "treating persistent storage as cookies"
> > should simply be removed. The remainder of that section already does an
> > adequate job of explaining the privacy implications of persistent
> > storage. The UI should be entirely at the discretion of the browser
> > vendor since it involves a variety of tradeoffs, with the optimum
> > solution depending on the anticipated user base of the browser. Placing
> > spec requirements simply limits the abilities of browser vendors to find
> > innovative solutions to the problem. In addition, since there is no
> > interoperability requirement here, using RFC 2119 language seems
> > inappropriate; especially since the justification given is rather weak
> > ("this might encourage users?") and not supported by any evidence.
>
> I think it's important to include this paragraph in a discussion of the
> privacy implications of these APIs. I feel like it would be irresponsible
> of me to not include this text, given how important this actually is.
>
>
> > As to what browser vendors should actually _do_, it seems to me that the
> > "user's expectations of privacy" is actually an illusion in this case;
> > all the bad stuff that can be done with persistent storage can already
> > be done using a variety of techniques. Trying to fix up this one case
> > seems like closing the stable door after the horse has bolted. Therefore
> > the "delete local storage when you delete cookies" model seems flawed,
> > particularly as it can lead to the type of problem that Jens described
> > above.
>
> Cookie resurrection has been a real concern on the Web. I don't think it's
> an illusion.
>
>
> > On a slightly different topic, it is unclear what the relationship
> > between the statement in section 4.3 "User agents should expire data
> > from the local storage areas only for security reasons or when requested
> > to do so by the user" and the statement in section 6.1 "User agents may
> > automatically delete stored data after a period of time." is supposed to
> > be. Does the latter count as a security reason?
>
> I've edited the latter text to indicate that the expiration should only be
> done at user option.
>
>
> On Fri, 2 Oct 2009, Jeremy Orlow wrote:
> >
> > Since my original post, I've continued thinking about LocalStorage,
> > structured clones, etc...and the more I've thought about it, the more
> > convinced I am that adding such support is a big mistake.  One way to
> > think about it is as follows:
> >
> > 1)  We've all pretty much agreed that localStorage's synchronous design
> > was a mistake that we should be careful to not repeat.
> >
> > 2)  I think we can all agree that storing structured clone data makes
> > LocalStorage more powerful and useful to developers.
> >
> > 3)  And I think we can all agree that developers like to use more
> > powerful APIs.  Especially when the API is easy to use and understand
> > (as LocalStorage is).
> >
> > 4)  Lock contention becomes worse as the frequency of acquires and/or
> > the duration the lock is held increases.
> >
> > Although there might be some subtleties about the statements I made that
> > people could argue with, I think all these statements are pretty
> > fundamentally true.  Assuming so, it's not a stretch to see that 2 and 3
> > imply that adding structured clones to local storage will lead to more
> > use of local storage.
>
> I don't see why it would add significantly more use. Once a site is using
> localStorage, whether it has structured storage natively or not, they're
> going to store structured data in it -- e.g. using JSON, as some people
> have said they already are -- and so I don't think that this effectively
> increases the usage. It just makes it simpler for those who do use it.
>
>
> > If use increases, then 4 implies that the storage lock is going to
> > become a bigger problem over time.  Since we can all agree that the
> > synchronous design of local storage is already a problem that we wish we
> > had avoided, I just can't understand why we're happy to make it a bigger
> > problem.
> >
> > Does anyone have an argument against this?
>
> I don't think it makes it a significantly bigger problem.
>
>
> > Anyone who's going to use LocalStorage in the near to medium future will
> > need to handle the case of LocalStorage only handling strings.  This is
> > because structured clones supports a super-set of what can be serialized
> > within a script, there's no way for libraries to build a transparent
> > compatibility abstraction.  Thus, for some time, developers will either
> > need to only use data that can be serialized (thus making structured
> > clones only a performance optimization) or developers will need to cut
> > off browsers that don't support structured clones.
> >
> > Assuming that, we're basically saying that structured clones is a
> > feature for the long term use and health of LocalStorage.  Now I know
> > that we can't just get rid of LocalStorage and coming up with viable
> > alternatives will take some time, but do we really believe that we can't
> > agree on and develop a better alternative in the mean time?
>
> I think it makes sense to allow Files to be stored today.
>
> However, I'm all for a better API. So if you can get people to agree to a
> better API before anyone ships this one and before pages start depending
> on it, then maybe we can remove the structured storage feature from
> localStorage.
>
>
> > I'm fine with SessionStorage supporting structured clones.  I just don't
> > think we should make LocalStorage any more powerful.  In fact, at this
> > point, I think we should redirect all the time and effort we're putting
> > into making LocalStorage better (including solving lock contention
> > issues) and instead put it into creating a new API that solves these
> > problems and that all the browser vendors can get behind.  (If you have
> > ideas on how I can get this ball rolling, I'd love to hear them!)
>
> I agree.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091029/a899c8a6/attachment-0001.htm>

Received on Thursday, 29 October 2009 23:27:44 UTC