[design doc] Better session restore

[Jochen Eisinger]

Rationale

When restarting Chrome, depending on the reason for the restart (e.g. for an update), the user might not expect to lose his or her session state (e.g. login cookies). We could do better by recording more session state. However, we will always just record a subset of the full state. It’s e.g. not feasible to persist the complete JavaScript state of a running renderer. 

When to persist session state

The main focus here is to make the forced restarts (for applying critical security updates) and crashes less annoying. However, we could also do this when the user checked the option to reopen the pages that were open last on start.

What new stuff to persist

I propose to persist the following session state (in addition to what is already persisted now):

• Session cookies
• Don’t apply “delete on shutdown” rules on restarts for updates
• window.sessionStorage
• POST data of navigation history

Similar to what Firefox does, I propose to apply this to http and https sites. I propose to implement this by a number of new SessionCommands.

Incognito

For now, we won’t persist any state about incognito windows. Rationale: Incognito mode wasn’t incongito anymore, if we’d write enough state to disk to restore it after a restart.

There’s a certain tradeoff between privacy and usability here. Users might be outraged if after a forced restart their incognito windows are lost. On the other hand, we don’t want to persist any information about incognito sessions.

Notifications

Since the restore won’t work in 100% of all possible cases, we might want to show a notification to the user about what happened and why, maybe pointing them at a help center article.

[Chris Bentzel]

On Wed, Nov 9, 2011 at 3:24 PM, Jochen Eisinger <joc...@chromium.org> wrote:

• POST data of navigation history

Are you going to prompt user for re-POST of data at session restore?  

[Charlie Reis]

Very nice-- I'd love to see session restore handle more types of state.

On Wed, Nov 9, 2011 at 12:24 PM, Jochen Eisinger <joc...@chromium.org> wrote:

Rationale

When restarting Chrome, depending on the reason for the restart (e.g. for an update), the user might not expect to lose his or her session state (e.g. login cookies). We could do better by recording more session state. However, we will always just record a subset of the full state. It’s e.g. not feasible to persist the complete JavaScript state of a running renderer. 

When to persist session state

The main focus here is to make the forced restarts (for applying critical security updates) and crashes less annoying. However, we could also do this when the user checked the option to reopen the pages that were open last on start.

What new stuff to persist

I propose to persist the following session state (in addition to what is already persisted now):

• Session cookies
• Don’t apply “delete on shutdown” rules on restarts for updates
• window.sessionStorage
• POST data of navigation history

Similar to what Firefox does, I propose to apply this to http and https sites. I propose to implement this by a number of new SessionCommands.

Incognito

For now, we won’t persist any state about incognito windows. Rationale: Incognito mode wasn’t incongito anymore, if we’d write enough state to disk to restore it after a restart.

There’s a certain tradeoff between privacy and usability here. Users might be outraged if after a forced restart their incognito windows are lost. On the other hand, we don’t want to persist any information about incognito sessions.

