[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #16620 [Tor Browser]: Transform window.name handling into Firefox patch

#16620: Transform window.name handling into Firefox patch
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:  mcs
     Type:  defect                               |         Status:
 Priority:  Medium                               |  assigned
Component:  Tor Browser                          |      Milestone:
 Severity:  Normal                               |        Version:
 Keywords:  tbb-torbutton-conversion,            |     Resolution:
  TorBrowserTeam201510                           |  Actual Points:
Parent ID:                                       |         Points:
  Sponsor:  SponsorU                             |
-------------------------------------------------+-------------------------

Comment (by arthuredelstein):

 Replying to [comment:6 gk]:
 > Replying to [comment:5 arthuredelstein]:
 > > As an experiment, I browsed to https://www.torproject.org, opened the
 page's JS console and entered `window.name = "test"`. Then I navigated to
 https://trac.torproject.org. I noticed that `window.name` was reset to an
 empty string. This behavior is different from our isolation policy for
 caches, DOM storage, favicons, etc, where we isolate by base domain. Might
 we want to use ThirdPartyUtil::GetBaseDomain instead of
 CheckSameOriginURI, so that www.torproject.org and trac.torproject.org are
 allowed to share data via `window.name`?
 >
 > Not sure what "navigated" in this context means. Are you saying the
 patch behaves differently than specified in 4.5.12 of our design document?

 Now I've read 4.5.12. :) I tried some more experiments, each of which I
 started by going to `https://www.torproject.org` and entering `window.name
 = "test";` in the content page JS console, then browsing to either
 `https://trac.torproject.org` (trac) or
 `https://www.internetdefenseleague.org` (idl), either by entering the
 latter address in the URL bar or clicking on the "Tor Wiki" link. Here are
 the results:

 || ||=Browser=||Target||=Method=||="Referer" in header=||`window.name`||
 || 1.||Firefox 41.0.2||trac||Clicked
 link||`"https://www.torproject.org/"`||Retained||
 || 2.||Firefox 41.0.2||trac||Entered in URL bar||None||Retained||
 || 3.||Firefox 41.0.2||idl||Clicked
 link||`"https://www.torproject.org/"`||Retained||
 || 4.||Firefox 41.0.2||idl||Entered in URL bar||None||Retained||
 || 5.||Chrome 43.0||trac||Clicked
 link||`"https://www.torproject.org/"`||Retained||
 || 6.||Chrome 43.0||trac||Entered in URL bar||None||Retained||
 || 7.||Chrome 43.0||idl||Clicked
 link||`"https://www.torproject.org/"`||Retained||
 || 8.||Chrome 43.0||idl||Entered in URL bar||None||Set to empty||
 || 9.||Tor Browser 5.0.3||trac||Clicked
 link||`"https://www.torproject.org/"`||Retained||
 || 10.||Tor Browser 5.0.3||trac||Entered in URL bar||None||Set to empty||
 || 11.||Tor Browser 5.0.3||idl||Clicked
 link||`"https://www.torproject.org/"`||Retained||
 || 12.||Tor Browser 5.0.3||idl||Entered in URL bar||None||Set to empty||
 || 13.||Patch in comment:3||trac||Clicked
 link||`"https://www.torproject.org/"`||Set to empty||
 || 14.||Patch in comment:3||trac||Entered in URL bar||None||Set to empty||
 || 15.||Patch in comment:3||idl||Clicked
 link||`"https://www.torproject.org/"`||Set to empty||
 || 16.||Patch in comment:3||idl||Entered in URL bar||None||Set to empty||

 If we reset window.name when the Referer is blank, as in section 4.5.12
 and TBB 5.0.3, we are differing from the behavior of vanilla Firefox and
 Chrome in (2, 4 and 6). If we isolate by first party base domain (like DOM
 storage and caching), then our behavior would be different from (3, 4 and
 7).

 I guess it's not entirely clear to me what the best choice is. Chrome's
 behavior seems possibly the least disruptive choice. It pains me that
 content can observe what third-party links a user clicks on and can send
 data to the third-party site, but as explained in the Tor Browser Design
 document, there are ways besides window.name to pass on that information
 via a link click.

 On the other hand, as Mark and Kathy point out, what Mozilla is willing to
 accept is a big consideration.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16620#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs