Unintentional connections by TBB to Google and Yahoo servers
The TorBrowser establishes unintentional connections to the following servers:
fusion.google.com/favicon.ico google.com/favicon.ico add.my.yahoo.com/favicon.ico
It remains mysterious to me why those connections do not occur at each start up of TBB, but periodically.
In fact, TBB should not permit connecting automatically to these data miners and loading items into the cache.
Activity
Trac:
Cc: N/A to g.koppen@jondos.deAdding mikeperry to Cc.
Could these be coming from the OmniBox?
Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, mikeperry
Hrmm.. Unlikely. The Omnibox stores icons in data url format.
Has this been tested on a fresh TBB directory? Note that if the user has created bookmarks, those can cause favicon loads when the bookmarks menu is accessed, if they have not been cached previously.
I'm moving this to my component, because either way it sounds like something in the plumbing of Firefox (or at least user configuration of the plumbing of Firefox), not our build process.
Trac:
Component: Tor bundles/installation to Firefox Patch Issues
Owner: erinn to mikeperry-
Hrmm. I found add.my.yahoo.com and fusion.google.com in ./browser/locales/en-US/chrome/browser-region/region.properties.. Do you also see any fetches for http://add.my.yahoo.com/rss?url= or http://fusion.google.com/add?feedurl=?
Also, if you remove these urls from browser.contentHandlers.types.0.uri and browser.contentHandlers.types.1.uri do the favicon requests stop?
-
Replying to mikeperry:
Also, if you remove these urls from browser.contentHandlers.types.0.uri and browser.contentHandlers.types.1.uri do the favicon requests stop?
(I meant in about:config here).
Replying to mikeperry:
Do you also see any fetches for http://add.my.yahoo.com/rss?url= or http://fusion.google.com/add?feedurl=? No. I have only seen fetches for "/favicon.ico" but not for "/rss?url=" or "/add?feedurl=". Also, if you remove these urls from browser.contentHandlers.types.0.uri and browser.contentHandlers.types.1.uri do the favicon requests stop? I removed these URLs now. But as described above, it is difficult to test because these connections only occur occasionally on start-up. Nevertheless I will focus the network map to check it.
After a while of testing, here is my result:
Up to now, it remains mysterious. After having removed those urls from "browser.contentHandlers.", I did not observe those connections anymore. But with a new and freshly installed TBB, I was able to catch those connections one single time ("browser.contentHandlers." being "activated"). Unfortunately, I am not able to test it systematically.
Have you been succesful in the meantime?
-
To be honest, I have not been watching closely. Do these requests cause cookies to get set or anything like that? I don't see any in my cookie list, and I have not changed this pref, and my browser has been open for about 48 hours or so.
If cookies are set, perhaps we can just merge the pref change if you go a long time without seeing a yahoo cookie (since who uses yahoo anyways?)
I have noticed those connections to Google and Yahoo servers again.
They cause cache entries to get set. The Yahoo cache entries want to be stored for a period of two months.
This has been watched while using a current version of TBB.
So, it seems to be a good solution to remove the urls from "browser.contentHandlers.*".
This is somehow relevant to your TBB issue of add.my.yahoo.com:
Not using Tor. Using Firefox 12 through Comodo Firewall. Firefox about:config has had the "add.my.yahoo.com" entry removed as recommended above. BUT, if Comodo Firewall is set to block "add.my.yahoo.com" then Firefox will not open some web pages e.g. https://www.startpage.com
Comodo Firewall writes to the DNS Cache. The DNS Cache may get flushed by other apps, or the DNS TTL expires, which can make it seem like everything is working ok, but then Comodo Firewall updates the DNS Cache and Firefox is broken again. (This is theory) Also DNS Cache gets very large by Comodo Firewall, which is slow to rebuild & recache, which hinders debugging.
I had to put the "add.my.yahoo.com" into the hosts file as a 0.0.0.0 entry to get around the problem and still block it.
This "add.my.yahoo.com" entry is bug or spyware for Comodo Firewall possibly, or it could be hardcoded into Firefox in spite of the about:config setting.
Trac:
Username: offthewheel-
Find me a violation of https://www.torproject.org/projects/torbrowser/design/#DesignRequirements to elevate this.
Trac:
Priority: normal to trivial -
@mikeperry, aren't the issues in the original ticket a violation of:
2.2.1 Cross-Origin Identifier Unlinkability
2.2.1 Cross-Origin Fingerprinting Unlinkability
Even innocuous requests to major aggregators of personal information like Google and Yahoo could theoretically be used to log information as simple as the time a given client was or was not browsing, and the presence or absence of the results of such requests--when combined with other information collected by those servers--could still be potentially useful in identifying and fingerprinting users.
The arguments for this behavior violating TBB design requirements are indirect, but rooted in the idea that it's not any one piece of information these companies collect that's problematic. It's the totality of information provided or leaked to Google and/or Yahoo that's problematic, and the connections mentioned in this ticket add to that.
Trac:
Username: browserprivacy
Cc: g.koppen@jondos.de, mikeperry to g.koppen@jondos.de, mikeperry, browserprivacy
Priority: trivial to minor Especially on the heels of recent disclosures (e.g. http://www.washingtonpost.com/blogs/the-switch/wp/2013/12/10/nsa-uses-google-cookies-to-pinpoint-targets-for-hacking/), I agree with the previous commenter and would suggest changing this ticket's priority.
Trac:
Priority: minor to majormentioned in issue #19262 (moved)
mentioned in issue tpo/applications/tor-browser#19262 (closed)