Opened 9 years ago

Closed 9 years ago

Last modified 2 years ago

#2428 closed defect (fixed)

nytimes.com login page loads after Torbutton toggled

Reported by: rransom Owned by: mikeperry
Priority: Immediate Milestone:
Component: Applications/Torbutton Version: Torbutton: 1.3.0-alpha
Severity: Normal Keywords:
Cc: Actual Points: 3
Parent ID: Points: 10
Reviewer: Sponsor:

Description

In Firefox 4.0b9 with Torbutton 1.3.1-alpha installed and Tor enabled:

  1. Open a new tab.
  2. Enter http://www.nytimes.com/2011/01/24/world/africa/24tunis.html in the address bar and click the green arrow ('Go') button. The page will not load.
  3. Close the tab.
  4. Toggle Torbutton off.

A nytimes.com login page will appear, containing at least 24tunis in its URL.

Child Tickets

TicketStatusOwnerSummaryComponent
#2490closedpdeUpdate HTTPS-Everywhere's noscriptHTTPS Everywhere/EFF-HTTPS Everywhere

Attachments (2)

rransom-bug2428-http-header-dump-2011-02-03-01.txt.gz (17.5 KB) - added by rransom 9 years ago.
HTTP requests during repro in TBB
https-everywhere-0.9.9.development.3~pre.xpi (188.5 KB) - added by mikeperry 9 years ago.
HTTPS Everywhere with noscript update. Seems to fix the channel issue

Download all attachments as: .zip

Change History (16)

comment:1 Changed 9 years ago by mikeperry

This page does in fact load for me.

How reliably can you reproduce this? It doesn't happen for me at all.

comment:2 in reply to:  1 Changed 9 years ago by rransom

Replying to mikeperry:

This page does in fact load for me.

How reliably can you reproduce this? It doesn't happen for me at all.

The login page appeared every time I tried this in Firefox 4.0b9 before filing the bug report.

I have now tested this again several times:

  1. In Firefox 4.0b9 on 'comet', I closed the tab while Firefox was displaying its gray 'Connecting...' animation, then toggled Torbutton. The login page did not appear.
  2. Same procedure as 1; same result.
  3. In Firefox 4.0b9 on 'comet', I closed the tab while Firefox was displaying its green 'Connecting...' animation, then toggled Torbutton. The login page appeared several minutes later in a new tab.
  4. In Firefox 4.0b10 on 'ceres' (the computer on which I originally observed this bug), I closed the tab while Firefox was displaying its green 'Connecting...' animation, then toggled Torbutton. The login page appeared several minutes later in a new tab, in fact, several minutes after test 5.
  5. In Firefox 4.0b10 on 'ceres', I accidentally toggled Torbutton before closing the tab, while Firefox was displaying its green 'Connecting...' animation; the login page loaded in the tab before I could close it.

