[whatwg] Private browsing vs. Storage and Databases

[Jeremy Orlow]

On Tue, Apr 7, 2009 at 8:39 PM, timeless <timeless at gmail.com> wrote:

> 2009/4/8 Jeremy Orlow <jorlow at google.com>:
> > 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.
> > 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.
>
> > 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.  :-)
>
> speaking of which.
>
> Is there any API in localStorage to enable the browser to tell the web
> app that it wants to reduce the size of its cache, to e.g. 0?


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?


> Because if we had an API which would let the browser tell an app "my
> user has decided to reduce your available space to <x>" and the user
> picks 0, then the app can choose to flush all of its pending data.
>
> And private browsing could use that API at the end. Sadly, it might be
> worth giving the user some indication of how much data has been stuck
> in private browsing by a given web page.


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.

I'd suggest adding a new event handler, but that still wouldn't solve the
problem of the user not being at the site.

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.

I'd suggest 3 w/ a thing to flush stuff. Preferably flushing as soon
> as the user closes the last page of a site (i.e. before the user
> closes the last page in their private browsing session). It should
> probably be in the form of a visible opt in bit:
>
> This site is using <counter> MB of data. When I leave it, I <[x] do
> not> want the site to know that its data is being removed. [?] <hide
> banner>
>
> 1 - Disable LocalStorage completely when private browsing is on.
> Remove it from the DOM completely.
>
> Many sites will just assume that they know a given useragent supports
> localstorage, so they'll be surprised and break.
> This will mean that a user can't use certain sites.


For sure.


> 2 - Disable LocalStorage mostly when private browsing is on.  It
> exists at window.localStorage, but is empty and has a 0-quota.
>
> This will enable sites to know that the user is browsing in private,
> which is probably also a violation of the user's trust model.
> If I were to be browsing in private, I wouldn't want most sites to
> know that I'm doing this (which is why the banner i mention above must
> give the user the choice).


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.


> 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.
>

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.


> 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.
>
> This means the site will know who you are (on average), and is almost
> certainly never what the user wants. If the user wants to tell the
> site who they are, then the user can log in after enabling private
> browsing.
>
> 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.
>
> This acts like 4 and isn't helpful either.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090407/5021347c/attachment.htm>