Would it be worthwhile to try to store the incognito state in another process while Chrome restarts?  That would keep it in memory and not persistent state, but it would require some format that is reasonably stable across Chrome versions.  (I suppose it also wouldn't work for ChromeOS restarts, which restart the whole machine.)

Charlie

 

Notifications

Since the restore won’t work in 100% of all possible cases, we might want to show a notification to the user about what happened and why, maybe pointing them at a help center article.

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

[Ben Goodger (Google)]

We should make sure we're targeting the biggest problem that people are having with session restore before we make it more complicated by persisting more stuff: it's too slow.

Specifically:

- I end up restoring a session of 4-5 windows some with 10-15 tabs each.

- Chrome browser window then takes longer than normal to come up, then:

- I end up with 40-odd tabs sitting there blank (white) with spinners, for what seems like minutes and minutes.

Jim had some great new tools for diving into the jank here. I also think there may be some smarter prioritization that could be done.

Can we fix this first?

-Ben

On Wed, Nov 9, 2011 at 12:24 PM, Jochen Eisinger <joc...@chromium.org> wrote:

--

[Jochen Eisinger]

Probably, yes. That's also what happens if you restore a tab that requires http auth

[Jochen Eisinger]

On Wed, Nov 9, 2011 at 9:51 PM, Charlie Reis <cr...@chromium.org> wrote:

Very nice-- I'd love to see session restore handle more types of state.

On Wed, Nov 9, 2011 at 12:24 PM, Jochen Eisinger <joc...@chromium.org> wrote:

Rationale

When restarting Chrome, depending on the reason for the restart (e.g. for an update), the user might not expect to lose his or her session state (e.g. login cookies). We could do better by recording more session state. However, we will always just record a subset of the full state. It’s e.g. not feasible to persist the complete JavaScript state of a running renderer. 

When to persist session state

The main focus here is to make the forced restarts (for applying critical security updates) and crashes less annoying. However, we could also do this when the user checked the option to reopen the pages that were open last on start.

What new stuff to persist

I propose to persist the following session state (in addition to what is already persisted now):

• Session cookies
• Don’t apply “delete on shutdown” rules on restarts for updates
• window.sessionStorage
• POST data of navigation history

Similar to what Firefox does, I propose to apply this to http and https sites. I propose to implement this by a number of new SessionCommands.

Incognito

For now, we won’t persist any state about incognito windows. Rationale: Incognito mode wasn’t incongito anymore, if we’d write enough state to disk to restore it after a restart.

There’s a certain tradeoff between privacy and usability here. Users might be outraged if after a forced restart their incognito windows are lost. On the other hand, we don’t want to persist any information about incognito sessions.

Would it be worthwhile to try to store the incognito state in another process while Chrome restarts?  That would keep it in memory and not persistent state, but it would require some format that is reasonably stable across Chrome versions.  (I suppose it also wouldn't work for ChromeOS restarts, which restart the whole machine.)

I think that's beyond the scope of a first version

-jochen

[Jochen Eisinger]

On Wed, Nov 9, 2011 at 9:56 PM, Ben Goodger (Google) <b...@chromium.org> wrote:

We should make sure we're targeting the biggest problem that people are having with session restore before we make it more complicated by persisting more stuff: it's too slow.

I agree with you that session restore is sometimes incredible slow.

However, we plan to force restart chrome for critical updates, and e.g. deleting browsing data on shutdown during such a forced restart will gives us a bunch of very unhappy users, so I'd argue that it's also important to tackle this problem.

wdyt

-jochen

[Ojan Vafai]

Also, at least on Mac, when you're in this situation, you can't load new pages and often doing anything (e.g. creating a new tab) brings up the rainbow wheel.

[Nicolas Zea]

What about webkit data, e.g. filled in form information, scroll position, etc.? I've thought about attempting to sync this as part of tab sync, but it's currently just a wish-list idea. Especially for the case of forced restarts or crashes, I hate having my half-filled form completely lost.

Though this might require migrating from an incremental session command approach to one more based on snapshots?

-Nicolas

[Peter Kasting]

On Wed, Nov 9, 2011 at 12:24 PM, Jochen Eisinger <joc...@chromium.org> wrote:

However, we could also do this when the user checked the option to reopen the pages that were open last on start.

Yes please! 

On Wed, Nov 9, 2011 at 9:56 PM, Ben Goodger (Google) <b...@chromium.org> wrote:

We should make sure we're targeting the biggest problem that people are having with session restore before we make it more complicated by persisting more stuff: it's too slow.

Indeed, we get dinged on this in public reviews sometimes.  This is something worth spending time on (dunno what bugs are already on file).

On Wed, Nov 9, 2011 at 1:09 PM, Jochen Eisinger <joc...@chromium.org> wrote:

However, we plan to force restart chrome for critical updates, and e.g. deleting browsing data on shutdown during such a forced restart will gives us a bunch of very unhappy users, so I'd argue that it's also important to tackle this problem.

I agree that if we are going to force-restart Chrome, we should implement your proposed session restore changes first, even if we do it before improving the speed of session restore, as dataloss problems > slowdown problems.

On Wed, Nov 9, 2011 at 3:00 PM, Nicolas Zea <z...@chromium.org> wrote:

What about webkit data, e.g. filled in form information, scroll position, etc.?

A lot of this stuff is already persisted in the case where you "undo close tab".  I don't know if it's dropped for session restore.  If so, this would be a good candidate to not drop (but my random guess would be that we already restore as much as we can).

PK

[Ojan Vafai]

The advantage of fixing the performance first is that you won't accidentally make things worse or make it harder to fix the performance later. Right now, if you do something fundamentally slow in the new code, then you won't notice because the current version is so busted.

[Ilya Sherman]

On Wed, Nov 9, 2011 at 3:07 PM, Peter Kasting <pkas...@chromium.org> wrote:

What about webkit data, e.g. filled in form information, scroll position, etc.?

A lot of this stuff is already persisted in the case where you "undo close tab".  I don't know if it's dropped for session restore.  If so, this would be a good candidate to not drop (but my random guess would be that we already restore as much as we can).

If I recall correctly, filled in form information is saved both for "undo close tab" and for session restore, but it lags considerably behind realtime -- on the order of several minutes or so.

[Scott Violet]

Indeeed. And there are limits to what it can store.

-Scott

[Bernhard Bauer]

On Thu, Nov 10, 2011 at 00:07, Peter Kasting <pkas...@chromium.org> wrote:
> On Wed, Nov 9, 2011 at 12:24 PM, Jochen
> Eisinger <joc...@chromium.org> wrote:
>>
>> However, we could also do this when the user checked the option to reopen
>> the pages that were open last on start.
>
> Yes please!

No please :) A browser restart is an immediate thing, but there could
be an arbitrarily long time between closing the browser and starting
it again, so users could be very surprised to see that their sessions
from X (hours, days) ago are still active. Also, how does this
interact with the "clear cookies and site data at browser exit"
checkbox? Are we just going to ignore it if reopen tabs is checked?

Bernhard.

>> On Wed, Nov 9, 2011 at 9:56 PM, Ben Goodger (Google) <b...@chromium.org>
>> wrote:
>>>
>>> We should make sure we're targeting the biggest problem that people are
>>> having with session restore before we make it more complicated by persisting
>>> more stuff: it's too slow.
>
> Indeed, we get dinged on this in public reviews sometimes.  This is
> something worth spending time on (dunno what bugs are already on file).
> On Wed, Nov 9, 2011 at 1:09 PM, Jochen Eisinger <joc...@chromium.org> wrote:
>>
>> However, we plan to force restart chrome for critical updates, and e.g.
>> deleting browsing data on shutdown during such a forced restart will gives
>> us a bunch of very unhappy users, so I'd argue that it's also important to
>> tackle this problem.
>
> I agree that if we are going to force-restart Chrome, we should implement
> your proposed session restore changes first, even if we do it before
> improving the speed of session restore, as dataloss problems > slowdown
> problems.
> On Wed, Nov 9, 2011 at 3:00 PM, Nicolas Zea <z...@chromium.org> wrote:
>>
>> What about webkit data, e.g. filled in form information, scroll position,
>> etc.?
>
> A lot of this stuff is already persisted in the case where you "undo close
> tab".  I don't know if it's dropped for session restore.  If so, this would
> be a good candidate to not drop (but my random guess would be that we
> already restore as much as we can).
> PK
>

[Peter Kasting]

On Thu, Nov 10, 2011 at 1:31 AM, Bernhard Bauer <bau...@google.com> wrote:

On Thu, Nov 10, 2011 at 00:07, Peter Kasting <pkas...@chromium.org> wrote:
> On Wed, Nov 9, 2011 at 12:24 PM, Jochen
> Eisinger <joc...@chromium.org> wrote:
>>
>> However, we could also do this when the user checked the option to reopen
>> the pages that were open last on start.
>
> Yes please!

No please :) A browser restart is an immediate thing, but there could
be an arbitrarily long time between closing the browser and starting
it again, so users could be very surprised to see that their sessions
from X (hours, days) ago are still active.

