Opened 11 years ago

Closed 4 years ago

#722 closed defect (fixed)

Extension should not override nsSessionStore.js

Reported by: yosh Owned by:
Priority: Very Low Milestone:
Component: Applications/Torbutton Version: 1.1
Severity: Keywords:
Cc: yosh, arno, arma, mikeperry, saint Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by saint)

The extension currently replaces nsSessionStore.js with its own copy. This is bad for many reasons:

1) It's currently the FF2 version, even when running on FF3. This breaks both the browser features that depend on functionality only available in FF3's session store, as well as any extension that depends on that functionality.
2) Even if it's synced up with the FF3 version, it's still bad, because if there is a security issue in nsSessionStore.js fixed in a point release for FF3, users of this extension will still be vulnerable until it is resynced in a new release, which could take a while.

Please find another way to do what you want to do without forking the component.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (7)

comment:1 Changed 11 years ago by mikeperry

For other components, Torbutton is able to re-implement certain functions to prevent actions that are
damaging to privacy, such as writing state to disk, and leaking it onto the network at inopportune times.

Unfortunately, the implementation of the SessionStore is such that it does not use its own published IDL
calls internally, so reimplementing them via ContractID has no affect on their (undesirable) ability to
write Tor-loaded tabs to disk and reload them later via non-Tor in the event of a crash.

If you can think of some way to use the existing IDL to prevent disk access during Tor without completely
disabling the session store, and/or breaking ability to undo closed tabs, I'd love to hear it. But it
just looks like the sessionstore component was not designed with extensibility in mind. :(

Adding the FF3 sessionstore implementation and version detection to choose between the FF2 and FF3 component
was something I had scheduled to do before 1.2.0, and it was done in r15413-r15416. I also keep diffs against
the original sessionstore in the repository at:

https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/nsSessionStore2.diff
and
https://tor-svn.freehaven.net/svn/torbutton/trunk/src/components/nsSessionStore3.diff

so it should be easy to keep them up to date.

Please let me know if you have any suggestions, otherwise I'm probably just going to close this as WONTFIX
(though I will file yet another Firefox bug for improving the extensibility of the SessionStore when I do so).

comment:2 Changed 11 years ago by arno

What about totally disabling session store when browsing with tor ?

It could be done by removing observers for global notifications, and adding them back when disabling tor.

comment:3 Changed 11 years ago by mikeperry

You mean reimplementing the sessionstore's observe method? Problem is once it is re-enabled it will save all
tabs, including the ones that have been loaded in Tor... At least that's what it looks like to me from the
code.. There are several timers and events for which it simply saves all state via ultimately
calling _saveWindowHistory().

comment:4 Changed 11 years ago by arno

You mean reimplementing the sessionstore's observe method?

No, I just meant disabling sessionstore while browsing with tor. but:

Problem is once it is re-enabled it will save all
tabs, including the ones that have been loaded in Tor

...

There are several timers and events for which it simply saves all state via ultimately

calling _saveWindowHistory().

Sorry, I had not read nsSessionStore.js carefully enough.

I have another idea. Do you think it is possible and/or useful to:

  • add an attribute to a tab loaded with tor (for example <tab torloaded="true"/>)
  • store that attribute in sessionstore file (using nsISessionStore.persistTabAttribute method)
  • when restoring, firefox will set torloaded attribute before loading url. So, torbutton will known that url must be loaded with tor.

I'f I'm correct, that could fix following problem:

why this setting is recommended is because after a session crash, your browser will be in an undefined Tor state, and can potentially load a bunch of Tor tabs without Tor.

comment:5 Changed 11 years ago by mikeperry

The problem with this approach is Torbutton must run in environments where it is downright
dangerous for Tor state to be written to disk. While this approach may work, we'd still be
stuck including the copies of the session store to be able to prevent disk writes for
dissidents whose lives depend upon their Tor browsing not leaving any traces on their
computer.

This is not just paranoia.. This is our userbase:
http://www.boingboing.net/2008/07/04/iran-death-penalty-f.html

comment:6 Changed 11 years ago by mikeperry

comment:7 Changed 4 years ago by saint

Cc: saint added
Description: modified (diff)
Resolution: Nonefixed
Status: newclosed

This has been fixed upstream by Mozilla, and the calls are now published here: https://developer.mozilla.org/en-US/docs/Observer_Notifications#Session_Store

Note: See TracTickets for help on using tickets.