'ceres' has the following Firefox extensions installed and enabled:

  • Firebug 1.7X.0a9
  • Greasemonkey 0.9.1
  • HTTPS Everywhere (katmagic's tree branch) 0.9.9.tree.1 (as packaged by EFF)
  • Java Console 6.0.23
  • NoScript 2.0.9.6
  • Torbutton 1.3.1-alpha

Both 'ceres' and 'comet' are running Windows 7.

comment:3 Changed 9 years ago by rransom

Firefox is configured to reject cookies from wt.o.nytimes.com and www.nytimes.com on both 'ceres' and 'comet'.

comment:4 Changed 9 years ago by mikeperry

Points: 10

Reproduce: 3
Fix: 7

comment:5 Changed 9 years ago by mikeperry

rransom: Since you have a semi-custom setup, and you can easily reproduce it, can you set torbutton's extensions.torbutton.loglevel to 2, and its logmethod to 0 and redirect Firefox's stdout for a few repro cases?

Since NYTImes doesn't always display a login page, can you try to also capture either that html, and/or use a request logger like Live HTTP Headers or Tamper Data to see exactly what requests are grabbed and when?

This doesn't seem to reproduce for me, so I'm at a loss. I'm guessing its some form of redirect timer that perhaps lives in a webthread that we don't effectively close after the toggle? Hence I need to see the source/request log for when nytimes does actually decide to even give you a login page.

comment:6 Changed 9 years ago by rransom

On IRC, Mike Perry suggested that I try to reproduce this bug using Firefox 3.6, since the only debugging tool available for Firefox 4.0b9 (Firebug) didn't capture anything. I was able to reproduce the bug using Firefox 3.6.13 in a newly unpacked TBB for Windows 1.3.17 using the following procedure:

  1. If possible, copy the cached-* files from a recently used Tor DataDirectory into 'Tor Browser/Data/Tor'.
  2. Run 'Start Tor Browser.exe'.
  3. When Firefox appears and has finished loading the 'Firefox Updated' and 'Are you using Tor?' pages, press Ctrl-T to open a new tab.
  4. Click 'Tools', then 'Options...', then 'Privacy'; click 'Accept cookies from sites' to uncheck it. Click 'OK'.
  5. Right-click on 'Tor Enabled' in the status bar, then click 'Preferences...'; click 'Disable Button and Hotkeys to prevent accidental toggle' to uncheck it. Click 'OK'.
  6. Click 'View the Network' in the 'Vidalia Control Panel'.
  7. Paste "http://www.nytimes.com/2011/01/24/world/africa/24tunis.html" into the Firefox address bar. Click on the right arrow to start loading the page.
  8. After the progress bar in Firefox's status bar becomes about half-full, click 'Tor Enabled' to toggle Torbutton off. Firefox will continue to access subdomains of nytimes.com, but not through Tor. Eventually, a New York Times login page will appear.

Changed 9 years ago by rransom

HTTP requests during repro in TBB

comment:7 Changed 9 years ago by rransom

I have attached a log (captured using 'Live HTTP Headers') of the HTTP requests that occurred while reproducing this bug in TBB for Windows 1.3.17. The 'Error Console' overflowed, and I don't think Firefox's stdout/stderr can be captured on Windows, so capturing Torbutton's log messages will require either modifying Torbutton or installing and using a capture-Firefox-log-messages-to-disk extension.

comment:8 Changed 9 years ago by mikeperry

Hah. This is definitely a conflict with https-everywhere. It is possibly due to the synthetic channel replacement redirect that we do there that is allowing NYT to escape Torbutton's window stop events and content policy checks.

comment:9 Changed 9 years ago by mikeperry

It looks like the tab's tor tag is being reset while a request is making it through HTTPS-Everywhere's redirect, because we are getting proper http observer notifications in torbutton, we just are not trying to block them.

We are not getting content policy notifications, however.. So it may be an issue with how we check these requests in our http observer.. We obtain the channel in that handler. It may be the wrong channel to cancel?

Changed 9 years ago by mikeperry

HTTPS Everywhere with noscript update. Seems to fix the channel issue

comment:10 Changed 9 years ago by mikeperry

rransom: Can you try this xpi to see if you still experience the issue? I could not get it to happen in my test setup that was reproducing the issue before I installed it.

comment:11 in reply to:  10 Changed 9 years ago by rransom

Replying to mikeperry:

rransom: Can you try this xpi to see if you still experience the issue? I could not get it to happen in my test setup that was reproducing the issue before I installed it.

That XPI seems to have fixed this bug.

comment:12 Changed 9 years ago by rransom

Resolution: fixed
Status: newclosed

I just tested this again with HTTPS Everywhere 0.9.9.development.3 (as released 2011-02-06), and this bug is definitely fixed.

comment:13 Changed 9 years ago by mikeperry

Actual Points: 3
actualpointsdone: 3
pointsdone: 10

comment:14 Changed 2 years ago by teor

Severity: Normal

Set all tickets without a severity to "Normal"

Note: See TracTickets for help on using tickets.