Opened 13 years ago

#460 closed defect (Fixed)

Date hooks fail for meta-refresh?

Reported by: mikeperry Owned by:
Priority: High Milestone:
Component: Applications/Torbutton Version: 1.1
Severity: Keywords:
Cc: mikeperry Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


It is possible that some meta-refresh based logins are able to cause the date hooking code to
believe that the hooks ran where as in fact they did not. This seemed to happen on one login
to my google summer of code mentor account, which sets the TZ cookie to the number of minutes
you are offset from UTC.

The problem is this is very difficult to reproduce. It is likely not just a meta-refresh login,
but also a race condition that depends on the speed at which the meta-refresh reloads the page..

I will be adding some code to double check both directions of date hooks for all LocationChange
progress events to detect this bug and at least alert the user somehow if its occurence is detected.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (4)

comment:1 Changed 13 years ago by mikeperry

So I'm getting a ton of false positives with the code I put in to 1.1.5: txt files, non-html files,
stuff loaded during non-tor and then a switch to Tor.

However, this site looks like it may be doing something with live bookmarks/xml RSS feed. The browser seems
to be rendering the XML as html.. I wonder if such pages can also run javascript.. it would appear not,
because the hooks did not apply, but worth investigating further:

comment:2 Changed 13 years ago by mikeperry

There appears to be an actual Firefox race condition relating to properties of the window object
bleeding over between tabs if they are loaded in parallel. In some cases variables are cleared
when they shouldn't be, in some cases they persist between loads, and in some they appear
to bleed from tab to tab.

If what I suspect is true, this is a Firefox security bug independent of Torbutton. I will
investigate further and then file a bug with them as needed.

comment:3 Changed 13 years ago by mikeperry

Potential fix in r11472. Turned out that inserting the div did not actually
evaluate the js until later, causing the race. Using evalInSandbox seems to block
until the script has fully ran, which should eliminate the race condition.

Firefox is of course innocent of all wrongdoing.

comment:4 Changed 13 years ago by mikeperry

flyspray2trac: bug closed.
Should be finally fixed in r12406 for 1.1.10. Needs some extensive independent testing though. If only there were a 'Verified' stage..

Note: See TracTickets for help on using tickets.