The entire point of "show my windows and tabs from last time" is that whenever I restart my browser I want it to continue where I left off, time irrelevant.  This option is not the default setting, if I change to it I know what I'm asking for.

Sites that care about actual timeouts already deal with this directly on the site, e.g. banks log you out after 20 minutes of inactivity.

 

Also, how does this
interact with the "clear cookies and site data at browser exit"
checkbox? Are we just going to ignore it if reopen tabs is checked?

No, clearly that checkbox should take priority and we should delete all site data on browser exit.

PK

[Ed Swierk]

A number of users have been surprised to find that Chrom{e,ium} no longer adheres to the longstanding convention that closing all browser windows clears session cookies when "Continue where I left off" is enabled.

http://code.google.com/p/chromium/issues/detail?id=128513

Any comments on the suggestion that restart-to-update be treated as a distinct case from closing all windows explicitly?

--Ed

[Peter Kasting]

On Thu, Jun 21, 2012 at 5:37 AM, Ed Swierk <esw...@gmail.com> wrote:

A number of users have been surprised to find that Chrom{e,ium} no longer adheres to the longstanding convention that closing all browser windows clears session cookies when "Continue where I left off" is enabled.

http://code.google.com/p/chromium/issues/detail?id=128513

Any comments on the suggestion that restart-to-update be treated as a distinct case from closing all windows explicitly?

