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
