30
edits
Talk:Session Restore: Difference between revisions
→Security of saved data
FrederikVds (talk | contribs) m (Forgot to put signature) |
|||
| Line 9: | Line 9: | ||
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? | 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? | ||
:[[User:Kroc|Kroc]] 01:32, 9 Feb 2006 (PST) | :[[User:Kroc|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 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, 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. [[User:Foxxen2|Foxxen2]] 08:57, 30 March 2006 (PST) | |||
== Restoring after voluntary exit not optional == | == Restoring after voluntary exit not optional == | ||