- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 7 Apr 2009 20:50:22 -0400
On Tue, Apr 7, 2009 at 8:24 PM, Brady Eidson <beidson at apple.com> wrote: > 1 - Disable LocalStorage completely when private browsing is on. ?Remove it > from the DOM completely. > 2 - Disable LocalStorage mostly when private browsing is on. ?It exists at > window.localStorage, but is empty and has a 0-quota. > 3 - Slide a "fake" LocalStorage object in when private browsing is enabled. > ?It starts empty, changes to it are successful, but it is never written to > disk. ?When private browsing is disabled, all changes to the private > browsing proxy are thrown out. > 4 - Cover the real LocalStorage object with a private browsing layer. ?It > starts with all previously stored contents. ?Any changes to it are pretended > to occur, but are never written to disk. ?When private browsing is disabled, > all items revert to the state they were in when private browsing was enabled > and writing changes to disk is re-enabled. > 5 - Treat LocalStorage as read-only when private browsing is on. ?It exists, > and all previously stored contents can be retrieved. ?Any attempt to > setItem(), removeItem(), or clear() fail. How are cookies handled right now? Surely the issues should be pretty much the same? > Option 3 is simple to implement and option 4 would difficult to implement > efficiently. ?Both would lead to bizarre behavior where data that the > application thought was saved really wasn't. I certainly can't think of how 3 could ever cause a problem. It should be the same as the user just logging in from a computer they haven't used before, shouldn't it? I'm not certain about 4. What would be a concrete case where 4 would break, but normal use from multiple computers would not? I don't think 1, 2, or 5 are good ideas, since they make localStorage semi-usable at best when privacy mode is enabled.
Received on Tuesday, 7 April 2009 17:50:22 UTC