Thus spake Joe Btfsplk (joebtfsplk@xxxxxxx): > On 1/13/2012 4:10 PM, Mike Perry wrote: > >Thus spake Greg Kalitnikoff (kalitnikoff@xxxxxxxxxxxxxxxx): > > > >>P.S. Also reading https://www.torproject.org/projects/torbrowser/design/ > >>I found this: "Filter-based addons such as AdBlock Plus, Request Policy, > >>Ghostery, Priv3, and Sharemenot are to be avoided." But here > >>https://lists.torproject.org/pipermail/tor-talk/2011-November/022052.html > >>we see Andrew Lewman`s "In my world, I'd replace noscript with > >>requestpolicy". I`m a bit confused :-/ > >There should be no need to use filters to address 3rd party linkability > >with a proper implementation of the requirements in > >https://www.torproject.org/projects/torbrowser/design/#privacy > > > >To my knowledge, the only remaining 3rd party direct linkability risk > >is through HTTP Keepalive (Section 3.5.6), but this linkability is > >limited to a 20 second window. > > > >There is a risk of first party linkability through redirects (Section > >3.5.7). This one will be harder to solve, but it is more noticable > >attack. > > > >There are also fingerprinting risks involving time that need to be > >addressed (3.6.6 and 3.6.7), but the verdict is not in as to exactly > >how much info these provide in practice. Regardless, we should also > >have some level of mitigation in place for Tor Browser 2.3.x. > > > >It is my opinion that these remaining threats do not justify the need > >for filters, and that we should focus on eliminating these few > >remaining issues rather than trying to design a filter mechanism that > >isn't full of fail. > > > I'm unclear. How does Tor ( in TBB) prevent trackers (beacons, web > bugs) from gathering & transmitting data, once these are loaded w/ web > pages? If there something in Tor that prevents these from phoning > home? If so, how? It's been mentioned about the discussion from > https://www.torproject.org/projects/torbrowser/design/#privacy These beacons can record your visit on one site, but they are not able to store identifiers in the browser that would allow them to determine it is the same you when you visit another site. This removes the linkability property that gives 3rd parties omniscience over browsing activity. > Side note - In TBB, the preference "network.http.sendRefererHeader" > comes w/ default setting to send referer header info (I believe that > wasn't always the case). With this default setting, doesn't that allow > websites to identify the site you just came from if you click a link? Yes, I believe that at best, blocking referrers only prevents accidental info leakage. There are too many direct channels between page elements to expect to stop all transmission. In fact, if you look at Google+ +1 buttons, they already encode the referer url directly in the GET request, probably because of the lack of referrers in http->https scheme transmissions. See http://archives.seul.org/or/dev/Jun-2011/msg00105.html, http://archives.seul.org/or/dev/Jul-2011/msg00019.html and the rest of that thread for more detailed discussion. > And haven't I read that all ads aren't necessarily JUST ads? I guess you mean they could be malware? Again, we should persue a general approach of least priviledge and hardening. You face the same risk from exit nodes, after all. I'd love to see Seatbelt, AppArmor, and SELinux policies created for TBB, though. -- Mike Perry Exterminate all dogma. Permit no exceptions.
Attachment:
pgpuCvcfHYWoj.pgp
Description: PGP signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk