<div class="gmail_quote">On Tue, Apr 7, 2009 at 8:39 PM, timeless <span dir="ltr"><<a href="mailto:timeless@gmail.com">timeless@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2009/4/8 Jeremy Orlow <<a href="mailto:jorlow@google.com">jorlow@google.com</a>>:<br>
<div class="im">> If a user is in private browsing mode typing up a message, they should<br>
> definitely not expect it to be there when they leave such a mode. If they<br>
> do expect it to be there, then they really wanted multiple profiles.<br>
> I know it's bad to make presumptions, but I just can't see any web developer<br>
> depending on the localStorage or database API as anything more than a cache.<br>
> When a user is on a web application, they expect to be able to go to<br>
> another computer and access that information.<br>
<br>
> Also note that, if you assume these APIs are anything other than fairly<br>
> permanent caches, then your browser had better have a good story for when<br>
> the user upgrades/downgrades their browser or even switches computers. This<br>
> feels like we're going back to the POP3 era of email. :-)<br>
<br>
</div>speaking of which.<br>
<br>
Is there any API in localStorage to enable the browser to tell the web<br>
app that it wants to reduce the size of its cache, to e.g. 0?</blockquote><div><br></div><div>There's the window.onstorage event which fires whenever there's a change to localStorage. But what do you do if the user doesn't have any windows open on that page when the size is reduced to 0?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Because if we had an API which would let the browser tell an app "my<br>
user has decided to reduce your available space to <x>" and the user<br>
picks 0, then the app can choose to flush all of its pending data.<br>
<br>
And private browsing could use that API at the end. Sadly, it might be<br>
worth giving the user some indication of how much data has been stuck<br>
in private browsing by a given web page.</blockquote><div><br></div><div>This is a very interesting suggestion. When in private mode, the browser could do an implicit .clear() and smart applications could pick up on this. Unfortunately, most apps would probably just be confused by this.</div>
<div><br></div><div>I'd suggest adding a new event handler, but that still wouldn't solve the problem of the user not being at the site.</div><div><br></div><div>Maybe something could be added to the spec with respect to App Cache. For example, an app in app cache could define something to be run when it's being evicted from storage? Of course, this could have some interesting/negative security implications. In addition, if the user is off line, they're completely screwed.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I'd suggest 3 w/ a thing to flush stuff. Preferably flushing as soon<br>
as the user closes the last page of a site (i.e. before the user<br>
closes the last page in their private browsing session). It should<br>
probably be in the form of a visible opt in bit:<br>
<br>
This site is using <counter> MB of data. When I leave it, I <[x] do<br>
not> want the site to know that its data is being removed. [?] <hide<br>
banner><br>
<div class="im"><br>
1 - Disable LocalStorage completely when private browsing is on.<br>
Remove it from the DOM completely.<br>
<br>
</div>Many sites will just assume that they know a given useragent supports<br>
localstorage, so they'll be surprised and break.<br>
This will mean that a user can't use certain sites.</blockquote><div><br></div><div>For sure.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
2 - Disable LocalStorage mostly when private browsing is on. It<br>
exists at window.localStorage, but is empty and has a 0-quota.<br>
<br>
</div>This will enable sites to know that the user is browsing in private,<br>
which is probably also a violation of the user's trust model.<br>
If I were to be browsing in private, I wouldn't want most sites to<br>
know that I'm doing this (which is why the banner i mention above must<br>
give the user the choice).</blockquote><div><br></div><div>Is this a real concern? Someone threw out the idea of explicitly making this data available to at least extensions and maybe even websites. I think it might help sites act as the user would want. In addition, websites know you've visited them. I'm not sure if knowing that it was in private mode really changes things much.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">3 - Slide a "fake" LocalStorage object in when private browsing is<br>
enabled. It starts empty, changes to it are successful, but it is<br>
never written to disk. When private browsing is disabled, all changes<br>
to the private browsing proxy are thrown out.</div></blockquote><div><br></div><div>I'll point out that this is the "I'm at a public workstation and wiped all data when I was done" model, which I believe is the right way to think of it.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">4 - Cover the real LocalStorage object with a private browsing layer.<br>
It starts with all previously stored contents. Any changes to it are<br>
pretended to occur, but are never written to disk. When private<br>
browsing is disabled, all items revert to the state they were in when<br>
private browsing was enabled and writing changes to disk is<br>
re-enabled.<br>
<br>
</div>This means the site will know who you are (on average), and is almost<br>
certainly never what the user wants. If the user wants to tell the<br>
site who they are, then the user can log in after enabling private<br>
browsing.<br>
<div class="im"><br>
5 - Treat LocalStorage as read-only when private browsing is on. It<br>
exists, and all previously stored contents can be retrieved. Any<br>
attempt to setItem(), removeItem(), or clear() fail.<br>
<br>
</div>This acts like 4 and isn't helpful either.</blockquote></div>