On Tue, Apr 7, 2009 at 8:24 PM, Brady Eidson <[email protected]> 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.
