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:

1. Session files have timestamp or incremental ID in their filename - "SavedSession03102006054627"
2. 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)
3. 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.
4. 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.
5. 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.
6. 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)

An opposing view

These suggestions seem over-designed, to me. The same logic would apply to any sensitive information stored on your computer. What about email addresses in your mail program? Financial accounting information for your company? By the same logic, all this should be encrypted too.

One problem with encrypting the information is that it's unrecoverable if you forget the password, or if there's a tiny data error through hardware faults that corrupt a bit. Nor can you dive in with a text editor and delete the saved URL that's causing your browser to crash. The session data is a black box, uneditable. On the design side, I argue that it goes against the Unix philosophy of modular easily-connected components. If you want encryption, save it to an encrypted file system, or encrypt the files with PGP or something.

IMHO, the file format for the saved session should be XML or even plain text. The most I'd suggest as far as security would be to avoid storing cookies or form data or passwords. Let the browser request fresh cookies, and the user re-enter their passwords etc., upon reload.

--LukeKendall 10:30, 18 July 2006 (EST)

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)

I'd say this feature is contrary to the privacy settings. I set firefox to clear private data when closing Firefox, yet this code circumvents that - when I restart, browsing history, etc, is there for all the world to see. At very least it should be switchable on/off by a user preferences option.

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)

What about sessions on web servers if you do storing of DOM? If we save URL then going by the link on restoring would probably load a page with notice that session is expired. Saving DOM, one could start putting data into a form, like doing long e-mail message and then during submit find out that the session is expired.

--Sofoz 07:01, 15 July 2006 (PDT)

I'm not sure if expired server sessions should be much of a concern. After all, the expiry would happen if you left the browser open or if you hibernated the OS. Trying to ensure fresh information in session restore case seems trying too hard and wouldn't be very consistent.

--Aapo Laitinen 22:36, 18 July 2006 (PDT)

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)

If there are multiple windows open, how do we decide what was the last session? The last window closed, or the last group of windows?

• If they're all exited together, by quitting from FF, the answer is clearly that all should be saved.
• But I think better would be to have an explicit Save Session and Restore Session function. Then the semantics can simply be to hold the session for auto reload (or prompted reload) after a crash; but normally to require an explicit Restore Session action by the user.

LukeKendall 10:20, 18 July 2006 (EST)

There should be an option to disable 'cookie restore'. I don't like the feeling that after crash or shut down any body can come on pc and login to my gmail and other accounts. Yes I can disable the sessions entirely but this will remove the feature entirely. I like session restoration in Opera but in FireFox it is less secure.

Crash Recovery and Session Manager have good code

Crash Recovery and Session Manager, both developed by zeniko, have good code.

They're both listed under Session_Restore#Relevant_Extensions Relevant Extensions on the Session Restore page.

Crash Recovery only runs when your browser crashes, not on every restart. Session Manager allows the user to restore session on every restart.

It also includes the following features and more:

• Session Management (Saving, Renaming, Deleting, Overriding)
• Session Loading Options
• POSTDATA, cookies, and form data saving
• Reopen Closed Tab / Window
• Restore closed tab / window list on startup

-- Frank (DesertFox) (talk) 21:58, 8 Apr 2006 (CDT)

UI

(moved from front page)

• Prompt for restore upon application start, post-crash.

For reference, this is a screenshot of the similar feature in the Gnome web-browser, Epiphany:

Privacy

[moved from front page]

Are there any privacy issues? Doesn't seem to be, as most (all?) of this information is already stored somewhere already, eg: history, cookies, etc.

There are most certainly privacy issues, just as there are with history, cookies etc. Hence the proliferation of utilities that remove tracking footprints.

Privacy can be an issue. Saving the detailed session includes elements of history, bookmarks. cookies, typed form information, etc.. and all of these have purge functions to erase tracks already implemented. The concept of saving session infos would seem to conflict with the desire for privacy. But need there be such a conflict?

What about encrypting the saved session info, so that the files containing the data are not 'in plain language', readable in notepad. After a crash, perhaps a password would be required to re-open the last known session. Without the password, it opens to about:blank.

Comment from an Ordinary User

There is, in some people's opinion, a serious and potentially dangerous security and privacy risk. This is caused by the fact that if the Cache is stored in RAM (a disk drive created in RAM whose contents 'disappear' when the power is removed), material to restore pages is then saved on conventional hard disk. As at Firefox version 2.0 the last viewed web pages are reproduced perfectly without a connection being re-established with the remote server. This is done when the Cache was on RAM disk and after the computer's power had been turned-off for 12 hours!

