Thanks a lot for the quick response. This does clear up a lot for me. Hopefully I'll send my first DOM Storage re-factoring [1] patch out in a day or two. Once the re-factoring is squared away, I'll try to tackle these inconsistencies. (And, a little further out, I'm hoping to add Quota support and memory reclamation code.) In the mean time I'll file a bug.
Note that, with respect to some of these corner cases, I think Chromium's behavior may need diverge from the default WebKit behavior. (For example, incognito mode will be different from WebKit's private browsing.) That said, I think it should be pretty easy to handle these differences in a clean manner. Thanks, Jeremy [1] https://lists.webkit.org/pipermail/webkit-dev/2009-May/007684.html On Wed, May 20, 2009 at 1:38 PM, Brady Eidson <[email protected]> wrote: > > On May 20, 2009, at 1:03 PM, Jeremy Orlow wrote: > > I'm pretty confused by the policy decisions in DOM Storage with respect to > private browsing. > > Just to be clear, I understand that Safari's private browsing has a > different philosophy from Chromium's incognito mode. > > > Right. To re-clarify for this discussion: > WebKit's private browsing feature exists as direct result of the design of > Safari's private browsing feature from many years ago. Safari's private > browsing feature has always been about "do not leave any local footprint on > the user's disk pertaining to this browsing session" and has never been > about creating an anonymous profile for the wild. > > Take a look at cookies, for example - a private browsing session starts > with an in-memory copy of the cookies that existed at the time the session > starts. Any changes to cookies during the session are not persisted to > disk. When the private browsing session is over, we revert back to the > stored cookies as they existed when private browsing began. > > We definitely discussed applying that model to > LocalStorage, and it's certainly not off the table to do so. But such a > solution would be much more complex, > and were more concerned with closing the "LocalStorage changes are written to > disk during private browsing" bug in the meantime. > > When in private browsing, both LocalStorage and SessionStorage return > QUOTA_EXCEEDED_ERR whenever setItem() is called and simply ignore > removeItem() and clear() calls. This is different from the behavior when > LocalStorage persistence is disabled (because > page->settings()->localStorageDatabasePath() returns nothing) which returns > a LocalStorage object that is not database backed. > > > I think this is a bug. The crux of the emails to whatwg that you reference > is that we have two strong convictions: > 1 - LocalStorage is guaranteed to be persistent. We're giving web > developers simple, reliable, persistent storage and we plan to treat it like > user data that only the controlling web apps or users themselves can make > decisions about > 2 - Since LocalStorage is guaranteed to be persistent, we should never give > a web app the indication that we've stored some data when we actually have > no intention to store it. > > If we can get a LocalStorage object that is not database backed, this goes > against that philosophy and is a potential bug. > > According to a FIXME in LocalStorage::fullDatabaseFilename [2], there's > also plans to allow LocalStorage (but just not back it with a database) when > there is no quota. > > The first question is why private browsing affects SessionStorage? The > original email [1] on the matter didn't mention changing this, and I can't > see any reason why it needs to. > > > From the ChangeLog for r42302 - "...made the change to restrict > SessionStorage to read-only, also, with the understanding that the spec > allows for SessionStorage to persist across relaunches, even though our > implementation currently doesn't do this." > > This may have been overzealous preparation for the future, but hopefully it > explains the thinking behind it. > > Next, why the (planned) inconsistency in quota handling? This seems to go > against the Apple view on LocalStorage persistence ("[doing this] would lead > to bizarre behavior where data that the application thought was saved really > wasn't" is the only example I could find in 1 minute, but I believe there's > others in [3] and other threads). It also seems confusing that the script > would get a QUOTA_EXCEEDED_ERR if there's a tiny quota but would just get a > non-database backed storage if there's 0 quota. > > > As said above, if we can't back a LocalStorage object with a database, we > shouldn't be pretending to store data in it. This is a bug. Same with 0 > quota. It should probably end up having the read-only behavior as currently > implemented for private browsing. > > Lastly, I have to ask (at the risk of rehashing [3]) why private browsing > gives access to data accumulated before entering private browsing (which > could be sensitive and user identifying!) and why it's considered ok to > silently ignore requests to clear/remove data (even though it's not OK > according to [1] to offer a non-persistent LocalStorage). > > I'm bringing this up because (as far as I can tell) WebKit is not > consistent internally. If any changes need to be made as a result of this > discussion, I'm happy to make them. :-) > > > I started out with a description of Safari's Private Browsing philosophy > then clarified a few points on our LocalStorage philosophy. Hopefully that > - combined with the acknowledgement of some bugs! - clears up the > inconsistencies. ;) > > As far as "silently ignoring requests to clear/remove data" - I personally > hate the fact that we silently ignore such requests. One intent of my > original email to whatwg was to get a mechanism to ignore these requests > LOUDLY. But unlike the setItem() case where the spec gave us an out in the > form of "QUOTA_EXCEEDED_ERR," there was no spec'ed behavior we could adapt > for the ignoring remove/clear requests. > > From our viewpoint, there's two great reasons to have the "read-only > LocalStorage" mode. One is our private browsing philosophy. Two is the > other cases where changes to the LocalStorage object won't actually be saved > to disk (such as the "no database filename" or "0 quota") issues. > > I completely understand that Chromium has a different philosophy with > Incognito mode versus Safari's private browsing. But I think the "we should > never pretend to store data that we have no intention to store" philosophy > is a more fundamental WebKit issue. WebKit shouldn't lie. :) > > ~Brady > > > > >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
