Talk:Session Restore

Tab Mix?

I'm not sure if regular old me is allowed to edit the main page even for this, so I'm just going to mention it here. AFAIK, it's Tab Mix Plus that does session saving and whatnot, not regular Tab Mix. -- Matt Nordhoff (talk) 00:34, 9 Feb 2006 (PST)

Security of saved data

Just as a precaution, the data that is saved in order to restore the session should be safe from potential reading. For example, you have several tabs open and some form information filled in on one, including your banking details. The session saver saves these details in order to restart Firefox, but afterwards when the user is finished and they close the browser, is this information left laying about on the hard disk, that could potentially be stolen by rogue software or exploits.

Also what would happen if after a restart by session saver, you cleared the history with Ctrl+Alt+Del. Even though the history would be removed from the browser cache, would the session saver cache be removed also to ensure that URLs and Form text were not left behind?

Kroc 01:32, 9 Feb 2006 (PST)

A robust solution would be that encryption was performed with a key that was created at random each time a session save occurred, and kept in config, or otherwise in the same manner all passwords are kept. It's not fully secure, but provided it's read-only and not read-write, it covers the basics: a session can be re-read by FF, the encryption key can't easily be pushed into FF by a user to read an old session, and when the key is overwritten at the point a new session is saved, the old key becomes permanently unreadable.

The algorithm I'm thinking goes something like this:

Session files have timestamp or incremental ID in their filename - "SavedSession03102006054627"
The ID and encryption key pair for the last <n> saved sessions is held. ("n", so that users can keep up to 3 or 5 previous state backups in case one or more become corrupted in a crash)
On restart, FF identifies the most recent saved session that it can decrypt and which has full integrity, and works with that backup. It also deletes any that it couldn't decrypt or which appear corrupted, and any key entries that don't appear to relate to actual valid saved session files.
When a new session backup is made, FF creates a random 256 bit key, encrypts the backup with that, and saves the new backup timestamp/decryption key pair for future use.
When the backup is confirmed saved, then if there are more than <n> backups held, the file and key for the oldest one(s) are deleted.
If the key file ID and key are held in a place the user can see within FF, there is code to prevent copy or pasting of that data.

I don't think you can do much better. Any code FF used to access the saved states on restart could be emulated by a rogue user or software. What this does is ensure that the files by themselves are harmless, that one key (if obtained) does not give access to any older backed up session files, and that a user cannot just copy and use the key to open a file. Any better security would require a user password on starting FF or similar, as well as all FF saved data and cache to be encrypted; it can't easily be done by FF alone.

As an amateur newcomer to FF this would seem to cover many of the bases, and deal with the main problems identified above. Foxxen2 08:57, 30 March 2006 (PST)

About the password, that's not a bad idea! Assuming secret data will be sent over a secure connection, firefox could, when the users exits with a https site open, ask if it has to encrypt the data, and if so, ask to give a password to reopen it. If the password can't be supplied the encrypted data will be lost, which will mostly not be a serious problem.

If a website doesn't use https, it is open to much more ways to get the information, so I don't think it is firefox's task to protect the data in that case.

--FrederikVds 15:04, 6 April 2006 (PDT)

Restoring after voluntary exit not optional

The main page currently (2006-02-13) lists this as an optional (P2, FF3 or left to extensions) feature:

 "Allow session restoration after voluntary application closure"

From my point of view, this is not an optional feature. The only time I ever make Firefox exit is to work around some bug (e.g., using too much memory, incapable of handling new extensions without restart, etc.). Otherwise my invocation of Firefox would run forever. Thus, for me, every manual exit of Firefox is undesired and equivalent to a forced crash. Generally I have dozens of tabs representing weeks or months of work that I definitely do not want to lose! If this feature was missing I would have to continue using SessionSaver, which would be undesirable.

Joe --Sllewbj 05:27, 13 Feb 2006 (PST)

Agree 100%! I came to SessionSaver for the crash recovery, but stayed for the non-crash session saving. It's incredibly useful when having to reboot your OS (e.g. because you installed a new piece of software, or applied OS or third-party software patches), or when having to shut down your laptop because you're on the go, to be able to save your work in Firefox the same way you can in document-oriented software applications, and be able to pick right back up where you left off after you've restarted and logged back in. It would be silly not to implement this and would just mean lots of people would be forcibly killing their own browsers in order to save their sessions.

-- Dan Harkless, 23:17, 16 Feb 2006 (PST)

Agreed this is the right default but there still needs to be a mechanism to bypass restoration in case the browser is crashing or just browsed p0rn at work accidentally. SessionSaver has a detection for a crashing set for the first purpose. For the second, you might check for holding down Shift during startup, like a Macintosh for not loading extensions.