I tried to write a detailed set of comments on that bug.

PK

[Jesper]

Peter, I think your comment 39 on Bug 128513 ( http://code.google.com/p/chromium/issues/detail?id=128513#c39 ) is actually a good example of how you "cavalierly disregard" the users. You just write an arrogant comment and then close the bug so nobody can say anything more. You are simply closing your ears to constructive criticism, and that is a very annoying and destructive way to behave. You are definitely not improving Chrome in that way. And you are not "getting on with things" in that way. On the contrary.

I have been in love with Chrome since the beginning, and I have caused a lot of non-technical people to switch to Chrome. But this behaviour from your side by first making serious security problems in Chrome without saying anything about it to the users, and then ALSO being arrogant about it when you are receiving constructive criticism for it is plain stupid! And I am losing my faith in Chrome and will no longer recommend people to switch to Chrome. It seems like Chrome is not really under control anymore when things like this can happen. And when you don't even listen to what people are saying! Jesus! Wake up!

The issue was actually created as a bug because we are several clever people that consider it to be a bug, even if you made it deliberately. Your way of acting towards this is not constructive and you are not "getting on with things" by ignoring what several users have spend hours and hours to try to describe and solve. You are not listening, and that is not wise.

I advice you to stop the arrogance and start listening! There is a reason for what we are writing. 

And the issue tracking system is definitely a relevant place to discuss a problem like that. I still believe it is a serious issue in Chrome. And closing the issue with an arrogant WONTFIX and an arrogant comment does not solve the issue. The issue is still there and is very real.

Jesper

[Peter Kasting]

On Thu, Jun 21, 2012 at 2:27 PM, Jesper <jesper...@gmail.com> wrote:

You just write an arrogant comment and then close the bug so nobody can say anything more.

The bug tracker is not the right place for people to debate behavior to begin with.  That's what other forums are for.  I'm not trying to halt debate, I'm trying to get people to take it somewhere appropriate.

To some degree, the bug tracker is _inherently_ arrogant.  You tell us you think there's a bug, then we decide what we're going to do about it.  That's our job as Chrome designers: to consider the evidence and then make a call.  I don't think the resulting product would be good if we didn't believe we could make the right decisions.

We're far from "not listening".  We understand what people have said, and we've noted both some reasons for our decision as well as some possible alternatives for people who don't like it.  If you still don't agree, or if you want to tell all your friends that Chrome is a horrible browser, you have the complete right to do so.  But you don't get to claim that we're not listening to you just because we're not making the decision the way you want even after you've given us feedback.

I'm sorry you think we're ignoring real problems here, but the truth is, a lot of the time reasonable people can disagree on what the most desirable outcome for some situation is.  No behavior in this case is without its drawbacks, and right now, our considered decision is that our current behavior is better on the whole for our userbase.  I think there are a variety of existing tools that can deal with the majority of the exceptions.  But I also want people to be able to do whatever they'd like, which is why I've been so vocal about trying to make sure it's possible to get the precise old behavior via an extension.  Ask yourself, if you aren't satisfied with all this, what would you be satisfied with, outside of us simply reversing our decision?  If the answer is "nothing", then aren't your position and ours equally "arrogant" insofar as they both believe they're the right thing to do by default?

PK

[Bart Wood]

In my opinion, this is a major security hole with Chrome.  

I just logged into 3 banking websites and then closed chrome - then I reopened chrome and used the history to click on links to re-open the banking applications with full access. 

This is crazy - I wonder how many people will be "hacked" by such a simple mechanism on public terminals... 

The 3 banking websites I used provide prominent log out mechanisms as well as auto-logout timer based mechanisms.  People forget to log out or they have been trained to think that the browser will reset when they close - browsers have worked like that for a long time.  Timers don't help - they are unrelated to closing the browser which is when the user normally thinks the session has been cleared.

What do you think the term "session" normally implies??  Isn't a "session" normally when a user opens an application until the time they close the application??  For chrome, session is now basically forever??

I have sent emails to the 3 banking web sites showing the security vulnerability and how Internet Explorer is more secure - I'm interested to see if their responses are as unconcerned as the chrome developers are...  I wonder if I start seeing a "This browser is unsupported" message...

[Ed Swierk]

Since this change, a number of off-the-beaten-track web sites are
still giving inaccurate advice about session cookies, e.g.
http://www.google.com/goodtoknow/data-on-the-web/cookies/

Sadly, "revisit every site you might have logged into, and find and
click the logout button on each one" is a poor substitute.

--Ed

[Bart Wood]

Good link Ed.  It's funny that the Google web site you link states

  " Some cookies will expire when you close your browser."  

[Kevin Hamilton]

I know this is an old discussion, but I just tripped over this feature for the first time today. Wasted one hour of my work day researching the "problem" with the client's website and left an upset Account Executive and I'm not sure the client is pleased in the end, either.

I just wanted to point out that you have some advocacy work to do.  Here's 11 million websites you can start with:

https://www.google.com/search?q=Session+Cookies+are+stored+only+temporarily+during+a+browsing+session+and+are+deleted+from+the+user’s+device+when+the+browser+is+closed

[Peter Kasting]

On Wed, Mar 13, 2013 at 8:15 AM, Kevin Hamilton <kevin.h...@gmail.com> wrote:

I know this is an old discussion, but I just tripped over this feature for the first time today. Wasted one hour of my work day researching the "problem" with the client's website and left an upset Account Executive and I'm not sure the client is pleased in the end, either.

I'm not sure what you're reporting.  Are you saying that session cookies are not properly being preserved when a user has the browser set to restore their previous windows and tabs?  Or are you just saying that some websites say that browsers won't always preserve session cookies, or something?

If the latter, the I'm not convinced it's really the Chrome team's mandate to go find and fix external websites' previous comments when we change our behavior...

PK 

[PhistucK]

I think Kevin was just being sarcastic in order to say that the decision to keep session cookies is against the standard assumption of people, as taught by millions of websites.

☆PhistucK

--

[authen...@gmail.com]

Sorry to resurrect an old, controversial topic but, as I've just discovered this issue I was looking for an explanation for the behaviour.

Having read through all the posts and not seeing it mentioned anywhere, I wondered anybody has considered, and would it not be better design for "Continue where I left off", to only keep the session cookies that belong to the open tabs and not the session cookies for every site that has been visited which has set a session cookie? Is this not what the whole thing is about - only restoring the tabs that are open?

The problem as I see it now is: When the "Continue where I left off" box is ticked, session cookies are kept forever even over multiple restarts (if the user does not log out or the site does not set them to timeout) which means that weeks, months or even years away from the original session, a session may still be active. I'd find that very confusing and potentially hazardous (as I could have long forgotten that I was signed into a particular site).

Is there anything that would prevent restoring only the open tabs' session cookies and not all session cookies being a better solution?

I'm not after resurrecting this debate - I am just asking for yes or no to the above question (and perhaps a brief explanation, if not - why not?)

Thanks.

[PhistucK]

Let us assume you logged into Facebook and had other open tabs.

You closed Facebook, but some other open tab had a small Facebook <iframe> (say, a Facebook Like button at its footer), so the Facebook session cookie is saved.

(Replace Facebook with any other website)

Would that be fine with you?

I think it can be very confusing, so it would better be all or nothing.

Besides, the name of the option reflects exactly what it is doing. You continue exactly where you left off - be it open or closed. It is the exact same session.

☆PhistucK

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Peter Kasting]

On Sat, Feb 1, 2014 at 5:12 AM, <authen...@gmail.com> wrote:

Having read through all the posts and not seeing it mentioned anywhere, I wondered anybody has considered, and would it not be better design for "Continue where I left off", to only keep the session cookies that belong to the open tabs and not the session cookies for every site that has been visited which has set a session cookie? Is this not what the whole thing is about - only restoring the tabs that are open?

That might work for first-party cookies, but what about sites which use third-party cookies?

Is there anything that would prevent restoring only the open tabs' session cookies and not all session cookies being a better solution?

Another problem: if I can hit ctrl-shift-t to resurrect a closed tab into a particular state, then if I restart the browser with "restore my session" on, I would still expect ctrl-shift-t to restore the same tab to the same state.  I would imagine your proposal would break this.

PK