<div class="gmail_quote">2009/4/7 Jonas Sicking <span dir="ltr"><jonas@sicking.cc></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">
2009/4/7 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <<a href="mailto:ifette@google.com">ifette@google.com</a>>:<br>
> 2009/4/7 Jonas Sicking <jonas@sicking.cc><br>
>><br>
>> 2009/4/7 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <<a href="mailto:ifette@google.com">ifette@google.com</a>>:<br>
>> > In Chrome/Chromium, "incognito" mode is basically a new profile that is<br>
>> > in<br>
>> > memory (plus or minus... the cache will never get written out to disk,<br>
>> > although of course the memory pages could get swapped out and hit the<br>
>> > disk<br>
>> > that way...). The implication is that, for many of these features,<br>
>> > things<br>
>> > could just naturally get handled. That is, whilst the session is active,<br>
>> > pages can still use a database / local storage / ... / and at the end of<br>
>> > the<br>
>> > session, when that profile is deleted, things will go away. I personally<br>
>> > like that approach, as there may be legitimate reasons to want to use a<br>
>> > database even for just a single session. (Perhaps someone wants to edit<br>
>> > a<br>
>> > spreadsheet and the spreadsheet app wants to use a database on the<br>
>> > client as<br>
>> > a backing store for fast edits, I don't know...). I just don't like the<br>
>> > idea<br>
>> > of saying "Sorry, incognito/private/... means a class of pages won't<br>
>> > work"<br>
>> > if there's no reason it has to be that way.<br>
>> > In short, I would prefer something closest to Option 3. It lets pages<br>
>> > just<br>
>> > work, but respects the privacy wishes of the user. (AppCache /<br>
>> > persistent<br>
>> > workers are the one exception where I think Option3 doesn't apply and we<br>
>> > need to figure something out.)<br>
>><br>
>> I do agree that there's still need for storing data while in private<br>
>> browsing mode. So I do think it makes a lot of sense for<br>
>> .sessionStorage to keep working.<br>
>><br>
>> But I do have concerned about essentially telling a website that we'll<br>
>> store the requested data, only to drop it on the floor as soon as the<br>
>> user exits private browsing mode (or crashes).<br>
>><br>
>> / Jonas<br>
><br>
> Doesn't the website have to handle that anyways? I mean, I assume that all<br>
> the browsers are going to allow users some way to "manage" this stuff, much<br>
> like cache/cookies - e.g. you have to assume that at some point in time the<br>
> user is going to blow you away. (Especially on mobile devices where space is<br>
> more of a premium...)<br>
<br>
</div></div>It's different in that the user managing his data is an explicit<br>
action on the users part. I.e. the user has to go to a place in the UA<br>
and click a 'clear data' button. Users are more likely to expect that<br>
this results in a half composed message disappearing than if the same<br>
thing happens when exiting private browsing mode.<br>
<br>
I think :)</blockquote><div><br></div><div>If a user is in private browsing mode typing up a message, they should definitely not expect it to be there when they leave such a mode. If they do expect it to be there, then they really wanted multiple profiles.</div>
<div><br></div><div>I know it's bad to make presumptions, but I just can't see any web developer depending on the localStorage or database API as anything more than a cache. When a user is on a web application, they expect to be able to go to another computer and access that information.</div>
<div><br></div><div>Also note that, if you assume these APIs are anything other than fairly permanent caches, then your browser had better have a good story for when the user upgrades/downgrades their browser or even switches computers. This feels like we're going back to the POP3 era of email. :-)</div>
</div>