--BillMcGonigle 10:48, 21 Feb 2006 (PST)

DOM restore vs. URL restore

What if we serialized and restored the current DOM (including event handlers and such) for each tab, instead of storing the URLs? That would solve all of the problems with reloading of non-idempotent GETs, as well as POST cases, and properly restore the state of apps like gmail. (If we don't do this, then we need to be very careful about restoring form state against a possibly-different form when we restore the session and reload the page. There have been attacks related to changing an input from type=hidden to type=file on reload which I think we would prefer to not revisit.)

Shaver 09:33, 13 Feb 2006 (PST)

I agree that a DOM restore would be preferrable, as otherwise all POSTed pages would be lost. Also a DOM restore would be clearly faster if you have a slow internet connection.

--FrederikVds 16:19, 18 Mar 2006 (PST)

Use-cases for Session Restoration

Corporate environments: "Most have a policy which states that you have to turn off your computer when you leave for the night. Now assuming that not every employee stays at work in the evening until all work is done, I consider it reasonable for the user to expect to be able to start in the morning right where he has left in the evening, although the machine was switched off over the night."

"A second scenario is, that, unfortunately, since even FF is not bug free, one has to restart it occasionally when it starts to behave oddly. This is not a crash, it's a user requested quit, but I expect to start work again at exactly the point where I have left."

consultants/travelers: people who involuntarily shut down the browser many times each day

admins: people who log onto their user account at many other people's boxes, many times during the day, such as IT/helpdesk workers at large organizations

mobile: people who load FF, or their profile, off of a usb key.

Mozilla Testers!: Now that we have auto-updates in testing code, with real Session Restore I can just click 'Restart Now' and always be testing the latest nightly. This is a dream for quality of bug reports. --BillMcGonigle 10:45, 21 Feb 2006 (PST)

Things Not to Do

There are some things you don't want to do when restoring a session, as evidenced by bitter tastes from Session Saver.

Don't re-POST forms. Session Saver will do this. I had 5 duplicate bugzilla bugs once before I realized what was happening. Imagine if I was using a poor shopping cart! --BillMcGonigle 10:54, 21 Feb 2006 (PST)
- If you can trust the maxim 'GET for actions without side effects, POST for actions with side effects' you could simply refuse to do POST on session restore. You can't actually trust that a web developer hasn't just decided to use POST for everything because "long URL's are ugly" but maybe it's the right thing to do anyway. --BillMcGonigle 10:54, 21 Feb 2006 (PST)

Unresolved questions

Do we ever want to store cached copies of the pages (i.e. for offline access) or do we just store the urls and load them all? Loading from cache would be snappier.

Well, there's multiple strategies:
1. Don't load more than <n> pages at a time, giving the focussed tab 1st priority, allowing the user to work, and then giving priority to tabs the user is working on, as one tab loads, start another so there are always <n> tabs loading until it's recovered.
  Advantages - user can work immediately, system is kept under moderate load, restore is probably transparent since any page the user works on is given priority.
2. Load all from cache, then update as visited
  Advantages - with luck the cached version should be what the user saw. But if it is we'll only know it if we reload, if it isn't then its misleading, and in any case since we then probably reload pages anyhow does the user benefit from loading the cached version of pages first?
3. Check latest update times of all pages quickly (a lower bandwidth job), and those that have update times matching the cache entry, assume the cache is up to date, otherwise load from web as per (1).
  Advantages - many pages will be up to date, so this saves reloading pages other than those changed. In theory this, compbined with (1) for loading web pages that do need reloading, should work. But would it?

Foxxen2 09:24, 30 March 2006 (PST)

Make sure that if the state of the current session crashes the browser, it doesn’t reload at startup and crash over and over again. Look into how SessionSaver and Total Recall detect this.

Whats really helpful would be a FF extension and page processing calls log that can be relied upon to note extension calls made (and their successful return) and page render or page processing calls made (and their successful completion). In theory when it crashes, very few extensions or pages will actually have commenced a call but not completed. Those will likely be the problem ones. beyond that its a problem with FF core code, and a safe start or debug session. The core of the problem is having a way to narrow down problematic pages and extensions. Perhaps if it crashes during a restore it offers to switch to a "safe restore" mode (as opposed to "safe mode"), where extensions are loaded one by one, then pages loaded one by one, and the cause of the crash identified and reported for debugging? Ie a fallback mode for restore where the user gets a slower restore, that keeps as many pages and extensions as it can alive. Foxxen2 09:24, 30 March 2006 (PST)

Should form state include saving checkbox and selectbox state as well as text input?

Yes. See above, re text box contents, same applies. Foxxen2 09:24, 30 March 2006 (PST)