Firefox's restore session ability must be loved and admired by Big Brother throughout the world. With anti-virus checkers deliberately ignoring "official" security service bugs and trojans and users becoming more aware of all the data Microsoft and its Internet Explorer saves about them, its probably inevitable that Mozilla, for whatever reason, started saving in secret information about its user's browsing habits!

It is a material consideration that Firefox does not permit ordinary users the ability to turn-off this security and privacy violating feature. If this feature is genuinely for the good of Firefox users, then Firefox ought to allow users to opt out easily and, of course, effectively and permanently. The fact that no such easily available disabling facility exists in Firefox clearly suggests the personal privacy and security of Firefox users was not adequately considered by Firefox's team. Why not?

A Mozilla User, 24 December 2006.

{Another user (wsanders):

Forget about the security and all that, it's an annoying feature since I and probably a bunch of other users normally exit by powering off the computer, exiting X/Gnome/KDE with Ctrl-Alt-Delete, or typing "init 0". All these make Firefox 2 think it has crashed, and annoy with a startup message next time it's launched. One should be able to at least disable this feature in about:config.

never - Never save closed tabs in sessions and delete all closed tabs when the browser is shutdown. Also closed tabs will not be restored from saved sessions that had been saved with closed tabs.

http://sessionmanager.mozdev.org/documentation.html

Understanding the Structure of sessionstore.js file

Hello all,

Sorry to intrude on your work, but I have a question that I just cannot find an authoritative answer on and I'm not sure that this is the appropriate place to ask, but here goes...

I am in law enforcement and currently looking at a fragment of data from unallocated space that *appears* to be in the same format as the a/n file. I need to determine what the nature of the fields are. I have a pretty good idea on most of them, but not all.

For example, let's say this information excerpt:

"... title"Hotmail", cacheKey:0, ID:1291, scroll:"0,0"}], index:1, zoom:1, disallow:"", xultab:""....."

I can see from other pages on this wiki what some of these items do/store, for example scroll stores scroll bar position, but ID, where is the 1291 obtained from? Is this the 1291st browsing instance since the browser was started? I can't tell very well from the source code, but I'm not super fluent in js.

Any help would be GREATLY appreciated. If this isn't the correct location for this, please let me know where I should ask.

--G-man 12:22, 1 May 2008 (PDT)

Have a look at http://forums.mozillazine.org/viewtopic.php?f=38&t=622036&p=10320887#p10320887" The code explains the structure, but only few attributes.

Disable session restore

I don't like the feature of Firefox that it tries to revisit or reload the webpages that caused my browser to crash. ... I desperatly want an option for NO session restore, ever.

Set browser.sessionstore.max_resumed_crashes to 0. Firefox will ask after a crash which windows/tabs to restore. See more Preferences on front page. Hbbb 07:22, 27 October 2009 (UTC)

A possibly better way to secure the data

One way that Firefox could secure the session restore automatically is using a hybrid asymmetric (like RSA, DSA, or ElGamal) and symmetric (like AES, Blowfish, Twofish, 3DES, or Serpent) encryption setup like what SSL, TLS, and PGP use.

All it needs to do is create a asymmetric key pair with a password encrypted "Private Key" the first time Firefox opens and then whenever you load up Firefox it quickly creates a temporary symmetric key which it uses for that session to encrypt the session restore data with and it encrypts the temporary symmetric key with your asymmetric "Public Key". So then if you ever need to restore your session you will need your private key and the password the private keys encrypted with to decrypt the sessions temporary symmetric key.

With asymmetric encryption you have a key pair with 2 keys a "Private Key" and a "Public Key" and you can give everyone your public key and when you encrypt something with someones "Public Key" the only way to decrypt the data is with that persons "Private Key" and the password the private key is encrypted with (technically it is possible to create a "Private Key" that isn't encrypted with a password then all you need is the "Private Key" to decrypt the data)

I'm with LukeKendall. Full Disk Encryption, or OS-level stuff like TrueCrypt, BitLocker and FileVault are the solution to this issue; no need to try and re-solve this problem. {But I'm going to add some of the info from http://www.blogsdna.com/4318/how-to-get-back-firefox-35-session-restore-page.htm and on sessionstore.js, which I think is key. (err, never mind about the latter; http://support.mozilla.com/en-US/kb/Session+Restore is the place for documentation.)} --MrElvey 04:47, 11 June 2010 (UTC)

Oh, and there's browser.sessionstore.resume_from_crash which is a partial fix to this issue for those who feel Firefox itself needs to be more careful with this sensitive/private info. --MrElvey 05:00, 11 June 2010 (UTC)

Panorama Support

How does Session Store support Panorama? I have repeatedly seen all my panorama tabs being cleared away, and there is no way of getting them back by just restarting Firefox.