Oh, and I forgot to mention: given your philosophy on private browsing and the potential for session data being written to disk in the future, I think it's reasonable to disallow writing to SessionStorage while in private browsing mode. I'll add a comment in the StorageArea.cpp code explaining this decision.
J On Wed, May 20, 2009 at 2:01 PM, Jeremy Orlow <jor...@chromium.org> wrote: > 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 <beid...@apple.com> 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 webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
