[webkit-dev] DOM Storage and private browsing
I'm pretty confused by the policy decisions in DOM Storage with respect to private browsing. 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. 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. 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. 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 sorry if these questions sound antagonistic, but I just want to understand what the overall way of thinking/vision is here. Just to be clear, I understand that Safari's private browsing has a different philosophy from Chromium's incognito mode. 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. :-) Jeremy [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/019238.html [2] http://svn.webkit.org/repository/webkit/trunk/WebCore/storage/LocalStorage.cpp [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-April/thread.html#19238 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] DOM Storage and private browsing
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
Re: [webkit-dev] DOM Storage and private browsing
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
Re: [webkit-dev] DOM Storage and private browsing
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.
